Model Context Protocol Security: How the MCP Transport Layer Changes the Inspection Boundary
The Model Context Protocol standardizes how an LLM client connects to tool servers and exchanges context, tool calls, and tool results. The transport layer carries the agent identity, the tool call payloads, and the tool return values. The inspection boundary an MCP deployment owes is the HTTP leg between the MCP client and the MCP server. This piece walks through the transport modes MCP supports, the inspection target on each, the identity-aware policy decisions the deployment commits per call, and the audit record format that survives an Article 12 review.
The Model Context Protocol (MCP) standardizes the connection between an LLM client and the external tool servers the client calls during a session. The protocol defines a request shape (tools/list, tools/call, resources/read, resources/list), a response shape, and a transport layer the client and server agree on. The two transport modes the protocol supports are STDIO (the client launches the server as a child process and they communicate over standard input and output) and HTTP-SSE / streamable HTTP (the client connects to the server over an HTTP endpoint and they exchange messages over server-sent events or chunked HTTP). The transport mode determines where the inspection boundary sits. The deployer's enforcement architecture depends on which transport the deployment uses.
I want to walk through the two MCP transport modes, the inspection target on each, the identity-aware policy decisions the deployment commits per call, and the audit record format that survives an EU AI Act Article 12 review.
The two MCP transport modes
The STDIO transport launches the MCP server as a child process of the MCP client. The client writes JSON-RPC requests to the server's stdin and reads responses from the server's stdout. The communication does not traverse any HTTP endpoint. The inspection layer that sits at the HTTP boundary cannot see the STDIO traffic, because the traffic never leaves the process pair. STDIO is appropriate for trusted local servers (a CLI tool, a local database client) where the client and server share the same trust boundary.
The HTTP-SSE and streamable HTTP transport connects the MCP client to the MCP server over an HTTP endpoint. The client and server exchange JSON-RPC messages over server-sent events or chunked HTTP responses. The transport traverses the network, terminates TLS at the server endpoint, and exposes the request and response payloads at the HTTP boundary. The HTTP-transport mode is the one production MCP deployments use for any non-local server.
The inspection boundary the deployment owes sits on the HTTP transport. The STDIO transport is out of scope for an HTTP-layer inspection product. A deployment that mixes STDIO and HTTP MCP servers needs the HTTP servers covered by the inspection layer and the STDIO servers covered by the process-launch policy the operating system enforces (which servers can be launched, by which user, against which binary).
What the inspection target carries on the HTTP transport
The HTTP-transport MCP request carries four classes of data the inspection layer reads.
The first class is the JSON-RPC envelope. The method (tools/list, tools/call, resources/read, resources/list, prompts/get), the parameters object, and the request identifier. The envelope is what the inspection layer matches against the MCP server's tool catalog.
The second class is the call parameters. For tools/call, the tool name and the arguments. For resources/read, the URI of the resource the agent is requesting. The parameters carry the user-controlled content the agent's planner produced.
The third class is the propagated identity context. The agent identifier and the natural-person identifier the agent acts on behalf of, carried in the HTTP headers the MCP client attaches to the request. The MCP specification does not mandate the identity propagation shape, and the deployment's policy is to attach the SSO claims to every outgoing MCP request.
The fourth class is the response payload. The tool result the server returns, including any data the server retrieved on the agent's behalf. The classifier passes over the response and tags the data classes the result carries.
The inspection layer reads all four classes at the HTTP boundary between the MCP client and the MCP server. The classification and identity context drive the policy evaluation. The decision attaches to the audit record before the response reaches the agent.
The identity-aware policy decisions the deployment commits per call
The deployment commits five decisions per MCP call.
The first decision is identity propagation verification. The inspection layer reads the propagated identity headers and verifies that the natural-person identifier and the agent identifier are both present and valid. A request without propagated identity produces a block decision at the boundary.
The second decision is the tool authorization. The policy bundle bound to the agent's route describes the tools the agent is authorized to call. A tools/call against a tool outside the authorized list produces a block decision. The policy bundle is keyed on the agent identifier and the route, so different agents on the same MCP server can have different tool subsets.
The third decision is the parameter inspection. The classifier reads the tool call arguments and tags the data classes the arguments reach. An argument that carries customer-PII content into a tool the policy disallows for PII produces a redact (mask the PII before forwarding) or block decision.
The fourth decision is the response classification. The classifier reads the tool result and tags the data classes the result carries. A result that returns data above the agent's authorized classification produces a redact decision before the result reaches the agent's next context window. The redaction handles the prompt-injection-via-tool-return-value risk by masking the injection-carrying content before the agent's planner reads it.
The fifth decision is the audit commit. The per-decision record carries the natural-person identifier, the agent identifier, the MCP server identifier, the method and tool name, the policy version that evaluated the call, the decision outcome, and the integrity metadata. The record commits to the tamper-evident store with hash chaining across records.
The audit record format that survives Article 12
EU AI Act Article 12 takes effect August 2, 2026 for high-risk systems and requires automatic event recording over the system lifetime, identification of the natural persons involved, and retention for at least six months. NIST AI RMF MANAGE 1.3 requires evidence that AI risks are tracked across the system lifecycle. ISO 42001 Annex A.9.5 covers operational records for AI systems.
The MCP audit record format carries eight fields per call. The record carries the natural-person identifier the agent acts on behalf of, the agent identifier, the MCP server identifier, the method invoked, the tool or resource targeted, the classification of the parameters and the response, the policy version that evaluated the call, the decision outcome, the upstream model that produced the call (if known), and the integrity metadata.
The record series joins to the agent's broader request series on the agent identifier and the natural-person identifier. A regulator query for "show me the MCP calls a specific data subject's interaction produced" returns the tool calls in time order, joined to the model decisions that emitted them.
The deployment topology that fits production MCP
The layer is stateless across calls. Each call evaluates against the propagated identity, the policy bundle bound to the agent's route, and the call content. The MCP server keeps its own server-side state. The two compose: the MCP server's logs cover the server's internal handling, the inspection layer's records cover the regulatory obligations.
DeepInspect
DeepInspect is the inspection layer at the HTTP-transport MCP boundary. The product terminates the TLS between the MCP client and the MCP server, reads the JSON-RPC envelope and the tool call parameters and the response payloads, evaluates identity-bound policy per route, applies pass, modify, redact, or block decisions, and commits per-decision audit records to a tamper-evident store with hash chaining across records.
The product runs as a stateless proxy in front of the deployment's HTTP-transport MCP servers. The STDIO MCP servers remain covered by the operating system's process-launch policy, which is the appropriate boundary for STDIO traffic. The mixed-transport deployments cover the HTTP servers through the inspection layer and the STDIO servers through the existing host-level controls.
If your team is rolling out MCP across the agent stack and the audit team is asking how the tool-call lineage is recorded, let's talk today.
Frequently asked questions
- Does the inspection layer work with the streamable HTTP transport that replaces HTTP-SSE?
The streamable HTTP transport carries the JSON-RPC messages over chunked HTTP responses. The inspection layer reads each message at the chunked-response boundary and applies the policy decisions per message. The classification and audit-commit mechanism is identical to the HTTP-SSE mode. The deployment can move between the two transport modes without changing the inspection layer's configuration.
- How does the inspection layer handle MCP servers running on localhost?
A localhost MCP server reached over HTTP (the loopback address with a chosen port) traverses the local TCP stack but not the network. The inspection layer can sit on the loopback path through an iptables or eBPF redirect, the same way a transparent proxy interposes on local traffic. The policy decisions and audit records work identically. The decision to interpose on localhost depends on the trust boundary the deployer assigns to the localhost server.
- What happens when a tool call's response carries content that would be a prompt injection?
The inspection layer's response classifier reads the tool result and tags the data classes the result carries. The classifier also runs an injection-content scan against the result. A result that matches the injection patterns produces a redact decision: the injection-carrying content is masked before the result reaches the agent's next context. The agent's planner reads the sanitized result and the injection cannot reach the model's decision surface. The audit record captures the redaction so the security team can review the patterns over time.
- Does the layer support MCP servers we run for partners outside our SSO?
The inspection layer can apply per-route policy that handles partner-MCP servers under a partner-identity context. The partner's MCP server reaches the deployer's MCP client through the HTTP boundary the inspection layer covers. The policy bundle for partner routes describes the tools the partner-side server can call into and the classifications the deployer accepts in the responses. The audit record carries the partner identifier on each call so the deployer can review the partner-route activity separately from internal-route activity.