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.
Transport and tokens
Begin with the principal, purpose and operation before discussing tools.
Tool execution
Follow the grant and policy into the protected execution path.
Trust and threats
Review failure, revocation and the evidence left after execution.
Further technical references
Follow a specific boundary.
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.
Explore the control plane