Content Security in the MCP Identity Gateway

The MCP Identity Gateway applies Content SecurityContent Security: Content Security is an Access Policy component that inspects content and enforces the allow, block, or transform verdict returned by an inspection service.Learn more to inspect the MCP traffic it proxies. You add Content Security to the gateway-to-server Access PolicyAccess Policy: Access Policies define, enforce, and audit access between Client and Server Workloads by cryptographically verifying workload identity and contextual factors rather than relying on static secrets.Learn more, and the Gateway sends matching MCP content to the configured inspection service and enforces the verdict it returns. This page explains where inspection sits in the Gateway request path, what it inspects, and how verdicts and failures affect MCP traffic.

For the Content Security component itself, see Content Security. To add it to a policy, see Add CrowdStrike AIDR Content Security.

Where inspection happens

Inspection runs in the Gateway’s data plane, after identity checks and before content moves on. On each MCP request, the Gateway validates the caller’s token and Aembit Cloud evaluates the Access Policies as usual. When those checks succeed and the policy includes Content Security, the Gateway sends the MCP content to the inspection service. The Gateway applies the verdict before it forwards the content to the MCP server or relays it back to the client.

Content Security inspects the MCP traffic the Gateway proxies: tool listings, tool call inputs, and tool call outputs. The Gateway proxies MCP requests between AI agents and MCP servers, not traffic between AI agents and large language model (LLM) providers. Prompts and completions exchanged with an LLM never pass through inspection.

Checkpoints and verdicts

Content Security adds an inspection step to the MCP Identity Gateway request path. When an Access Policy that governs MCP Identity Gateway traffic includes Content Security, the Identity Gateway sends MCP content to the configured inspection service at three checkpoints:

• Tool listings - The set of tools an MCP server advertises to a client.
• Tool call inputs - The arguments a client sends when it calls a tool.
• Tool call outputs - The results a tool returns to the client.

At each checkpoint, the inspection service returns one of three verdicts, which the Gateway applies before the request continues:

• Allow - The content passes inspection, and the Gateway forwards it unchanged.
• Block - The content violates a policy, and the Gateway blocks it.
• Transform - The inspection service returns modified content, and the Gateway forwards the transformed content in place of the original.

Inspection sequence

The following diagram shows the inspection path for a tool listing and a tool call. Token validation and Access Policy evaluation complete before inspection starts, so the diagram shows only the inspection path.

The Gateway inspects tool listings and tool outputs on the response leg, before it relays content to the client. It inspects tool inputs on the request leg, before it forwards the call to the MCP server. When the verdict at any checkpoint is Block, the Gateway stops the content there. It doesn’t forward a blocked request to the MCP server and doesn’t relay a blocked listing or result to the client. Instead, the Gateway returns an error response to the client explaining that Content Security blocked the content.

Inspection is per MCP message

Content Security evaluates each MCP message on its own. A verdict covers only the single tool listing, tool call input, or tool call output the inspection service evaluated, not the conversation, session, or task that message belongs to. Blocking one message doesn’t block the messages that follow it. If an AI agent retries a blocked call with different arguments and the new message passes inspection, Aembit forwards it.

In a workload event stream, a retry appears as a blocked message followed by an allowed one for what looks like the same underlying task. Each event reflects the verdict for its own message.

Latency and failure behavior

Each checkpoint adds a call to the inspection service on the request path, which adds latency to inspected MCP traffic. The Timeout and Max Retries settings on the Content Security component bound how long the Gateway waits for a verdict.

If the Gateway can’t reach the inspection service or an inspection request errors, the component’s Fail Open on Error setting determines whether the Gateway forwards the content without inspection or blocks it. For the trade-off between availability and guaranteed inspection, see Fail-open and fail-closed behavior.

Oversized MCP content is a common source of inspection errors. CrowdStrike AIDR rejects content that exceeds its size limit, and the Gateway handles that rejection through the same Fail Open on Error path. See AIDR content size limit.

CrowdStrike AIDR

CrowdStrike AI Detection and Response (AIDR) is the Content Security integration the Gateway sends MCP content to. For AIDR concepts, credentials, and the CrowdStrike AIDR for Agents subscription requirement, see CrowdStrike AIDR Content Security.

CrowdStrike AIDR Content Security is separate from the CrowdStrike Access Condition integration, which evaluates endpoint posture on a different Access Policy component. Configuring one doesn’t enable the other.