Every governance framework for AI agents tells you to do the same handful of things: establish identity, scope authorization, log actions, keep a human in the loop. OWASP and CoSAI both say these things, and the NIST AI Agent Standards Initiative is convening federal guidance around much of that list. The prescriptions are mature and they are nearly unanimous.
What none of them tell you is whether any of it actually exists in deployed systems.
So I went and measured. I looked at 945 Model Context Protocol servers, drawn from a population of 17,563 enumerated across the MCP Registry, npm, and PyPI, and I checked their source code for the controls these frameworks prescribe. The full pre-print study is now up on Zenodo, but herein is the short version of what I found and why it matters.
(And if you're the kind of person who reads papers instead of teasers, here's the link: https://doi.org/10.5281/zenodo.20972250)
The headline number is the FLOOR for how bad this is
Among the 760 servers in the sample whose source I could read, 71% exhibit at least one accountability gap (95% CI: 67.6% to 74.0%).
That number is worse than it sounds, because of how the measurement works. A gap can only be detected where some governance infrastructure already exists to be found incomplete. A server that authenticates callers but never logs who did what has a gap. A server with no authentication, no logging, and no authorization at all registers zero gaps, because there's nothing partial to flag. (Analogous to giving a security rating to a lock when it's a door without a lock... I just rated locks, not doors.) The 71% is a lower bound that, by construction, excludes the servers that did nothing. The real posture of the ecosystem is not better than this figure. It is somewhere (really, really, really) south of it.
Another 20% of the sample, 185 remote-only servers, couldn't be assessed at all. No source, no introspectable endpoint in most cases. The opacity is itself a finding: a fifth of the ecosystem is closed to anyone trying to evaluate whether it can be governed. That was a jawdropper for me, too.
One gap to rule them all
The single most important finding is a disconnect between enforcement and audit.
81% of source-available servers authenticate their callers. Only 17% attribute logged actions to a specific principal. Servers check your credentials at the door, and then either don't write down what you did or write it down without recording who you were.
In access-control terms, these systems can answer "was this access authorized?" but not "who took which action?" If an agent holding valid credentials - whether those belong to the individual delegating or identify the agent itself - does something it shouldn't, through prompt injection, scope escalation, or a compromised delegation chain, an audit trail that records the action but not the attributed principal can't distinguish the compromised agent from the legitimate one. So you know something happened. Kinda.
This is what I'd call security without accountability, and it's the ecosystem's default state right now, not an edge case. The two most prevalent gap patterns, near-equal at roughly 41% and 40%, are a single authentication layer applied uniformly across tools of wildly different sensitivity, and authenticated access with no actor-attributed logging. A user authorized to list files has the same gate as one authorized to drop a database, and when either acts, the record often can't say which user it was.
There's a structural reason this particular link breaks first. When a human delegates a task to an agent, four roles that used to be separate collapse into one chain: the requester, the reasoner, the actor, and the record-keeper become the same operational entity. Conventional web systems tolerate weak downstream logging because the human's identity survives in session state, browser context, transport telemetry, things a downstream audit can reconstruct after the fact. The agent setting doesn't preserve those out-of-band surfaces. The only authoritative record of which principal authorized an action is the one the enforcement point chooses to write. Forty percent of servers don't write it.
Now, you may ask, "What about MCP EMA?," and that's a good question. I addressed that in the paper, but here's a spoiler: it doesn't solve for this.
Sensitive reads
A lot of access-control thinking is organized around write operations, which creates a bit of a blind spot in and of itself. The dangerous thing is the tool that changes state: deletes, modifies, transacts, etc. Read operations get treated as comparatively safe.
But that framing misses an entire class of risk: Sensitive reads. I found 198 tools across 91 servers that expose protected data, credentials, PII, financial records, through read operations that never modify persistent state. Under a strict persistent-effect definition, these are correctly classified as "reads." But a tool that exports PII or retrieves patient records needs exactly the same accountability infrastructure as one that writes: authentication to prevent unauthorized access, logging to create a record, attribution (to trace who pulled the data).
Among those 91 servers, 79% lack co-located audit logging. Sensitive data can be read without creating a record of that action. A governance model that keys on write operations, which is most of them, leaves this exposure completely unaddressed.
Composition problem > protocol problem
Every one of these gaps has a corresponding standard that already exists to close it. I last wrote about this in my response to the NIST NCCoE concept paper "Accelerating the Adoption of Software and AI Agent Identity and Authorization" and I've since expanded my worldview to include more standards and a focus on composing those standards as the core of a solution.
Actor attribution has the OAuth 2.0 Token Exchange profile, with sub and act.sub claims that name the principal and the agent acting on their behalf, workload identity has SPIFFE, and cross-system correlation has OpenTelemetry trace context. Tamper-evident audit has hash-chained evidence records, standardized in RFC 4998, available since 2007. The components are mature, and in several cases they've been mature for the better part of two decades. No new protocol necessary, though a new envelope certainly would help.
What hasn't been demonstrated is their adoption in deployment. The ecosystem is strongest at the thing it's had longest, authentication, and weakest at the thing that depends on composition, attributed and tamper-evident audit across a workflow. The audit posture is stark: 38% of servers log nothing, 42% log fully, very little sits in between. That pattern is what you'd expect if audit is an architectural decision made early in a project rather than a feature teams add incrementally. Either you built for it or you didn't.
This is the same conclusion I reached in that NCCoE response earlier this year, that the work in front of us is composing existing standards rather than inventing new ones, now with an ecosystem-scale measurement behind it. The orchestration-layer moves arriving in mid-2026, enterprise-managed authorization in MCP, vendor agent-identity models, IETF delegation drafts, these mostly govern the first connection hop. None of them yet propagate the calling principal's identity into per-server audit records, and none carries published adoption evidence. The 64-percentage-point gap between authentication and attribution sits underneath all of them, because the audit primitive they presuppose is the unadopted one.
And this is the single-server case. The attribution loss I'm measuring at one MCP server is the substrate that multi-agent systems compose on top of, and attribution that degrades at one hop degrades further at every subsequent one. The single-server gap is the lower bound on a problem that delegation chains only amplify.
What I want you to take from this
Agent governance gets discussed as a policy problem or an identity problem. It's neither, or rather it's both plus a third thing that turns out to be the binding constraint: an implementation-evidence problem. Governance becomes meaningful only when enforcement actually constrains behavior and audit actually proves what happened. Until then, the frameworks describe controls that may or may not exist in the systems they're meant to govern. Before I did this primary research, that would not have been my spicy take.
The point of this study isn't to argue that MCP servers are insecure. Plenty of them gate access perfectly well, and the go-to-market state is likely getting better. The point is that gating access and being accountable are different properties, and the ecosystem has substantially more of the first than the second. So bringing back that lock+door metaphor, the most common failure doesn't result from a missing lock on the door but the missing logbook.
The methodology, the per-pattern prevalence, the framework mappings to OWASP and CoSAI, the limitations and the direction-of-bias analysis, the full classification approach, all of that is in the paper. If you build, deploy, or govern agent tooling, I think the paper is worth your time. The reproduction package, including the analysis instrument published as the cc-mcp-audit npm package, is available so you can run the same assessment against your own servers.
The frameworks have tried to tell us what to build. This is a measurement of how much of it we've actually built as a community. The answer is: less than the frameworks assume, and the gap is in the place that matters most when something goes epically wrong.
Credits: Anthropic Claude for editorial support, ChatGPT for cover image.
References:
[1] Fending, Brian. (2026). "Measuring Agent Governance Posture: Accountability Gaps in MCP Servers and Implications for Single- and Multi-Agent Governance." Ordovera Advisory. https://doi.org/10.5281/zenodo.20972250
[2] Fending, Brian. (2026). "Governance belongs at the enforcement boundary." NCCoE response to "Accelerating the Adoption of Software and AI Agent Identity and Authorization." https://doi.org/10.5281/zenodo.20974262
[3] Fending, Brian. (2025). "The MCP Security Problem." https://brianfending.com/articles/mcp-security-problem-supply-chain