Edera OCAP: AI agents get scoped capabilities instead of raw credentials

Edera has laid out a security model it calls bounded authority, its product-level application of object-capability security (OCAP) to AI agents and Kubernetes workloads. In a post that reached the Hacker News front page, the company argues that the standard approach to agent security — hand over a credential, then surround the environment with policy — has the logic backwards. In its model, a workload holds no authority at all until it is granted a capability, and that capability can be scoped down to a single operation on a single resource.

The ambient authority problem

According to Edera, the root issue is that credentials are blunt instruments. Give a program access to a filesystem and you may have handed it every secret, configuration file and source tree reachable from that filesystem. Give an MCP server a cloud credential and a compromise of that server can turn a narrowly intended integration into a much broader incident.

The conventional response, Edera writes, is to layer controls around the environment: firewalls, sandboxing, identity systems, secrets managers, admission control, network policy, prompt inspection and increasingly elaborate allowlists. These are useful, but they share an assumption — that the workload already possesses authority, and the job of security is to constrain how that authority gets used.

From ambient authority to capabilities

Ambient authority is authority a program can exercise simply because of where or how it runs: a process reads a directory because of its Unix user, a pod calls an API because a cloud identity is attached, an agent reaches a GitHub repository because a token sits in its environment. The danger, in Edera's telling, is that if the workload is compromised, its authority comes along with it.

Object capabilities invert that relationship. Authority is carried by an unforgeable reference to a particular object or service, and an object can exercise only what the references it holds permit. Edera argues this matters more for agents than for conventional trusted applications, because an LLM's behaviour is generated dynamically, may consume untrusted context, and can be steered by prompt injection. If an agent holds a capability to modify one repository, compromising it does not expose every repository the developer can access; if an MCP server can invoke three explicitly granted commands, a breach does not amount to arbitrary command execution. The boundary is the authority itself, not the model's behaviour.

What bounded authority adds

An object capability combines two things that conventional access control keeps separate: designation, meaning which object or service is being addressed, and authority, meaning what may be done with it. In a traditional setup, the agent authenticates as a principal and an external policy system decides each request. In a capability system, the grant itself is the evidence of authority — something Edera summarises as write(project-a), where the holder needs no general-purpose GitHub token, does not know which other repositories a credential could reach, and carries no reusable secret.

Edera's bounded authority is an object capability deliberately constrained around a specific resource, operation, identity, or a combination of the three. The post contrasts github.write(repository="acme/payments") with ordinary GitHub usage, and command.execute("git diff") with shell.execute(anything). In both cases the permission is explicit and bound to that agent, with nothing else it could do. Edera frames this as answering the question security teams actually ask — what exactly is this agent allowed to do in production — rather than whether a pod has the correctly associated role.

capcurl: HTTP without the credential

The most concrete piece is capcurl, Edera's treatment of HTTP as a bounded authority. A broker holds the credential — a GitHub token, for example — and exposes a capability representing only the operation the agent may perform, such as a POST to the pulls endpoint of one specific repository. Edera says the capability can carry additional constraints on rate, paths, identity, headers, destination, HTTP method and request shape. The agent simply calls the capability, and the broker translates the request into the authenticated API call. Coding agents like Codex or Claude Code therefore never see the token, so a prompt injection, dependency compromise or malicious tool invocation can only ever exercise the narrow scope the capability defines.

Why it matters

Agent security debates tend to centre on model behaviour — better filtering, better prompts. Edera's proposal shifts the problem to infrastructure: if an agent never holds a credential, injection and compromise hit a hard structural ceiling rather than a policy-enforced one. That is a meaningful reframing for MCP servers and coding agents, which routinely operate with long-lived tokens today. Two caveats are worth noting. This is a single-source vendor post describing its own design, and the text as circulated is truncated before operational questions — how capability brokers are deployed, audited and revoked — are addressed. Those details usually decide whether capability systems succeed in practice.