The Confused Deputy Keeps Getting Promoted

Delegation is the thing computers do. A user asks a program to act on their behalf, and the program carries some authority to do so. The confused deputy is what happens when the boundary between "acting for whom" becomes ambiguous. The same structural question keeps surfacing in different eras, wearing different clothes.

Around 1977, a Fortran compiler at Tymshare overwrote a billing file. Nobody hacked anything. A user told the compiler to write debugging output to a file path that happened to be the billing ledger. The compiler had permission to write files in its home directory and it accepted filenames from users. It had no mechanism for keeping those two authorities apart. Norm Hardy published the story in 1988 and gave it a name: the confused deputy. The compiler's write access came from where it lived in the system, not from an explicit grant tied to a specific action. Authority floated in the environment, available to anything running in the right context. Security researchers call this ambient authority.

His proposed fix: bind authority directly to the thing being accessed, so permission and designation travel together. No ambient privileges. No confusion about who authorized what.

Then the web rebuilt the pattern from different materials. When a browser sends a request, it automatically attaches session cookies for the target domain. A malicious page can trigger a request to your bank; the browser dutifully includes your authentication. The bank sees a properly authenticated request and acts on it. OWASP describes this as the confused deputy problem directly. Peter Watkins explicitly connected the two in 2001. Same mechanism: ambient authority, attached by context rather than intent, lets a deputy act without knowing on whose behalf.

Each time, the response was to scope the authority. Add a token. Make the deputy prove it knows who it's working for. The same pattern appeared again with over-scoped API keys and delegated OAuth tokens, where applications carried broader credentials than any single action required. Each time, fixes worked, because the deputy could be taught to distinguish instruction from data. The confusion was circumstantial.

In December 2025, the UK's National Cyber Security Centre drew a different kind of line. LLMs, they wrote, are "inherently confusable." Instructions and data occupy the same token stream, distinguished by nothing except next-token prediction. An LLM processes a user's request and a webpage's content in the same context window and cannot reliably tell which is which. The confusion lives in the architecture itself. No implementation patch addresses it.

This matters more now than it did when LLMs were chatbots. Agents hold real authority: network access, tool invocation, the ability to write to production systems. The deputy is confused, and it's carrying keys.

The proposed fix sounds familiar. MCP's authorization specification mandates audience-bound, scoped tokens. Academic frameworks for agent security explicitly cite Dennis and Van Horn's 1966 capability model. Bind authority to specific resources. Eliminate ambient privileges. Make the deputy carry proof of what it's allowed to touch.

Hardy would recognize the vocabulary. The fix is as old as the problem, refined by the object-capability community for four decades. Why it never became the default, why access-control lists and perimeter models won instead, is a longer story. Probably one worth understanding before assuming this time will be different, given that the deputy just got harder to teach.