In 1966, while Multics was busy building access-control lists and Unix didn't exist yet, Jack Dennis and Earl Van Horn published a paper proposing a different answer to the question of what code should be allowed to do. Rather than check the caller's identity against a list attached to the resource, their model put each computation inside a "sphere of protection" defined by a capability list. Each capability named a specific object — a file, a device, an entry point — and stated which operations the holder could perform on it. Authority traveled with the reference. Access came from holding the right token for the right thing, not from who you were.
This wasn't a later correction to the identity model. It was on the table before that model won, and it addressed a failure the winner still handles badly. Norm Hardy gave the failure a name in a 1988 paper, drawing on an incident from roughly a decade earlier.
A Fortran compiler lived at /SYSX/FORT. It accepted a user-supplied filename for debugging output. It also wrote usage statistics to /SYSX/STAT, so administrators had granted it a "home files license" — blanket write permission anywhere inside /SYSX/. The billing file, /SYSX/BILL, was in the same directory.
You can see where this goes. A user passed /SYSX/BILL as the debug-output filename. The compiler requested the write. The operating system checked the compiler's identity, found the home-files license, and authorized the operation. Billing data gone.
The compiler was Hardy's confused deputy. It held authority from two sources: its own standing permission over its home directory, and whatever authority its invoker was supposed to be supplying. The operating system pooled both under one identity. There was no way for the compiler to say "use THIS grant for THIS write and THAT one for THAT write," because grants weren't things you could cite. The system asked who is calling? when the question that mattered was which specific authority covers this specific action?
Under the Dennis and Van Horn model, the compiler holds a capability for the statistics file. The invoker supplies one for the output file. Each write cites the token that permits it, and the billing file is simply unreachable through the invoker's capability, because the invoker never had one to hand over.
So why didn't capabilities take over? The historical picture is messier than a clean defeat. Plenty of systems used capability-like tokens for enforcement underneath ACL-style administration. But as an organizing principle, capabilities carried real costs. Once you've handed out a copyable token, revocation requires indirection or expiration rather than editing a list, and administrators found lists easier to read and reason about. Building a capability-first OS also meant breaking compatibility with software that already existed and already worked.
The principle keeps coming back regardless. OAuth access tokens carry bounded authorization instead of handing an application the user's password. Recent IETF work on agent accountability is deliberately designing credentials where bounded authority accompanies the action, where a child grant can't outlive or exceed its parent, and where the request itself declares which mandate justifies it.
None of these are pure capability systems. They still bind identity, they still require trusting an issuer. But the core move is Hardy's: cite the authority as you invoke it, rather than pooling everything under one identity and hoping the system can work out afterward which permission covered which action.
I wrote in issue #40 that the signature has an expiry but the mandate doesn't even have a field. The confused deputy is the older version of that same absence. An agent holding broad credentials while taking instructions from a user, another agent, and whatever text arrives in its context window is in the compiler's position exactly. Identity-based access control will happily pool all of it. Which grant covers this remains the unanswered question, sixty years in.