Norm Hardy's best-known paper opens with a warning: "This is a nearly true story (unessential details have been changed)." The anecdote was smoothed for teaching, but Hardy kept the mechanism intact. That is why an incident from nearly fifty years ago still shows up in cloud security manuals.
The setting is Tymshare in the late 1970s, a company that rented time on large computers shared among many customers. One of its tools was a Fortran compiler, the program that translates a programmer's code into something the machine can run. Customers could tell the compiler where to write debugging output, the notes that help track down mistakes. The compiler also kept usage statistics of its own, and to write them Tymshare gave it a broad grant: permission to write any file in SYSX, the folder holding the system's own files.
The billing records lived in SYSX too. A user named /SYSX/BILL as the destination for debugging output. The compiler did as it was asked, and the record of what every customer owed was overwritten.
The operating system did its job. It checked whether the compiler was allowed to write that file, and the answer was yes. The compiler was carrying two kinds of authority: what the user had lent it, and what Tymshare had granted it for bookkeeping. In Hardy's words, there was "no way to keep them apart." The system could see which program was acting. It could not see which of that program's permissions a given write was drawing on.
The grant itself was drawn wide. It covered a whole folder, the unit the license worked in, rather than the single file the compiler needed, and that is what put the statistics file and the billing file under one permission.
Tymshare's repair let the compiler say which permission it meant to use whenever it opened a file. Hardy noted that this scaled badly. A program could hold more than two sources of authority, not all of them about files, and the change had to reach every place the program opened anything.
His own proposal was to stop letting a name and the right to use it travel separately. Give the compiler a capability for its statistics file: a single token that both identifies the file and carries permission to write it. Have the user hand over a capability for the output location instead of typing a filename. A user who holds no capability for the billing file has nothing to pass along. The file picker on your laptop runs on the same idea, handing an app access to the one file you chose.
Amazon Web Services now names the confused deputy in its permissions documentation. When a customer lets an outside company act inside its account, AWS recommends requiring a code that the company issues separately to each customer, so some other customer can't point the company at that account and have it act there. This is Hardy's question with Tymshare's kind of answer. "Who is acting" gets checked by default. "On whose behalf" is a line someone has to remember to add.
AI agents working inside a person's logged-in browser sit where the compiler sat. They can do nearly anything the person can, and they take the names of things to act on from users, documents and web pages. Asking whether the agent is permitted settles very little; the compiler was permitted too. Hardy's remedy points somewhere more specific: give the agent only the authority meant for its task, and let the name of each thing it touches arrive with permission attached. A document that says /SYSX/BILL would then be supplying a name and no permission to write to it.