Key Takeaways
- 53% of public MCP (Model Context Protocol) servers rely on static, rarely rotated API keys, and only 8.5% use OAuth (Astrix Security, 2025).
- MCP is already in limited or broad production at 41% of software organizations (Stacklok, 2026): this is live infrastructure, not an experiment.
- Detecting and approving MCP servers closes visibility gaps, but not authorization gaps: OWASP's MCP Top 10 names insufficient authorization and privilege-escalation-via-scope-creep as distinct, unresolved risks.
- Closing the gap requires binding agents to tools at registration, holding servers in one central catalog, and revoking access live, at the moment of the call, not on the next deploy.
Fifty-three percent of MCP servers run on static API keys that rarely get rotated. That's not a minority edge case. Across the more than 5,200 public MCP implementations security researchers at Astrix Security analyzed in 2025, it's the majority default. Model Context Protocol is already in limited or broad production at 41% of software organizations, and adoption now sits at director-level and above as a strategic priority. The protocol is real infrastructure, moving at real speed. Most of it is still authenticating like a side project.
The instinct, understandably, is to go find every server running and force it through one approved path. That's shadow MCP detection, and it's solving the right first problem. It just isn't solving the problem most teams think it is. A fully detected, fully approved MCP server still doesn't tell you which agent can call it, with what, or who can revoke that on the spot. Detection makes the invisible visible. It doesn't decide who can act.
MCP by the numbers: fast growth, thin authentication
MCP servers are scaling fast, but authentication practice hasn't caught up. Source: Astrix Security (2025), Stacklok (2026).
MCP adoption is outrunning governance by design, not by accident
This is a familiar shape. A decade ago, cloud and API sprawl outpaced governance the same way. Infrastructure that's easy to stand up always outpaces an organization's ability to track it. Gartner had already predicted that by 2027, 75% of employees would acquire, modify, or create technology outside IT's visibility, up from 41% in 2022.
MCP follows the same pattern, but faster. Run the arithmetic on an organization of 5,000 employees connecting to 40 MCP servers, and "sprawl" stops being a mood and becomes a number: thousands of people, dozens of servers, and no natural ceiling on the combinations.
Detection answers "what's out there," not "who's allowed to call it"
Finding unregistered servers and routing traffic through an approved path closes the first, most obvious gap, and it's necessary. But OWASP's MCP Top 10 names the next one explicitly: insufficient authentication and authorization (MCP07) and privilege escalation via scope creep (MCP02), as risks distinct from, and unresolved by, network-level detection. Visibility into the server is a different claim than authorization over the call.
| Question | Shadow MCP detection answers it? | What actually answers it |
|---|---|---|
| Which MCP servers exist in our environment? | Yes | Network-level discovery/detection |
| Is this server on our approved list? | Yes | Detection + an approval workflow |
| Which agent is allowed to call this server? | No | Per-agent authorization at registration |
| What exact tools can this agent call, and with what? | No | Least-privilege binding, scoped at registration |
| Can we revoke one agent's access right now, without a deploy? | No | A centrally-held, live-revocable binding |
Authorization has to be a decision made per agent, not per server. Registering an agent should mean binding it to the exact tools it may call, on a least-privilege basis, by default, with nothing broader available to it unless that binding says so. If that decision isn't happening wherever servers get detected and approved, it's worth asking where it's actually being made right now.
The answer, today, is: inside the agent's own code
Which tools an agent can call typically live in the agent's code, set by whoever built it and changed only by shipping a new version. A tool built to watch traffic at the network layer has no way to see logic baked into a deployment. The two are looking at entirely different layers of the stack. That's why the OWASP risk categories above persist even in organizations that have already deployed detection tooling: authorization is invisible to that tooling by design, not by oversight.
The fix isn't asking every team to expose their code. It's making the tool itself a registered, governed object once, centrally, so agents reference a shared catalog instead of each wiring their own path to it.
At real scale, that decision has to move in seconds, not a release cycle
Return to the scale math above: thousands of employees, dozens of servers, growing combinations. At that density, a tool binding that can only change by redeploying code is already too slow to contain a problem the moment it's found.
The bar this sets is specific. A tool or server binding can be revoked live, effective on the very next call, no deploy required. A call outside the allowlist is refused at the point of the call itself, before it reaches the tool, so a blocked attempt costs nothing.
Closing the gap means moving authorization outside the agent
Better detection isn't the answer. Authorization that lives outside the agent, decided centrally, enforced at the moment of the call, is. Three things together do this: binding an agent to its tools at registration; holding every server in one governed catalog instead of scattering it across agent code; revoking a binding the instant something looks wrong. None of these are exotic. They're the same discipline organizations already apply to identity and network access, applied to the layer that agentic AI added.
This is the model Forgebench is built around: a credential reaches what it's bound to, and nothing else, decided once, held centrally, enforceable the moment a call is made, regardless of how fast the fleet behind it keeps growing. If your organization is past asking "what MCP servers do we have" and into "which agent should be allowed to call them," that's the conversation worth having next.
