The oldest good idea in computer security
In 1966, Jack Dennis and Earl Van Horn, working at MIT, published a paper describing a mechanism they called a capability: an unforgeable token that both names an object and conveys the rights to operate on it. The idea was simple. Instead of asking “who are you?” and consulting a central list of what you may do, the system hands you a key that says what you can do and to what. If you hold the key, you can act. If you don’t, you can’t.
This was a sharp departure from the access control lists (ACLs) that came to dominate operating system design. ACLs attach permissions to resources: “this file can be read by Alice and written by Bob.” Capabilities attach permissions to the holder: “Alice holds a read capability for this file.” The difference sounds cosmetic. It is not.
Why capabilities lost (the first time)
Despite their elegance, capabilities spent decades in the wilderness. The reasons were mostly pragmatic, not theoretical.
The hardware wasn’t ready. Early capability machines such as the Cambridge CAP computer in the 1970s and IBM’s System/38 at the end of that decade needed hardware support to keep capabilities distinct from ordinary data. That made them expensive and incompatible with the commodity hardware that was winning the market.
UNIX won. Ken Thompson and Dennis Ritchie chose simplicity over fine-grained access control. UNIX’s owner/group/other model with read/write/execute bits was coarse, but it was understandable, easy to implement and good enough. When UNIX became the foundation of the internet, its list-based model came along for the ride.
Ambient authority was convenient. In an ACL world, a process inherits whatever permissions its user has. You run a program and it can do everything you can do. This ambient authority makes programming easy, because you never have to think about which rights to pass where. It also makes security very hard, though that wasn’t obvious until systems grew complex enough for it to matter.
Revocation seemed hard. The standard critique: once you hand out a capability, how do you take it back? ACLs make revocation trivial; you edit the list. Capability revocation needs indirection, such as revocable forwarders, which looked like needless complexity.
The capability underground
Capabilities never died. They went underground and kept resurfacing in systems built by people who cared about getting security right.
KeyKOS, developed through the 1980s, and its research successor EROS in the 1990s showed that capability-based microkernels could be both secure and fast.
E, created by Mark S. Miller and colleagues in the late 1990s, brought capabilities into a programming language. E’s object-capability model showed you could have capability security without special hardware: the language’s references were the capabilities. If you couldn’t name an object, you couldn’t invoke it. No ambient authority, and no room for the confused deputy.
Capsicum, from Cambridge in 2010, brought a capability mode to FreeBSD. A process in capability mode loses access to global namespaces: no filesystem paths, no process IDs, no arbitrary network addresses. It keeps only the file descriptors it already holds. Capsicum showed that capability security could live alongside POSIX.
WebAssembly (2017) and WASI (2019) are capability-secure at their core. A WebAssembly module starts with no ambient authority: no filesystem, no network, no system calls. The host passes in exactly the handles it chooses when it instantiates the module. This is Dennis and Van Horn’s model, shipping in every major browser.
The confused deputy, or why this matters
The most compelling argument for capabilities comes from Norm Hardy’s 1988 paper, “The Confused Deputy.” Hardy described a real incident. A compiler had been given write access to a system billing file so it could record usage. A user named that billing file as the compiler’s output target. The compiler, acting as the user’s deputy, overwrote the billing records, because it had the authority to write there and no way to tell whose authority it was using.
ACLs cannot prevent the confused deputy without increasingly baroque layers: mandatory access control on top of discretionary access control, sandboxes, policy languages. Capabilities prevent it by construction. The compiler would receive write capabilities only for the files the user explicitly designated. The billing file was never handed over in the user’s context, so the attack cannot occur.
In an agentic system, where autonomous agents act on behalf of principals and compose operations across security boundaries, every action is a potential confused deputy. This is not a theoretical concern. It is the central security problem of the agentic era.
The fabric’s capability kernel
That is the context in which Pharos Fabric’s security model was designed. Not as an academic exercise but as a practical necessity: how do you build a system where agents can compose capabilities safely, where delegation is explicit and auditable, and where the confused deputy is ruled out by construction rather than by policy?
Atomic capabilities
A capability in the fabric is an atomic permission: a verb applied to a target class, filed under a category. The categories cover the whole surface of the system:
- Kernel: the capability system itself (meta-capabilities)
- Construct: working-graph operations such as edit, promote and delete
- Agent: agent lifecycle (spawn, pause, terminate, migrate)
- Node: infrastructure node management
- Ledger: canonical ledger writes
- Ontology: schema evolution
- Flow: workflow execution
- Domain: application-specific permissions
This is not role-based access control. Roles exist as conveniences; they expand to their constituent capabilities at evaluation time and can be narrowed with exclusions. But the ground truth is always the individual capability.
Grants, not lists
Capabilities are bound to principals through grants: first-class ledger entities that record who granted what to whom, when it took effect, and the signature that attests it. A grant is never deleted. Revoking it records a new fact that changes its status, and the full history stays in place.
This is the capability model’s answer to “but how do you revoke?” The same way you change anything in an append-only ledger: you record the revocation as a fact. The evaluator asks for active grants, and a revoked grant is simply not active.
Delegation without ambient authority
Each capability carries a flag saying whether its holder may re-grant it. A non-delegatable capability stops absolutely. A delegatable one creates an explicit chain, because every delegation is itself a grant, attested and recorded.
No principal can grant a capability it doesn’t hold. The fabric checks this when the grant is written, not after the fact, so privilege escalation is prevented by construction rather than caught by audit.
The kernel governs itself
The most distinctive part of the model is its meta-capabilities, the kernel-category capabilities that govern the capability system itself. They include the rights to define new capability types, to grant and revoke, to compose roles, to define quorum rules, and to evolve the shapes that define the kernel.
Evolving the kernel is the most powerful operation in the system. It cannot be delegated, and it requires a quorum: no single principal, however privileged, can change the security kernel alone. That answers one of the oldest questions in capability systems, who guards the guards. In the fabric, the answer is a cryptographic quorum, not a superuser.
The bootstrap axiom
Every capability system has a chicken-and-egg problem. You need a capability to grant capabilities, so where does the first one come from?
The fabric’s answer is explicit and minimal. When a new fabric instance is created, a single self-signed root grant is written. That is the one axiom: a root principal, attested by its own cryptographic identity, holding the root role. Every later grant traces its authority back to that genesis event through a verifiable chain.
The root identity is bound to an external identity provider and can be further constrained by quorum. After genesis, the root principal follows the same rules as every other principal. It just holds more capabilities.
The constitution is data
The capability kernel is defined in SHACL, the Shapes Constraint Language, the same technology the fabric uses to validate everything else. The kernel’s shapes for identities, capabilities, roles, grants and quorums are themselves stored in the ledger and validated like any other data.
That matters because the security model is not compiled into a binary. It is data in the ledger, queryable and auditable with the same tools as everything else. Changing the security model is a ledger transaction that needs the kernel-evolution capability and a quorum, and it leaves a permanent, signed audit trail.
This realizes a principle that runs through the whole capability tradition: the security policy should be a first-class object in the system, not a configuration file on a server somewhere.
Why now?
Capability security languished for decades because the systems it was designed for didn’t exist yet. When your security boundary is one machine running batch jobs, ACLs work. When it is a fleet of servers behind a web application, ACLs plus firewalls plus OAuth get you a long way.
But when the boundary is an open-ended network of autonomous agents, each with its own identity, acting on delegated authority, composing operations across trust boundaries, building speculative knowledge in fast memory and promoting it to canonical truth, the confused deputy isn’t an edge case. It is the default failure mode.
The agentic era doesn’t need a new security paradigm. It needs the one Dennis and Van Horn described in 1966, refined through sixty years of implementation experience, and now realized in a ledger-native form: capabilities not as tokens passed around in kernel memory, but as facts recorded in an immutable, signed graph.
Capabilities all the way down. Finally.