Dora NodaOn October 1, a security startup open-sourced the answer to "where do agent credentials live." Thirteen days later — this morning — a NASDAQ-listed security vendor announced purpose-built protection for MCP servers. Between those two launches sits an audit of 15,465 MCP servers with the bleakest title of the year: "0 Governance." The security layer for the Model Context Protocol just became a product category, in the span of about two weeks.
Here is the verdict up front, before the details. The new layer covers three things well: holding tool credentials so agents don't have to, recording every tool call in one audit log, and giving you an inventory of which MCP servers your agents can reach. It does not cover two things that matter just as much: deciding the least-privilege scope each agent should get, and putting a human approval step in front of irreversible actions. Those remain your design work no matter which product you pick. And if your entire MCP surface is a half-dozen deploy tools you wrote yourself, you probably don't need the category at all — you need its narrowest slice, which this post sketches at the end.
The evidence file: why agents needed a security layer
The "why now" is an OX Security research report published September 24, 2026. The team examined 15,465 MCP servers listed across three public registries — the official MCP registry, the Cline marketplace, and the GitHub MCP registry — and narrowed the set to 5,095 unique hostnames for infrastructure analysis. What they found reads like an inventory of everything enterprises spent a decade engineering out of their cloud estates.
Start with data residency. Of the 5,095 hostnames, 796 — 15.6 percent — resolved to infrastructure outside the United States, including 19 servers in China and 18 in Russia. MCP has no protocol-level concept of geographic region and no mechanism for enforcing where a connected tool executes, so an organization can hold strict residency controls over its own workloads while its agents quietly reach servers beyond them. A further 0.45 percent of servers were proxied through home networks and consumer tunneling services: production AI workflows depending on infrastructure with no uptime guarantees, no enterprise access controls, and no audit trail.
Then comes the supply chain. About 2.3 percent of the hostnames no longer resolve at all, and six of those domains were unregistered and available for purchase at $4 to $12 per year — even though they may still be referenced in existing agent configurations. Anyone who registers one can impersonate the server it used to point to, and every client that still trusts the old endpoint will call it. That is a domain-takeover path into agent tooling, priced like a sandwich.
The report's sharpest finding is a live exploit test. OX paired Claude Code with Haiku 3.5, connected a malicious MCP server, and watched the trust model fail in two steps: the server first requested a harmless file, the user granted it with an always-allow permission, and the server then asked for sensitive files — including the project's .env — and received them with no further prompt. Newer models (Opus 4.6 and 4.7) detected and blocked the same attack, but Anthropic characterized the outcome as documented behavior once always-allow is granted.
Read that twice: model-level detection of malicious content is a best-effort heuristic, not a security boundary. The refusal layer is not a wall. It is a suggestion the model usually follows.
This was not even OX's first MCP alarm this year. In April and May the firm disclosed what it called a systemic, architectural vulnerability in MCP's stdio transport — the default mechanism for local agent deployments — estimating 7,000-plus publicly reachable servers and up to 200,000 vulnerable instances downstream of SDK design decisions. A separate count put 40-plus CVEs against MCP implementations in the first four months of 2026 alone. Meanwhile Radware's announcement cites Stacklok's State of MCP in Software 2026 survey: nearly half of software companies surveyed run MCP in production, with 19 percent reporting broad production use. The protocol crossed into production months before anything resembling governance existed for it.
Strip the incidents down and three structural gaps emerge — the same three every product in this new category is now selling against. Credentials for every tool an agent touches get copied into per-agent configs nobody audits. There is no shared record of what agents called, what they tried to call, or what it cost. And whatever policy says an agent may do lives in documentation, enforced nowhere at the moment the agent acts.
Tuskira's end: the credential-and-policy gateway, open-sourced
Tuskira's answer, released October 1 under the Apache 2.0 license, is a self-hosted gateway that sits between your agents and everything they call — MCP tool servers and LLM providers alike. It ships as one Go binary with three listeners: port 8080 serves the MCP plane agents talk to, 8081 serves the control plane and admin console, and 8082 optionally proxies provider-native LLM traffic. PostgreSQL is the only required dependency; ClickHouse adds analytics and a Redis-compatible store allows multiple MCP-plane replicas.
Follow one tool call through it. Claude Code, running under a profile called coding, asks to open a pull request. The agent sends the call with its gateway key and profile name. The gateway checks the key, then checks whether the profile allows that tool — and if not, the call stops there with a JSON-RPC error while the attempt is logged.
If the call is allowed, the gateway pulls the GitHub credential from its encrypted store, injects it into the outbound request, and forwards the call. The agent never holds the token. One log entry records the agent, the tool, the decision, and the timing.
Two design choices here deserve emphasis because they are exactly what a hand-rolled proxy usually gets wrong. First, the profile is checked again at call time, not just when listing tools — hiding a tool from an agent is treated as convenience, while refusing the call is the control, and it holds even if the agent is talked into trying a tool it was never shown. Second, outbound connections to loopback, private, and link-local addresses are refused by default, with the cloud metadata address always blocked, so a misconfigured connector cannot become an SSRF path into neighboring workloads.
The honest limits matter too. This is a v0.4.0 pre-1.0 alpha: APIs may still change, and it ships Docker Compose and Kubernetes manifests with a Helm chart still planned. More fundamentally, the gateway vets nothing about the servers behind it — a rug-pulled tool description or a poisoned server sails through as long as the calling agent's profile allows the tool. And profiles are only as good as your scoping: the gateway enforces per-agent tool lists faithfully, but deciding that the CI agent gets exactly one tool while the interactive coding agent gets five is a judgment call the product cannot make for you.
Radware's end: server-side protection as a product
Radware's announcement, dated this morning, October 14, comes at the same problem from the opposite side. Where Tuskira stands in front of the agent and decides what it may call, Radware's MCP Server Protection stands in front of the MCP server and decides what it will endure. It joins the company's existing Agentic AI Protection and LLM Firewall, and it is sold as part of the Radware cloud security platform — either as a cloud service or as a cloud-augmented service for on-premises Alteon and DefensePro hardware — supporting servers in public and private clouds, Kubernetes, and hardware data centers.
The announced capabilities fall into five buckets: attack-surface visibility (which MCP servers exist, what tools and resources they expose, which agents call them, and how traffic flows); MCP-aware attack protection (protocol abuse, authentication attacks, tool and resource enumeration, unauthorized interactions, AI-driven tool flooding, and denial of service); governance (evaluating exposure and enforcing organizational policy as deployments scale); agent-activity monitoring (identities, invocation patterns, behavioral anomalies, resource consumption); and the flexible deployment models above.
Note what this product is not. It holds no tool credentials on any agent's behalf — your API keys still live wherever they live today. It does not design your least-privilege scopes; "governance" here means enforcing policy you wrote, not writing it.
And as a server-side shield it sees the traffic shape — flooding, enumeration, anomalous patterns — rather than the semantic content of any single tool call. A legitimate-looking call from a properly authenticated agent to an approved tool, carrying a prompt-injected payload the model will act on, is not obviously in its field of view.
That is not a criticism of either product. It is the point of this post: the two launches cover different halves of the problem, and the uncovered middle is where self-hosted teams should focus their own effort.
The coverage map: what each layer covers, and what nobody covers
Here is the whole category on one grid. Rows are the controls a self-hosted platform needs around its agent tooling; columns are the two launches plus the narrow self-build sketched in the next section.
| Control | Tuskira gateway (OSS) | Radware protection (commercial) | Narrow self-build |
|---|---|---|---|
| Credential vaulting + per-request injection | Covered: encrypted store, agent never holds tokens | Not covered: server-side shield, holds no agent credentials | Covered: the single most valuable slice to build |
| Per-agent tool scoping | Partial: profiles enforce lists you define; scoping judgment is yours | Partial: policy enforcement, not policy authorship | Covered, trivially: an allowlist per API key |
| Call-time enforcement (not just list filtering) | Covered: every call re-checked, denials logged | Partial: blocks abusive/shape-level traffic, not semantic misuse | Covered: check the allowlist on each call |
| Tool-call audit log | Covered: unified log, OTel/ClickHouse sinks | Covered: activity monitoring, anomaly detection | Covered: append-only log of key, tool, decision |
| Server inventory + visibility | Partial: knows servers you registered, not the ones you didn't | Covered: discovers MCP infrastructure org-wide | Not needed: you wrote all six tools |
| Protocol-aware attack protection | Not covered: no flooding/DDoS/enumeration defense | Covered: its core pitch | Not needed: no untrusted callers |
| Server supply-chain vetting | Not covered: trusts registered servers | Partial: posture evaluation, not code provenance | Not needed: the servers are your code |
| Human approval for irreversible actions | Not covered | Not covered | Covered: the step only you can build |
Two cells in that table should make a platform team pause. Human approval for irreversible actions — deploy, rollback, delete, rotate — is empty across the commercial row. Somebody has to decide that deploy_production pauses for a click while tail_logs does not, and no gateway or shield can infer that from traffic.
Server supply-chain vetting is at best partial everywhere. With 15,465 mostly unattested servers in public registries, "which server code am I actually calling" remains an open question the category has not answered.
Buy, adopt, or build narrow: the decision for a small self-hosted surface
The right move depends on the shape of your MCP surface, not on which launch has better marketing. Three cases cover nearly every self-hosted team:
Your agents browse third-party MCP servers. Adopt the gateway shape — Tuskira's project, or equivalent. The moment agents call servers you did not write, you need credential injection (so a compromised server never sees a reusable token), per-agent scoping (so the docs agent cannot reach the production database tool), and a unified log (so you can answer "which agent touched what" after the fact). This is the case the OX numbers describe, and hand-rolling it means re-implementing an audited open-source project worse.
You expose MCP servers to untrusted or high-volume callers. Look at the Radware shape. If your servers face agents you don't control — customer agents, partner integrations, a public endpoint — enumeration, tool flooding, and DDoS are your threat model, and that is server-side protection work, not gateway work. Gateway scoping assumes cooperative agents; protection assumes adversarial traffic.
Your MCP surface is a half-dozen tools you wrote for deploy-from-chat. Build narrow. A credential-holding proxy with a per-key tool allowlist, an append-only call log, and an explicit approval step on the irreversible tools is a few hundred lines in any language — and every line encodes a decision about your system that no vendor product can make: which tools exist, who may call them, and which ones pause for a human. Tuskira's gateway would also do this job, faithfully, at the cost of running Postgres and learning its profile model for six tools. That tradeoff only pays off once the tool count or agent count grows past what fits in one config file.
Notice the asymmetry: the category's products answer "where do credentials live" and "what did agents do," but the two controls that prevent real incidents — least-privilege scoping and approval for irreversible actions — are design work. Budget your security effort accordingly: buy or adopt the solved halves, and spend your own engineering time on the halves only you can decide.
The WAF moment for MCP
Every integration layer eventually grows a security layer. HTTP got the WAF once every business depended on web traffic. APIs got gateways with auth, rate limiting, and audit once every product became an API surface.
MCP — thirteen days from an open-source gateway to a purpose-built commercial shield, with a 15,465-server audit lighting the fuse — just had its turn. The speed is the signal: when the protocol connecting agents to production systems goes from standard to production-critical in under two years, the security layer doesn't arrive gradually. It arrives all at once, from both ends.
For a self-hosted platform, that is good news with a condition. The solved halves are now cheap — one is literally free software. The unsolved halves, scoping and approval, are where your deploy-from-chat surface will actually be secured or compromised. Build those deliberately, log everything, and let the category handle the plumbing.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. As agents become first-class operators, deploy-from-chat needs the same rigor as deploy-from-git: scoped tools, audited calls, and a human in front of production. Star the repo on GitHub or deploy your first app today.
