MCP runtime controls: are proxies and DLP enough?

TL;DR: The NSA’s May 2026 MCP security guidance points buyers toward filtering outgoing proxies, enterprise DLP, sandboxing, logging, and discovery tools, according to PipeLab, but also makes clear that runtime controls only work when traffic cannot bypass them. The real issue is governance of agent egress, not just inspection depth.

Editorial analysis by NHI Mgmt Group, based on content published by PipeLab: “What the NSA's MCP security guidance says, and what an agent firewall does”.

Key questions

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

A: Policy becomes advisory instead of enforced.

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.

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

A: Use both for different decisions.

Practitioner guidance

• 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.

Bottom line: MCP security is now about controlling live agent traffic, not just validating server exposure before deployment.

Explore further

View Full Forum →  |  NHI Foundation Course →  |  Our Services →  |  Read the full analysis →