Twenty-two thousand MCP servers indexed in Glama. Nineteen thousand on mcp.so. More than fifty publicly tracked vulnerabilities in the past twelve months — and that's just the public set, separate from the thirty-plus CVEs filed in a single sixty-day window between January and February 2026. According to Docker's 2026 State of Agentic AI report, eighty-five percent of teams are familiar with the Model Context Protocol; two-thirds actively use it. Forty-six percent of teams further along the adoption curve identify security and compliance as their top MCP challenge. Docker's own framing for the current state is "leap-of-faith mode."
These numbers don't describe a security problem. They describe a trust problem. The distinction matters.
A security problem is a bug — a missing input check, a misplaced permission, a path traversal in someone's filesystem server. You patch it, ship a CVE, move on. The MCP ecosystem has plenty of those, and security teams know how to triage them. They're uncomfortable, expensive, sometimes reputational, but they sit inside the operating system of how software gets fixed.
A trust problem is structural. It's the gap between what a protocol's capability lets you do and what its surrounding stack lets you verify, audit, control, and revoke. Every distribution era — containers, packages, public APIs — has gone through this gap. Adoption races ahead. The trust layer arrives later, retrofitted under pressure from breaches, regulators, and procurement.
Six months ago, in The MCP Governance Problem Nobody's Talking About, I called this gap a vacuum. The vacuum now has shape. Three incidents from the past twelve months show what kind of shape. A five-layer audit shows where it lives. The rapidly inflating MCP gateway market shows what's being built to fill it — and what isn't.
This is not a doom piece. The protocol is solid. The capability is real. But the trust layer is missing, and someone is going to ship it. The only question is whether the industry does it on its own terms or after the third regulator-mandated post-mortem.
Different surfaces, same disease
Three incidents from the past twelve months. Different attack surfaces. Different vendors. Same underlying gap.
June 2025: Asana cross-tenant exposure. Asana shipped an MCP server on May 1. By June 4 they discovered a logic flaw in their tenant isolation check that allowed users in one organization to access project metadata, task descriptions, comments, and uploaded files belonging to other tenants. Approximately one thousand customers were potentially affected, with data exposed for thirty-four days. Asana pulled the server offline on June 5 and didn't restore service until June 17. There was no external attacker. There was no novel exploit chain. It was a routine access-control bug, of the kind that has been the bread and butter of cross-tenant SaaS breaches for two decades. The Register's coverage captured the architectural lesson plainly.
What MCP did here was not introduce a new attack class. It accelerated the velocity of an old one. A tenant-isolation bug in a SaaS dashboard takes days to materialize into damage because customers need to actively use the broken feature. A tenant-isolation bug in an MCP server materializes the moment any agent connected to it asks a question. The amplifier is not the bug. The amplifier is the LLM running queries autonomously, on behalf of users, against permissioned data, at machine speed.
July 2025: Supabase, Cursor, and the lethal trifecta. General Analysis published a proof of concept on July 6. The setup was an out-of-the-box Supabase project with Row-Level Security enabled exactly as documented. A developer used Cursor with the Supabase MCP to occasionally summarize support tickets. The agent was configured with the service_role key, which Supabase's own documentation states bypasses RLS by design. An attacker filed a support ticket containing prompt-injection text that instructed the Cursor agent to read the integration_tokens table and post its contents back into the ticket thread. The agent did exactly that. Secrets ended up in plain text in the customer-facing UI.
Simon Willison named the pattern: a privileged agent, exposure to untrusted input, and a channel back out to the attacker. He called it the lethal trifecta. None of the three components was novel. The MCP architecture made combining them trivial — and made the combination invisible to every traditional security control built around the assumption that humans, not autonomous agents, decide which queries to issue. Supabase's mitigation was read-only mode. The deeper issue — that agents inherit privileges no human would have been granted, against inputs no human would have parsed — remained.
May 2025: GitHub MCP toxic agent flows. Invariant Labs published the canonical demonstration on May 26. A user with broad GitHub access connects Claude Desktop to the official GitHub MCP server. They ask the assistant to check open issues in their public pacman repository. The assistant fetches a malicious public issue containing a prompt-injection payload. The injection instructs the agent to read the user's private repositories and append an "About the Author" section to a public README, populated with personal financial information, relocation plans, and salary data harvested from private repos. The agent — running on Claude 4 Opus — obeys. It opens an autonomous pull request against the public repo with the exfiltrated data. The vulnerability is not a code flaw in the MCP server. It is the architecture of trust between a Personal Access Token, an agent that auto-approves tool calls, and untrusted content treated as instructions. As Invariant noted, the issue is architectural — not patchable in the GitHub MCP server itself.
Three incidents. Three different vendors. Three different attack surfaces. One disease: code that acts on behalf of users with autonomous authority, plugged into a protocol that does not require, mandate, or in most cases support the kind of capability declaration, runtime enforcement, audit, and revocation that we have built into every other meaningful distribution layer.
The Trust Stack every distribution era eventually builds
There is a pattern. It's clear in hindsight, less obvious while you're inside it.
Containers in 2014 were docker run something/image:latest and you trusted Docker Hub because what else were you going to do. By 2026, anything running in production runs through OCI image specs, content-addressed registries, image signing via Cosign and Sigstore, runtime sandboxing in runc or crun, admission controllers in Kubernetes, OPA policies, image scanning at build and at admission, and SBOM generation as table stakes. None of that existed in 2014. All of it exists now because the gap between "I can pull and run any image" and "I can prove what I'm running, why, and under what authority" was filled, layer by layer, after a decade of breaches and standards work.
Public APIs followed the same arc. OpenAPI specifications, OAuth 2.0 and 2.1, mutual TLS, API gateways, rate limiting, schema validation, contract testing, API management platforms — every one of these layers shipped after the wave of REST adoption made it obvious that "let me just expose this internal service" was a category problem, not a single-vendor problem.
Package ecosystems are a useful counter-example because the trust stack is still incomplete. npm and PyPI have package formats and registries. Sigstore arrived in 2022, more than a decade after the package managers themselves. Runtime sandboxing is mostly absent — most package execution is in your build pipeline, in your container, on your laptop, with your credentials. Provenance attestation through SLSA is starting. Continuous monitoring through Socket and Snyk and the like is the application layer above. The package ecosystem is still living through the consequences of an underbuilt trust stack: typosquatting attacks, dependency confusion, postmark-mcp.
Every era looks like this. Adoption races ahead. The trust layer follows under pressure. The mature stacks have five layers, not always with these names, but always covering these properties:
| Layer | What it answers | Container era | API era | Package era |
|---|---|---|---|---|
| Identity | Who is calling, who is responding, on whose authority? | mTLS, ServiceAccounts | OAuth, OIDC, mTLS | Publisher accounts (weak) |
| Packaging & provenance | What code is this, who built it, can I verify? | OCI image spec, Cosign, SLSA | OpenAPI, schema validation | Package manifests + Sigstore |
| Discovery & registry | Where do I get it, is it the real thing? | Docker Hub, Harbor, GAR | API catalogs, gateways | npm, PyPI |
| Runtime governance | What is it doing, is it allowed to, who decides? | OPA, Kyverno, runtime sandboxing | API gateway policies, WAF | Mostly absent |
| Audit & non-repudiation | What happened, can I prove it? | Audit logs, attestations | Gateway logs, SIEM | Install logs (weak) |
MCP is eighteen months old. The audit below walks the same five layers.
Layer 1: Identity
The 2025-06-18 spec update introduced OAuth 2.1 as a hardening direction. The April 2026 update added incremental scope consent. These are good changes, and they exist because the early MCP authentication story was, in plain language, terrible. Astrix Security analyzed 5,200 unique open-source MCP server implementations and found that eighty-eight percent require credentials, fifty-three percent rely on long-lived static API keys or Personal Access Tokens, and only eight and a half percent use OAuth. Seventy-nine percent of API keys are passed through plain environment variables. NeighborJack — public exposure of MCP servers bound to all interfaces with no auth — was a documented class of misconfiguration as recently as June 2025.
Even where authentication exists, the agent-side identity story is hand-wavy. Whose authority is the agent acting under? The user who started the session? The service account that owns the token? The application as a whole? Modern enterprise applications spent fifteen years building delegated authority models — token exchange, on-behalf-of flows, identity propagation across service boundaries. Most MCP deployments have a Personal Access Token wired into a config file. That PAT is the agent's identity, the user's identity, the application's identity, all collapsed into one credential with the broadest possible scope.
The OWASP Top 10 for Agentic Applications 2026 framed this directly in ASI03 (Identity & Privilege Abuse): an agent's identity includes both its defined persona and any authentication material that represents it — keys, OAuth tokens, delegated sessions, tool credentials. When an agent operates, it acts with the full authority of every credential and permission assigned to it. A single agent merges multiple non-human identities into one execution point. If an attacker can confuse the agent, they inherit the authority of every credential that agent carries.
The identity layer is partially built. It's also the layer where the gateway market has the most real value to add — token exchange, scoped credentials, identity propagation are exactly what API gateways have done for a decade. CrowdStrike paid $740 million for SGNL in January 2026 specifically to extend continuous, context-aware authorization to non-human and AI agent identities. That's serious money on the proposition that identity is the layer enterprises want first. But identity alone solves none of the other layers.
Layer 2: Packaging and provenance
This is where the gap is widest. There is no MCP-specific bundle format with required metadata. There is no signing standard for MCP servers. There is no provenance attestation — no equivalent of SLSA for MCP packages. What we have is npm packages, PyPI uploads, GitHub repositories, and an honor system.
The postmark-mcp incident is the canonical demonstration. A developer published fifteen clean versions of an npm package that mirrored the legitimate Postmark MCP server's code exactly. Those fifteen versions worked, accumulated trust, became part of developer workflows. Version 1.0.16, published September 17, 2025, added one line at line 231 — a hidden BCC of every outbound email to phan@giftshop[.]club. Roughly three hundred organizations, by Koi Security's estimate, spent the next eight days having their automated emails — password resets, invoices, internal memos, API keys included — copied to an attacker-controlled address. The attacker registered the package on September 15, weaponized it on September 17, was discovered on September 25, deleted the package, and disappeared. Installed copies kept exfiltrating.
There is no version of this incident that survives a real packaging-and-provenance layer. Sigstore-style code signing would have required the publisher's identity to be cryptographically tied to the version. Reproducible builds would have made the diff between version 1.0.15 and 1.0.16 visible at install time. Mandatory provenance attestation would have made an unsigned, non-attested package fail to install in any environment with policies that match what we routinely enforce on container images. None of those layers exist for MCP today. The honor system is the system.
OX Security's April 2026 disclosure made it worse. Their researchers identified a systemic command injection class baked into Anthropic's official MCP SDKs across Python, TypeScript, Java, and Rust. More than seven thousand publicly accessible servers, 150 million package downloads, and an estimated 200,000 vulnerable instances sit downstream. Anthropic declined to fix the issue at the protocol level, describing the STDIO execution model as a secure default and putting the responsibility for input sanitization on application authors. That sentence — behavior as expected — is the trust deficit in the packaging layer reduced to a procedural artifact. Ten or more high-severity CVEs have been filed against individual downstream projects so far.
Layer 3: Discovery and registry
Smithery has roughly seven thousand servers. Glama indexes around twenty-two thousand. mcp.so lists nineteen thousand. The official Anthropic registry, in preview since September 2025, is the canonical source for clients but does not enforce security baselines on what gets listed. None of these registries — including the ones that pitch governance — operate as a real trust boundary.
Two failure modes show why. First, in their STDIO command injection research, OX Security uploaded a proof-of-concept malicious MCP to eleven major MCP marketplaces, including platforms with hundreds of thousands of monthly visitors. Nine accepted the submission with no review. Only GitHub rejected it; one platform did not respond. The submission flow on most registries treats the submitter's claim about what their package does as authoritative. Second, the registries themselves have been the attack surface. GitGuardian found a path traversal bug in Smithery's smithery.yaml build configuration: setting dockerBuildPath: ".." caused the registry to build Docker images from the builder's home directory, exfiltrating a fly.io API token that controlled over three thousand hosted MCP servers. The trusted intermediary was running an unsanitized YAML field through a build pipeline. Disclosed June 13, 2025; patched within forty-eight hours. No evidence of in-the-wild exploitation — that time.
Discovery layers in mature ecosystems do more than list. Docker Hub publishes vulnerability scan results for official images and signs them. Maven Central enforces namespace ownership. The npm registry has spent years tightening typosquat detection, two-factor authentication on publishing, and provenance attestation through GitHub's OIDC integration. MCP discovery is, in 2026, where npm was in 2014: lots of stuff, low signal-to-noise, no enforcement.
Layer 4: Runtime governance
This is the layer the gateway market is loudest about and weakest at delivering.
Runtime governance, properly understood, has four properties. It enforces what the server declared it can do (capability enforcement). It detects when the server starts doing something different than its baseline (behavioral profiling and drift detection). It controls what leaves the server's sandbox at the network level (egress control). And it can stop a deviation in real time, not just log it after the fact (active enforcement).
The lethal trifecta is a runtime governance problem. The Cursor agent's service_role privilege was declared and accepted. The agent's interaction with untrusted support-ticket text was within its declared inputs. The exfiltration channel — writing back to the support thread — was within its declared outputs. Every individual action passed an application-layer auth check. The composition of the actions did not pass any check, because no layer was watching the composition.
The postmark-mcp BCC was a runtime governance problem. The MCP server's declared capability was "send email through Postmark." The actual behavior added a recipient. No application-layer audit log shows this — it appears as a normal Postmark API call. The drift was at the protocol-message level, invisible to the gateway sitting in front of the agent. A behavioral baseline of the server's outbound traffic would have caught the new destination on first connection. A network-layer egress policy declaring "this server may only contact api.postmarkapp.com" would have blocked the BCC delivery to the attacker's domain even if the application logic was compromised. Neither of those controls was in place because the runtime governance layer for MCP, in most deployments, is "we hope the gateway logs are useful in the post-mortem."
The GitHub toxic flow is a runtime governance problem. The agent's PAT was declared. Its access to multiple repos was declared. Its ability to write to README files was declared. What was missing was a constraint of the form "an agent session may interact with at most one repository unless explicitly authorized to bridge them" — a constraint at the level of action composition, not the individual API call. Invariant Labs' suggested mitigation was exactly this. It is not a property of the GitHub MCP server. It is a property of a runtime governance layer that knows what an "agent session" is.
BlueRock's analysis of more than seven thousand MCP servers found 36.7% had a server-side request forgery exposure similar to one disclosed in Microsoft's MarkItDown MCP server, and 42% expose credentials insecurely. Endor Labs' parallel research on 2,614 MCP implementations found 82% use file system operations prone to path traversal, 67% use sensitive APIs related to code injection, and 34% use sensitive APIs related to command injection. These are the patterns runtime governance should catch and stop. Most of what the gateway market sells under "runtime governance" is application-layer proxying — auth, rate limiting, schema validation, prompt-injection classifiers running on inputs. These are useful. They are not the layer that catches drift, enforces declared scope at the network boundary, or stops composition attacks. Useful is not sufficient.
Layer 5: Audit and non-repudiation
The audit layer in MCP is dominated by application logs. Every gateway pitches "comprehensive audit trails" as table stakes. What almost none of them ship is what audit means in regulatory contexts: tamper-evident, event-sourced, cryptographically signed, exportable for legal proceedings.
This distinction matters increasingly fast. The EU AI Act categorizes high-risk AI systems and demands auditable records of how they made decisions; Article 12 explicitly requires automated logging events sufficient to enable post-market monitoring and incident traceability. SOC 2 Type II attestation, which the gateway market is racing to claim, attests that the vendor follows controls — it does not attest that the audit log they produce is suitable as evidence in a legal dispute. ISO 42001, the AI management system standard, increasingly shows up in enterprise procurement. NIST and CAISI closed comments on March 9, 2026, on a Federal Register Request for Information specifically about AI agent security — the first formal US government solicitation in this area.
What enterprises will need, and what the audit layer must produce, is a chain of evidence: this user, through this agent, with this scope, called this MCP tool, with these arguments, and received this response, at this time, signed by the runtime so that it cannot be tampered with later. Application logs are a starting point. They are not the end point. A SIEM full of structured JSON is not the same artifact as an event-sourced ledger with cryptographic provenance. The former satisfies your engineering team's curiosity. The latter survives a regulator's audit, an insurance investigation, or a court proceeding.
Most gateway products produce the former. A few, mostly in the "Enterprise tier" that the same products gate behind sales calls, claim the latter. The market has not yet sorted this out, and procurement will sort it out for them, slowly, painfully, after the first meaningful enforcement action.
The magical-healer market
Forty-plus vendors have entered the MCP gateway, registry, and "AI agent security" space in eighteen months. SGNL, an identity platform, was acquired by CrowdStrike in January 2026 for $740 million specifically to bring continuous, context-aware authorization to AI agent identities. Khosla Ventures funded Runlayer. Composio built a managed integration platform with five hundred MCP servers and a hundred thousand developers. MintMCP claims first-to-SOC-2-Type-II among MCP platforms. TrueFoundry, Cequence, Lasso Security, MCP Manager, Pomerium, Operant AI, Klavis Strata, Portkey, Kong, Cloudflare's MCP Server Portals, Microsoft's Azure API Management with MCP, Docker MCP Catalog and Toolkit, IBM ContextForge, Bifrost, and at least a dozen more all pitch some version of "secure your MCP."
The marketing is almost interchangeable. Every page leads with "zero trust." Every pitch promises real-time threat detection. Every product claims comprehensive audit trails. Every gateway centralizes authentication, enforces RBAC, and offers prompt-injection scanning. Every registry is enterprise-vetted. Every solution prevents rogue MCP servers and enables governed adoption.
This is not snake oil. Every one of these products solves something. A few solve serious problems well. The issue is not that the market is fraudulent. The issue is that the market is converging on the same shape — application-layer proxy with auth, audit, and content scanning — and pricing that shape as a complete answer to the trust deficit. It isn't. It addresses Layer 1 (identity) reasonably well, parts of Layer 5 (audit) acceptably, and very little of Layers 2, 3, and 4.
Mike Schwartz, the Gluu founder, observed in a Cerbos webinar that the gateway count had grown to the point where you could throw a rock and hit ten of them. Buyers, especially at the enterprise level, are starting to notice. The question they're asking is no longer "which gateway should I deploy" but "what does this gateway not solve, and where does that risk land."
The answer, layer by layer, is that the gateway market does identity well, audit partially, and governance — in the runtime-enforcement, capability-declared, drift-detected, network-egress-controlled sense — barely at all. Every gateway will tell you it has tool reputation scoring. None of them will tell you what their false-negative rate is on a server that behaves correctly for fifteen versions and adds one line on the sixteenth. The postmark-mcp pattern is the worst case for reputation scoring: fifteen versions of accumulated trust, one malicious commit, no signal until exfil completes. There is no public data on tool-reputation false-negative rates against this class of attack — but there is a one-line proof of concept.
What day-zero governance actually looks like
Day-zero governance, as a concept distinct from day-one operations, means that governance is a property the deployment had at moment zero — not a feature added after the first incident, after the first procurement push, after the first regulator inquiry. Containers, in 2014, had day-one governance: you ran the image, and you bolted on monitoring, scanning, and admission later. By 2020, mature container deployments had day-zero governance: signed images were a precondition, scan results gated admission, runtime policies enforced at admission, and the audit log was a first-class artifact.
For MCP, day-zero governance has five properties, mapped to the five layers above:
Capability declaration enforced at the protocol level. An MCP server declares what it does — what tools it offers, what scopes those tools require, what destinations it contacts, what data it touches. The runtime enforces that declaration. A server that declared "send email through Postmark" cannot, at the network layer, send email anywhere else, regardless of what its application logic decides.
Behavioral profiling at runtime, with drift detection. The first thing a governance layer does, on first connection, is baseline what the server actually does — its outbound destinations, its message frequencies, its tool-call patterns. The hundredth thing it does is compare current behavior to baseline and flag deviations. In ENFORCING mode, deviations stop. In OBSERVING mode, they generate evidence. Postmark-mcp's BCC is a deviation from baseline. The behavioral profile catches it before the second email goes out.
Network-layer egress control. The OSI Layer 3 and 4 question — where can this server's traffic go — is a property the runtime answers, not a property the application asserts. A Kubernetes NetworkPolicy is the canonical mechanism here, but the principle is older than Kubernetes. Application-layer proxies cannot match this; they sit above the network layer and inspect what they're shown.
Signed, attested packages with provenance. An MCP server installed in a governed environment carries a signature, an attested build provenance, and a reproducible-build property. Unsigned servers fail to install. The packaging-and-provenance layer is a precondition, not a quality signal.
Cryptographically signed, event-sourced audit log. Every action the agent takes, every tool the server invokes, every argument and response, is recorded in an append-only, tamper-evident log keyed to user, agent session, and tool call. The log is exportable in evidentiary formats. SOC 2 Type II is a process attestation; the log is the artifact. The two are not the same.
None of this is novel in the abstract. Every property has a precedent in how containers, packages, or APIs eventually got governed. None of it is delivered today by the dominant gateway model, which sits at the application layer and proxies. All of it is deliverable — that's the point. The question is not whether MCP can have day-zero governance. It's whether the industry ships it before the regulators write the spec for it.
Closing
The trust deficit is what fills the gap when adoption outruns the trust stack. It's not a single bug, not a single vendor's failure, not a property of MCP-the-protocol. It is the structural consequence of a capability shipping eighteen months ahead of its supporting layers.
The protocol is solid. The capability is real. The market has correctly identified that something is missing. What it has incorrectly identified is the layer that's missing — and that misidentification is what produces forty gateway products converging on the same answer while the actual gap stays open.
The next eighteen months go one of two ways: maturation, driven by serious open-source work, procurement pressure, and regulatory clocks; or reckoning, driven by a breach large enough that the EU AI Act grows enforcement teeth and SOC 2 attestation stops counting as a substitute for evidentiary audit. Either path produces day-zero governance. One produces it on the industry's terms. The other on the regulator's.
Different surface, same disease — except now we have the diagnosis.
Three questions worth taking into your next architecture review:
- Where does an agent in your deployment inherit privileges no human user would have been granted?
- Where does an MCP server's behavior drift go undetected because nobody baselined it?
- Where does your "audit log" stop being evidentiary and start being engineering curiosity?
Answer those honestly and the next eighteen months are a maturation, not a reckoning.
Disclosure: I'm building MCP Hangar in this space. The MIT core is at github.com/mcp-hangar/mcp-hangar. The runtime governance and audit layers are part of the BSL-licensed enterprise layer — source-available, auditable, not black-box. Vendor characterizations in this article are based on publicly stated marketing and documentation.