Difference between revisions of "Capability"

Revision as of 16:22, 6 October 2025

Full Title or Meme

Capability refers to the set of valuable functions that a Entity can effectively bring to bear on a problem. A person's capability represents the effective freedom of an Entity to choose between different functioning combinations – between different kinds of life – that she has reason to evaluate and decide.

- A **capability** is an **unforgeable token of authority**. - It simultaneously **designates a resource** (what you want to access) and **authorizes the rights** (what you can do with it). - Possession of the capability itself is sufficient proof of access — no further lookup in a central permissions table is required.

Think of it like a **cryptographic key**: if you hold it, you can open the lock.

Access capability model

one of the most important alternatives to traditional access control lists (ACLs) in computer security and governance.

How It Works - **Traditional ACL model**:

 - Each resource has a list of who can access it and how.  
 - The system checks your identity against that list every time.  

- **Capability model**:

 - Each user or process holds a set of capabilities (tokens).  
 - To access a resource, you present the capability.  
 - The system doesn’t need to check a central list — the capability itself encodes the authority.  

---

Advantages - **Least privilege by design**: You only hold the capabilities you’ve been explicitly given. - **Delegation**: You can pass a capability to another process or user, granting them the same rights. - **No ambient authority**: Unlike ACLs, you can’t accidentally use privileges you weren’t explicitly handed. - **Decentralization**: Security is “pushed to the edge” — no single central table to compromise.

Problems It Solves - **Confused deputy problem**: A program can’t be tricked into misusing its authority, because it only acts with the capabilities it holds. - **Ambient authority trap**: Eliminates the risk of programs having more power than they need just because of who launched them.

Real‑World Analogies - **Physical world**: A hotel keycard is a capability. It doesn’t matter who you are; if you hold the card, you can open the room. - **Digital world**:

 - **Bitcoin/private keys**: “Your keys are your money.”  
 - **Cloud storage links**: A shareable link with embedded rights is a capability.  

Takeaway An **access capability model** replaces identity‑based permission checks with **token‑based authority**. It’s elegant because it collapses *designation* (what resource) and *authorization* (what rights) into a single, unforgeable object.

• • Sources:** Wikipedia on capability‑based security; Storj developer docs on capability‑based access.

Eleanor Hayes Meritt

Technology Executive | Identity & Access ManagementTechnology Executive | Identity & Access Management

Why Most AI Security Discussions Miss the Point

When it comes to securing AI agents, the focus often shifts to OAuth, JWTs, and identity providers. However, the real challenge lies in controlling the actions of AI agents with access privileges. How can you ensure that an AI agent operates on your behalf without exposing sensitive credentials or overstepping its boundaries?

Enter capability models, offering a modern, lightweight, scalable solution to this dilemma.

Three Approaches to Capability Security:

1. OCap (Object-Capability Model)

- Power is held through references.
- Delegation occurs via passing references.
- Ideal for systems/languages, less prevalent in distributed APIs.

2. Macaroons

- Cryptographic tokens with constraints.
- Authority can be limited with time or specific services.
- Delegation involves creating a more restricted macaroon.
- Drawback: challenging to revoke once issued.

3. Biscuits

- An advanced version of macaroons.
- Utilizes public key cryptography and logic policies.
- Transferable across federated systems.
- Delegation is achieved through logic blocks.
- More intricate but with added weight.

Why It Matters for AI Agents:

To ensure responsible AI assistants, the reliance on full OAuth tokens must diminish. OCap embodies the concept of least authority by design. Meanwhile, macaroons and biscuits exemplify practical solutions: portable, verifiable tokens allowing for delegation and constraint. However, both lack an efficient revocation method, necessitating additional infrastructure.

Your Turn:

In the realm of securing AI agent delegation, would you lean towards macaroons for their simplicity and lightweight nature, or do biscuits appeal to you for their flexibility and compatibility across federated systems? Would love to know what you are thinking.

References