Capability-based security
Also called: capability security · object-capability model · ocap
Most systems you use every day answer authorization questions with an access control list. A request arrives, the system asks who is this, looks the identity up in a table, and decides. Unix permissions work this way. So do most cloud IAM systems.
Capability-based security answers the question differently. Authority is not looked up from identity; it is held. A capability is an unforgeable reference that both designates a specific resource and carries the right to use it. If you have it, you can act. If you do not, there is no table to be listed in.
Why the difference matters
Under an ACL, authority is ambient. A process acts with everything its identity is permitted, whether or not the current task needs any of it — which is exactly the ambient authority problem. Under a capability model, a process starts with nothing and can only use what it was handed, for the specific things it was handed references to.
That single change closes the confused deputy problem as a class. A deputy holding a capability for one file cannot be tricked into using it on another, because the capability names the file. There is no filename to substitute — the authority and the designation are the same object.
Where you have already seen it
The model is old and unevenly adopted, but it is not exotic:
- A file descriptor is a capability. You can pass one to a child process, and it grants access to that specific open file and nothing else.
- A pre-signed URL is a capability: it designates one object and carries the right to fetch it, without the holder having an account.
- macOS security-scoped bookmarks are capabilities — the user picks a folder, and the app receives a persistable right to that folder specifically.
The AI-shaped version
Agents make the argument concrete because they are the worst possible ACL subject. Their identity is broad by necessity — they need to read files, run commands and reach the network to be useful at all — but any individual task needs a slice of that.
Capability thinking gives the practical rule for tools and credentials: hand over the narrow right to perform one operation, not the reusable secret that would permit every operation. That is capability brokering, and it is why BitShout’s answer to “the agent needs GitHub access” is to broker one approved call rather than to hand over a token.
BitShout is not a pure object-capability system — it enforces at OS boundaries that are themselves ACL-shaped. But the design pressure is the same one: make authority something that is granted for a purpose and designates a resource, rather than something a process has because of who started it.