Capability-Based Security for AI Agents, Explained

Capability-based security for AI agents starts from a simple idea: authority should travel with a reference rather than with an identity. In a capability system, the only way to act on a resource is to hold a capability, an unforgeable token that names both the resource and the operation you are allowed to perform on it. No token, no action. This is a fifty-year-old idea from operating-systems research, and it turns out to be the cleanest answer to a very 2026 problem: how do you let a non-deterministic model build and run software without letting it reach anything it wasn't explicitly given?

What a capability actually is#

A capability is defined as "a communicable, unforgeable token of authority" that bundles two things: a reference to a specific object and the set of access rights over it (Wikipedia: Capability-based security). The classic concrete example is a Unix file descriptor. When a process calls open("/etc/passwd", O_RDWR), the descriptor it gets back lives in kernel memory, out of reach of user code, and its very existence proves access was legitimately granted. The model traces to Jack Dennis and Earl Van Horn in 1966 and was developed into the modern object-capability model, where "a capability describes a transferable right to perform one (or more) operations on a given object," carried by "an unforgeable reference that can be sent in messages." The whole model, in its own words, "relies on not being able to forge references."

Two properties matter. First, designation and authority are fused: naming the thing and being allowed to touch it are the same act. Second, capabilities are transferable and unfabricable. You can pass one you hold to someone else, and you can never conjure one you were never given. Authority only spreads along existing reference chains. The object-capability literature compresses this to a rule: "only connectivity begets connectivity."

Capabilities vs. ambient authority and ACLs#

Contrast this with how most systems work today. Under an access-control list (ACL), you present a forgeable name such as a file path, a URL, or an account ID, and the system checks it against your ambient authority, meaning the standing permissions attached to your identity. The reference carries no rights of its own, so the system decides at each call whether "you" are allowed. That indirection is where a whole class of bugs lives.

The canonical example is the confused deputy: a program tricked by a less-privileged caller "into misusing its authority on the system." Norm Hardy's original case was a compiler with write access to a billing file. A user who couldn't touch that file directly simply asked the compiler to write its debug output there, and the compiler, acting on the user's request with its own authority, destroyed the data. The capability fix is structural: "bundle together the designation of an object and the permission to access that object" and pass the capability to the output file in place of its name. A deputy that holds no capability to the billing file cannot be talked into reaching it, because there is nothing to name.

Why this is the right model for AI agents#

An AI agent is, from a security standpoint, an unusually persuadable deputy. It acts on instructions that arrive mixed into untrusted input: user messages, retrieved documents, tool responses, web pages. OWASP's AI Agent Security Cheat Sheet catalogs exactly this, from prompt injection that hijacks agent behavior to "excessive autonomy" where agents take high-impact actions without oversight. Its top recommendation is to "grant agents the minimum tools required for their specific task" with "per-tool permission scoping," which is POLA restated for agents.

The dominant pattern today does the opposite. You give the agent an API key, a broad token, a service account, all of it ambient authority, and then wrap it in guardrails that try to detect misuse before it happens. Call it the "give it keys and hope" model. It fails the way ACLs fail the confused deputy: the authority is standing and identity-scoped, so any instruction the model accepts runs with the agent's full privileges. A hallucinated resource name or an injected instruction never has to defeat a check. It only has to ride the authority the agent already carries.

Capabilities close that gap by changing what is representable. If an agent holds only the capabilities it was explicitly granted, a prompt cannot widen its authority. There is no ambient permission to escalate into, and an action it wasn't given has no token to name. Unapproved actions get no chance to be blocked at runtime, because they are unexpressible in the first place. The gap between unrepresentable and merely denied is the gap between a guardrail you hope fires and a boundary that holds. It is also why capability thinking maps so cleanly onto how a well-designed agent receives its tools as scoped capabilities in place of raw credentials.

What this looks like in practice#

Concretely, capability-based security for AI agents means handing the agent a scoped, unforgeable reference to this table with read rights, where a database credential would have gone. Grant "send email to addresses on this list" where an SMTP account would have gone. Every authority the agent has is something it was deliberately handed, enumerable and revocable. The manifest of what it can do is the security boundary, and anything outside that manifest describes a program that cannot be written.