---
slug: what-is-confused-deputy
title: What Is a Confused Deputy
canonical: https://miscsubjects.com/a/what-is-confused-deputy
---

<!-- hierarchy:nav -->
> **Path:** [OIP](https://miscsubjects.com/a/oip) › [Thinker Reference](https://miscsubjects.com/a/oip-thinker-reference) › [Protocol Concepts](https://miscsubjects.com/a/oip-protocol-concepts) › **What Is a Confused Deputy**
>
> **Shelf:** Protocol Concepts · **Traversal:** self-explaining · hierarchical · voxel-ready
> **Machine root:** [OIP tree](https://miscsubjects.com/api/dispatch?map=1&format=markdown) · [Registry](https://miscsubjects.com/api/dispatch?registry=1)

# 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:

1. **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.

2. **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](https://miscsubjects.com/a/oip) — protocol root, zero-context entry
- [Thinker Reference hub](https://miscsubjects.com/a/oip-thinker-reference) — full hierarchy map
- [Protocol Concepts shelf](https://miscsubjects.com/a/oip-protocol-concepts) — siblings on this shelf
- [Voxel graph article](https://miscsubjects.com/a/what-is-voxel-graph) — how pages link as voxels
- [Self-describing protocol](https://miscsubjects.com/a/what-is-self-describing-protocol)

## Related on this shelf

- [What Is Autopoiesis](https://miscsubjects.com/a/what-is-autopoiesis)
- [What Is Capability-Based Security](https://miscsubjects.com/a/what-is-capability-security)
- [What Is a Capability Token](https://miscsubjects.com/a/what-is-capability-token)
- [What Is Context as Cursor](https://miscsubjects.com/a/what-is-context-as-cursor)
- [What Is a Convergence Catalogue](https://miscsubjects.com/a/what-is-convergence-catalogue)
- [What Is a Falsification Surface](https://miscsubjects.com/a/what-is-falsification-surface)
- [What Is HATEOAS](https://miscsubjects.com/a/what-is-hateoas)
- [What Is the History of Link Protocols](https://miscsubjects.com/a/what-is-link-protocol-history)

## 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`

