MCP Firewall Coverage Gap: What Agent Tool Policy Actually Inspects · Enterprise Agentic AI Insights
Microsoft's MCP firewall covers remote HTTP and SSE traffic on enrolled devices. Work out the share of agent tool-call paths it leaves outside policy, and the retention gap underneath.
The item that just moved on your board deck If you run Microsoft, yesterday's Entra release notes handed you something you have wanted since the first agent shipped. The Global Secure Access MCP Firewall is in public preview. It sits at the network edge, reads Model Context Protocol traffic, and makes an allow or block decision per server, per tool, per resource, per prompt template, without touching a single MCP client, host or server implementation. You can block all MCP traffic tenant-wide until you have approved a list. You can allow a server and block one tool on it. You can refuse outdated protocol versions. Discovery runs in Generative AI Insights, so you can watch first and write rules second. [VERIFIED C01] That is a real control, and it is the first one in this category that a network team can operate without begging developers to instrument anything. It is also the moment where the risk gets created, because the natural next move is to mark the ungoverned agent tool surface as closed and move on. What the control actually covers Microsoft states the boundary plainly in its own documentation, which is more than most vendors do. The MCP firewall inspects streamable HTTP and Server-Sent Events. It does not inspect stdio or other non-HTTP transports. It sees remote MCP servers only. Local MCP servers running on a device are not visible to it. JSON-RPC batches are not inspected. And it works only where the forwarding client is installed on a directory-joined device with TLS inspection enabled, because MCP messages travel inside the encrypted payload. [VERIFIED C02] [VERIFIED C03] None of that is a defect. It is a network control doing network control things. The problem is what sits on the other side of the boundary. The evidence A measurement study published on 31 July 2026 ran four passes over the public MCP population during July. It confirmed 640 production servers, dynamically audited 414, and found 68 reportable vulnerabilities including SQL injection, server-side request forgery against cloud metadata services, prompt template injection and path traversal. Three findings matter for the coverage question. [VERIFIED C05] <figure class="ariana-chart" role="group" aria-label="Three findings from the July 2026 internet-facing MCP measurement study" <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 720 300" width="720" height="300" role="img" aria-labelledby="mcpCvTitle mcpCvDesc" <title id="mcpCvTitle"Three findings from the July 2026 internet-facing MCP measurement study</title <desc id="mcpCvDesc"91.8 percent of audited servers lack OAuth authentication. 687 tool instances expose shell execution without access controls. 41.6 percent of confirmed servers disappear within three days.</desc <rect width="720" height="300" rx="14" fill="0D0F12"/ <text x="28" y="38" fill="07A3D1" font-family="Roboto,Arial,sans-serif" font-size="15" font-weight="600"JULY 2026 MEASUREMENT, 414 SERVERS AUDITED</text <text x="28" y="82" fill="EDE8E3" font-family="Roboto,Arial,sans-serif" font-size="16" font-weight="500"No OAuth authentication</text <rect x="28" y="94" width="620" height="26" rx="8" fill="2A2C2F"/ <rect x="28" y="94" width="569" height="26" rx="8" fill="FF7900"/ <text x="600" y="113" fill="FFB340" font-family="Roboto,Arial,sans-serif" font-size="19" font-weight="900"91.8%</text <text x="28" y="160" fill="EDE8E3" font-family="Roboto,Arial,sans-serif" font-size="16" font-weight="500"Gone within three days of being confirmed</text <rect x="28" y="172" width="620" height="26" rx="8" fill="2A2C2F"/ <rect x="28" y="172" width="258" height="26" rx="8" fill="07A3D1"/ <text x="300" y="191" fill="71D8F5" font-family="Roboto,Arial,sans-serif" font-size="19" font-weight="900"41.6%</text <text x="28" y="238" fill="EDE8E3" font-family="Roboto,Arial,sans-serif" font-size="16" font-weight="500"Tool instances exposing shell execution, no access control</text <text x="28" y="272" fill="FFB340" font-family="Roboto,Arial,sans-serif" font-size="34" font-weight="900"687</text <text x="120" y="272" fill="C9C4BF" font-family="Roboto,Arial,sans-serif" font-size="15" font-weight="500"across the confirmed population</text </svg <figcaptionPadilla, arXiv:2608.00150v1, 31 July 2026. 414 servers dynamically audited from a confirmed population of 640.</figcaption </figure 91.8 percent lack OAuth. Access control is not the default state of this ecosystem, so an uninspected path is not a neutral path. 687 tool instances expose shell execution with no access controls. The highest consequence tool class is concentrated exactly where nobody is gating. 41.6 percent of confirmed servers disappear within three days. This is the one that changes your operating rhythm. A quarterly attestation is describing a population that has already turned over twice. Add the older survey context and the shape of the problem is familiar: 82 percent of executives said existing policy protected them from unauthorised agent action, while 47.1 percent of agents were actually monitored or secured. That survey was fielded in December 2025, so treat it as directional rather than current. The gap between the two numbers is the finding, not either number by itself. [CITED C09] Read the classes side by side Six combinations of transport and host. Only one of them is fully covered by a network MCP policy. | Class | Where it runs | Transport | Network MCP policy sees it | Where the evidence has to come from instead | |---|---|---|---|---| | Remote server, managed device | Vendor or internal service | HTTP or SSE | Yes, with TLS inspection on | Gateway traffic logs plus Generative AI Insights | | Remote server, unmanaged or contractor device | Vendor or internal service | HTTP or SSE | No, device is outside the forwarding path | Vendor-side logs, or refuse the path | | Local server, developer laptop | On the endpoint | stdio | No, stated limitation | Endpoint detection, software inventory, developer policy | | Local server, build agent or CI runner | On the runner | stdio | No | Pipeline configuration review, image scanning | | Batched calls | Either | JSON-RPC batch | No, batches are not inspected | Application-layer logging in the host | | Agent-to-agent, no MCP hop | In-platform | Platform internal | Not applicable | Platform audit log, for example the identity or workspace layer | The row that catches most organisations is the third one, because it is where the productivity story lives. Developer tooling is where local stdio servers are started, and it is the same transport the NSA's Artificial Intelligence Security Center singled out in its May 2026 design considerations sheet on MCP, which covers access control, prompt handling, tool execution, agent permissions, auditability and governance of third-party integrations. [VERIFIED C06] The governance turn Here is where this stops being a security architecture question and becomes a board one. Transparency obligations under Article 50 of the EU AI Act have been in application since 2 August 2026. They are not limited to high-risk systems, and they attach per system that interacts with a person. Providers of in-scope systems placed on the market before that date have until 2 December 2026 for the machine-readable marking piece. [VERIFIED C07] Record-keeping under Article 12 and log retention under Article 19 attach to the high-risk set, which the Digital Omnibus package proposed deferring to December 2027 for Annex III and August 2028 for Annex I. That is the published direction of travel, not a duty binding this quarter, and any vendor telling you otherwise is selling against a date that moved. Meanwhile the retention floors that already bind you have nothing to do with AI. A US broker-dealer keeps records for six years. HIPAA documentation retention is six years. If your tool-call log survives ninety days, the evidence expires long before the question arrives. So the attestation a Chief Risk Officer can actually sign is not "we have deployed an MCP firewall."