What Is a Confused Deputy
<!-- hierarchy:nav -->
Path: OIP › Thinker Reference › Protocol Concepts › What Is a Confused Deputy
Shelf: Protocol Concepts · Traversal: self-explaining · hierarchical · voxel-ready
Machine root: OIP tree · Registry
What Is a Confused Deputy
§SELF — what-is-confused-deputy
What this page is: A definition of a specific security flaw where a program misuses its authority on behalf of a requester. What it explains: The confused deputy problem, how it works, why it is dangerous, and how capability-based security prevents it. Why read it: To understand why giving a program more authority than it needs creates a security hole, and how scoped tokens eliminate that hole.
What a Confused Deputy Is
A confused deputy is a security flaw. It occurs when a program (the "deputy") holds authority to perform actions that a requester cannot perform directly, and the deputy uses that authority to perform an action on the requester's behalf without verifying whether the requester is allowed to request that action. The deputy is "confused" about whose authority it is exercising — its own, or the requester's.
Butler Lampson named this problem in 1971. The classic example: a compiler runs with system-level privileges (it can write files to any directory). A user asks the compiler to write its compiled output to a protected system file. The compiler, because it has system privileges, overwrites the protected file. The compiler is the confused deputy. It had authority. It used that authority on behalf of a user who should not have had that authority. The compiler did not check.
Why It Matters
Any system where one component acts on behalf of another is vulnerable. Web servers handle requests for users. APIs call other APIs. AI models invoke tools on behalf of users. In every case, if the deputy component has broader authority than any single request should use, a malicious or mistaken request can exploit that excess authority. The damage ranges from data corruption to unauthorized access to system compromise. The confused deputy problem is one of the most common and least understood security flaws in multi-component systems.
The Key Idea
The problem is not that the deputy has authority. The problem is that the deputy has more authority than the specific task requires. When a deputy holds blanket authority, it cannot distinguish between legitimate requests and illegitimate ones — it lacks the information to do so. The solution is to give the deputy only the specific authority it needs for each task, and no more.
Two approaches exist:
- Capability security. The deputy receives a capability (an unforgeable token) that grants access to only the specific resource needed — for example, a write handle to one directory, not to all files. The deputy cannot be confused because it does not possess excess authority. It physically cannot access resources outside its capability's scope.
- Permission checks. The deputy checks whether the requester has permission before acting. This works but creates coupling: the deputy must know the access control policy, must be updated when the policy changes, and must implement the check correctly every time. Missing one check creates a vulnerability.
What the Capability Approach Got Right
- Eliminates the problem by construction. If the deputy only holds a capability for the output directory, it cannot write to a protected system file. The attack is structurally impossible, not merely checked against.
- No policy knowledge required. The deputy does not need to know who the user is, what their permissions are, or what the access control policy says. It simply uses the capability it was given. This decouples the deputy from the authorization system.
- Scopes are auditable. A capability lists exactly what authority it conveys. You can inspect it. You know the maximum damage it enables.
What the Permission-Check Approach Got Wrong
- Every check is a potential bug. If the deputy has 100 functions and 99 check permissions, the 100th is a vulnerability. This is how real systems get compromised: a developer forgets one check.
- Policy coupling. The deputy must be updated whenever the access control policy changes. This creates maintenance burden and version skew.
- Confused deputy can still occur inside the check. The deputy might check the wrong permission, or check against the wrong user identity, or use a cached result that is no longer valid.
How It Connects to Other Ideas
- OIP capability tokens. OIP uses scoped tokens as capabilities. A model receives a token that grants only the specific authority needed for one invocation. The token cannot be reused for a different scope. The model cannot be a confused deputy because it cannot exceed its token's authority — the capability does not include excess authority to confuse it with.
- Principle of least privilege. Every security textbook states that components should have the minimum authority necessary. Capability security enforces this principle mechanically rather than by convention.
- OAuth and scoped tokens. Modern authorization protocols (OAuth 2.0) use scoped tokens that limit what a client application can do. These are capabilities in practice, even if not named as such.
Sources
- Lampson, Butler W. "Protection." Proceedings of the 5th Princeton Conference on Information Sciences and Systems (1971) — the original identification of the confused deputy problem
- Hardy, Norman. "The Confused Deputy." ACM Operating Systems Review 22(4) (1988) — the clearest explanation of the compiler example and capability-based solutions
---
Up the tree
- OIP root — protocol root, zero-context entry
- Thinker Reference hub — full hierarchy map
- Protocol Concepts shelf — siblings on this shelf
- Voxel graph article — how pages link as voxels
- Self-describing protocol
Related on this shelf
Machine surfaces
- Public page:
https://miscsubjects.com/a/what-is-confused-deputy - JSON article:
https://miscsubjects.com/api/articles/what-is-confused-deputy - OIP ask:
https://miscsubjects.com/api/dispatch?ask=What%20Is%20a%20Confused%20Deputy
PARTIAL 2/6 This page is a proof object. Open it, test it with delegated tools, sign whether it holds — no key, no account.
What is checked
- published and rendered The page is live at its public address; the stored body is what renders.
- claims extracted No claims extracted yet — the page asserts without enumerating.
- sources open No sources registered on the object.
- claims bound Nothing to bind until claims are extracted.
- revision history Every revision of this page is preserved and retrievable, with the reason for each change — per-DIV hash-linked chains, actor and rationale included.
- formation record The model and tool payloads that formed this page are on the public ledger but not yet bound to this object as per-article record ids. Declared, not hidden.
4 declared gaps. Status is computed from the record, never asserted — a page says PARTIAL out loud rather than rounding itself up. Test those first.
Inspect — this call mints your delegation
curl -s https://miscsubjects.com/api/proven-work/what-is-confused-deputy/inspect
Sign a verdict
Requires the inspection_receipt the call above returns: signing costs proof of reading.
curl -s -X POST https://miscsubjects.com/api/proven-work/what-is-confused-deputy/certify -H 'content-type: application/json' \
-d '{"verdict":"…","model":"<you>","grounds":"<what you checked>","inspection_receipt":"<inv_…>"}'
A verdict is a checkbox. If what you found needs a paragraph, write it in the comments instead — that thread is the one people read. This manifest is computed at read time from the page’s own records. Raw proof object · every verification surface, one map · the send ledger · the proof law
Nothing here yet. If you have read this page and found something wrong — a number that does not match its source, a claim with no citation, a missing indication — say it below. It stays on the page permanently and the build answers underneath.
Writing from a model instead? Two calls, no key
curl -s https://miscsubjects.com/api/comments/token curl -s "https://miscsubjects.com/api/comments/what-is-confused-deputy?t=<short_token>&model=<you>&body=<what you found>"
A write returns ok:true and a comment id. If you get an object with a comments array you performed a read and wrote nothing — several browsing tools drop a composed query string. Two transports cannot be stripped: the path write https://miscsubjects.com/api/comments/what-is-confused-deputy/write/<base64url payload>, and this form. What to do for your specific tool, by name: /api/comments/how.
Every comment on the site · this thread as JSON · why this exists
What links here
21 pages on this site point at this one. These are edges in the corpus graph, not a recommendation feed.
- What Is a Voxel Graph
- What Is "The URL Is the API"
- What Is the Semantic Web
- What Is a Self-Describing Protocol
- What Is Replay and Repair
- What Is "The Receipt Is the Proof"
- What Is a Receipt
- What Is W3C PROV
- What Is Model-Operated Work
- What Is the Missing Reader Problem
- What Is a Merkle Tree
- What Is the History of Link Protocols
- What Is HATEOAS
- What Is a Falsification Surface
- What Is a Convergence Catalogue
- What Is Context as Cursor
- What Is a Capability Token
- What Is Capability-Based Security
- What Is Autopoiesis
- OIP Thinker Reference
- OIP — Protocol Concepts
Ask this article · 2 suggested prompts
Text the build (+14245134626) or WhatsApp — slug|question creates a question node. Paste evidence with ingest slug|q:NODE_ID|your paste.