Confused Deputy Problem

A confused deputy is a privileged program that can be induced to use its own authority for a caller’s improper purpose. The caller supplies a name, identifier, or request; the deputy resolves it under the wrong security context. The resulting operation is valid under the deputy’s credentials even though the caller could not perform it directly.

The failure is about authority selection, not merely excess privilege. A service can hold exactly the permissions its legitimate function requires and still become confused when it cannot distinguish the authority it should use for one request from the authority it should use for another.

Hardy’s compiler

Norm Hardy named the problem in 1988 after an incident at Tymshare. A Fortran compiler could write debugging output to a user-supplied filename. It also held a “home files license” so it could write usage statistics in its system directory. A user supplied the billing file’s name as the debugging destination, and the operating system accepted the write because the compiler—not the user—had the necessary authority.¹

The compiler therefore combined two sources of authority: the invoker’s authority and its own. It intended to use the former for debugging output and the latter for statistics, but the pathname-based interface gave it no way to express that distinction. Blacklisting the billing filename or its directory would only repair one instance; other sensitive files and legitimate uses would remain.

Hardy’s capability solution binds designation and authorization. The caller passes a capability for its intended output file, while the compiler holds a separate capability for its statistics file. Each operation explicitly selects the appropriate capability, so the caller cannot redirect the compiler’s ambient authority by naming another resource.

Contextual binding in cloud IAM

The same pattern appears when a shared service acts for multiple customers. AWS’s example is a third party that assumes a customer’s IAM role: if another customer supplies the victim’s role ARN, an unchecked deputy may access the victim’s account. An ExternalId controlled by the deputy and required by the role’s trust policy binds the request to the intended customer. For service-to-service calls, conditions such as aws:SourceArn, aws:SourceAccount, and organization identifiers similarly restrict the context on whose behalf a service principal may act.²

These controls do not make an ARN or role secret. They add contextual evidence that the deputy is acting for the expected principal, resource, account, or organization. The general design question is: what unforgeable or policy-checked context ties this request to the authority it is allowed to exercise?

Authorization oracles and durable authority

Signing services, CI/CD systems, OAuth brokers, code-signing services, and payment switches can act as authorization oracles: their outputs remain valid even when the process that requested them was malicious. Policy must therefore check the object being authorized—target, operation, amount, calldata, and context—not just authenticate the requesting workload.

The October 2026 Binance incident illustrates the containment consequence. According to Binance’s preliminary report, an attacker gained unauthorized access to an internal wallet-signing service and used it to establish malicious EIP-7702 delegations. Suspending withdrawals and shutting down hot-wallet services did not remove those on-chain authorizations. Binance had to issue new authorizations to the zero address to clear them, using a specialized procedure because the wallet used multi-party computation.³

This separates two response tasks:

• Revoke access used to create authority — credentials, sessions, deployment tokens, endpoints, and service reachability.
• Revoke authority already created — active grants, delegations, signed artifacts, approvals, and other attacker-created state.

An inventory of compromised machines and rotated passwords does not establish containment until the second task is complete. The required revocation procedure may live in a different control plane from the compromised service, which makes it a threat-model and incident-response requirement rather than an implementation detail.

Defenses

• Minimize ambient authority and pass resource-specific capabilities where the architecture supports them.
• Bind delegated actions to the intended principal, resource, account, and operation with contextual conditions.
• Validate the semantic object being signed or authorized, not only the caller’s identity.
• Inventory durable authority a compromised deputy can create and rehearse its revocation independently of ordinary service shutdown.
• Treat each deputy’s separate duties as separate security contexts; do not assume one process identity keeps them distinct.

Related

• eip-7702-delegation — a protocol mechanism whose persistent delegation makes the revocation plane explicit.
• threat-modeling — deputies and their authority flows belong in the system model, including recovery paths.
• common-mode-failure — local controls can all share the same false assumption that a validly authorized request is legitimate.

Sources

• Norm Hardy 1988 — The Confused Deputy: (or why capabilities might have been invented)
• Amazon Web Services — The confused deputy problem
• 29 October 2026 Binance Security Incident: Initial Findings and Response Update

Footnotes

1. Norm Hardy 1988 — The Confused Deputy: (or why capabilities might have been invented) ↩

2. Amazon Web Services — The confused deputy problem ↩

3. 29 October 2026 Binance Security Incident: Initial Findings and Response Update ↩