agent-readings · Capability Myths Demolished

<div class="slide-frame slide-frame--center">
  <p class="deck-kicker">agent-readings / Isolation and Sandboxing</p>
  <h1>Capability Myths Demolished</h1>
  <p class="deck-subtitle">Permissions as unforgeable authority</p>

<div class="deck-meta-strip">
    <div class="deck-meta-pill"><strong>2003</strong><span>Technical report / USENIX submission</span></div>
    <div class="deck-meta-pill"><strong>7</strong><span>claims</span></div>
    <div class="deck-meta-pill"><strong>7</strong><span>evidence refs</span></div>
    <div class="deck-meta-pill"><strong>paper-read</strong><span>status</span></div>
  </div>
</div>

---

<div class="slide-frame">
  <p class="deck-kicker">The one sentence</p>
  <h2>Capability Myths Demolished argues that object-capability systems are not just ACLs in another notation: they better support least privilege, delegation, confinement, revocation, and confused-deputy avoidance.</h2>
  <p class="deck-note">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.</p>
</div>

---

<div class="slide-frame">
  <p class="deck-kicker">Before this paper</p>
  <h2>The friction was structural.</h2>
  <div class="apple-card-grid apple-card-grid--three">
    <div class="apple-card"><p>Access-control-list systems bind authority to subjects, identities, and objects, often relying on ambient authority.</p></div>
<div class="apple-card"><p>Capability systems were frequently dismissed through three myths: equivalence with ACLs, inability to enforce confinement, and inability to revoke access.</p></div>
<div class="apple-card"><p>Different papers used different meanings of capability, creating confusion between access-matrix rows, key-like capabilities, and object capabilities.</p></div>
  </div>
  <div class="deck-callout">
    <span>Key gap</span>
    <p>The paper asks whether common objections to capability systems are valid once the object-capability model is distinguished from weaker or misleading capability interpretations.</p>
  </div>
</div>

---

<div class="slide-frame">
  <p class="deck-kicker">Core idea</p>
  <h2>Compare ACLs-as-columns, capabilities-as-rows, capabilities-as-keys, and object capabilities through concrete security properties, then show that the myths...</h2>
  <p class="deck-note">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.</p>
  <div class="idea-loop" aria-label="Agent loop">
    <div><strong>Model</strong><span>reason</span></div>
    <div><strong>Runtime</strong><span>act</span></div>
    <div><strong>World</strong><span>observe</span></div>
  </div>
  <div class="step-strip">
    <div class="step-item">
  <span>01</span>
  <p>State the equivalence, confinement, and irrevocability myths.</p>
</div>
<div class="step-item">
  <span>02</span>
  <p>Distinguish four models: ACLs as columns, capabilities as rows, capabilities as keys, and object capabilities.</p>
</div>
<div class="step-item">
  <span>03</span>
  <p>Define security properties that separate the models rather than collapsing them into an access matrix.</p>
</div>
<div class="step-item">
  <span>04</span>
  <p>Show why the ACL/capability equivalence comparison misses designation, delegation, and least-privilege behavior.</p>
</div>
  </div>
</div>

---

<div class="slide-frame">
  <p class="deck-kicker">Action grammar</p>
  <h2>The agent is an interface contract.</h2>
  <div class="apple-card-grid apple-card-grid--two">
    <div class="apple-card"><p>principal/subject: entity attempting to access resources.</p></div>
<div class="apple-card"><p>object: resource or service being accessed.</p></div>
<div class="apple-card"><p>ACL entry: object-side rule granting subjects permissions.</p></div>
<div class="apple-card"><p>capability/reference: unforgeable token held by a subject/object.</p></div>
  </div>
</div>

---

<div class="slide-frame">
  <p class="deck-kicker">Executable shape</p>
  <h2>The mechanism should fit on one screen.</h2>

```python
class Revoker:
    def __init__(self, target):
        self.target = target
        self.enabled = True

def call(self, request):
        if not self.enabled:
            raise PermissionError("revoked")
        return self.target.call(request)

def revoke(self):
        self.enabled = False

# Grant only attenuated authority.
read_only_file = ReadOnlyWrapper(file_capability)
revocable = Revoker(read_only_file)
agent_tool = Tool(file=revocable.call)

# Later:
revocable.revoke()
```
</div>

---

<div class="slide-frame">
  <p class="deck-kicker">Evidence</p>
  <h2>The proof objects.</h2>
  <div class="proof-grid">
    <div class="proof-card">
  <span>E-three-myths</span>
  <p>The paper explicitly names the Equivalence Myth, Confinement Myth, and Irrevocability Myth as common misconceptions about capability systems.</p>
</div>
<div class="proof-card">
  <span>E-models</span>
  <p>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...</p>
</div>
<div class="proof-card">
  <span>E-least-privilege</span>
  <p>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...</p>
</div>
<div class="proof-card">
  <span>E-confused-deputy</span>
  <p>The authors connect object capabilities to confused-deputy avoidance by showing that authority follows explicit references rather than ambient identity-based authority.</p>
</div>
  </div>
</div>

---

<div class="slide-frame">
  <p class="deck-kicker">Claim map</p>
  <h2>What the review actually supports.</h2>
  <div class="claim-grid">
    <div class="claim-card">
  <span>C1 · paper-supported</span>
  <p>The paper identifies three common capability myths: ACL/capability equivalence, inability to enforce confinement, and inability to revoke capability-based...</p>
  <small>E-three-myths</small>
</div>
<div class="claim-card">
  <span>C2 · paper-supported</span>
  <p>Confusion comes from treating different capability models as equivalent: rows in an access matrix, keys, and object capabilities have different security...</p>
  <small>E-models</small>
</div>
<div class="claim-card">
  <span>C3 · paper-supported</span>
  <p>Object-capability systems provide better support for least privilege than ACL systems because authority is passed explicitly as needed rather than drawn from...</p>
  <small>E-least-privilege</small>
</div>
<div class="claim-card">
  <span>C4 · paper-supported</span>
  <p>Object capabilities help avoid confused deputy vulnerabilities by binding designation and authority in the same reference.</p>
  <small>E-confused-deputy</small>
</div>
  </div>
</div>

---

<div class="slide-frame">
  <p class="deck-kicker">Agent infrastructure</p>
  <h2>What changes if you build systems.</h2>
  <div class="apple-card-grid apple-card-grid--two">
    <div class="apple-card"><p>An agent permission should be an object it holds, not a row in a global ACL checked against the agent's broad identity.</p></div>
<div class="apple-card"><p>Tool calls should receive attenuated capabilities: read this file, post to this endpoint, spend up to this amount, for this run id.</p></div>
<div class="apple-card"><p>Revocation requires indirection. If an agent receives a raw credential, later policy changes may be too late.</p></div>
<div class="apple-card"><p>Capabilities reduce confused-deputy risk because the tool must be invoked with the specific authority for the specific resource, not ambient user...</p></div>
  </div>
</div>

---

<div class="slide-frame">
  <p class="deck-kicker">Caveats</p>
  <h2>What this does not prove.</h2>
  <div class="apple-card-grid apple-card-grid--two">
    <div class="apple-card"><p>The paper is conceptual and model-driven, not an empirical benchmark.</p></div>
<div class="apple-card"><p>Object-capability reasoning assumes references are unforgeable and communication paths are controlled.</p></div>
<div class="apple-card"><p>Capabilities do not eliminate all covert channels or all logic bugs.</p></div>
<div class="apple-card"><p>Revocation must be designed before direct authority leaks; after a raw capability is copied, revocation can be difficult.</p></div>
  </div>
</div>

---

<div class="slide-frame">
  <p class="deck-kicker">Run it</p>
  <h2>No PoC yet.</h2>
  <p class="deck-note">No PoC yet - contributions welcome. A small PoC could implement an object-capability wrapper around filesystem/network tools and show attenuation plus revocation.</p>
  <div class="reference-list">
    <ul><li>Paper: <a href="https://srl.cs.jhu.edu/pubs/SRL2003-02.pdf">Capability Myths Demolished</a></li><li>Project/code: <a href="https://papers.agoric.com/papers/capability-myths-demolished/abstract/">https://papers.agoric.com/papers/capability-myths-demolished/abstract/</a></li><li>kernel_capabilities: <a href="https://sel4.systems/Research/pdfs/sel4-formal-verification-os-kernel.pdf">seL4</a></li><li>import_capabilities: <a href="https://webassembly.github.io/spec/core/">WebAssembly</a></li><li>threat_model: <a href="https://arxiv.org/abs/2302.12173">Indirect Prompt Injection</a></li></ul>
  </div>
</div>

Note: This deck is synthesized from `data/reviews/capability-myths-miller-2003.json`. Update the review record, then run `bun run build`.