Capability-Based Security

A capability is a cryptographically protected reference that cannot be guessed, forged, or fabricated by an untrusted process. Unlike access control lists that rely on identity lookup, the token itself is the proof of authority.

• Tokens are typically sparse random bit strings or signed objects managed by the kernel
• Possession of the token is necessary and sufficient for access
• No ambient authority exists—processes operate in a capability-denied default state

This eliminates confused deputy attacks where a privileged program is tricked into misusing its authority on behalf of an attacker.

In a capability system, naming an object and proving the right to access it are the same operation. A capability simultaneously identifies a resource and encodes the permitted operations on that resource.

• A single capability might grant read-only access to a specific file descriptor
• No separate lookup in an access matrix or group membership check is required
• Rights amplification occurs only through explicit capability invocation, never implicitly

This fusion eliminates time-of-check-to-time-of-use (TOCTOU) race conditions common in ACL-based systems.

A process holding a capability can create a derived capability with strictly reduced rights and pass it to a less-trusted subsystem. This is the principle of least privilege made programmatic.

• A file-read capability can be attenuated to read-only for the first 100 bytes
• A network capability can be restricted to a specific IP range and port
• Attenuation is enforced by the capability manager or kernel, not the recipient

This enables secure composition: you can safely delegate work to third-party agents without granting them full access to the underlying resource.

Capabilities are designed to be passed between processes over channels without losing their integrity. Unlike file descriptors in traditional Unix systems, true capabilities can be serialized, transmitted over networks, and stored.

• Capabilities can be sent via capability-passing IPC primitives
• Receiving a capability is the only way to gain new authority—no global namespace lookup
• Revocation is achieved through indirection tables or capability invalidation mechanisms

This property makes capability systems ideal for microkernel architectures and distributed agent mesh networks where authority must flow dynamically.

Since capabilities are held by untrusted user-space processes, the system must support revocation without requiring cooperation from the holder. This is typically implemented through a level of indirection.

• C-list indirection: The kernel maintains a capability table; revoking the table entry invalidates all copies
• Generation numbers: Each capability carries a version that can be invalidated globally
• Proxy objects: A forwarder capability can be destroyed, cutting off access to the real object

Revocation is essential for dynamic agent environments where trust relationships change rapidly and compromised agents must be isolated.

The defining property of a pure capability system is the complete absence of ambient authority. A process has access only to objects for which it holds explicit capabilities—never based on user identity, group membership, or global namespaces.

• No superuser or root account with universal access
• No global file system namespace accessible by path traversal
• Every resource access requires a capability invocation as the first operation

This property makes capability systems inherently resistant to privilege escalation and lateral movement attacks that plague identity-based security models.

The purest expression of capability-based security, where capabilities are the only mechanism for designating authority. In an ocap system, a subject can only interact with an object if it holds a reference to it. This combines designation and authorization into a single, unforgeable primitive. Key properties include:

• No ambient authority: No global namespace or superuser permissions exist.
• Attenuation: Capabilities can be wrapped to create new capabilities with strictly reduced rights.
• Delegation: Passing a capability to another subject grants them exactly the rights you hold, no more.

A fundamental dichotomy in authorization models. ACLs are object-centric: each object has a list specifying which subjects can access it and with what rights. Capabilities are subject-centric: each subject holds a list of tokens granting access to specific objects. The critical distinction is that ACLs require ambient authority to look up the list, while capabilities are self-contained. In a distributed agent mesh, capabilities avoid the bottleneck and fragility of a central ACL store.

Capability-based security is a natural enforcement mechanism for the Zero Trust principle of 'never trust, always verify.' In a Zero Trust model, implicit trust based on network location is eliminated. Every access request must be authenticated and authorized. Capabilities serve as the ideal credential in this environment because they are bearer instruments that grant only the minimum necessary access (least privilege) and can be cryptographically verified without querying a central authority, enabling high-frequency, low-latency agent-to-agent communication.

A core feature of capability systems where authority is passed from one agent to another. If Agent A holds a capability to read a database, it can create a new capability with the same or attenuated rights and hand it to Agent B. This creates a verifiable chain of delegation. Attenuation is critical here: Agent A can delegate a read-only capability to Agent B even if its own capability allows read-write access. This enables secure, decentralized workflow orchestration without a central authorization server.