I drew the illustration above on the back of an actual envelope (one of my new “things” these days). It’s either the most or the least appropriate medium for a diagram about attack surface. Your call.
It’s here because my colleague Mark Jaffe — NetFoundry’s Chief Strategy and Marketing Officer — just published an article called MCP Is Spreading Through Your Enterprise at Developer Speed. Your Security Architecture Isn’t, and it makes a point that I think is worth more than a link-and-a-shrug. So I illustrated one of its key ideas the old-school engineer way, because you’ve probably seen enough AI-generated images and need to look at something a little more human.
Read the article: https://netfoundry.io/ai/mcp-is-spreading-through-your-enterprise-at-developer-speed-your-security-architecture-isnt/
You’re probably seeing this happening around you: teams are wiring AI agents up to their CRMs, databases, and internal APIs through Model Context Protocol servers, because MCP makes it easy. What almost nobody is asking, and what security teams usually can’t even see, is whether the way they’re connecting those servers is quietly creating a new attack vector. In most of the deployments NetFoundry runs into, it does.
The cartoon is Mark’s “before and after,” in three panels. The first two are how nearly everyone connects an MCP server today. The third is what he argues you should be doing instead.
1: Public MCP (a.k.a. “door open to anyone”)
You publish the MCP server on a public hostname, stick a load balancer in front of it, and rely on an API key or an OAuth token to authenticate the agent.
If that gives you déjà vu, it should. This is the exact pattern we all used for REST APIs back around 2012, and it carries the exact same flaw. The server is reachable by anyone on the internet who can enumerate the endpoint or get their hands on a credential. It has to be reachable, because the agent needs to find it. Which means so does everybody else.
That’s the evil bot in the corner going “poke poke.” He doesn’t need to be clever. He just needs the door to exist.
2: Jump host inside (a.k.a. “one session pivots to all”)
“Fine,” you say. “We’ll keep everything internal. Run the agent on a jump host or a dedicated VM inside the network, nothing exposed to the public internet, problem solved.”
Except now you’ve traded one problem for a subtler one. That agent is the thing that’s calling an external LLM, ingesting user-supplied prompts, and taking actions across a dozen connected tools. It’s also now sitting on a trusted internal segment with network-level reach to systems far beyond what it actually needs. Compromise a single agent session and you’ve got a pivot point. One hop to the CRM, one hop to the database, one hop to the internal APIs.
That’s the middle panel: the agent with arrows fanning out to everything. One session pivots to all of them.
3: Outbound only (a.k.a. “don’t call me, I’ll call you”)
Here’s the fix, and the almost annoying thing about it is that it isn’t new. It’s the same outbound-only, identity-bound, least-privilege model that zero trust has been asking for all along. What’s new is applying it to the one connection (agent to MCP server) where none of your existing controls (firewalls, WAFs, network segmentation) actually operate.
The MCP server lives on a private subnet with no inbound connectivity. Instead of the agent reaching in to find the server, the server dials out to meet the agent through an authenticated, encrypted tunnel. There’s no public address to enumerate, no port to probe, nothing sitting there waiting to be found.
Or, as my little pencil agent puts it: don’t call me, I’ll call you.
That line did more work in one speech bubble than a paragraph of my prose could, which is a humbling thing to learn from a robot you drew yourself.
The part that isn’t about doors at all
The panels are the fun part, but the argument I’d actually push you to sit with is why this isn’t just an API-gateway problem wearing a new hat. Mark lays out three things MCP changes that break the old assumptions:
The client is autonomous. An AI agent doesn’t just call an endpoint. It decides which endpoints to call, in what order, with what parameters, based on reasoning you can’t fully predict or constrain up front. So your attack surface isn’t “the MCP server.” It’s the full action space of every tool that agent can touch, across every session it runs.
The session context carries risk. MCP servers receive the agent’s reasoning context right alongside its tool requests. If an attacker can inject content into that context (prompt injection in a document the agent reads, a poisoned result from an earlier tool call, a malicious server the agent got pointed at) they can influence the next tool call in the same session. The MCP connection is the channel that influence travels down.
The inventory is invisible. Most organizations have no systematic way to know which MCP servers their teams have already stood up, which agents are connected to them, or what those servers can reach. If “shadow API” gave you a twitch a decade ago, meet shadow MCP. It’s the same problem, but building up considerably faster.
That speed is the whole thesis, really. The API security industry got the better part of ten years to retrofit controls around a pattern it shipped before it fully understood. MCP is running the same curve compressed into months. Nobody’s getting ten years this time.
So what do you do with this?
If AI-agent security is landing on your desk right now, the uncomfortable truth in Mark’s piece is that the architecture decisions your developers are making this quarter are the ones that’ll be expensive to unwind later. A dev who wires an MCP server to your production CRM through a public hostname isn’t making a temporary choice. They’re setting the pattern every future agent deployment quietly copies.
The good news is that the fix is boring and well-understood. Outbound-only. Identity bound to the connection. Every session governed and observable. Panel 3, basically.
Go read the whole thing! It’s about an eight-minute read and it’s sharper than my envelope.
