WebMCP security checklist: safer bookings, purchases, and account actions

1. Use a three-layer security model

A secure agent action has three separate decisions:

WebMCP improves the first layer. It does not automatically provide the second or third. A tool that says “book appointment” may still receive an expired session, an account ID belonging to another user, or a duplicate retry. Your existing application controls must remain the source of truth.

Write down what the tool can read, what it can change, and what the user must approve. The distinction is valuable even if you later decide not to use WebMCP.

2. Choose a small, explicit tool strategy

Chrome’s WebMCP guidance recommends planning a tool strategy before implementation, giving each tool a single purpose, reducing overlap, and registering tools when they are useful for the current page state. WebMCP best practices.

For a scheduling product, “find available times” and “book a time” are different risk levels. Keep them separate. A read tool can return options; a write tool should receive the selected slot, the authenticated account context, and the idempotency key generated for that attempt.

Describe the tool in language that says exactly what it does and when it is useful. Avoid a catch-all “manage booking” tool that asks an agent to infer whether it is searching, editing, cancelling, or committing. Narrow contracts are easier to review, log, and revoke.

Use typed inputs where they clarify intent, but validate every value in code. A schema helps an agent form a request; it is not a security check.

3. Enforce authorization on the server

Every tool call should pass through the same authorization policy as an equivalent human request. Check the authenticated principal, resource ownership, allowed operation, current state, and business rules on the server. Never trust a hidden field, a browser-only flag, or an agent-generated account ID.

For a purchase, verify the cart and price server-side at commit time. For an appointment, verify that the slot is still available and belongs to the requested service. For an account action, require a session with the right role and record the actor and reason.

Return errors that help a legitimate agent recover without exposing private data. “This slot is no longer available; choose another slot” is useful. Dumping an internal stack trace, account list, or authorization rule is not.

Rate limits, CSRF protection where relevant, replay protection, and fraud controls remain necessary. WebMCP changes how a request may be initiated; it does not remove web security fundamentals.

4. Understand what security hints can and cannot do

Chrome’s current WebMCP security guidance describes annotation hints for tools:

• readOnlyHint can identify a tool that does not change state.
• consequentialHint can identify a high-stakes or irreversible action so an agent or browser can request confirmation.
• untrustedContentHint can flag user-generated or externally sourced data returned by a tool.

These hints communicate risk to the agent and browser. They do not grant permission, validate inputs, prove that a user approved a charge, or stop a malicious caller that bypasses the browser. Chrome’s WebMCP tool-security guidance also discusses prompt injection and careful origin exposure.

Use the hints consistently with the real behavior. A tool that sometimes sends an email is not read-only because most calls only preview it. If a tool changes state, model it as a write and make its confirmation and server audit path explicit.

5. Treat page content and tool output as untrusted

Agents read the page while they plan. A product description, review, uploaded document, or third-party integration can contain text that tries to redirect the agent. Chrome’s security explainer describes this as indirect prompt injection: malicious instructions can be included in content the model is processing.

Keep untrusted content separate from control instructions in your application. Label tool results that contain user-generated text. Do not build a tool that turns arbitrary page text into an executable command, URL, recipient, or amount without validation and a user-visible review.

For a checkout tool, calculate totals from server-side cart data. For a support tool, treat the customer’s message as content to summarize, not as authorization to change an account. For a booking tool, accept a structured slot ID and verify it; do not parse an arbitrary sentence at commit time.

Test hostile strings in product descriptions, form fields, and tool results. The desired behavior is not that the model “wins” every prompt-injection contest. The desired behavior is that a malicious string cannot bypass your authorization and validation layers.

6. Control cross-origin exposure

Keep tools private to the page and origin unless you have a clear reason to share them. Chrome’s security documentation notes that tools are not observable by other websites or cross-origin iframes by default, and that an explicit exposedTo list can grant access to trusted origins. Origin exposure guidance.

Review each origin as if it could invoke the tool with a user’s authority. A read-only tool can still reveal private favorites, prices, or account data. A read/write tool can act on behalf of the user. Share only with origins you trust for that exact data and operation.

Prefer same-origin tools for an initial pilot. If an integration needs cross-origin access, document the data shared, the allowed operations, the embedding relationship, and the revocation process. Test a disallowed origin and a compromised or missing session.

7. Design confirmation and consent around the commitment

Confirmation should appear immediately before the irreversible step, with the object, amount, recipient, timing, and important conditions visible. “Continue” is weak confirmation for a €2,000 purchase. “Book the 14:00 appointment for Alex on 18 September” gives a person something concrete to review.

Do not let the agent infer consent from an earlier research request. Keep preparation and commit operations separate. If the user changes a value after review, require confirmation again.

Consent for data processing has its own requirements. A tool’s confirmation is not automatically consent for marketing, recording, or a new data use. Present the relevant choice in the product and store the decision with the request.

For a detailed browser test of this boundary, follow the demo-form testing guide. It includes a prepare-versus-submit contract and checks the sandbox result.

8. Make writes safe when the network is uncertain

An agent may retry after a timeout because it cannot tell whether the server committed the action. Design write operations for that reality. Accept an idempotency key, bind it to the authenticated user and intended operation, and return the original result for a safe repeat.

Do not rely on the agent to invent a stable key. Generate it in the client or server for the attempt and carry it through the request. Reject a reused key when its payload differs from the original payload.

Record a durable operation status such as prepared, authorized, committed, or rejected. Return a request or operation ID so the agent can query the result instead of submitting again.

Test the uncertain cases: timeout after commit, timeout before commit, duplicate click, browser refresh, and a retry with changed price or recipient. A single final state should be visible to both the user and your support team.

9. Test tools with evidence, not assumptions

WebMCP is evolving and browser support can change. Chrome describes the APIs as an early preview and recommends testing and debugging tools rather than assuming that a declaration means an action works. Chrome’s WebMCP early-preview overview.

Test in a sandbox with fake users, fake money, and isolated integrations. Keep the tool version, browser, page state, account role, and consent state in the test record.

Use our WebMCP tool-testing guide to separate registration, execution, agent selection, and final-state checks before applying this security matrix.

Run a read-only task first, then a prepared write, then an explicitly authorized commit. If a test fails, fix the first layer that diverged and repeat the same scenario. Do not “prove” safety by running one happy-path demo.

Printable WebMCP security checklist

• We defined one task, one tool purpose, and one expected result.
• Every read and write is authorized on the server for the current user and resource.
• Tool hints match real behavior; hints are not treated as access control.
• Untrusted page, user, and integration content is labeled and validated as data.
• Cross-origin exposure is absent or restricted to documented, trusted origins.
• Consequential actions show the exact object and require explicit confirmation.
• Writes carry idempotency and return an operation ID for uncertain retries.
• Errors are recoverable without exposing secrets or private account data.
• Sandbox tests cover unauthorized calls, injection, origin restrictions, and timeouts.
• We keep a trace, server result, version, and retest date for each important journey.

Once the controls pass, revisit the main readiness guide to check discovery and content. The robots.txt and llms.txt comparison explains why crawler policy cannot replace tool security.