WebMCP Security
Before writing code
Fetch live docs:
- Fetch
https://webmachinelearning.github.io/webmcp/for security-related sections of the specification - Web-search
webmcp security privacy permission modelfor security architecture details - Web-search
site:github.com mcp-b securityfor polyfill security guidelines - Web-search
webmcp fingerprinting data minimizationfor privacy best practices
Conceptual Architecture
Permission-First Design
WebMCP's security model is permission-first:
- The site defines what tools exist (tool registration)
- The browser mediates — prompts the user before allowing agent invocation
- The user grants or denies permission per tool or per session
- Annotations (
destructiveHint,readOnlyHint) inform browser permission decisions - Tools execute within the page's secure context (same-origin, HTTPS required)
Threat Model
| Threat | Description | Mitigation |
|---|---|---|
| Deceptive tool descriptions | Tool named "addToCart" actually charges the user | Honest descriptions; browser/audit verification |
| Agent hallucination | Agent calls wrong tool or passes bad parameters | Schema validation; user confirmation for high-risk tools |
| Over-parameterization | Tool requests excessive personal data from agent | Data minimization; server-side session lookups |
| Fingerprinting | Tool parameters reveal user attributes | Minimal input schemas; avoid asking for identity data |
| Rapid automation abuse | Agent makes rapid repeated transactions | Server-side rate limiting; CAPTCHA for bulk operations |
| Cross-origin data leak | Tool exposes data from another origin | Same-origin enforcement; browser sandboxing |
| Session hijacking | Tool's session exploited by malicious agent | Standard CSRF protection; secure cookie flags |
| Prompt injection | Malicious content in tool results manipulates agent | Output sanitization; structured JSON responses |
Honest Descriptions
Tool descriptions are a critical security surface:
- Agents rely on descriptions to decide which tools to use
- A malicious site could expose
addToCartthat actually callsplaceOrder - Descriptions MUST accurately reflect what the tool does
- Include side effects: "Adds item to cart AND applies default shipping"
- Include limitations: "Only works for in-stock items"
Data Minimization
Minimize the data tools request from agents:
Bad — over-parameterized:
// DON'T: asking agent to supply user's personal data
inputSchema: {
properties: {
userId: { type: "string" },
email: { type: "string" },
shippingAddress: { type: "object" },
creditCardLast4: { type: "string" }
}
}
Good — minimal, server-side lookup:
// DO: only take what's needed, look up user data server-side
inputSchema: {
properties: {
productId: { type: "string" },
quantity: { type: "integer" }
}
}
// execute callback uses session cookies to identify the user server-side
Input Validation
Always validate tool input:
- JSON Schema validation happens at the browser level before
executeis called - Add server-side validation in your API endpoints — don't trust client-side schema alone
- Sanitize string inputs to prevent XSS or injection attacks
- Validate IDs against actual database records
- Reject unexpected fields or overly long values
Rate Limiting
Protect against agent abuse:
- Implement server-side rate limits on APIs called by tools
- Limit transactions per session (e.g., max 5 orders per hour)
- Use CAPTCHA or user interaction for bulk operations
- Monitor for anomalous patterns (rapid-fire tool calls)
Audit Logging
Log all agent interactions:
- Tool name, input parameters (sanitized), timestamp
- User session identity
- Whether user interaction was requested and the user's response
- Tool result status (success, failure, canceled)
- Agent identifier if available
Liability Considerations
- If an agent mistakenly places an order, who is responsible?
- WebMCP's human-in-the-loop design and confirmation prompts help
- Always require
requestUserInteractionfor financial actions - Log user approvals as evidence of consent
- Consider displaying pending agent actions as reversible/draft before committing
Best Practices Checklist
- All tool descriptions accurately match behavior
- No sensitive data in input schemas (no passwords, SSNs, full card numbers)
-
destructiveHintset on all financial/irreversible tools -
requestUserInteractionused for purchases, deletions, and account changes - Server-side input validation on all API endpoints
- Rate limiting on APIs called by tools
- Audit logging for all tool invocations
- CSRF tokens included in POST requests
- Sensitive tools only registered for authenticated users
-
clearContext()called on logout
Fetch the specification for the latest security requirements, permission model details, and browser enforcement behavior before auditing.