Capability-Based Security, Explained | Elacity
Capability-based security means a program reaches only what you hand it. Here is how it works, why AI agents make it urgent, and how Elacity builds on it.
Capability-Based Security, Explained: Hand Your AI Agent a Ticket, Not Your Login
Capability-based security is a way of building software in which a program can touch only what it has been explicitly handed: one file, one payment, one connection, for a limited time. The model running almost every computer you own works the other way, letting any program you launch do anything you can do.
That difference used to be academic. Now that you are inviting AI agents to read your inbox, move your files, and spend your money, it decides what a single bad instruction can cost you.
What Capability-Based Security Means
A capability is an unforgeable reference that bundles two things: which object, and what you may do with it. Hold the capability and you can act on that object. Lack it, and the object does not exist for you; there is nothing to guess, scan for, or escalate into.
The idea is older than the personal computer. Jack Dennis and Earl Van Horn described capability lists in 1966 as a way to define exactly which resources a running computation could reach.
Ambient Authority: The Model You Use Today
The mainstream alternative is what researchers call ambient authority: on Unix and Windows, a program runs with the authority of the user who started it. Your spreadsheet, a browser extension, and a script copied from a forum all inherit your full reach.
In 1988, Norm Hardy documented what goes wrong. In The Confused Deputy, a compiler holding write access to a billing file was steered by a user into overwriting it, because the program could not separate its own authority from its caller's request.
An AI agent is a confused deputy by design. It acts on your behalf while reading text written by strangers: web pages, emails, shared documents. If one of those carries a hidden instruction, the agent spends your authority on someone else's goal.
Why AI Agents Make This Urgent
This is already showing up in the field. In a Salt Security survey released in September 2026, 49.8 percent of respondents said an AI agent had taken, or was suspected of taking, an unintended or unauthorized action in the past year. Only 12.5 percent said they could consistently trace an agent's path from the first prompt to the systems it touched.
The OWASP Gen AI Security Project calls this risk Excessive Agency and traces it to too much functionality, too many permissions, and too much autonomy. Its guidance is pointed: enforce authorization in the downstream system rather than relying on the model to decide what it is allowed to do.
That is the capability argument in modern language. You cannot train a model to never be fooled. You can build a system where being fooled reaches nothing the agent was not handed.
How Capability-Based Security Works in Practice
Four properties separate a real capability system from a permissions dialog with better branding:
- Explicit: nothing is reachable by default. A program starts with zero authority and receives only the references you grant.
- Narrow: a grant names one resource and one action, such as read this folder or pay this merchant up to a set amount, never full access.
- Expiring and revocable: a grant can carry a time limit, and revoking it stops the action mid-flight rather than at the next login.
- Fail-closed: when a check cannot complete, the answer is no. Errors deny; they never default to allow.
Where Elacity Fits
Elacity exists so you can turn your data, work, and IP into property you own: a Wealth Capsule, sealed with Elacity dDRM, carrying its rights and royalties with it. Property only stays property if nothing can quietly reach past you to take it, which is why the layer underneath is built on capabilities.
ElastOS, the open-source runtime Elacity runs on, starts every app, script, and AI with zero ambient authority. Nothing touches your files, network, or money until you grant a specific, narrow, expiring permission; revoke it and the action stops mid-flight. When a check fails, ElastOS fails closed.
Humans and AI agents pass through the same capability model. There is no looser path for software: an agent asking for access gets a grant shaped exactly like one you would need yourself, and nothing wider.
Keys follow the same discipline. A key can sign, decrypt, or pay for you while the secret exists in the clear only for a split second inside a sealed sandbox, bound to that one transaction, then wiped. An agent can use a key it was granted without ever seeing it, so a hijacked agent has no secret to leak.
The honest edge: the hard primitives are in place, but the agent product around them, including agent wallets and an approval and kill loop for autonomous actions, is still being built.
To see these failures in real incidents, read how a rogue AI agent never needed permission to try and why, in the Denmark CPR breach, the flaw was standing access. More engineering explainers live under Protocol Engineering.
Capability-Based Security FAQ
Is capability-based security the same as least privilege?
Least privilege is the goal; capabilities are one way to enforce it structurally. A least-privilege policy layered on ambient authority can drift over time, while a capability system has no ambient reach to drift into.
Does a capability system stop prompt injection?
No. It limits the damage. An injected instruction can still mislead an agent, but the agent can act only through the grants it holds, so a narrow grant means a small blast radius.
Do I have to approve every single action?
No. You grant a bounded capability once, such as read access to one folder until Friday, and the program works inside it. You step back in only when it asks for something wider.
The question to ask of any agent, app, or platform is not whether it promises to behave. It is what it can reach if it doesn't. Follow Elacity on X for more plain-English guides to owning your digital life.