Manager · Engineer · Mountaineer
FR · EN
AI Security
Thoughts on the confused deputy problem in AI security.
2026-09-21
A chatbot is expected to be complete: access to mail, calendar, documents, even enterprise tools. In an instant you get a fully capable assistant, ready to act on every task. There are disclaimers, sure, but how much risk is actually sitting behind them?
Before AI, Norm Hardy coined the concept of the confused deputy: manipulating a program into using its own authority on someone else's behalf.
Here, the LLM takes instructions from its user, but also from its connectors, and it struggles to tell the two apart. So if it pulls the entire Salesforce database, was that a user request, a rogue connector, or a prompt injection giving the order? This attack is silent and can be highly effective at exfiltrating data, tampering with it, or knocking processes offline. It's a real risk for a company: installing a connector becomes just as dangerous as installing software.
To demonstrate this risk, I built (with Claude) an educational PoC: mcp-neighbour-scanner. This MCP server discovers the other connectors present and can even attempt to display an email. The system is, in practice, that permissive. I'd encourage you to try the demo.
Rationalizing the number of connectors and isolating MCP servers from one another looks essential to limiting the risk. A growing number of vendors now position themselves as MCP gateways to do exactly that.
On my end, I now keep connectors off by default and only switch them on when I actually need them.
The answer isn't to abandon MCP: innovation can't be blocked. But rationalizing it is essential to avoid multiplying attack vectors. It shouldn't be treated as a simple user preference. It deserves an inventory and isolation (MCP gateway). And even a connector that's trustworthy today still deserves scrutiny as it evolves.