MCP security and authorization

MCP transport authorization establishes access to a protected resource. Securing an agent’s effect also requires per-tool, per-argument decisions and a real enforcement boundary.

Start with the distinction

From recognition to a bounded effect.

A technical field guide to server and client trust, tool decisions, and downstream effects. The references below each own a different question, from the source of permission to the decision at the action boundary. Use them as a map for an architecture review, then test the model against a real task and its downstream execution path.

Start with a decision

Which MCP boundary is being secured?

HTTP transport authorization proves a client can address a protected MCP resource. Tool visibility and a valid token do not establish permission for the business effect of a tools/call. The server and downstream executor need separate checks.

Architecture review: For one tool, test a wrong-resource token, a valid token with an out-of-scope target, and direct downstream API access. These are distinct tests, not one generic MCP allowlist.

01 / Transport and tokens

Transport and tokens

Begin with the principal, purpose and operation before discussing tools.

MCP authentication and its limitsIdentify the caller to a remote MCP server without mistaking that for tool permission.MCP token audience validationReject access tokens intended for another protected resource.mcp security authorization guideRead the authority model and related guidance.
02 / Tool execution

Tool execution

Follow the grant and policy into the protected execution path.

MCP tool authorizationDecide whether this caller may invoke this tool with these arguments now.MCP tool discovery versus authoritySeeing a tool is not permission to cause its effect.MCP gateway securityUnderstand what a gateway can inspect, enforce and miss.
03 / Trust and threats

Trust and threats

Review failure, revocation and the evidence left after execution.

MCP threat model for consequential tool actionsMap MCP client, server, token, tool metadata and downstream execution trust boundaries before an agent can cause an effect.MCP server securityProtect the server as a privileged intermediary between agents and real systems.MCP tool poisoning and action boundariesTreat tool metadata as untrusted instructions, not as authority.Confused deputy attacks on AI agentsStop a lower-trust requester from borrowing an agent’s stronger authority.

Further technical references

Follow a specific boundary.

MCP client securityA client decides which servers to contact and which server-provided content enters the agent context.MCP protected resource metadataA remote MCP client discovers the authorization server for the particular protected MCP resource through resource metadata.MCP resource indicatorsThe OAuth resource parameter tells the authorization server which MCP server the client intends to access.MCP token passthrough riskA token issued for an MCP server must not be forwarded as if it also authorizes a downstream API.MCP credential securityClient and server credentials need distinct storage, audience and lifecycle controls.MCP server trustTrusting an MCP server means assessing its operator, code provenance, downstream privileges and data handling.MCP tool trustA tool definition is an interface description supplied by a server, not proof of safe behavior or authority.MCP tool allowlistingAn allowlist limits which tools an agent may invoke but does not decide whether one allowed call is authorized.MCP policy enforcementA tool-call policy check must bind the caller, task, tool name and arguments to an enforceable result.MCP revocation and active workRevoking an OAuth grant or task authorization must affect future tool effects, including paused work.Local versus remote MCP transportLocal process transport and remote HTTP create different identity and containment questions.MCP server isolationA server compromise should not confer every tenant, tool and downstream system privilege.MCP dynamic tool changesA tools/list change can alter the agent’s available operations or the instructions inside descriptions mid-task.MCP roots and resource boundariesRoots describe client-visible workspace boundaries; server-side filesystem access must still be enforced by the actual host.MCP sampling authorityServer-initiated sampling asks a client to use its model context and potentially tools; it does not inherit unlimited client authority.MCP elicitation securityAn MCP server can request user input, but the client must preserve who is asking and what the answer authorizes.MCP long-running task securityA durable task can outlive the authorization context in which it began.MCP cross-tenant isolationA shared MCP server must keep tenant identity attached to discovery, invocation and downstream data access.MCP data exfiltration pathsData can leave through tool arguments, tool results, sampling context, elicitation destinations or server egress.MCP read versus write toolsA read-like tool and a mutating tool need different authority and outcome checks, regardless of their names.

Connect the architecture

Identity, permission, decision, outcome.

An MCP server exposes tools and may hold downstream credentials. The protocol specifies how remote clients gain access to a protected resource, while organizational policy must still answer whether one tool invocation and its arguments fit the caller’s task. Review the client, server, gateway and protected API as separate trust boundaries. A tool listing is not authority; a gateway log is not proof that no direct server or API path exists. Start with a negative call that has a valid token but no business grant.

Platform authority ↗Developer authority model ↗Compliance and audit context ↗ProofGrid Research ↗

Explore the control plane

Make one authority chain reviewable before scaling it.

Request a Conversation