A practical security and privacy review for WebMCP tools
Review WebMCP as another path into existing application behavior, with explicit attention to session privilege, misleading intent, excess data, and untrusted content.
The short version: WebMCP security is defense in depth across contract, browser, application, server, agent, and evaluation layers.
Threat-model the session and every exposed action
A browser agent may operate inside an authenticated session and carry context from other sites. List the assets available to the page, the irreversible effects each tool can trigger, and the parties whose content can influence metadata, inputs, or outputs. Treat the agent as a capable caller, not as a trusted employee.
Review the tool boundary alongside the existing UI and API boundary. WebMCP does not create permission merely because a handler can reach an application function.
Make mutations and irreversible effects unambiguous
Separate read and write tools. Use names and descriptions that disclose the effect, preserve confirmation for purchases or destructive changes, and prefer idempotency keys where retries can duplicate work. Do not bundle discovery and finalization into one surprising operation.
Minimize and bound every parameter
Only request information required for the stated action. Reuse trusted session identity instead of asking the model to restate personal data. Bound free text, arrays, and numeric ranges. Reject unknown properties. Data minimization reduces both accidental disclosure and the personalization-to-fingerprinting path described in the draft risk analysis.
Treat metadata and returned content as potential attack surfaces
Keep descriptions static and concise. Never interpolate user or remote content into tool metadata. Returned text from catalogs, messages, documents, or the open web may contain instructions aimed at the agent; label it untrusted when appropriate and keep it separate from control fields.
Annotations are signals for downstream policy, not sanitizers. The application still needs safe rendering, output limits, and a deliberate distinction between data and instructions.
Reuse trusted controls and verify the result
Enforce authorization and business rules on the server or another trusted layer, validate CSRF and origin assumptions appropriate to the application, use secure contexts, and review any cross-origin exposure. Log high-risk actions with actor, target, contract version, and outcome without logging secrets.
Finish with adversarial evaluations: misleading descriptions, injected output text, cross-tenant identifiers, repeated mutations, route changes during execution, and attempts to bypass confirmation. No single check proves safety.
Primary references
Read the sources
Put it to work
Use the guide on a real product surface.