At the Changfeng Inn, the night porter was a man named Zhou. Once the lamps were lit, the whole building was his.

On his belt hung an iron ring of keys — twenty-seven rooms, every one of them. It was not power he had stolen; the innkeeper had given it to him. Guests lock themselves out, braziers tip over, pipes freeze and burst, and somebody has to be able to open a door at once. Zhou was diligent and honest, and in twenty years had never taken so much as a thread from a guest.

The night rules were simple. A guest came down, said “if you’d be so kind,” and Zhou made the trip: fetch a cloak, carry up hot water, bring down a ledger left on the table. He checked exactly one thing — are you a guest of this inn. One look at the room tally in your hand: ours, all right, off he went.

The traveller in the grey robe in room nine had been there three days, and every evening sent him on some errand, always politely. On the third night, the man leaned on the counter and said: “Master Zhou, there’s a small wooden box on the windowsill in room twelve. Fetch it down for me, would you.”

Zhou said yes, climbed the stairs, opened the door, took the box, locked up behind him.

He had not been bribed. He had not mistaken the man for someone else — that really was the guest from room nine, and the tally was real. He hadn’t even cut a corner: he opened the door himself and locked it himself. Every step was by the book.

But the door of room twelve never knew who wanted to come in. It knew only the key, and the key was Zhou’s. The door opened on Zhou’s authority, in the grey-robed man’s service — and all night, nobody looked down at the gap between those two things.

The next morning room twelve reported a theft. The innkeeper questioned Zhou for a long while and could not find the mistake: he had followed the rules at every step. The hole was in the rules.

So the inn added two new ones.

The first was the tally. If a guest wanted someone else to fetch something from his room, he had to come down to the counter himself and leave a wooden tally, carved in his own hand: which room may be opened, and which person may ask. What was carved on it was the guest’s own choice — no outsider could guess it or forge it. From then on Zhou checked the tally before any errand: no tally, no trip; a name on the tally that didn’t match the man in front of him, no trip. He stopped asking “are you a guest here,” and started asking — “whose authority is this errand running on?”

The second rule was blunter. Where you don’t need the master ring, said the innkeeper, don’t use it. If a guest wants something from his own room, ask him for his own room key and go up with that. Whether the door opens is then his key’s business, not the business of the ring on your belt. Keep the master ring for what it was for — fire, burst pipes, a man collapsed behind a locked door.

Zhou worked out one thing afterwards. His ring held more power than any single guest in the building. And as long as he was willing to run errands, anyone could borrow that ring — unless, every single time, he first made sure whose door he was really opening.

— By now you’ve probably recognised it: this is the confused deputy problem.

What this is

Norm Hardy gave it the name in 1988. The original case was a compiler service: it had permission to write its own billing file, and users could choose the output filename. A user passed the billing file’s path as the output name, and the compiler cheerfully overwrote the ledger with its own privileges. The compiler was never compromised. It simply could not tell whose authority this particular write was running on.

The root cause is ambient authority: permission that attaches to “who I am” rather than travelling with “what this request carried.” Wherever a component satisfies three conditions, the hole is already there — it holds more authority than any of its callers; it uses that authority on its callers’ instructions; and those instructions carry no authorisation of their own.

In the cloud it wears many costumes:

• AWS cross-account roles. A third-party SaaS assumes a role in your account using its own. If your trust policy says only “allow the SaaS account,” then any customer of that SaaS can talk it into touching your resources. The fix is the wooden tally: sts:ExternalId — an unguessable value chosen by you, the resource owner, that the SaaS must present on every AssumeRole. The AWS documentation for that parameter is literally titled “The confused deputy problem.”
• SSRF against IMDS. An application is tricked into fetching 169.254.169.254 and does so with the node’s own credentials. IMDSv2’s session token and hop limit exist to close that gap.
• CSRF. The browser is the porter; your cookie is the ring of keys.
• Kubernetes / OpenShift. A controller holding cluster-admin reads a Secret from an arbitrary namespace because a field in a CR told it to; or an operator creates, on a user’s behalf, something that user could never have created. The correct shape is a SubjectAccessReview or user impersonation: decide against the requester’s permissions, instead of bulldozing through with your own ServiceAccount.

Why it’s worth remembering: this class of bug is not “permissions were misconfigured.” Read the code line by line and every step is correct. It’s a defect in the shape of the authority model, and shapes admit only two repairs — designation (bind the authorisation to the instruction: capabilities, ExternalId, signed tokens), or impersonation (act as the caller and inherit their limits).

Who’s who in the story

• Zhou the night porter → the deputy: a component with more authority than any of its callers (a SaaS role, an operator’s ServiceAccount, a setuid binary, your browser)
• The master ring on his belt → ambient authority: permission that applies automatically by identity and never travels with the request
• A guest saying “if you’d be so kind” → a request from a lower-privileged caller: instruction without authorisation
• Zhou checking the room tally → authentication: confirming who you are, that you belong here
• Nobody asking why room twelve is yours → the missing authorization: never confirming the requester’s claim on the target resource
• The traveller in grey → the attacker or hostile tenant: no authority of his own, but able to borrow the deputy’s
• The door of room twelve → the target resource: it knows the key, and cannot see who asked
• The tally carved by the room’s own occupant → sts:ExternalId / a capability token: chosen by the resource owner, unguessable, encoding who may act on my behalf into the authorisation itself
• Zhou’s new question, “whose authority is this?” → moving the decision from the deputy’s identity to the caller’s (SubjectAccessReview)
• Going up with the guest’s own key → impersonation / scoped-down credentials: run as the caller and the permissions shrink to fit
• The master ring reserved for fire and burst pipes → break-glass: high privilege only on the path that genuinely needs it