What jumps out to me is not that MCP has security bugs. Of course it does. The unsettling part is that the same old classes of bug — prompt injection, SSRF, trust abuse between services — are now getting a second life because agent builders are treating one internal agent like a trusted coworker instead of like untrusted input. That feels like the real failure mode here.
The Ars piece makes a decent case that the protocol itself is only part of the problem. The more interesting issue is the architecture people are rushing into around it. Once you let one agent hand instructions to another, and then let credentials travel with that handoff, you’ve basically built a hallway full of assumptions and very little verification. That’s not some exotic “AI risk.” It’s the oldest enterprise mistake in the book: internal traffic is safe because it’s internal. We’ve been paying for that assumption for decades.
I also think the “protocol pivoting” label is useful mostly as a wake-up call, not because it names a wholly new attack. The researcher and the other security people quoted seem to disagree a bit on whether this is a new class or just prompt injection with extra steps. I’m closer to the second view. If malicious text can move from one agent to another and end up acting like a privileged task, that’s still prompt injection in spirit. But the cross-protocol angle matters because it shows how quickly trust can evaporate when you chain tools together. The interesting part is the translation loss: one system thinks it’s receiving delegated work, another thinks it’s processing a normal request, and nobody re-checks the source.
The Google example is the part I’d actually study in code. It sounds much less mystical and much more like classic sloppy HTTP handling: redirects, target validation, unsafe base URLs. That’s useful because it tells you the fix is not “wait for smarter models.” It’s boring defenses. Validate aggressively. Treat every hop as hostile. Don’t let a request that started life as agent chatter turn into a privileged network call without a very explicit authorization step. If this article pushes people toward better guardrails, good. If it just convinces them to rename the same old hole, less good.
What I don’t know from the article is how widespread the practical blast radius is once you move beyond demos and proof-of-concepts. “Millions of organizations” is the sort of broad claim that can be true in a vague sense and still hide a lot of nuance. Some environments will have enough containment that this is noisy but manageable; others will be a disaster waiting to happen. I’d want to know how often these agent chains actually exist in production versus how often vendors are selling the architecture before the controls are real.
Still, the admonition at the end is the one I’d pin to the wall: anything passed from an LLM to a tool should be treated like input from the internet. Not “kind of like.” Exactly like. Until teams internalize that, agent-to-agent systems are going to keep turning trust into an exploit surface.
Reference: MCP for agent-to-agent comms may be the riskiest protocol you've never heard of
