Today, the Model Context Protocol (MCP) is the commonly agreed-upon mechanism to facilitate the discovery, execution, and sharing of tasks across AI-driven tools. In essence, it serves as the universal adapter for AI tool and agent integration.
The value proposition makes sense on the surface: let models and agents seamlessly connect to enterprise data sources, query databases, and trigger workflows without building custom API glue for every new tool. But for those of us who have been doing security for more than five minutes, you know this lack of friction is also an open invitation for atrocious security boundaries.
Enter the National Security Agency (NSA) - a phrase almost no one wants to hear. They recently released an advisory addressing this exact tension: Model Context Protocol (MCP): Security Design Considerations for AI-Driven Automation. The report makes their position abundantly clear: relying on MCP to serve as your primary security layer is fundamentally broken.
To be clear, this doesn’t mean MCP is useless. It serves as an excellent translation layer for structured data. But there's a difference between a discovery/translation layer and a security layer. There's a reason most advanced firewalls aren't embedded into router operating systems - they serve different purposes. Let's review what the authors of the NSA report highlighted, focus on the real-world operational challenges, and look at why these challenges ultimately point toward a sidecar model.
One of the first and most important concepts the authors call out is the shifting dynamic of application communication and execution. Whereas traditional software had servers acting on behalf of client requests, the MCP architecture flips this relationship entirely. Clients are now acting on requests and context provided by the server. This means the security controls and assumptions we've had in the past, like client-side authentication and input validation checks, aren't as valid as they used to be. The developers writing the client applications now own those security responsibilities, even if they didn't realize it. Good luck explaining that to your local vibe-coder. We're introducing the AI-era equivalent of the classic Server-Side Request Forgery (SSRF). As the NSA notes:
"For MCP systems, the risks include dynamic tool invocation (where agents can autonomously call new tools at runtime), implicit trust relationships (where one agent's output is assumed valid by another without explicit verification), and context sharing (where long lived or overlapping context windows can leak, blend, or misalign across tasks)."
This implicit trust is a core problem with agentic workflows. We've talked at length about why Zero Trust principles have become so essential in agentic workflows, and the NSA calls it out in this paper as well. (Although it seems they went to great lengths to never say those two words.)
But this is also why the authors' suggestion that securing this architecture requires "reworking of the entire lifecycle from the design of the protocol and agent behaviors, to runtime scheduling" is obviously unrealistic. Enterprise IT isn't going to completely rework its architectures for this or wait for vendors to do it for them. Instead, the answer is simpler but harder to execute: an inherent, absolute distrust of all inputs and outputs.
Along similar lines, the authors call out dynamic tool discovery in the "Design for boundaries" section. For any truly secure enterprise system, dynamic tool discovery is completely off the table. If your agent can autonomously find and call new tools at runtime without strict, static white-listing, you aren’t running an automated workflow, you’re running a shadow-IT generation engine.
The structural vulnerability of MCP deepens when evaluating how the protocol handles payloads. Because MCP handles multi-step workflows, data parsed by one component becomes the input for the next. When input validation and parameter parsing break down, it opens the door to output poisoning. The NSA report flags this directly:
"MCP enables the transmission of structured objects, such as context, configuration, and payloads, through serialization mechanisms that often lack strict validation or schema. […] This problem echoes well-known serialization risks… with some newer implications for the application-level protocol that could embed content for natural language parsing."
This lack of validation is where we see the blueprint for serious exploitation. Think back to Log4Shell. Log4Shell wasn't an access control failure or a network permission issue; it was a fundamental failure of input validation and parameter parsing. A vulnerable server took an untrusted text string from a log and dynamically parsed it as an executable JNDI command.
In an MCP ecosystem, a poisoned input from a user, compromised output from a downstream MCP server, or otherwise unexpectedly formed input can embed system-level commands in place of regular data. Because subsequent agents implicitly trust output from earlier tools or agents, they parse it, leading to session hijacking, social engineering of downstream agents, or accidental data destruction. When long-lived context windows blend across tasks, a single piece of poisoned data can linger in the agent's memory, silently derailing future automation.
We've written about Identity in agentic systems before, and I think the authors of this paper didn't necessarily give enough credit to where On-Behalf-Of does try to solve access-control issues within MCP server use. But the crux of their argument still rings true - you can't expect MCP servers to always do security right and the lack of mandatory, embedded RBAC (or ABAC) is a recipe for disaster. Now add in lack of standards around bearer tokens and you're just asking for security issues. The "Token or session security" section outlines very clearly the issues with the current model.
Now let’s look at this pragmatically: OBO flows are optional, architecturally complex, and brand new. In production environments, developers aren't incentivized to deliver robust identity controls. Instead of setting up granular OBO scoping, it's more likely they'll pass a single, highly privileged bearer token down the entire chain. This lazy token propagation expands the permission footprint exponentially, creating a massive opportunity for session hijacking and credential theft.
What's probably the most frustrating part of all of this is that we've spent the last decade fixing these issues in web APIs by mandating JSON Web Token (JWT) expirations, implementing tight Mutual TLS (mTLS) bindings, and building strict token-exchange microservices. MCP treats these hard-learned lessons as an afterthought, forcing client tool developers to build custom token rotation wrappers for every single integration.
Another place where there's been some, but nowhere near enough, work is Supply Chain Attacks in generative AI. OWASP has identified LLM03:2025 Supply Chain to try to address some of the risks, and we see companies like Chainguard are doing their best. When you read the NSA's advisory's warnings on "Misconfigurations and poor implementation," it reads exactly like the open-source supply chain compromises we've dealt with over the past few years. EventStream in 2018, ctx and phpass in 2022, and fsevents in 2023, are all examples where ownership of commonly used packages was obtained by malicious actors. Imagine an enterprise pulling a seemingly benign MCP server to do something like check their stock price for their intranet home page; they are inviting this exact style of supply-chain risk all over again.
To mitigate these exposure windows, the NSA suggests a traditional network engineering countermeasure:
"In order to protect the MCP environment, use a filtering outgoing proxy (e.g., Squid, tinyproxy) or an enterprise data loss prevention (DLP) solution, with specific resource URLs and access methods, for connections destined to external entities."
This advice contains some of the most and least pragmatic advice of the whole document. Companies today are likely to have an outgoing firewall or proxy, so reusing that architecture is a good start. But we've been doing DLP for decades and still struggle to get it right, so I think this is unlikely to be part of any near-term solution. Regardless, this highlights a critical shift away from pure "prompt security" and toward outcome-based security. Instead of playing an impossible game of whack-a-mole trying to sanitize natural language prompts, outcome-based security focuses strictly on the execution boundaries and egress points: What destination is this tool actually hitting, and what data is attempting to leave the system?
However, while the NSA's advice to "constrain and sandbox tool execution" is theoretically perfect, forcing all distributed, asynchronous agents to route traffic through a monolithic proxy or DLP appliance introduces more problems than it solves. A central proxy sits too far away from the agent's internal state to understand why a specific parameter was parsed or whether a tool call represents a malicious output poisoning attempt. This is just us trying to use existing architectures to solve new problems, without really thinking about the best or most sustainable way.
This is container security all over again. When microservices exploded, we quickly learned that routing internal pod-to-pod communication through even virtualized firewalls became operationally untenable. So instead, we built the service mesh and embraced the sidecar architecture.
When the NSA writes about needing to "filter and monitor output pipelines and chained execution," they are describing the core tenets of Zero Trust.
The issues outlined by the NSA and the distributed, untrustworthy nature of agentic workloads demand adopting Zero Trust principles. Instead of relying on an underspecified protocol to secure itself, or a centralized network proxy to police traffic, security enforcement must be attached directly to each agent. We've discussed why having the security embedded into the agent is problematic, so the next best option is in an isolated security sidecar attached directly to each agent's local compute environment.
By deploying an agentic sidecar model, you establish a hardened execution boundary that handles the messy realities of MCP integrations:
The NSA isn't telling us to banish MCP from our tech stacks; they are telling us to stop treating it like a trusted security boundary. MCP is an excellent translation layer for structured tools, but it is fundamentally an open-ended conversation starter. To build resilient, autonomous agent ecosystems that ship value without creating massive systemic risk, we have to rethink trust. Stop trusting that agents are acting appropriately, and instead Assume Breach when agents communicate to each other. The Model Context Protocol is not what will protect you from a breach, and proxies are only going to get you so far. So as much as I hate to sell what we're building, I truly think agentic sidecars are the only way to address the current reality.
If you're interested in evaluating the security of your MCP ecosystem, or if you're currently designing or implementing agentic AI workflows and grappling with these boundaries, we'd love to hear from you. Feel free to send us an email at questions@generativesecurity.ai to keep the conversation going and provide us your thoughts. We always love hearing from others working on these hard problems.
About the author
Michael Wasielewski is the founder and lead of Generative Security. With 20+ years of experience in networking, security, cloud, and enterprise architecture Michael brings a unique perspective to new technologies. Working on generative AI security for the past 3 years, Michael connects the dots between the organizational, the technical, and the business impacts of generative AI security. Michael looks forward to spending more time golfing, swimming in the ocean, and skydiving... someday.
