85.6% of Your Deployed Agents Don't Have Full IT Approval: The Gravitee Numbers Behind the MCPProxy Case

Algis Dumbris • 2026/05/05

The Gravitee State of AI Agent Security 2026 report is, as far as I can tell, the most precise public measurement of how AI agents enter enterprise production today. Most prior work in this space relied on adjacent metrics — usage counts, deployment surveys, model traffic estimates — that capture activity without distinguishing between sanctioned and unsanctioned activity. Gravitee asked the question directly: what fraction of your agent fleet has gone through complete security and IT approval?

The answer, across the surveyed population, was 14.4%.

The remaining 85.6% is the number that makes governance teams uncomfortable. Eight and a half out of ten agents in production today are running without complete approval. They were installed, configured, and given credentials through paths that bypass the institutional review processes that exist precisely to track this kind of deployment. The deployment happened. The record of the deployment did not.

This is the same pattern Shadow IT exhibited fifteen years ago, when SaaS adoption outran procurement. The pattern repeats because the structural conditions repeat. A new technology lands. The technology is useful immediately. The institutional approval process takes longer than the user is willing to wait. The user proceeds. By the time the institutional process catches up, the deployment is already in production and the approval becomes retrospective at best, performative at worst.

For MCP specifically, the 85.6% number is more than a Shadow IT echo. It is a direct measurement of the deployment surface that MCP-aware admission control is designed to intercept.

What 14.4% Actually Measures

The Gravitee figure is worth reading carefully. It does not say 85.6% of agents are unapproved. It says 14.4% of organizations have complete security and IT approval for their entire agent fleet. The other 85.6% have at least some agents in production without full approval. The fraction of unapproved agents within those organizations is a separate question, but for governance purposes it does not need to be answered. The relevant unit is the organization, because the organization is the unit that gets cited for noncompliance, breached, or audited.

By this measurement, 85.6% of organizations are operating with a partial blind spot in their agent fleet. The exact size of the spot varies. In some organizations it is one agent. In others it is most of them. In all of them it is non-zero, and in all of them it is non-zero by structural definition: there is no internal record that distinguishes the approved part of the fleet from the unapproved part with confidence.

The figure has two operational consequences. First, the organization cannot answer the question “is this agent approved?” without ambiguity. Second, the organization cannot satisfy regulatory frameworks that require an answer to that question on demand. EU AI Act Article 12, the OWASP Agent Observability Standard, the ISO/IEC 42001 alignment that the CSAI Foundation is now anchoring its CVE program against — all of these frameworks assume the organization can produce a complete approval record for its agent fleet. For 85.6% of organizations today, that assumption does not hold.

The Three Structural Gaps

The Gravitee report supplies three additional numbers that explain why 85.6% is not just an artifact of slow paperwork.

The first is the credential identity gap. Forty-five point six percent of organizations report that their agents share API keys across multiple agents and connections. A shared key by definition cannot identify which specific agent or which specific connection used it. When a security event occurs and the audit trail names the key, the trail terminates at the key. There is no further information available about which agent or which sub-process actually performed the action.

The implication for MCP is direct. An MCP server connection authenticated with a shared key has no per-server connection identity in the credential layer. The connection is anonymous within the scope of the key holder. Approval at the connection level is impossible because the connection layer cannot distinguish which approval would apply.

The second gap is the spawning gap. Twenty-five point five percent of organizations have agents that can spawn sub-agents. Each spawn is a deployment event. Each spawned sub-agent potentially makes its own MCP connections. The spawn event is initiated by code, not by a person, which means the institutional approval workflow — which is built around human-initiated deployments — has no triggering event to attach to. The sub-agent comes into existence, opens its connections, and operates outside the approval flow that the parent agent went through.

This gap is structural. It cannot be closed by training developers to file approval tickets, because the deployments are not initiated by developers. It can only be closed by an admission gate that operates at the connection layer, where the spawn events surface as connection attempts that have to be admitted before they become connections in fact.

The third gap is the monitoring gap. Fifty-two point nine percent of agents are unmonitored or only partially monitored in production. The monitoring gap is a different problem from the approval gap, but the two interact in a way that makes governance harder. An unapproved agent that is also unmonitored is twice invisible: there is no record of its admission, and there is no record of its behavior. When a regulatory inquiry or security incident demands answers, the available evidence is whatever telemetry was incidentally captured, which is not the same as a structured audit trail.

Eighty-eight percent of the surveyed organizations had reportable AI security incidents in the last year. Eighty-two percent of executives at those organizations report feeling confident in their agent governance posture. The eighty-eight to eighty-two gap is the confidence gap that the unapproved, unmonitored deployment surface produces. The executives are confident because they are looking at the approved, monitored agents. The incidents are happening in the part of the fleet that does not show up on either dashboard.

What an Approval Record Provides That a Shared Key Cannot

The 45.6% shared-key statistic is the easiest of the three gaps to discuss in concrete terms. A shared API key is convenient. It avoids per-agent credential provisioning, simplifies key rotation when rotation does happen, and reduces the friction for new agent deployments. These are the reasons shared keys end up in production. They are also the reasons shared keys cannot satisfy a per-connection approval requirement.

A connection-level approval requires a record that is created when the connection is established and that contains, at minimum, the identity of the approving party, the identity of the approved server, and the timestamp of the approval. The credential layer does not produce this record. The shared key was issued at a higher level — to a team, to a service account, to an agent group — and is reused across connections without re-attestation.

MCPProxy’s admission record produces the missing artifact. Each admission is an independent decision attached to a specific server identity, a specific manifest hash, and a specific reviewer. The record exists regardless of what credential the agent uses to make its actual API calls. The credential answers “is this caller authenticated?” The admission record answers “is this server approved?” These are different questions, and the second one has been structurally unanswerable in deployments that depend on the credential layer to provide both answers.

The record also supplies the artifact regulators are now asking for. Article 12 does not require per-call attestation; it requires per-deployment logging. The admission record is the per-deployment artifact, and it satisfies Article 12 directly. The shared key, by contrast, satisfies Article 12 only indirectly and incompletely — it tells the auditor who the agent is in some abstract sense, but not which servers the agent’s deployment was approved to talk to.

The Spawn Multiplier Is Where the Numbers Compound

The 25.5% spawning statistic looks small in isolation. One in four organizations have agents that can spawn sub-agents. The implication seems modest until the multiplication is performed.

Take the population of organizations with multiple models in production — Datadog measured this at over 70%. Take the population with incomplete IT approval — Gravitee measured this at 85.6%. Take the population with agents capable of spawning — Gravitee at 25.5%. The intersection is the population where the deployment surface is not just incomplete but actively expanding through automation that does not interface with the approval system.

The exact intersection size depends on how the populations overlap. In the most conservative reading, the populations are independent and the intersection is the product: roughly 15% of organizations. In the more realistic reading, the populations are positively correlated — organizations running multiple models are more likely to have both approval gaps and spawn-capable agents — and the intersection is larger. Either way, the result is the same in qualitative terms: a meaningful fraction of organizations have a deployment surface that grows during normal operation through processes that the approval system does not see.

This is why the spawn problem matters more than the spawn statistic suggests. A 25.5% one-time gap is not a long-term problem. A 25.5% mechanism for the gap to grow indefinitely is a long-term problem. Without a structural intercept at the connection layer, every sub-agent spawn is another opportunity for the unapproved fleet to expand.

Closing the Gap Without a New Approval Process

The natural response to the Gravitee numbers is to recommend a stricter approval process. This is not the right response, because the existing approval process is not the failure point. The failure point is that the process operates at a layer where most of the deployments are no longer happening. Approval forms are filed for the deployments that humans initiate. The deployments that compounded into the 85.6% are happening through code paths that do not interact with approval forms.

Closing the gap requires an intercept at the layer where the deployments actually happen — the MCP connection layer. The intercept does not have to replace the existing approval process. It has to attach the approval record to the moment the connection is established, regardless of whether the deployment was human-initiated, code-initiated, or spawn-initiated.

This is the function MCPProxy’s admission gate provides. Every MCP connection passes through the gate. Every connection produces an admission record. The record is created at the moment the connection is established, not at the moment a form is filed. The 85.6% gap closes from the bottom: the deployments that previously had no record now have one, because they cannot proceed without one.

The 91-day window to Article 12 enforcement is the deadline by which the closing has to be at least partially accomplished. Every day of admission records accumulated before August 2 is a day of compliance evidence available at the deadline. Every organization that starts after August 2 starts with zero history and a six-month retention clock running against an empty database.

The Gravitee numbers describe the problem with a precision the industry has not had before. They also describe the addressable surface for any control that operates at the right layer. MCPProxy is the control at the connection layer. The 85.6% is what it is built to address.