MCP Security

What is MCP Security?

Model Context Protocol security is the set of controls that protects hosts, clients, servers, tools, authorization flows, and downstream resources. It includes consent, token audience validation, least-privilege scopes, tool authorization, input validation, isolation, and audit.

Why it matters

Model Context Protocol can connect model-controlled tool calls to files, APIs, and other systems. A weak boundary can expose credentials, accept a token for the wrong service, or let one tool reach unrelated resources.

How it works

1. Authenticate remote requests and bind each access token to its intended server.
2. Validate and authorize each tool call and its inputs at the server or enforcement point.
3. Minimize tools and scopes, isolate risky execution, require confirmation for sensitive actions, and log results.

Example

An internal repository server requires user authentication, permits read tools for developers, denies administrator tools, and uses a separate per-user OAuth connection for the upstream repository.

Pomerium boundary

Pomerium can protect Streamable HTTP Model Context Protocol servers as a gateway, manage documented upstream OAuth patterns, and apply identity and tool policy. Pomerium logs authorization decisions, and operators can add Model Context Protocol fields for the method, tool name, and parameters.

Limits and non-claims

• Model Context Protocol authorization is optional and applies to HTTP transport. Local stdio uses a different credential and process model.
• A gateway does not secure the model runtime or unsafe code inside a tool.
• OAuth proves token properties and granted scope, not that a requested action is safe or correct.
• Pomerium protects Model Context Protocol servers that use Streamable HTTP through a Pomerium route. The mcp_tool criterion applies only to tools/call. Logged tool parameters are configurable and can contain sensitive data.

Evaluation checklist

• Check that every token is issued for the MCP server as its audience. Reject token passthrough to downstream APIs.
• For an MCP proxy, require consent for each user and client before a third-party authorization flow. Bind the consent record to that client to prevent confused-deputy attacks.
• Test every OAuth metadata fetch for server-side request forgery (SSRF), including redirects, DNS changes, private addresses, and cloud metadata endpoints.
• Use random state handles and bind each handle on the server to the authenticated user. Do not treat handle possession as authentication.
• Before a client starts a local MCP server, show the exact command and require user consent. Run the server in a sandbox with minimal file, network, and system access.