← Blog

Anthropic MCP Server Security: The Enterprise Controls That Sit Around Claude's Tool Layer

Anthropic's Model Context Protocol implementation lets Claude call tool servers with a standard schema. The enterprise question is what security controls have to sit around the MCP server when the LLM behind the protocol is Claude. This piece walks through the controls: transport authentication to the MCP server, token exchange between Claude's session and the tool call, response inspection before the tool result reaches the model, and audit records tied to the human user who authorized the session.

ByParminder Singh· Founder & CEO, DeepInspect Inc.
Platform & Architectureanthropicmcpclaudeai-securityai-agentai-gateway
Anthropic MCP Server Security: The Enterprise Controls That Sit Around Claude's Tool Layer

Microsoft's May 7, 2026 disclosure documented prompt-to-shell escalation paths in mainstream agent frameworks, and the disclosure applies to any framework that composes tool calls into an LLM session. Anthropic's Model Context Protocol standardizes how Claude calls tool servers with a defined schema. The enterprise question is what security controls sit around the MCP server when the LLM behind the protocol is Claude. I want to walk through the controls the enterprise deployment adds on top of Anthropic's protocol implementation: transport authentication, token exchange, response inspection, and per-user audit records.

What the MCP protocol provides and what it does not

The protocol provides message framing, session lifecycle, tool discovery, and a standard JSON-RPC-like invocation schema. The protocol handles the mechanics of Claude asking a tool server "what tools do you have" and calling one of them with a set of arguments.

The protocol does not prescribe transport authentication, per-call authorization, response filtering, or audit records. The enterprise deployment fills each gap.

An enterprise that runs an MCP server behind Claude has to decide how the client authenticates to the server, how the server authorizes the specific call, whether the response goes back to Claude unmodified, and where the audit records live.

The transport authentication control

Mutual TLS between Claude's runtime host and the MCP server establishes the connection identity. The MCP server presents a certificate that Claude's runtime verifies against a trusted authority. Claude's runtime presents a certificate that the MCP server verifies the same way.

The control binds the connection to the runtime identity. A rogue process on Claude's host that does not hold the client certificate cannot open a connection to the MCP server. The MCP server rejects the connection at the TLS handshake.

The pattern also produces a per-connection audit record: the client certificate's subject, the server certificate's subject, the connection timestamp, and the session identifier the client subsequently opens.

The token exchange for per-call authorization

The token exchange pattern uses RFC 8693 to trade Claude's session token for a downscoped token per tool call. Claude's session token holds the scope the enterprise's identity provider granted for the entire session. The tool call needs a narrower scope, bounded to the specific tool and the specific arguments.

The gateway between Claude and the MCP server performs the exchange. The gateway resolves the session token, evaluates the tool call against the enterprise policy, and mints a short-lived token scoped to the specific call. The MCP server accepts the short-lived token, executes the tool, and returns the response.

The pattern prevents Claude from reusing the session token across tool calls without the enterprise policy re-evaluating each call. The audit record captures the exchange with the (session, tool, arguments, scope, ttl) tuple.

The response inspection layer

The MCP server returns the tool's output as a structured response Claude consumes as context for the next model call. The response can contain data Claude should not see in the current session's scope: cross-user data from the tool's underlying system, cross-tenant data in a multi-tenant tool, or sensitive content the tool exposed unintentionally.

The response inspection layer runs between the MCP server and Claude. The layer applies the enterprise's classifier to the response, redacts patterns the policy identifies, and forwards the redacted response to Claude. The pattern is the same shape as the LLM-response-side inspection the enterprise runs against Claude's own output.

The audit record captures the pre-redaction hash of the flagged patterns, the redaction action, and the request identifier. The reviewer can prove the response-side control fired without the audit log storing the raw sensitive content.

The per-user audit chain

The audit chain ties each tool call back to the human user who authorized the Claude session. The chain runs through the session token, the exchanged tool call token, the MCP server's execution record, and the response-side inspection record.

Each step in the chain records the identifiers that link it to the next step. The session token holds the user's identity. The exchanged token holds the session token's sub claim. The MCP server records the exchanged token's identifiers. The response-side record includes the request identifier the exchange produced.

The chain lets the reviewer walk from a specific tool call back to the human user and forward to the response Claude received. The chain satisfies EU AI Act Article 12's traceability requirement for the MCP-mediated tool layer.

The interaction with Anthropic's enterprise agreement

Anthropic's enterprise agreement describes the retention window for the API traffic, the customer's ability to disable retention, and the model provider's own audit controls. The agreement is one piece of the compliance evidence.

The gateway-side audit records are the other piece. The gateway records the traffic before it reaches Anthropic and after Anthropic returns the response. The enterprise's evidence file for a compliance review includes both: the enterprise agreement that describes Anthropic's behavior, and the gateway records that describe the enterprise's own control at the boundary.

The pattern lets the enterprise satisfy a reviewer's traceability question without depending only on the model provider's cooperation for the record.

The MCP-specific attack patterns to defend

The MCP layer introduces attack patterns that do not appear on direct-invocation LLM APIs.

Rogue MCP server injection: an attacker publishes a malicious MCP server the enterprise's runtime accidentally connects to. Transport-layer authentication with certificate pinning prevents the connection.

Tool spoofing at discovery: an MCP server returns a fabricated tool description that the LLM interprets as a legitimate action. The gateway's tool catalog validates the discovery response against a known-good tool set.

Prompt injection through tool response: the tool response contains adversarial content that steers Claude's next call. The response inspection layer strips or flags the adversarial content before Claude consumes it.

Argument tampering: the gateway intercepts a tool call, inspects the arguments against the policy, and rejects arguments that fall outside the policy's boundary. The pattern prevents Claude from being coerced into calling a tool with adversarial arguments.

DeepInspect

This is the gap DeepInspect closes at the MCP boundary. DeepInspect sits inline between Claude's runtime and the MCP servers Claude calls. The gateway holds the token exchange logic, the tool catalog, the response inspection layer, and the audit chain.

The gateway forwards each call to the underlying MCP server with a short-lived credential the gateway holds. The MCP server never sees the long-lived enterprise token. The response side runs through the classifier before Claude consumes it. The audit records land in a hash-chained log the reviewer can query per user, per tool, or per session.

Book a demo today.

Frequently asked questions

What does Anthropic's MCP protocol handle out of the box?

The protocol handles message framing, session lifecycle, tool discovery, and the JSON-RPC-like invocation schema. The protocol delegates transport authentication, per-call authorization, response filtering, and audit records to the enterprise's deployment. The gaps are where the enterprise adds its own controls.

Why is mutual TLS the transport-layer control?

Mutual TLS binds the connection to the runtime identity. A rogue process on Claude's host that does not hold the client certificate cannot open a connection to the MCP server. The pattern rejects the connection at the TLS handshake and produces a per-connection audit record that captures both parties' certificate subjects.

How does RFC 8693 token exchange fit the MCP flow?

The exchange trades Claude's session token for a downscoped token per tool call. The gateway performs the exchange, evaluates the tool call against the enterprise policy, and mints a short-lived token scoped to the specific call. The MCP server accepts the short-lived token, executes the tool, and returns the response. The pattern prevents cross-call token reuse.

What is response inspection at the MCP boundary?

The pattern runs the enterprise's classifier against the tool's output before Claude consumes it as context. The classifier redacts patterns the policy identifies, and the audit record captures the pre-redaction hash and the redaction action. The pattern prevents cross-user or cross-tenant data the tool exposed from reaching Claude's context inadvertently.

How does the audit chain tie a tool call to a human user?

Each step in the chain records the identifiers that link it to the next step. The session token holds the user's identity. The exchanged token holds the session token's sub claim. The MCP server records the exchanged token's identifiers. The response-side record includes the request identifier the exchange produced. The chain lets the reviewer walk from a tool call back to the human user.

What MCP-specific attack patterns need defenses?

Four patterns appear on the MCP layer that direct-invocation LLM APIs do not carry: rogue MCP server injection, tool spoofing at discovery, prompt injection through tool response, and argument tampering. Transport pinning, tool catalog validation, response inspection, and argument policy checks are the four defenses that map to the four patterns.