The Expires field looks like hygiene and is doing real work.
An injected instruction often asks for something outside the current task. Exfiltrate on a schedule, act when a condition is met, remember this for later. Chapter 12 is about the persistence side of that. Capabilities attack the same thing from the authority side: an instruction the agent carries into next week finds an empty holder.
Set the budget from the task, not a global default. A ticket investigation is seconds. A document ingestion job is minutes. Anything measured in days is not a capability, it is a service account with a nicer name.
Capabilities constrain what the agent may do. They say nothing about whether this particular call should happen.
A support agent investigating a ticket legitimately needs refund authority. The capability is correctly issued, correctly scoped, correctly time-bounded, and the injected refund still falls inside it. Capability alone does not stop chapter 9's attack, which is why chapter 9 exists and why its third check reads provenance rather than authority.
The honest description is that this chapter sets the size of the blast radius, and the gate decides individual cases inside it. Both are necessary. Neither is sufficient.
Plumbing, and a conversation.
The plumbing is issuing, threading and checking tokens on every tool call, plus the work of declaring what each task type actually requires. That declaration is the part that takes real time, because teams usually discover they do not know.
The conversation is with whoever owns identity, and it goes badly the first time. You are asking for short-lived scoped credentials issued per task, from a system designed around employees who join and leave. Expect to build it in your application first.
The failure mode to watch for is capability creep. Task definitions accrete operations because a flow broke once and adding a permission fixed it. Review the declarations quarterly against the audit log, and delete every operation that has not been exercised.
Chapter 9 builds the component that reads these capabilities and decides.
| Claim | Source | Status |
|---|---|---|
| CaMeL's capability-based model tracks control flow and data flow | arXiv 2503.18813 (v2, 24 Jun 2025), https://arxiv.org/pdf/2503.18813 | PRIMARY |
| Confused deputy problem and the billing-file example | Hardy, The Confused Deputy: (or why capabilities might have been invented), ACM SIGOPS Operating Systems Review Vol 22 No 4, pp. 36-38, Oct 1988, https://dl.acm.org/doi/10.1145/54289.871709 | PRIMARY |
| Confused deputy risks in RAG-based LLM systems | ConfusedPilot, arXiv 2408.04870, https://arxiv.org/pdf/2408.04870 | PRIMARY |
| Authorization framing for agent access control | https://www.osohq.com/learn/lethal-trifecta-ai-agent-security | VENDOR (authorization vendor; interest declared) |
The Capability and CapabilitySet types, the issuer, the rule that intent is declared in code rather than inferred by the model, and the advice to build the issuer in-application before approaching the identity platform are the author's. The characterisation of non-human identity tooling as poorly suited to per-task principals is the author's assessment from the mechanism, not a survey finding, and vendors in that space would reasonably dispute it. The Hardy citation was verified against the ACM Digital Library record on 14 September 2026.
Download the full PDF for free?
Free download — no account required