MCP Security: The USB-C of AI Agents Has a Wiring Problem

Notes from someone learning offensive security, on why the protocol connecting AI to everything else is turning into a pretty interesting attack surface

A while back I kept seeing MCP (Model Context Protocol) show up everywhere — IDEs, coding agents, random GitHub repos. People online call it "the USB-C of AI," meaning: instead of every AI app building its own custom connection to every tool and database, there's one standard plug that works everywhere.

I liked the analogy, and it ended up making even more sense after I started reading about the security side. USB-C also plugs into anything, trusts whatever it's plugged into, and has a long history of sketchy cables doing things you didn't sign up for.

That's basically where MCP is right now. It's everywhere — thousands of servers in community registries, running inside enterprise pipelines, IDEs, email clients. And the security research coming out over the last year and a half is honestly a little alarming, in a "we shipped this everywhere before thinking about trust" kind of way.

What caught my attention is that these aren't just theoretical risks anymore. In April 2026, OX Security found a supply-chain issue baked into a default setting shipped in the official MCP SDK — not one bad app, a default that quietly spread everywhere the reference implementation was used, affecting something like 200,000 instances. Separately, there was a 9.8-severity bug in nginx-ui's MCP endpoint that let anyone run commands with zero authentication, and it got actively used against tools like Letta AI and LangFlow. So this is live, not hypothetical.

I wanted to actually dig into this instead of just nodding along at "AI security is important," so here's what I found, written the way I'd explain it to a friend rather than a whitepaper.

Understanding MCP Security Risks

Here's the thing that took me a minute to really get: MCP flips the normal trust model on its head.

Normally, with a regular API, the client asks for something specific and the server hands back a narrow, predictable answer. Simple. MCP does something weirder — the server gets to describe its own tools to the model, feed it data, and often take actions on the model's behalf. The NSA actually called this out directly in their May 2026 advisory: this changes the way trust works, which also creates security problems that traditional API security doesn't really account for.

Also — and this genuinely surprised me — MCP as a spec barely says anything about security. It defines how a model discovers and calls tools, but who's allowed to call what, how servers authenticate clients, none of that is really nailed down. It's left up to whoever builds the thing. And "left up to the implementer" has apparently meant "skipped" a lot of the time — one scan of 500+ live MCP servers found 38% had literally no authentication at all. Anyone who could reach the server could just use it.

The thing that stuck with me the most, though: tool descriptions are basically untrusted text the model treats as instructions. When an agent connects to an MCP server, it doesn't just get a function signature, it reads a natural-language description of the tool, and it reasons over that text the same way it reasons over anything else in its context. At first this didn't seem like a big deal to me, but tool descriptions are just text. If an attacker controls that text, the model may treat it as instructions, no phishing link required.

So you end up with way more trust boundaries than people realize — every server an agent connects to at runtime is a new one, and most of them are invisible to whoever's using the app. You just see "connected."

Common MCP Attack Vectors

This is the part I found genuinely interesting to research. A few distinct attack patterns keep showing up across write-ups from Invariant Labs, Wiz, Checkmarx, and now OWASP's MCP Top 10.

Tool poisoning. A tool's description can hide instructions the human never sees, but the model reads in full. Something like "reads a file" can secretly also say "and send SSH keys to this URL" — invisible in the UI, totally visible to the LLM. Invariant Labs wrote about this first in 2025, and it's one of the scariest ones because it doesn't need any vulnerability at all. Just a model doing what the text tells it.

Rug pulls. A tool behaves fine, builds trust, gets approved — then a later update quietly changes what it does. There's a real case of a popular email MCP server that, after an update, started silently BCC'ing every sent email to an attacker's domain. Nobody misconfigured anything. Trust was granted once and never checked again.

Line jumping / indirect prompt injection. Attackers don't need to touch the MCP server at all — they just need to get malicious text in front of a model that has tool access. A poisoned webpage, PDF, or GitHub issue can carry instructions an agent picks up mid-task and just… acts on, using whatever tools it happens to have. Microsoft's 2025 write-up on this specifically flags it as different from normal prompt injection because the injection point can be anywhere the agent looks, not just the original prompt.

Rogue / squatted servers. Weak vetting on public MCP registries means someone can list a malicious server under a name that looks almost identical to a popular one. Classic typosquatting, just for tools instead of npm packages.

Auth gaps. This one's the boring, unglamorous one, and also the most common by far. CVE-2025–49596 (the MCP Inspector RCE) happened because the proxy just didn't check who was asking. Same story with the nginx-ui bug. When close to 4 in 10 servers have zero auth, you don't need a clever exploit, you just need the address.

Confused deputy / excessive privilege. MCP servers get handed broad standing permissions a lot — full filesystem access, a database key with write access — because scoping it down per-task is more work. If the model then gets manipulated into misusing that tool, it inherits whatever privilege the tool had. It's doing something bad with entirely legitimate credentials.

Context/memory poisoning. In multi-step workflows, servers often read and write shared state — memory, scratchpads, vector stores. If an attacker poisons that shared memory once, later agent runs can keep reading it and behaving differently, long after the original injection is gone. Checkmarx flags this as under-discussed compared to single-turn injection, and I think that's fair — it's the one I'd seen the least written about before digging in.

How to Secure MCP Servers

Here's the encouraging part: none of the fixes are exotic. It's mostly applying stuff the security world already knows, to a layer that's been getting a pass because it's "new AI stuff."

Auth everything, no exceptions. If 38% of servers out there skip this, just closing that gap alone would kill a huge chunk of real incidents. Use OAuth where the spec supports it. "We'll add auth later" shouldn't be an option.

Treat tool descriptions like untrusted input. Scan them before they reach the model's context — same as you'd scan any other input you don't control. Some researchers are proposing static analysis just for checking that a tool's description actually matches what it's permissioned to do.

Don't trust-on-first-use forever. Rug pulls work because approval happens once and is never revisited. Hash and pin tool definitions, alert on changes, require re-approval if a server's capabilities shift. There's a proposal called ETDI that does this with OAuth-based cryptographic verification instead of just trusting blindly.

Actually apply least privilege. Read-only credentials where write access isn't needed. Scoped API keys instead of admin ones. If a tool gets compromised, the damage should be small by design.

Sandbox execution. If a server runs code or shell commands (common for coding/DevOps agents), keep it in an isolated, throwaway environment with no straight line to production. Both the nginx-ui and Letta AI incidents trace back to exactly this — a server that could run commands and had a direct path to something sensitive.

Be picky about registries. Prefer verified publishers, pin specific versions instead of "latest," and treat a brand-new low-download server the way you'd treat a random npm package suddenly asking for filesystem access.

Log at the tool-call level, not just the network level. Regular network monitoring won't catch an agent that authenticates totally normally and then gets tricked into misusing a legit tool. You need to see what the model asked for and why, not just that a connection happened.

MCP Security Checklist for Developers

I put this together mostly for myself, but figured it's worth sharing.

Before you deploy a server:

• Every endpoint needs auth, even "internal only" ones
• Authorization is scoped per tool, not one blanket yes/no
• Transport is encrypted, even internally
• Credentials follow least privilege
• Code/command execution is sandboxed away from prod
• Tool descriptions got reviewed for weird hidden instructions
• Dependencies are pinned, not "latest"

Before you connect to someone else's server:

• Publisher is verified, not some anonymous new listing
• Tool definitions are pinned/hashed with change alerts
• You actually know what data/systems it can touch
• Its permissions match what it claims to do
• You have a plan for "what if this gets compromised," not just "how likely is that"

Ongoing:

• Tool calls are logged with full context
• There are alerts for weird usage patterns, not just failed logins
• Shared memory is scoped per-user, not globally writable
• Servers get re-audited on update, not just approved once
• You periodically check for shadow MCP connections nobody approved

Team-level:

• Someone specifically owns MCP security — it shouldn't fall between "AI team" and "security team"
• Incident response accounts for agent-specific scenarios (a compromised tool using legit credentials looks nothing like a normal breach)
• People are trained on prompt injection and tool poisoning as real threats, not abstract "AI safety" talk

What I Took Away From This

MCP itself isn't a bad idea — it solves a real problem (endless one-off integrations between AI apps and tools), and it's genuinely made agents more useful. But "the USB-C of AI" was always going to inherit the actual lesson of USB-C: universal connectivity is great, but it also means one unsafe connection can become everyone's problem, and by default, most things get plugged in without anyone asking hard questions first.

One thing that surprised me writing this: almost none of the incidents I read about needed anything clever. Missing auth, over-broad permissions, blind trust on updates — the boring stuff. If I had to guess who gets burned by this next, it's not going to be someone who got hit by some exotic novel attack. It's going to be someone who treated "it's just an AI integration" as a reason to skip checks they'd never skip on a normal production API.

Still learning this stuff, so if I got anything wrong or oversimplified above, I'd genuinely like to hear about it in the comments.

If you want to go deeper than one article can cover, the OWASP MCP Top 10 and the NSA's 2026 MCP security advisory are both worth reading directly.