TL;DR
MCP is trying to reinvent the wheel, and it’s square. It repeats all the mistakes RPC spent decades fixing and then adds a full Freddy Kruger of security nightmares. Combine that with human cognitive biases and fallibility, and it’s obvious: outsourcing life-and-death security calls to the end user is a terrible idea. MCP must learn from history, from present risks, and from psychology. If it does not, responsible enterprise customers will avoid it. Irresponsible enterprise customers [1] would then be in real trouble.
1. Lessons from RPC: Why History Matters
Remote Procedure Calls (RPCs) emerged in the 1980s to make calling a function across a network feel like calling a function locally (Birrell & Nelson, 1984). Over time, developers learned the hard way that naive approaches didn’t scale and could not be made secure.
Key Lessons:
Remote Procedure Call (RPC) initally lacked a universal standard, leading to fragmentation across platforms and languages. This created the classic N×M problem: each of N clients and M servers may require unique adapters, multiplying integration costs. See Tanenbaum & van Steen, Distributed Systems: Principles and Paradigms, 2nd ed., Ch. 4 (2007). The solution was standardization.
Standardization: OpenAPI and the Language Server Protocol (LSP) are succeeding because they have been standardized across vendors. Formal standards processes help, but adoption and community acceptance are the keys.
2. New Risks: Simon Willison’s “Lethal Trifecta”
Simon Willison has been the clearest voice warning about MCP’s new dangers. See his Bay Area AI talk and his post on the Lethal Trifecta
2.1 Prompt Injection as the Root Vulnerability
Prompt injection is the LLM-era equivalent of SQL injection. It happens because instructions and untrusted input get concatenated into a single string (Willison, 2025a).
2.2 The “Lethal Trifecta”
· Access to private data
· Exposure to untrusted content
· Ability to exfiltrate data externally
Examples already seen include GitHub MCP, Supabase MCP, Atlassian MCP, and GitLab Duo MCP—each vulnerable in real-world scenarios (Willison, 2025b).
2.3 Guardrails and User Reliance Don’t Work
“Guardrails” that claim 95% effectiveness are useless in security—5% failure is catastrophic (Allard de Winter, 2025).
2.4 Neutralizing the Risk
· Remove private data access.
· Sanitize untrusted input.
· Prevent exfiltration.
3. Human Fallibility: Lessons from Anderson’s Security Engineering
Ross Anderson’s Security Engineering (2020, Ch. 2: Usability and Psychology) is a bible on why systems fail when humans are asked to do the heavy lifting.
· SSL/TLS certificate warnings: users just click through.
· Email macro warnings: users enabled macros to get their work done, enabling the Melissa and ILoveYou worms.
· Personal firewalls: too complex; users made rules that were either too open or broke functionality.
3.2 Cognitive Limits and Base Rate Neglect
Humans ignore low-probability risks. If most interactions are benign, they’ll assume the next one is too—right until an attack lands.
3.3 Application to MCP
MCP explicitly asks end users to choose which tools to connect, and to approve or deny actions. This is exactly the flawed pattern Anderson warned against.
3.4 Principles for Better Design
· Secure defaults: tools should start in “safe mode,” not dangerous mode.
· Least privilege: no tool should get more capability than it absolutely needs.
· Deny by default: risky combinations (the trifecta) should not even be possible without deliberate, administrative override.
· Institutional controls: in enterprises, security policy belongs to administrators, not line-level users.
4. Synthesis: What MCP Must Learn
· From RPC history: Don’t repeat solved problems.
· From Simon Willison: Don’t ignore the new attack surface.
· From Anderson: Don’t dump the responsibility on users.
Conclusion
MCP’s current trajectory is untenable for enterprise. It combines the worst of all worlds: old RPC mistakes reborn and new AI-driven vulnerabilities ignored. And by outsourcing decisions to users, it all but guarantees failure.
The fix is clear:
- Bake in schema rigor, versioning, and robust transport.
- Engineer away the lethal trifecta by design, not by “user choice.”
- Default to safety, minimize privilege, and shift responsibility to system designers and administrators.
You might decide to build on top of infrastructure that has a good record of serious attention to security, such as Cloudflare. If you have a real business need for agents, and trust the infrastructure provider, that’s defensible.
But if you are going to roll your own, know what you are dealing with and do the right things. Otherwise, MCP won’t just fail—it will fail loudly, expensively, and predictably.
References
Anderson, R. (2020). Security Engineering (3rd ed.). Wiley.
Willison, S. (2025a). Bay Area AI Talk.
Willison, S. (2025b). The Lethal Trifecta.
Allard de Winter (2025). Commentary on the Lethal Trifecta.
Wikipedia: Language Server Protocol.
[1] More than likely, irresponsible enterprise customers will be in the majority.