MCP Policy Enforcement: Treating Model Context Protocol Calls Like AI Traffic, Not Plugin Traffic
Model Context Protocol turned a model conversation into a fan-out of tool calls and resource reads against external systems. Each fan-out arm now carries its own identity, its own scope, and its own data classification, and the policy plane has to evaluate every arm before the model receives the result. MCP policy enforcement sits at the boundary where the agent reaches the MCP server, inspects the call as AI traffic rather than plugin traffic, and produces an audit record per tool invocation. This walkthrough covers the boundary, the policy fields a Principal Engineer expects to see, and the audit fields the regulator expects.
Anthropic published Model Context Protocol on November 25, 2024. By May 2026 the major IDEs, agent frameworks, and enterprise assistants ship MCP support out of the box. A single user request to "summarize the sales pipeline" now expands into a dozen MCP calls against a CRM server, a data warehouse server, and a document repository server, each call carrying its own scope and returning its own payload back to the model. The policy plane that was wired for plain HTTP-to-LLM traffic has to learn how to read MCP.
I want to walk through the enforcement boundary that works, the policy fields a Principal Engineer expects to see on each MCP call, and the audit fields the regulator expects per tool invocation.
What MCP actually moves through the wire
MCP is a JSON-RPC protocol over HTTP or STDIO. The HTTP transport carries tools/list, tools/call, resources/read, and prompts/get calls between the agent and a named MCP server. Each call carries a method, arguments, and an identity envelope.
The gateway sees the request as a structured payload, not as opaque text. The structured payload is what makes per-call enforcement tractable.
The method name and the arguments together define what the agent is asking the MCP server to do. The policy plane treats each tools/call as a separate decision and records each one with its own audit row.
The enforcement boundary
DeepInspect intercepts HTTP AI traffic between authenticated users and agents on one side and LLMs and MCP servers on the other. For MCP, the enforcement points are two:
The agent-to-MCP-server boundary is the call site. The gateway inspects the tools/call, checks the identity of the calling agent, classifies the arguments, and resolves the policy. Allowed calls reach the MCP server. Denied calls return a structured error the agent receives in place of the result.
The MCP-server-to-agent boundary is the result site. The gateway inspects the response body before the model sees it. Sensitive fields can be redacted; oversized responses can be trimmed; unexpected schema shapes can be rejected.
Both boundaries record an audit row. The pair of rows describes the call and the response the agent actually consumed.
The identity envelope on MCP calls
MCP carries an identity envelope from the calling agent. The envelope is what binds the call to a real principal in the directory. Three identity layers travel together.
The natural-person identity is the human who initiated the session. For a developer using an MCP-enabled IDE, the person is the authenticated SSO user. The natural-person identity is what HIPAA, the EU AI Act, and most sector regulations expect to see in the audit log.
The agent identity is the named agent that issued the call. The same human can drive ten different agents in a session; each agent has its own identity and its own scope.
The tool identity is the MCP server and the tool name being invoked. crm.search_deals against the acme-crm MCP server is one tool identity; crm.update_contact against the same server is a different tool identity. The policy plane operates on tool identity, not on server identity alone.
What the policy evaluates per call
The policy evaluates four properties of the call.
The first property is the agent's permission to invoke the named tool. A sales summarizer might have crm.search_deals but not crm.update_contact. The directory binds agent identities to tool sets.
The second property is the argument classification. customer-pii, financial-figures, phi, source-code are common classifications. The policy compares the classification to what the calling identity is allowed to receive.
The third property is the rate budget. An agent that calls the same tool 200 times per minute is likely in a loop or under prompt-injection pressure. Per-identity rate limits at the gateway are the place this gets caught.
The fourth property is the route's data-residency constraint. A call from an EU-based identity that would touch a US-hosted MCP server fails the residency check; the policy rejects the call before it reaches the server.
What the audit record carries per invocation
A per-invocation audit record carries the fields the regulator's question resolves against.
The response_classifications field describes what came back, separate from what went out. A search call that returned a different classification than the arguments implied is a finding the audit pipeline can surface.
How MCP traffic interacts with the EU AI Act
EU AI Act Article 12 requires automatic recording of events over the lifetime of the system. A high-risk system that uses MCP to reach into clinical records, hiring decisions, or credit decisions has to record the MCP call inputs and the MCP call results. The per-invocation audit row is the artifact the regulator expects to retrieve.
Article 19 sets the retention at six months. The MCP per-invocation rows go into the same audit pipeline as the LLM call rows. They are linkable through request_id and natural_person, which the regulator's question requires.
DeepInspect
DeepInspect intercepts MCP traffic at the agent-to-MCP-server boundary. The gateway resolves the agent identity from the call's envelope, classifies the arguments, evaluates the policy version, and records the per-invocation audit row. Denied calls return a structured MCP error the agent can interpret. Responses can be inspected and redacted before reaching the agent.
The gateway runs in-line with sub-50ms p95 enforcement overhead from internal DeepInspect testing. The audit pipeline writes to tamper-evident storage; the per-invocation rows survive the regulator's traceability questions. Book a technical deep dive at deepinspect.ai to walk through MCP enforcement against your current agent posture.
Frequently asked questions
- Does MCP policy enforcement break the protocol?
The gateway returns standard MCP errors when a call is denied. The agent's MCP client handles the error the same way it handles a tool-not-found error from the server itself. The protocol contract holds.
- How does the gateway see STDIO-transport MCP?
The STDIO transport does not flow through HTTP and sits outside the HTTP enforcement boundary. The supported path is to deploy a thin HTTP proxy in front of STDIO servers and route the agent through the HTTP transport. The gateway inspects HTTP-mode MCP only.
- What about MCP server-side resources?
resources/readis treated as a separate method with its own policy rule. The same identity, classification, and residency fields apply. A resource that returns a different classification than the read implied is flagged in the audit row.- How does this interact with OAuth-protected MCP servers?
The OAuth token the agent presents to the MCP server is part of the agent's identity envelope. The gateway inspects the token's claims and uses them to resolve the agent identity in the directory. The token never leaves the gateway in the audit record; the resolved identity does.
- What is the rollout path for an existing agent stack?
The path is to point the agent's MCP client at the gateway, register the MCP servers behind the gateway, and migrate rules one tool at a time. The audit pipeline begins emitting rows from the moment the first tool is routed. Rules that are not yet defined fail-closed; explicit allow rules are added per tool as the rollout proceeds.