Traditional security for AI agents often relies on 'ambient authority.' In this model, a program exercises power simply because of its environment: a process might read a directory because it runs as a specific Unix user, or an AI agent might access a GitHub repository because a token is present in its environment variables. This creates a significant risk; if an agent is compromised via a prompt injection or a dependency vulnerability, the attacker inherits every permission associated with that broad credential. Edera argues that instead of trying to constrain a workload that already has authority, security should start by ensuring the workload has no authority until it is explicitly granted a specific capability.
Edera’s approach is based on the Object Capability (OCAP) model, which merges 'designation' (which object you are talking to) and 'authority' (what you are allowed to do with it) into a single unforgeable reference. In a capability-oriented system, an agent does not need a general-purpose credential; it simply holds a handle that represents the authority to perform a specific operation, such as `github.write(repository="acme/payments")`. This is implemented through a 'capability broker' that holds the actual credentials. For example, in Edera's `capcurl` concept, the broker manages the GitHub token and exposes a bounded authority to the agent. The agent never sees the token, and the broker enforces specific constraints—such as allowed paths, rate limits, or specific HTTP methods—before executing the request.
The diagram illustrates the shift from agents holding broad credentials to using a capability broker to receive narrowly-scoped handles.
This model is particularly suited for AI agents because their behavior is dynamic and difficult to predict with static policies. Because capabilities are composable and granular, an agent's effective power is the sum of the specific authorities it has been granted. For instance, a Model Context Protocol (MCP) server can be restricted to only three specific commands rather than being given a privileged bridge to the entire infrastructure. While OCAP does not replace identity—Edera still uses SPIFFE/SPIRE to establish *who* a workload is—it provides a cleaner separation of concerns. Identity establishes the subject, while capabilities manage the specific, least-privileged actions that subject is allowed to perform. This creates a two-layer security model where microVMs provide isolation from the host, and bounded authorities provide isolation from the actions the agent can perform within that sandbox.
This visual demonstrates the granularity of capabilities, where an agent's power is the sum of specific authorities like 'git-diff' or 'restart-deployment'.