Runtime controls for MCP need proxy inspection and DLP

At a glance

What this is: This is PipeLab’s analysis of NSA MCP security guidance, focusing on how runtime proxy inspection, DLP, sandboxing, and logging map to practical controls for agents using MCP servers.

Why it matters: It matters because IAM and security teams need to decide where to enforce policy on MCP traffic, how to keep agents from bypassing controls, and how to align runtime inspection with discovery and audit.

Context

Model Context Protocol gives agents a standard way to reach tools and data sources, but that also creates a new runtime boundary for identity and policy enforcement. The question is not whether MCP can be used safely in theory, but where traffic inspection, output filtering, and access control actually sit in the path of execution.

PipeLab’s reading of the NSA guidance is that MCP security fails when teams treat proxies as optional. If an agent can route around inspection, the control is decorative rather than governing, which is why the runtime layer has to be designed as part of the access model, not added after deployment.

Key questions

Q: What breaks when MCP traffic can bypass runtime inspection?

A: Policy becomes advisory instead of enforced. If agents can route around the proxy, then content filtering, DLP, and tool-result scanning only cover a subset of traffic, which leaves unsafe calls, leakage, and prompt injection paths outside the governance boundary.

Q: Why do MCP runtime controls need both discovery and inspection?

A: Discovery tells you whether an MCP server should be trusted enough to install or expose, while inspection tells you whether a specific live call is safe to execute. Treating those as one control creates blind spots, because installation risk and runtime abuse are different failure modes.

Q: How should teams decide whether to use an MCP proxy or a scanner?

A: Use both for different decisions. A scanner is for pre-deployment assessment of exposed servers and listeners, while a proxy is for in-path policy enforcement once the agent is running. If you need one to replace the other, the control model is incomplete.

Q: What should IAM teams monitor to prove MCP governance is working?

A: IAM teams should monitor which workload identities are calling which servers, whether policy is default-deny, and whether outbound requests are auditable back to the calling agent. If those signals are missing, the environment may be relying on implied trust rather than enforced identity controls.

Technical breakdown

Why MCP-aware proxies matter at runtime

An MCP-aware proxy is not just a network relay. It is a policy enforcement point that can inspect request content, tool selection, and response data before the agent uses the result. The practical difference is that generic proxies see packets, while MCP-aware controls can interpret JSON-RPC structure, resource URLs, and tool metadata. That makes them relevant to prompt injection, tool misuse, and data leakage. The limitation is equally important: if the deployment allows direct egress, the proxy cannot govern traffic it never sees. See the MCP Security Guide.

Practical implication: Treat the proxy as a control boundary only when network routing prevents bypass paths.

Why sandboxing and tool inventory pinning are separate controls

Sandboxing limits what wrapped processes can do on the host, while tool inventory pinning limits what the agent believes is available during the session. Those are different failure domains. A sandbox can constrain execution even when a tool is malicious or misbehaving, but it does not prevent registry drift or name collision attacks. Inventory pinning helps detect when a tool changes shape after first observation, but it does not stop runtime abuse on its own. Together they reduce both execution risk and trust ambiguity. See the Multi-Agent and A2A Security Guide.

Practical implication: Use sandboxing for host containment and tool pinning for session-level trust stability.

How output scanning changes the trust model for agent responses

Output scanning turns tool results into inspected data rather than blindly trusted output. That matters because MCP agents often chain one tool’s response into the next action, which means a compromised or poisoned response can become an execution trigger. Bidirectional inspection is the key idea: the control must evaluate both the request leaving the agent and the result coming back before the next step is taken. This is closer to content governance than traditional perimeter filtering, because the risk is not only exfiltration but also malicious instruction flow.

Practical implication: Inspect tool outputs before downstream reuse so poisoned responses do not drive the next action.

Threat narrative

Attacker objective: The attacker wants to turn a legitimate MCP session into a trusted pathway for data leakage, tool misuse, or unauthorized downstream action.

1. Entry occurs when an agent establishes a legitimate MCP connection to a server that can exchange tool calls and results with the runtime environment.
2. Credential or data exposure follows when the connection carries resource URLs, access methods, or secrets that exceed the intended scope of the call.
3. Escalation happens when the agent or an attacker uses the trust placed in the MCP session to pivot through tool output, bypass inspection, or reach a different backend path.
4. Impact is achieved when uninspected MCP traffic leaks secrets, triggers unsafe actions, or expands the agent’s effective access beyond the intended policy boundary.

Breaches seen in the wild

• Smithery.ai MCP hosting breach 2025: A Smithery.ai build flaw gave GitGuardian a live fly.io token controlling 3,000+ hosted MCP servers and the API keys their clients sent.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Runtime inspection becomes the control plane for MCP trust: When agents call tools dynamically, policy cannot live only in pre-deployment review. The meaningful boundary is the point where the request and response are still observable, because that is where exfiltration, injection, and unsafe tool chaining can still be stopped. In practice, runtime inspection is not a bolt-on feature; it is the place where governance either exists or is bypassed.

Capability separation is the real design test: Security teams often talk about proxies, scanners, sandboxes, and gateways as if they were interchangeable. They are not. Each one answers a different question, and MCP security only becomes operational when discovery, inspection, containment, and audit are intentionally separated rather than collapsed into one control surface.

Protocol maturity does not remove governance debt: The NSA guidance is useful precisely because it names a control shape without pretending the ecosystem is settled. That is a signal to buyers that they need to validate how tool inventory, bidirectional scanning, and direct egress restrictions behave together. The field is moving toward governed agent traffic, and operators should measure the gap between policy intent and actual routing.

MCP security is now an identity and routing problem, not just an application problem: NHI authentication matters because the agent’s trust posture depends on how it proves itself, how it is authorized, and whether those permissions can be constrained inside a live session. The implication is that identity governance has to follow the runtime path, not stop at login.

From our research library:

• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
• Read next: MCP Security Guide

What this signals

Runtime governance for MCP will increasingly be judged by bypass resistance: If a deployment can be routed around, the policy is not truly controlling the agent. The practical standard will shift from “does the proxy inspect traffic” to “can the environment prevent any unmanaged path from reaching MCP servers.”

Tool-chain visibility is becoming part of identity governance: As agents chain requests through multiple tools, the trust question moves from authentication alone to whether the session can be observed, constrained, and audited end to end. That makes governed agent traffic a programme design issue, not a point product decision.

Ephemeral trust needs durable evidence: Short-lived sessions still need records that security teams can reconstruct later, especially when tool output can trigger the next action. Without signed or structured receipts, operators may know a call happened but not why it was allowed or what it influenced next.

For practitioners

• Enforce direct egress restrictions Block bypass paths with network policy or container network rules so the proxy is the only governed route for MCP traffic.
• Separate discovery from runtime inspection Use pre-deploy scanners to assess exposed MCP servers, then use runtime proxies to inspect live calls before execution.
• Pin tool inventory during each session Fingerprint tool names, descriptions, and parameters so drift or collision is visible before the agent reuses a changed tool.
• Log bidirectional MCP activity Emit structured records for requests, tool results, and policy decisions so security teams can trace unsafe execution paths later.

Key takeaways

• MCP security is now about controlling live agent traffic, not just validating server exposure before deployment.
• The main gap is bypass risk, because proxies and DLP only work when all MCP paths are forced through them.
• Discovery, inspection, sandboxing, and audit logs solve different problems and should be treated as separate controls.

Related NHI Mgmt Group resources: MCP Security Guide · NHI Authentication Guide · Multi-Agent and A2A Security Guide

Key terms

• MCP proxy: An MCP proxy is a middle layer that sits between an AI agent and MCP servers, forwarding requests, enforcing policy, and often logging activity. In technical terms, it mediates Model Context Protocol traffic, can normalize tool calls and responses, and helps control authentication, authorization, auditing, and data exposure across connected resources.
• Tool Inventory Pinning: Tool inventory pinning is the practice of locking a session to a known set of tools, names, descriptions, and parameters. In agentic environments, it limits drift and collision risk by making tool availability stable enough to govern and audit.
• Bidirectional Inspection: Bidirectional inspection means examining both prompts sent to an AI system and the responses it produces. This is essential when outputs can trigger follow-on actions, leak sensitive data, or carry instructions that affect downstream systems, users, or automated workflows.
• Egress Bypass Risk: Egress bypass risk is the possibility that traffic escapes the intended inspection path through direct network routes or unmanaged container networking. In MCP deployments, it undermines proxy-based governance because the control cannot inspect what it does not see.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.