1. Problem and context
A service accepts a request to read or write a resource. The service itself has broad permissions, while the caller should receive only a narrow authority. If the service uses a caller-controlled path or resource ID and then acts with its own privileges, an attacker may make it perform an action the caller could not perform directly. AWS calls this a confused deputy problem.
Capability-based security addresses this by making authority explicit in a reference or token that both identifies the resource and carries the right to use it. The capability should be unforgeable, scoped, and passed only to code that needs it. The question is a general security-model discussion; it is not limited to one cloud provider or programming language.
2. What the interviewer evaluates
- Authority reasoning: Can you distinguish authentication, authorization, and possession of a delegated authority?
- Threat modeling: Can you show the deputy, the confused input, the privileged action, and the attacker-controlled boundary?
- Least privilege: Do you attenuate a capability to one operation, object, tenant, or time window?
- Lifecycle judgment: Can you explain revocation, expiry, auditability, and leakage without claiming capabilities solve everything?
- Trade-off clarity: Can you compare capabilities with ambient identity and policy checks under realistic operational constraints?
A weak answer says “use a token.” A strong answer explains what the token authorizes, how it is constrained, and what happens when it leaks or must be revoked.
3. Questions to clarify first
Is the deputy local code, a service, or a cloud role?
The pattern is the same, but the boundary changes. A library can accidentally inherit a file handle; a service can use its workload identity; a cloud role can be tricked into acting on a cross-account resource. Name the principal that owns the broad authority.
What resource and operation are being delegated?
Clarify whether the authority is read, write, append, delete, invoke, or a compound operation. A capability for one object and one method is easier to audit and revoke than a wildcard resource name.
What are the revocation and leakage requirements?
Ask whether immediate revocation, offline use, multi-tenant isolation, or non-repudiable audit is required. These constraints determine whether to use an in-memory reference, a signed token, a lease, a broker, or a central policy check.
4. A 30-second answer framework
“A confused deputy appears when a less-privileged caller supplies a resource name to a more-privileged service, and the service uses its own authority without binding the request to the caller’s intended scope. Capability security makes authority explicit: pass an unforgeable reference or token that names one resource and allowed operation, and require the deputy to use only that reference. I would attenuate capabilities on delegation, bind them to a tenant and audience, expire or revoke them according to risk, and log issuance and use. Capabilities reduce ambient authority and confused-deputy risk, but leakage, replay, recovery, and audit remain design problems.”
5. Step-by-step explanation
Step 1: Separate identity from authority
Authentication answers who is calling. Authorization answers what that identity may do under a policy. A capability is a concrete authority-bearing reference: possession plus the reference's unforgeable integrity grants a specific action. The model can coexist with identity, but it does not rely on a global ambient identity check at every internal call.
Step 2: Draw the confused-deputy flow
Suppose a report service can read any file under its workload identity. A user sends file=/reports/other-tenant.csv. If the service validates only that the request is authenticated, it becomes a deputy: the user supplies a name, and the service spends its broader privilege. The missing binding is “this caller was explicitly given authority to this object.”
Step 3: Replace names with scoped authority
Instead, an authorized owner creates a capability for a specific report and operation, such as read-only access for tenant A until a deadline. The caller passes that capability to the service. The service dereferences the capability or presents it to a broker; it does not turn an arbitrary path into authority. Object-capability research describes this pattern as encoding access rights in individual objects and restricting their interactions.
Step 4: Attenuate on delegation
When a component delegates, it should produce a weaker capability: fewer methods, one child object, a shorter lifetime, a tenant constraint, or a rate limit. Never widen a capability because a downstream component is convenient. A wrapper that exposes only readMetadata() is safer than passing a file-system handle with write and delete rights.
Step 5: Handle tokens and replay
If the capability crosses a process boundary, use a protected reference such as a signed, audience-bound token or a broker-issued handle. Include resource, action, tenant, issuer, audience, expiry, and a unique ID where replay matters. Verify integrity and context before use. Encryption can hide contents, but it does not by itself enforce scope or stop replay.
Step 6: Plan revocation and recovery
Pure in-memory capabilities are easy to pass but hard to revoke globally. Leases, short expiry, indirection through a revocation store, or key rotation trade immediate control against availability and latency. If a token is leaked, revoke the handle or binding, rotate the relevant key if necessary, and inspect usage logs; simply deleting a user record may not invalidate an already-issued capability.
Step 7: Preserve audit and policy boundaries
Record who issued a capability, what scope it carried, which deputy used it, and the result. Keep identity context for accountability even when the capability is the authorization primitive. For high-risk actions, combine capability checks with policy checks such as tenant state, legal hold, or step-up authentication.
6. High-quality sample answer
“The confused deputy is a privilege mismatch. A caller supplies a resource name, but a service with broader rights performs the operation. The service is confused because the name is treated as authority. AWS documents this pattern for cross-account and cross-service access.
I would pass an explicit capability instead: an unforgeable reference or protected token scoped to one tenant, object, operation, audience, and expiry. The deputy can use only that capability, and delegation creates an attenuated child. For a remote token I would verify integrity, context, and replay constraints, then log issuance and use.
Revocation is the trade-off. I might use short-lived leases or a revocable handle for sensitive actions, accepting a lookup cost. Capabilities reduce ambient authority and make the data flow easier to inspect, but they do not remove leakage, recovery, audit, or policy requirements. I would test cross-tenant attempts, token replay, confused names, and revocation races.”
7. Common mistakes
- “Authentication is enough” → Lets a broad service identity decide scope → Bind the operation to an explicit, constrained authority.
- “A signed token is automatically a capability” → Ignores audience, operation, expiry, and replay → Treat integrity as one property and enforce scope separately.
- “Use the caller’s path after checking login” → Recreates the confused-deputy flow → Pass a capability or broker handle rather than an arbitrary name.
- “Capabilities eliminate authorization policy” → Misses tenant state and contextual rules → Combine capability checks with high-risk policy checks.
- “Revocation is free” → Overlooks distributed copies and offline use → Choose leases, indirection, or expiry based on the revocation requirement.
- “Hide all identity context” → Makes incident investigation impossible → Preserve issuer, subject, scope, and use events for audit.
8. Follow-up questions
How is a capability different from an ACL lookup?
An ACL lookup starts with an identity and resource name, then consults policy at use time. A capability carries a delegated authority reference through the data flow. ACLs centralize policy and revocation; capabilities make authority explicit and can reduce ambient authority, but they need lifecycle and leakage controls.
Can a capability be copied?
An in-process reference can often be copied by code that already holds it. The security boundary is who can receive it and whether it is attenuated. A remote token can be replayed unless it is bound to a channel, nonce, audience, or short lease. Copyability is a risk to model, not a reason to assume the token is harmless.
How would you secure a capability URL?
Treat it as a bearer credential: use HTTPS, narrow scope, short expiry, non-guessable entropy, audience binding, rate limits, and redaction from logs and referrers. For sensitive or reusable actions, prefer a one-time exchange for a revocable handle.
Where does the confused deputy still appear in cloud systems?
It appears when a service role, build runner, or storage proxy accepts a user-controlled resource identifier and uses its own broad role. Bind the request to a resource policy, tenant, and intended action; AWS's cross-account guidance is a concrete example of this boundary.