The WebMCP security model, and the parts that are still open

The security story starts well. Tools run inside the page with the visitor's existing browser session, so nothing new is issued, nothing is stored in a model's context, and revocation is logging out. Compared with generating an API key and pasting it into an assistant's configuration, that is a real improvement in posture rather than a rhetorical one.

What the platform gives you

• Secure context only. The interface is exposed on Window under [SecureContext] — no HTTPS, no tools.
• Origin isolation. Tools are visible to same-origin documents unless you list other origins in exposedTo.
• Permissions policy. The tools feature defaults to an allowlist of ['self']; a cross-origin iframe needs an explicit allow="tools" and throws NotAllowedError otherwise.
• Same-origin credentials. Handlers fetch with credentials: "same-origin", so the session travels and the token never does.

What it does not give you

The specification acknowledges a lethal trifecta: an agent that can read private data, process untrusted content and send information outward can be induced to chain those three into an exfiltration. Every one of those capabilities is individually reasonable. The combination is the problem, and it is not one a page can solve alone.

Prompt injection reaches further here

An agent reading a page treats what it finds as information. If your page renders content other people wrote — reviews, comments, listings, uploaded documents, support threads — then an instruction hidden in that content arrives in the same channel as your own tool descriptions.

This is why untrustedContentHint exists: it marks a tool whose return value contains material you did not author, so the agent can downgrade its trust in what comes back. Set it on every tool that surfaces user-generated content. It is the cheapest thing on this page and it is routinely skipped.

Read-only first is a strategy, not a compromise

The instinct in a regulated business is to refuse the whole category. The better move is to ship the read half, which carries most of the customer value and almost none of the risk.

const readOnly = { readOnlyHint: true };

register("find_my_policy",          "List the policies on this account.",              readOnly);
register("explain_coverage",        "Explain whether a scenario is covered.",          readOnly);
register("get_claim_status",        "Return the status and next step for a claim.",    readOnly);
register("list_required_documents", "List documents needed for a claim type.",         readOnly);
register("locate_form",             "Return the URL of the correct form for a topic.", readOnly);

// Anything that writes stops for a human first.
register("prefill_claim_draft",
  "Prepare a claim draft for the user to review. Does not submit.",
  { readOnlyHint: false });

Five tools, no write path, and a customer can ask their own assistant what their policy covers instead of navigating a portal. The draft tool prepares and stops; submission stays a deliberate human act in your UI.

Confirmation before consequential actions

The API is described as offering a way for a tool to pause execution and request explicit user interaction before continuing. Use it for anything that spends money, cancels something, sends a message on the user's behalf or cannot be undone.

A review checklist

1. Every read tool carries readOnlyHint: true.
2. Every tool returning user-generated content carries untrustedContentHint: true.
3. Server-side authorisation is enforced independently of any annotation.
4. No tool accepts a raw identifier the caller could enumerate — scope to the session instead.
5. Anything consequential stops for explicit human confirmation in your UI.
6. Tool descriptions contain no secrets, internal hostnames or ticket references.
7. Rate limits apply per session, and return Retry-After so an agent can back off rather than hammer.
8. Cross-origin iframes are given allow="tools" deliberately, not by default.

Bring that list to the security review rather than waiting to be asked. In our experience the objection in a regulated environment is never this is unsafe — it is nobody has told us what this is. A read-only surface with an explicit threat model gets approved; a request to enable an experimental browser API does not.