A July 2026 security assessment of internet-facing Model Context Protocol servers audited 414 servers in depth and found that 91.8% were running without OAuth authentication. In our experience, the teams that fix this are not the cautious ones holding back their agent programs. They are the ones getting agents into production.
Security work has a reputation problem inside engineering organizations. It is understood as the thing that arrives late, blocks the launch, and adds a quarter to the roadmap. Specifically, on the agent integration layer, that framing has it backward, and three measurement studies published in July 2026 explain why.
The Model Context Protocol went from novelty to default integration layer in under two years. It is now the standard way for an agent to reach your ticketing system, data warehouse, file storage, and production APIs. That makes it the most consequential piece of new infrastructure that most engineering organizations added in 2026, and the piece almost nobody inventoried.
The result is not an abstract risk. It is a measured one, and the measurement is unusually good.
What Is Actually Exposed on the MCP Layer Right Now?
More than most teams assume. Across four measurement runs spanning July 2026, a security assessment of internet-facing MCP servers confirmed 640 production servers, dynamically audited 414 of them, and uncovered 68 reportable vulnerabilities. Of the 414 audited, 91.8% lacked OAuth authentication. Across the confirmed servers, 687 tool instances exposed shell execution capabilities with no access controls. For scale, the same study cites Censys telemetry putting more than 21,000 MCP endpoints on the public internet as of May 2026.
The vulnerability classes found were not exotic. SQL injection, server-side request forgery targeting cloud metadata endpoints, prompt injection, and path traversal, which is to say the same catalog application security teams have handled for twenty years, arriving through a new door that nobody assigned an owner to.
One finding deserves separate attention because it explains why this persists: 41.6% of confirmed servers disappeared within three days between consecutive measurement runs. That is not stealth. That is an ecosystem where servers are stood up for a project, forgotten, and left running or torn down without anyone tracking either event. You cannot secure what nobody is counting, and at the moment almost nobody is counting.
The author of that study is affiliated with CobaltoSec, and the scanning framework used is published under that firm's GitHub organization, which is worth knowing when you read the findings. The methodology is disclosed in full, and the companion study below, from a completely separate academic team, points in the same direction.
Why Do MCP Security Scanners Not Solve This For You?
This is where the picture gets more interesting than the usual vendor alarm, and where it starts to argue for engineering work rather than a purchase.
A Fudan University team assembled the largest collection of MCP servers gathered for dynamic analysis to date, cataloging 64,611 unique MCP servers out of 113,927 total entries, with more than 37,288 supporting dynamic analysis. They then ran the security scanners the market currently relies on against that corpus.
Those scanners flagged 96.89% of servers as risky, including any server caught by at least one of them. Manual validation found that fewer than 50% of sampled alerts were true positives, with average scanner precision of 45.53%. Worse for anyone hoping to resolve this by buying two tools and taking the union: average pairwise agreement between scanners, measured as Jaccard similarity, was 15.66%. The scanners are not finding the same problems as each other, and more than half of what they do find is not a problem.
A tool that flags nearly everything provides no signal. Your team either investigates 96.89% of your inventory, which is not a plan, or learns to ignore the tool, which is worse than not having it. This is the specific reason MCP security cannot currently be delegated to a scanner and must be built into how you stand up servers.
The same study surfaced the operational root cause. 78.6% of MCP server projects ship no Dockerfile, and among those that do provide complete build artifacts, the native build success rate is only 19.6%. 37.6% of tools provide high-capability operations such as command execution. And 28.3% of unique servers are duplicate representations created by forks, copies, and mirrors, with the largest single cluster comprising 537 identical instances of a single Cloudflare Worker template. Most MCP servers in circulation cannot be reproducibly built, more than a third of the tools they expose can execute commands or modify files, and a large share are copies of copies whose provenance nobody traced.
What Does Getting This Right Actually Buy You?
Here is the part that does not get said often enough. Organizations that treat the integration layer as engineering rather than paperwork are not moving more slowly. They are the ones whose agents reach production.
Your agent projects clear security review instead of dying in it. In the engagements we see, what stalls an agent pilot is rarely model quality. It is that a security team is handed a system it cannot reason about, cannot scope the blast radius of, and cannot approve. A documented server inventory with authentication, scoped permissions, and audit logging turns that review from an open-ended investigation into a checklist. That is not overhead recovered at the margin; it is often the difference between shipping this quarter and shipping next year.
You get to say yes to more integrations, not fewer. Every organization without a control pattern eventually defaults to a blanket restriction, because a blanket no is the only defensible position when you cannot evaluate individual cases. Teams with a real pattern approve integrations on their merits. Over a year, that gap compounds into a meaningful capability difference between two companies that started in the same place.
Human approval is no longer your only control. A study of 1,723 MCP-enabled applications mined from GitHub found that only 37.2% gate tool execution behind a blocking approval step, meaning 62.8% require no approval before a tool executes, and 3.5% implement no human-in-the-loop mechanism at all. Organizations relying entirely on a human to click approve are relying on the weakest control available. NIST made this point directly in August 2026, warning about consent fatigue: just as attackers overwhelm users with authentication prompts until the victim blindly approves a malicious login, overly chatty agents condition people to reflexively click allow to keep their workflow moving. Proper authorization means the human approval you do ask for actually gets read.
You build one control plane instead of re-litigating every agent. The teams that do this once, properly, get to add the tenth agent in an afternoon. The teams that skip it end up having the same security conversation ten times and get slower with each addition. This is the same argument we made about AI agent governance, viewed from the infrastructure side rather than the policy side.
You gain real leverage over your vendors. Once you can articulate what authentication, scoping, and logging you require from an MCP server, you can evaluate a vendor's integration in an afternoon rather than accepting their assurances. Our guide to choosing an AI development partner covers the questions that separate a real answer from a rehearsed one, and the integration layer is where those questions get concrete.
Where Should You Start?
Five steps, in this order, none of which require a procurement cycle.
Inventory what you are running. Not what is approved. What is running. Given that 41.6% of confirmed servers in the scan vanished within three days, assume your real inventory differs from your documented one, and assume some of it is reachable from outside your network.
Authenticate everything, then scope it. With 91.8% of audited servers running without OAuth, authentication alone puts you ahead of most of the ecosystem. Scoping is what puts you ahead of the risk: an agent should hold the narrowest set of permissions that lets it do its job, issued as short-lived and never shared. NIST's guidance is blunt on this point, warning that credentials shared between humans or between agents create accountability gaps with security, privacy, and legal consequences.
Put a blocking approval gate on state-changing tools. Not on every call, which causes consent fatigue, but on operations that write, delete, transact, or deploy. The 62.8% figure is the ecosystem default, and it's wrong.
Audit tool capability, not just tool count. 37.6% of cataloged MCP tools provide high-capability operations such as command execution, and 687 tool instances in the scan exposed shell execution with no access controls. Ask of every server what the worst thing it can do is, and whether it needs to be able to do that.
Require reproducible builds and known provenance. With 78.6% of projects shipping without a Dockerfile and 28.3% of servers being forks or mirrors of other repositories, provenance is the cheapest control available. If you cannot rebuild a server from source, you cannot say what is in it. Our DevOps consulting practice treats this as table stakes for anything that touches production, and MCP servers touch production by design.
Handled together, these are a scoped and finite piece of engineering work. Handled after an incident, the same work arrives with an audit attached and a much shorter deadline. That gap is the actual return on doing it early, and it is why we build it into agent engagements rather than bolting it on at review, whether the work runs through our AI orchestrator practice or a set of tailored AI agents.
Common Questions About MCP and Agent Security
What is the biggest MCP security risk right now?
Unauthenticated, internet-reachable servers with high-capability tools attached. A July 2026 assessment found that 91.8% of the MCP servers it audited in depth lacked OAuth authentication, and 687 tool instances across confirmed servers exposed shell execution with no access controls. The exposure is ordinary in nature and unusual only in how little of it anyone is tracking.
Can an MCP security scanner handle this for us?
Not on its own today. A Fudan University study of 64,611 unique servers found that scanners flagged 96.89% of servers as risky, while fewer than half of the sampled alerts were true positives, with an average precision of 45.53% and only 15.66% agreement among scanners. Use them as one input, not as a gate.
Does securing the integration layer slow down agent deployment?
The opposite, in practice. A frequent cause of a stalled agent pilot is a security review that cannot scope the risk. An inventory, authentication, scoped permissions, and audit logs turn that review from an open-ended investigation into a checklist, which is usually the difference between shipping this quarter and shipping next year.
How do we know which MCP servers we are actually running?
Assume you do not, and go find out. Scan your own environment rather than reading your approvals list, since 41.6% of confirmed servers in the July 2026 assessment disappeared within three days between measurement runs. Anything that was stood up for a project and then forgotten is exactly what will not appear in the documentation.
If your agent roadmap is real for 2027, the integration layer will determine whether it ships. Talk to the Golabs team about auditing what you are running today and building the control pattern once, so that the next ten agents are deployments rather than negotiations.