How WordPress sites should handle WebMCP's security gaps

Our companion piece walked through what the WebMCP spec's own security section names as risk and what it leaves as an open question. This one is narrower and more opinionated: given a typical WordPress site — comments, a checkout, user accounts, maybe a forum plugin — what should actually be built, in order?

1. Risk-tier every tool before you register it

Not every WebMCP tool carries the same risk, and treating them as if they do is the single most common mistake we'd expect to see. A tool that reads a published post's title is not the same category of thing as a tool that submits a checkout, deletes a comment, or changes account email. Before a tool is ever registered, it needs a declared tier — read-only, or consequential — and that tier has to be a real property in code, not a naming convention someone will eventually forget to follow. This maps directly onto the spec's own Consequential Annotation concept: use it, don't reinvent it.

2. Every consequential tool needs a human on the other side of it

This is the practical answer to the spec's "misrepresentation of intent" risk. A tool that finalizes a purchase, publishes content, or changes a password should never execute purely on an agent's say-so — it should land in a real approval step a logged-in human actually sees and confirms, with enough detail to know what they're approving (not just "confirm?", but the actual order total, the actual comment being posted, the actual field being changed). A confirm() dialog is not an approval gate. An approval gate is a queue with an identity behind it.

3. Treat your own comment section like untrusted input — because it is

The spec is explicit that output injection includes "untrusted user-generated content on social media platforms, forums, review sites" — which is most of what a WordPress comment thread, product review, or bbPress forum actually is. Any tool whose return value can include content someone else typed needs the spec's Untrusted Annotation applied to that output, every time, with no exceptions for "trusted" commenters. The moment a site special-cases a user as safe, that's the account an attacker targets first.

4. Scope tool parameters to the one authenticated user, not the whole dataset

The spec's over-parameterization risk shows up concretely in anything shaped like search or filter: a search_orders or list_customers tool should never accept an unbounded free-text filter that can enumerate across a whole store's records. Scope every parameter to what the currently authenticated user is actually allowed to see, and reject the temptation to make a tool more "flexible" than the UI it's replacing — a flexible tool is a wider hole.

5. Don't trust a plugin's tool description any more than you'd trust its output

Tool poisoning targets metadata — the name, description, and parameter descriptions an agent reads as context. On a WordPress site that's often a third-party plugin's responsibility, not the site owner's, which makes it easy to assume someone else already checked it. Review registered tool descriptions the same way you'd review a plugin's PHP before activating it, and be especially wary of any plugin that lets its own tool descriptions be edited from user-submitted content.

6. Default cross-origin exposure to nothing

Multisite installs and staging subdomains are exactly where same-origin assumptions quietly break. Unless a tool has an explicit, reviewed reason to be reachable from another origin, leave exposedTo unset and let the spec's same-origin default do its job.

Where this fits the bigger picture

This is, concretely, what our Agent-Ready Score methodology means by approval_gate_configured: not "does a popup exist," but "does every exposed tool have a declared risk tier, with a real human-approval gate actually reachable." It's also why Safety & Trust can't be checked externally the way Discoverability or Content markup can — it requires the tool-exposure layer to genuinely exist on the site, gating real consequential actions, not just a claim in a privacy policy.

Building that tool-exposure-and-approval layer for WordPress specifically is a bigger job than any one article — it's the whole reason Agent Builder exists as a plugin rather than a checklist. But the six practices above apply regardless of what implements them: they're read directly off the spec's own named risks, not off any one product's feature list.

Primary sources

• webmachinelearning.github.io/webmcp/#security-privacy — the spec's Security and Privacy Considerations section
• github.com/webmachinelearning/webmcp — spec source and open issues
• developer.chrome.com/docs/ai/webmcp/secure-tools — Chrome's implementation-level security guidance