Wiki · Concept · Last reviewed June 25, 2026

Capability-Based Security

Capability-based security is an access-control model where authority travels through explicit, unforgeable references rather than ambient identity, making delegated agent actions easier to scope, inspect, and revoke.

Category: Concept Updated: June 25, 2026 Tags: AI agents, authorization, capability security, least authority, MCP, OAuth

Definition

Capability-based security is the security model in which possessing a protected reference confers the authority to use the object, service, or operation designated by that reference. A capability is not just a name. It is a name-like handle plus permission, protected so that untrusted code cannot forge it by guessing a string or constructing a path.

The model is contrasted with ambient authority. In an ambient-authority system, a program names a resource and the platform consults a surrounding identity, session, role, or process privilege. In a capability system, the caller presents the specific authority needed for the specific object. Mark S. Miller, Ka-Ping Yee, and Jonathan Shapiro's 2003 paper Capability Myths Demolished describes properties such as no ambient authority, no designation without authority, and support for least-privilege operation.

This entry is about security authority, not model performance capability. For AI agents, tool access is often delegated through handles, tokens, browser sessions, connectors, and servers. The question is which concrete authority is available when an external action is taken.

How It Works

A capability can be a protected pointer, object reference, file descriptor, narrow service handle, or token whose audience, scope, and lifetime are constrained by protocol and policy. The form differs, but the discipline is consistent: authority should be explicit, hard to forge, narrow enough for the task, and passable only through authorized channels.

Capability systems reduce two hazards. They avoid treating a global name as authority, and they make delegation visible because passing the handle is the moment of granting power. A parent can create a restricted child, pass a read-only view, wrap an existing authority with a smaller interface, or expire a grant after a task.

Norm Hardy's 1988 confused-deputy paper explains the motivation. A compiler could write a privileged statistics file and also accepted a user-supplied output filename. When a user supplied the protected billing-file name, the operating system saw the compiler's authority and allowed the write. Hardy's point was that naming the file and authorizing the write had been separated.

Agent Context

Agent systems recreate old capability questions with newer nouns. A browser agent may hold a user's web session while reading untrusted pages. A coding agent may hold repository write access while reading issue comments. A support agent may hold CRM update authority while reading customer messages.

Capability-shaped design gives the agent the narrow handle needed for the next step, not a general account context that silently follows every tool call. A tool handle might permit "read this ticket," "draft a reply," or "append a note" without also granting sending, exporting, or billing authority.

The Model Context Protocol makes the issue concrete. Its 2025-11-25 authorization specification requires OAuth 2.0 Resource Indicators for HTTP authorization flows so a client can identify the target MCP server when requesting a token. The same specification says an MCP server must not pass through a token it received from an MCP client. MCP's security best-practices page treats confused-deputy attacks and token passthrough as risks for proxy servers and downstream APIs.

Governance and Safety

Governance should preserve the difference between identity, instruction, evidence, tool argument, grant, approval, and external effect. NIST defines least privilege as giving users or processes only the access needed for assigned tasks. Capability-based design turns that principle into an interface question: what handle was issued, who could pass it, what did it authorize, how long did it last, and where was it accepted?

OAuth mechanisms are not pure object capabilities, but some pursue similar boundaries. RFC 8707 defines a resource parameter that lets a client tell the authorization server where it intends to use an access token. RFC 9700 describes audience-restricted access tokens, where the resource server verifies that a token was intended for it and refuses mismatched requests.

For AI governance, capability records belong in the audit trail. A useful incident record identifies the human principal, agent process, tool server, backend service, token audience, scope, approval event, untrusted inputs consulted, and state change.

Defense Pattern

Source Discipline

Capability claims should name the authority mechanism. A file descriptor, object reference, bearer token, OAuth access token, API key, browser cookie, MCP connector grant, and service-account credential are not interchangeable. When reporting an agent security incident, name the object, grant, receiver, instruction source, and service that accepted the authority.

Spiralist Reading

Spiralism reads capability-based security as a discipline of explicit power. Authority should travel as a visible handle, not as a mood in the room. The cleaner question is not "Do we trust the agent?" but "What has this system handed to it, for what purpose, and who can see the handoff?"

The design virtue is friction at the right boundary. A capable institution can let software act without letting every instruction borrow every key. It can grant, attenuate, log, expire, and refuse.

Open Questions

Sources

Return to Wiki