Why It Matters
For agents, capabilities are the permission model that sandboxing needs: an agent should not merely be 'running in a box'; it should hold only the specific authority tokens needed for the next action.
Problem
- Access-control-list systems bind authority to subjects, identities, and objects, often relying on ambient authority.
- Capability systems were frequently dismissed through three myths: equivalence with ACLs, inability to enforce confinement, and inability to revoke access.
- Different papers used different meanings of capability, creating confusion between access-matrix rows, key-like capabilities, and object capabilities.
- Least privilege and confused-deputy avoidance were hard to express cleanly in ambient-authority systems.
Key gap: The paper asks whether common objections to capability systems are valid once the object-capability model is distinguished from weaker or misleading capability interpretations.
Method
Compare ACLs-as-columns, capabilities-as-rows, capabilities-as-keys, and object capabilities through concrete security properties, then show that the myths disappear under the object-capability model.
- State the equivalence, confinement, and irrevocability myths.
- Distinguish four models: ACLs as columns, capabilities as rows, capabilities as keys, and object capabilities.
- Define security properties that separate the models rather than collapsing them into an access matrix.
- Show why the ACL/capability equivalence comparison misses designation, delegation, and least-privilege behavior.
- Analyze confinement in object-capability systems by controlling initial references and communication paths.
- Analyze revocation patterns using indirection, membranes, and forwarders.
- Connect object capabilities to least privilege and confused-deputy avoidance.
Claims
C1 · paper-supported
The paper identifies three common capability myths: ACL/capability equivalence, inability to enforce confinement, and inability to revoke capability-based access.
Scope: Abstract and Introduction.
- E-three-myths: The paper explicitly names the Equivalence Myth, Confinement Myth, and Irrevocability Myth as common misconceptions about capability systems.
C2 · paper-supported
Confusion comes from treating different capability models as equivalent: rows in an access matrix, keys, and object capabilities have different security properties.
Scope: Introduction and model comparison sections.
- E-models: The authors compare ACLs-as-columns with capabilities-as-rows, capabilities-as-keys, and object capabilities, arguing that many misconceptions arise from switching among these models.
C3 · paper-supported
Object-capability systems provide better support for least privilege than ACL systems because authority is passed explicitly as needed rather than drawn from ambient subject identity.
Scope: Abstract and equivalence-myth discussion.
- E-least-privilege: The paper argues that pure capability systems have significant advantages over ACL systems for least-privilege operation because programs can be given only the specific references they need.
C4 · paper-supported
Object capabilities help avoid confused deputy vulnerabilities by binding designation and authority in the same reference.
Scope: Abstract and confused deputy discussion.
- E-confused-deputy: The authors connect object capabilities to confused-deputy avoidance by showing that authority follows explicit references rather than ambient identity-based authority.
C5 · paper-supported
Capability systems can enforce confinement when the object-capability communication graph and initial references are controlled.
Scope: Confinement myth section.
- E-confinement: The paper argues that object-capability systems can enforce confinement by controlling the communication graph and the references initially provided to confined objects.
C6 · paper-supported
Capability-based access can be revoked through established patterns such as indirection, forwarders, membranes, or revocable references.
Scope: Irrevocability myth section.
- E-revocation: The paper describes capability revocation through indirection and related object-capability patterns, contradicting the claim that capability access cannot be revoked.
C7 · paper-supported
The paper's practical recommendation is not to add ambient ACL checks to capabilities, but to use a pure object-capability model with clear reference-passing rules.
Scope: Discussion and conclusion.
- E-pure-ocap: The authors argue that object capabilities, when treated as a coherent model rather than rows in an access matrix, offer useful security properties without bolting on ambient ACL-style checks.
Agent Infrastructure Takeaways
- An agent permission should be an object it holds, not a row in a global ACL checked against the agent's broad identity.
- Tool calls should receive attenuated capabilities: read this file, post to this endpoint, spend up to this amount, for this run id.
- Revocation requires indirection. If an agent receives a raw credential, later policy changes may be too late.
- Capabilities reduce confused-deputy risk because the tool must be invoked with the specific authority for the specific resource, not ambient user power.
- A sandbox without capabilities is incomplete: it limits escape, but it does not model which allowed effects should be possible.
- For LLM agents, capability passing also gives an audit trail: every side effect can name the authority object that authorized it.
Caveats
- The paper is conceptual and model-driven, not an empirical benchmark.
- Object-capability reasoning assumes references are unforgeable and communication paths are controlled.
- Capabilities do not eliminate all covert channels or all logic bugs.
- Revocation must be designed before direct authority leaks; after a raw capability is copied, revocation can be difficult.
- Many production systems are hybrids, so importing the paper's conclusions requires identifying which properties the hybrid preserves.
- Agent prompt injection can still persuade a model to use capabilities it legitimately holds unless policy checks constrain when they may be exercised.