Why MCP Requires Additional Enforcement Architecture
Model Context Protocol standardizes how AI agents discover and call external tools, resources, and prompts through a client-host-server architecture using JSON-RPC 2.0 messages. This standardization is useful for interoperability, but it does not solve access control. The MCP specification defines tool primitives, including name, description, and an input schema used to validate request structure, but it does not define how permissions are scoped to individual agents or how those permissions are enforced at runtime.
The protocol's authorization specification adds OAuth 2.1-based flows for HTTP transports, giving clients and servers a standard way to obtain and present access tokens. However, the specification explicitly assigns token validation and scope enforcement to the MCP server acting as a resource server, not to the protocol itself. This means two organizations implementing MCP servers can have identical protocol compliance while enforcing very different, or no, least-privilege controls. For platform engineering teams, this gap is the actual implementation problem: MCP gives you a transport and a discovery mechanism, not a security model.
Where MCP Structurally Allows Permission Boundaries
Tool-call requests in MCP are discrete JSON-RPC messages with a method and a params object. This structure matters because it means a policy engine can intercept and evaluate each call as a distinct, inspectable event before it reaches execution logic, rather than trying to infer intent from unstructured model output. The input schema attached to each tool definition also gives servers a mechanism to validate request structure, which is a necessary but not sufficient control since schema validation confirms shape, not authorization.
MCP also separates tool discovery (listing available tools) from tool invocation (calling a tool). This separation creates two enforcement stages rather than one. A server can conditionally list only a subset of tools to a given session, enforcing coarse-grained least privilege at discovery time, and separately enforce fine-grained checks at invocation time. Teams that enforce only at the invocation stage miss the opportunity to reduce an agent's visible attack surface earlier in the interaction.
Placing the Policy Enforcement Point
Zero trust architecture principles, as described in NIST SP 800-207, establish that access decisions should be made per-request at a policy enforcement point (PEP), informed by a policy decision point (PDP) that evaluates identity, context, and resource sensitivity. Applied to MCP, this means the PEP must sit between the MCP server's request handler and the actual tool execution logic, since the protocol does not mandate where this check occurs.
Separating Agent Identity from User Identity
MCP does not define a standardized agent identity separate from the connecting client or user. Identity and permission delegation are left entirely to the host application and server implementation. This is a significant gap in practice, because if an agent inherits the full permission scope of the human user or system that invoked it, least privilege is effectively impossible: any agent action carries the authority of the broadest credential available in the session.
A more defensible model treats the agent as its own principal, issued distinct, scoped credentials, often modeled on workload identity or service-account patterns rather than reusing the human user's token. OAuth 2.1 scopes referenced in the MCP authorization spec can map to coarse tool-category permissions, but they do not natively express fine-grained, per-resource or per-parameter constraints, so scope design has to be deliberate rather than inherited from whatever token happens to be available. Session-scoped or short-lived credentials further reduce the blast radius if an agent session is compromised, compared to long-lived static tokens.
Governance and Audit Requirements
MCP does not mandate a standard audit log format, which means enterprises must define their own logging schema to satisfy internal and regulatory audit requirements. At minimum, this schema should capture agent identity, the tool requested, parameters passed, the policy decision, the specific policy matched, and a timestamp, since this is the level of detail needed to reconstruct what an agent did and why a request was allowed or denied.
OWASP's guidance on agentic application security identifies excessive agency and insufficient tool-call authorization as a named risk category, recommending that tools be classified by risk or sensitivity, with stricter approval or human review required for high-impact actions. This classification work is a governance decision, not a protocol feature, and it should be documented alongside the permission scopes themselves, including who or what identity authorized each agent's scope. Because MCP leaves delegation model design to the implementer, this documentation is what allows compliance stakeholders to verify that access decisions are enforced consistently rather than applied ad hoc.
Practical Guardrails for Multi-Server Deployments
- Define policy centrally when operating multiple MCP servers, since independently configured servers tend to drift into inconsistent enforcement.
- Enforce least privilege at both tool discovery and tool invocation stages, not invocation alone.
- Treat OAuth scopes as a starting point for permission design, not a substitute for parameter-level checks.
- Issue agents their own credentials rather than reusing the invoking user's token.
- Retain tool-call logs at a level of detail sufficient to answer specific audit questions about identity, decision, and matched policy.