How it works
A confused deputy appears when a component has more authority than its caller and cannot reliably distinguish permitted work from work that merely looks valid. The deputy may be a tool server, orchestrator, retrieval service, filesystem bridge, or background worker. It receives a request, interprets caller-controlled arguments, and performs the action using credentials attached to the service itself.
The failure usually follows a short sequence:
- A caller asks a privileged component to act on a target.
- The component validates that the request is well formed but not that this caller may affect that target.
- The component uses its own broad credential or ambient permission.
- The resulting read, write, or side effect exceeds the caller's authority.
The request does not need to exploit code execution. It may only substitute a resource identifier, destination, tenant, repository, account, or path. In an agent system, those arguments can originate in a model decision, retrieved text, tool output, or prompt injection. The model is therefore not the authorization boundary. The deputy must bind each operation to an authenticated principal, an explicit delegation, an allowed target, and a narrow action. If it cannot establish that binding, it should reject the call before the privileged effect occurs.
Why it matters in an agent harness
Agent harnesses create deputies by design. They let models invoke tools, let orchestrators launch workers, and let services carry credentials that models should never see. This separation protects secrets, but it also concentrates authority behind interfaces whose inputs may be partly model-generated. A narrow-looking tool can still expose broad power if its server executes every request under one privileged identity.
The immediate engineering risk is unauthorized reach. An agent approved to summarize one repository might pass another repository's identifier to a shared connector. A worker permitted to prepare a draft might direct an export service toward a production destination. A retrieval tool might enforce valid query syntax while failing to enforce access to the requested corpus. In each case, the deputy performs a legitimate operation for an illegitimate scope.
Prompt instructions and tool descriptions cannot close this gap. They influence model behavior but do not establish authority. The enforceable control belongs at the point where the request becomes an effect. The harness should pass caller identity and delegation context through orchestration layers, while the receiving component independently checks the requested action and resource.
This also changes what useful observability looks like. A trace that records only “export succeeded” cannot show whether the export was authorized. The execution record needs the requesting principal, delegated scope, selected target, credential used, policy decision, and resulting effect. That attribution supports incident review and exposes authority laundering across multiple agents or services.
Failure containment depends on the same design. Per-run credentials, tenant-bound resource handles, allowlisted destinations, and read/write separation reduce what a confused deputy can do. Approval gates help only when the operator sees the concrete target and effect. Approving an abstract plan while allowing later argument substitution leaves the deputy problem intact.
Confused deputy vs delegated authority
Delegation is not itself a confused deputy. A harness often needs one component to act for another. The design question is whether the authority is explicit, bounded, and checked at use time.
| Axis | Confused deputy | Delegated authority |
|---|---|---|
| Source of power | The service's ambient or broadly shared privilege | A caller-bound grant for a defined operation |
| Target binding | Caller-controlled target is insufficiently checked | Grant identifies or constrains eligible targets |
| Scope | Determined by what the service can do | Limited to what the caller may delegate |
| Attribution | Effect appears to belong only to the service | Requester, delegation, and executor remain traceable |
| Expiry and revocation | Often inherited from a long-lived service credential | Defined by the delegation contract |
Least privilege reduces the blast radius but does not prove that a request is authorized. A narrowly privileged deputy can still misuse all of its available scope. Explicit delegation addresses the missing relationship between caller, action, and target.
The Rifty take
We treat authority as data that must survive every hop, not as an assumption attached to a trusted service. We accept some interface friction to make principal, scope, target, and effect explicit. If a tool cannot explain whose authority it is exercising, the call should not cross the control boundary.
Implementation checks
- Identify every service, worker, and tool that acts with more privilege than its caller.
- Require caller identity and delegation context at the effect boundary, not only at the orchestrator.
- Authorize the exact action and target after resolving aliases, paths, handles, and tenant ownership.
- Avoid shared ambient credentials when a run-scoped or task-scoped credential can express the intended authority.
- Keep untrusted content from selecting credentials, permission scopes, or approval policies.
- Bind approvals to concrete arguments and invalidate them when those arguments change.
- Record requester, delegator, executor, target, policy result, and credential class in the execution trail.
- Test cross-tenant identifiers, path substitution, stale grants, indirect tool calls, and retries after permission changes.
- Fail closed when identity, scope, or target attribution is missing or contradictory.
- Review whether a successful low-risk call can be reused as authority for a different high-impact operation.
Frequently asked questions
Can least privilege prevent a confused deputy?
Least privilege limits the damage but does not remove the flaw. A service can still misuse every permission it legitimately holds when it fails to bind a request to the caller's authority. Preventing the issue requires per-request authorization over the specific principal, action, and target.
Why are agent tools especially exposed to confused deputy failures?
Agent tools translate model-selected arguments into privileged effects. Those arguments may be influenced by prompts, retrieved content, prior tool results, or another agent. If the tool trusts its own credential without checking the originating authority and target, the model can unintentionally route power across a permission boundary.
Does an approval gate solve the confused deputy problem?
An approval gate helps only when approval is bound to the final action, target, and material arguments. A generic approval to continue is insufficient if a later model step can substitute a repository, account, destination, or path. Changed arguments should require a fresh policy decision.
What should an audit trail record for privileged tool calls?
Record the requesting principal, any delegation chain, the executing service, the resolved target, requested action, policy decision, credential class, and resulting effect. This makes authority laundering visible across orchestration hops and distinguishes a legitimate service operation from one performed outside the caller's permitted scope.