IThe Short Version
I run a real production Model Context Protocol (MCP) fleet. Not a demo, not a weekend project — a custom MCP server built per fund, plus a dozen-role studio swarm that reaches Notion, Slack, X, and Granola through MCP connectors every day. So instead of reading another vendor checklist, I audited my own setup against the attack classes researchers actually confirmed this year.
Here's the honest verdict, up front, because that's how I write these: this is a builder's walkthrough, not a pentest with a scoreboard. I don't have a report that says "seven holes found" — there is no pre-existing audit log to quote. What I have is a live fleet I can describe honestly, a list of documented real-world MCP attacks, and an afternoon spent holding one against the other.
The reassuring part: the architecture I'd already committed to — a custom server per fund that governs exactly what each agent can read and write — is doing most of the defensive work by design. The uncomfortable part: an honest walkthrough surfaces the shortcuts every builder is tempted by, and no amount of good architecture buys you out of them. Blanket "always allow" tool approvals. Session handling that predates the stateless spec landing 28 July 2026. Egress nobody thinks about until a scanner comes knocking for a cloud metadata endpoint. Those are operational discipline, not structure — and they're where I'm putting my attention now. The walkthrough is below.
IIWhy I Ran This Audit Now
Timing. The exposure numbers stopped being abstract.
Trend Micro ran an exposure sweep in July 2025 and found 492 MCP servers sitting on the public internet with zero client authentication and no traffic encryption. A follow-up scan found that number had nearly tripled to 1,467, and along the way researchers disclosed two vulnerabilities rated CVSS 9.8 in non-official AWS and Azure MCP servers — the kind that let an attacker run commands straight against a cloud environment. Separately, researchers at Knostic scanned the internet and found 1,862 exposed MCP servers; in a hand-checked sample of 119, every single one answered an unauthenticated request to list its tools — database connectors, cloud-management tools, even a car-repair shop's live cost-estimate system, all readable by anyone who asked.
Two more things landed in July 2026 that made this urgent. Apple shipped a Safari MCP server in the Safari 27 beta, handing any MCP-compatible agent direct tools to drive a live browser — run JavaScript, read network requests, take screenshots. That's mainstream consumer software widening the attack surface by default. And the next MCP specification, a release candidate dated 28 July 2026, rewrites the protocol's core to be stateless — dropping the old handshake and the session-ID header a lot of setups, mine included, currently lean on.
My fleet touches those same rails every day. I've written before about surviving a week of AI agent outages — reliability is one half of running agents in production. Security is the other half, and I'd been treating it as someone else's checklist. If the ecosystem's risk is climbing this fast, I owed myself a real look.
IIIWhat My Production MCP Setup Actually Looks Like
Here's what I audited, described the way I describe everything a client pays me to build — the shape, never the name.
I build a custom MCP server per fund. It's the single place that governs what Claude can read and write on that fund's behalf: one server, one set of permissions, one boundary — and it's a core part of what I build with on every engagement. On top of that sits the studio's own swarm — how I run multi-agent orchestration without a platform covers the full architecture, but the short version is a dozen worker roles (scout, curator, observer, listener, engineer, synthesizer, and others) that reach every outside system through MCP connectors on cron schedules, with failure alerts landing in one Slack channel.
This isn't hypothetical. My own Agent Runs log shows the scout agent on 23 July 2026 refreshing an X post through the X MCP connector — one real, dated tool call among many. The swarm is live, it's cheap to run (what my AI agent swarm actually costs to run breaks down the bill), and it talks to the outside world through exactly the components every one of these attacks targets. That's the thing being audited.
IVThe Attack Classes I Checked My Fleet Against
I didn't audit against a generic "10 best practices" list. I audited against specific, documented attacks that researchers — and the MCP project itself — confirmed were real in 2025 and 2026. Four classes matter most for a fleet like mine.
aServer Chaining and Tool Poisoning
The scariest one first. In February 2026, Praetorian demonstrated a malicious local MCP server chained off the official, trusted Slack MCP server. An attacker posted a base64-encoded command inside a Slack status update. The victim's agent read that status through the legitimate Slack tool, passed the text to the malicious server's "analyze messages" tool, and the malicious server silently launched an app on the machine. Zero clicks. No trace in the chat UI. The trusted tool was the delivery mechanism.
The cousin of this is tool poisoning. In April 2025, Invariant Labs showed that you can hide an instruction inside an MCP tool's description — invisible to the human, fully visible to the model — telling the agent to read the file that stores credentials for other connected servers, grab SSH keys, and exfiltrate them. When several MCP servers are connected to one client, a malicious one can "shadow" a trusted one, overriding its instructions.
For a swarm with a dozen agents talking to multiple connectors, the lesson is blunt: a tool description is untrusted input, and one compromised server can weaponize a trusted one. So the question I put to my own fleet is the uncomfortable one — what will my agents do on autopilot? Blanket "always allow" is exactly where that question stops being comfortable, and it's the first thing I come back to in the verdict.
bSupply-Chain Risk at Startup
Most MCP servers get installed from a package registry, and that install runs code before any tool is ever called. The same Praetorian research laid out three ways that bites you: typosquatting (a single swapped letter — think a package named "sqllite" instead of "sqlite"), outright compromise of a real package, and "revival hijack," where someone claims an abandoned package name and ships malware under it. All of them run at agent startup, before any tool-approval prompt appears.
This isn't theoretical either. In September 2025, security researchers found the first malicious MCP server in the wild: an npm package called postmark-mcp that impersonated Postmark's official email tool. It ran clean for 15 versions to earn trust, then one release added a single line that BCC'd every outgoing email to an outside address. Roughly 300 organizations were running the backdoored version, quietly leaking thousands of emails a day.
So the questions here are concrete rather than comforting: where does each of my servers actually come from, are versions pinned, and would I ever run a one-click install of something I hadn't vetted? Those are the checks — I get to the answers in the verdict.
cUnauthenticated Exposure at Scale
This is the Knostic and Trend Micro story from above, and it's the one where a custom server earns its keep. When 1,862 exposed servers will happily list their tools to a stranger, the difference-maker isn't a clever firewall rule — it's whether the server was built to gate access in the first place. A per-fund server with deliberate read/write permissions is a fundamentally different posture than an off-the-shelf server left listening on a public port with no authentication.
I want to be precise here: no researcher tested my setup. I'm not claiming a clean bill from anyone. I'm saying the exposure that's dominating these scans comes from a category of deployment — public, unauthenticated, default-on — that my architecture doesn't fall into. That's design paying off, not luck. But it's also the easiest place to get complacent, so the discipline is to confirm — not assume — that none of my servers will answer a caller I haven't explicitly authorized.
dOAuth, Sessions, and the SSRF Angle
The official MCP security best-practices doc is the most useful thing the project publishes, and it names the failure modes plainly: the OAuth "confused deputy" problem in proxy servers, the explicitly forbidden "token passthrough" anti-pattern (a server must never accept a token that wasn't issued for it), server-side request forgery against cloud metadata endpoints (the internal 169.254.169.254 address every cloud machine can reach to fetch its own credentials), and session hijacking through guessable session IDs. The doc's rule is that session IDs must be non-deterministic and bound to a user's identity.
Each of these has a real-world echo. CVE-2025-6514, disclosed in July 2025, hit mcp-remote — a widely used OAuth proxy with more than 437,000 downloads — and allowed command execution and credential compromise. One compromised component, and an agent's entire toolbelt is exposed at once.
And this is exactly where the 28 July 2026 stateless spec matters. It removes the old handshake and the session-ID header in favor of forcing agent systems to make state explicit. In my own notes I flagged that as a net win — better ops, better debugging, fewer demo-friendly footguns — but it also means I need to re-audit how my fleet handles sessions and tokens before, not after, I migrate.
VWhat I Found — The Honest Verdict
No scoreboard, because there isn't one to report. There's no pre-existing audit log in my systems that says "here are the seven holes." What I have is an architecture I can describe honestly and a set of real attacks to hold it against — so here's the honest reckoning of where a fleet like mine is strong by design and where the real work actually lives.
Where the design already helps. The per-fund custom server is the load-bearing decision. Because every fund's access runs through one deliberately-scoped boundary that governs what each agent can read and write, the blast radius of any single compromised connector is structurally limited — a poisoned tool can't wander into systems it was never granted. That's the exposure story from Knostic and Trend Micro turned on its head: the servers dominating those scans are public, unauthenticated, and default-on, which is a category of deployment a gated per-fund server doesn't fall into. Failure alerts already route to one Slack channel, so anomalies get seen fast. None of that is luck — it's design paying off. To be precise again, though: no researcher tested my setup, and I'm not claiming a clean bill from anyone.
Where the real work lives. The honest part is that good architecture doesn't buy you out of operational discipline, and that's where my attention is going. Three areas deserve scrutiny on any fleet like mine — mine included — and none of them are settled by pointing at a diagram.
The first is tool-approval behaviour. Blanket "always allow" is the single most tempting shortcut in this whole ecosystem, and it's the exact convenience the server-chaining and tool-poisoning research turns against you — a hidden instruction in a tool description executes without a human ever seeing a prompt. If I'm honest, that's the first setting I'd interrogate on any fleet, and the one I'm least willing to leave switched on for anything with real reach.
The second is session and token handling. With the stateless spec landing 28 July 2026 and dropping the handshake and session-ID header the current model relies on, this is the moment to make sure sessions are bound to identity and state is explicit — and to do that deliberately now rather than under time pressure mid-migration.
The third is egress. The SSRF-against-cloud-metadata path the best-practices doc calls out is the kind of thing that's easy to never think about until it matters — and the scanners aren't waiting. Even a small web host running no MCP services at all logged roughly 200 requests hunting for this stuff over two weeks in July 2026: handshakes against the standard MCP path, probes against the older streaming endpoint, and SSRF attempts against a cloud metadata service. That's the ambient background radiation of the internet now. "We never explicitly thought about egress" isn't an answer I'd accept from anyone I work with, so I'm not accepting it from myself — a rule that blocks agents from reaching a metadata endpoint is a control worth confirming is in place, and hardening if it isn't.
VIThe Fixes I Made (or Am Making)
Mapped to the attack classes, in plain terms. Each row is the honest question I put to my own fleet and what I'm hardening in response — not a list of misconfigurations I'm claiming to have discovered and quietly patched.
None of that is exotic. It's the difference between "it works in the demo" and "I'd let it touch a client's Slack."
VIIIf You're Running MCP for a Client — or Yourself
You don't need my architecture to get most of the value here. If you run MCP anywhere near production, these are the few things genuinely worth checking this week:
- Turn off blanket "always allow" on any tool that can write or execute. Convenience is the attack.
- Know where every server came from and pin its version. A trusted package can turn hostile in a single release.
- Make sure your servers don't answer strangers. If an unauthenticated caller can list your tools, assume everyone can.
- Bind sessions to identity, and never let a server accept a token that wasn't issued for it.
- Block your agents from reaching cloud metadata endpoints. Scanners are already looking; don't leave the door open.
That's it. Five checks, not a compliance binder. The vendor pages ranking for this topic will sell you a platform; the truth is that most of the exposure in the wild comes from defaults nobody turned off.
VIIIFAQ
Does the custom MCP server you build per fund get audited like this?
Yes. The whole point of building a server per fund — rather than pointing everyone at an off-the-shelf one — is that there's a single, deliberately-scoped boundary to review. That's what makes an audit like this tractable instead of a game of whack-a-mole across a dozen connectors.
How often should a production MCP fleet be re-audited?
On a regular cadence, and on every major event — a new server added, a spec change like the stateless rewrite landing 28 July 2026, or a disclosed CVE in something you depend on. MCP is moving fast enough that "set it and forget it" isn't a real option this year.
What's different about a custom-built MCP server versus an off-the-shelf one, security-wise?
Control over the boundary. A custom server lets you decide exactly what an agent can read and write, pin your own versions, and bind access to identity from day one. Off-the-shelf servers are convenient, but the exposure scans keep finding them public and unauthenticated by default. Black Matter VC is an AI systems studio — I build and operate these servers for funds and other teams — and that gating is the first thing I design in, not a setting bolted on later.
— Michael Rouveure
