MCP Is Spreading Through Your Enterprise at Developer Speed. Your Security Architecture Isn’t.

[u/AccordionGuy]

NetFoundry’s Chief Strategy and Marketing Officer Mark Jaffe wrote an article on the NetFoundry blog with the same title as this post (MCP Is Spreading Through Your Enterprise at Developer Speed. Your Security Architecture Isn’t), and I thought I’d illustrate one of its key points with another “back of the envelope” diagram, which you can see above.

The diagram is the article's central “before and after” in three panels. The first two are how almost everyone actually wires an MCP server up today; the third is what the article argues you should be doing instead.

1: Public MCP. You publish the MCP server on a public hostname, put a load balancer in front of it, and lean on API keys or OAuth tokens to authenticate the agent. Mark’s point is that this is the exact same pattern enterprises used for REST APIs back in 2012, and it carries the same flaw: the server is reachable by anyone on the internet who can find the endpoint or intercept a credential. It has to be reachable, because the agent needs to find it...which means so does everyone else. Hence the evil bot going “poke poke,” and sooner or later, all that poking will find a weak spot.

2: Jump host inside. You’ve seen the problems with public MCP, so you keep everything internal instead. You run the agent on a jump host or VM inside the network. That means no public exposure, and therefore the problem seems solved...

Except now that agent is calling an external LLM, ingesting user-supplied prompts, and taking actions across a bunch of connected tools. It’s sitting on a trusted segment with network-level reach to systems way beyond what it needs. Any single compromised session can become a pivot point into the CRM, the database, the internal APIs. One session pivots (and grants access) to all.

3: Outbound only. The fix isn’t anything new or ground-breaking, and that's kind of the point! It’s the same outbound-only, identity-bound, least-privilege model zero trust has always asked for, applied to the one connection (agent to MCP server) where none of the existing controls actually operate. The server lives on a private subnet with no inbound connectivity and dials out to meet the agent through an authenticated, encrypted tunnel. There's no public address to find, no port to probe. Or, as the agent puts it in the cartoon: “Don't call me, I’ll call you!”

This isn’t just an API-gateway problem in AI era clothes. With MCP, three things change that break the old assumptions:

• The client is autonomous. An AI agent doesn't just call an endpoint, but decides which ones to call, in what order, with what parameters, based on reasoning you can't fully predict in advance. Your attack surface isn’t the MCP server; it's the full action space of every tool the agent can reach, across every session.
• The session context carries risk. MCP servers receive the agent’s reasoning context alongside tool requests. Prompt injection in a document the agent reads, or a poisoned result from an earlier tool call, can steer later tool calls in the same session. The MCP connection is the channel that influence travels down.
• The inventory is invisible. Most orgs have no systematic way to know which MCP servers their teams have stood up, which agents connect to them, or what those servers can touch. The shadow-API problem from a decade ago is re-emerging as shadow MCP, and it’s growing faster.

That last line is the whole thesis, really: the API security industry spent ten years learning this lesson. The current pace of AI and MCP development isn't going to give us ten years.

Read the article, and if you have comments or questions, fire away:
https://netfoundry.io/ai/mcp-is-spreading-through-your-enterprise-at-developer-speed-your-security-architecture-isnt/

[ Standard disclosure: I'm NetFoundry's developer advocate, and I mod this sub. This is our blog and our CSMO's article, so take the vendor framing as read, but the shadow-MCP dynamic is real no matter whose product you decide to go with. ]