Here's the setup Ariadne Conill says she sees most often. A developer wants a coding agent to open a pull request against one repository. The easiest path is to hand the agent the developer's personal access token. It works. But now the agent can read every repository that developer can see.
Nobody designed it that way on purpose. It's just what happens when the only tool you have is "give the workload a secret."
Edera thinks the fix is to stop giving agents secrets at all. On November 5, the company announced Object Capability Bounded Authority, part of its Agent Runtime. I asked Conill, co-founder and distinguished engineer at Edera and maintainer of Alpine Linux, how it works and what developers should change now, whether or not they use Edera.
Roles assume predictable programs. Agents aren't.
Most of us think about permissions as roles and access lists. A workload signs in as a principal, and a central policy decides what that principal can do. Conill says that model breaks down with agents.
"In practice, the principal ends up with whatever the token or role allows, because that is ambient authority sitting in the environment," she said.
An object capability works differently. Conill describes it as "an unforgeable reference" that combines the resource and the action allowed on it. "If you hold the reference, you have the authority. If you don't, there is nothing to ask for."
Why does that matter for agents? Because an agent's control flow comes from model output, and it reads untrusted input. "So the question you have to answer is what happens when the agent does exactly the wrong thing," Conill said. "With capabilities, the answer is that it can only exercise the references it was handed, and nothing about its behavior can widen that."
Personal tokens are the most common problem, but not the only one. Conill pointed to MCP servers as a bigger risk, because authority piles up there.
"A single server exposes twenty tools, holds one credential that works for all of them, and serves callers who should only be able to use two or three."
Then there's the agent's filesystem. When an agent runs in a developer's environment, it often has access to cloud credentials, SSH keys, and kubeconfigs, just because they happen to be there.
What happens when the agent opens a PR
The GitHub example shows how the pieces fit together. The agent runs in its own isolated zone, a VM, with no GitHub token inside it. When the zone is created, it gets a capability: a reference to a broker running in a separate zone. That capability stands for a bounded operation, such as "create pull requests against acme/payments."
From the agent's side, opening a PR through capcurl is a local socket call. Edera's control plane carries the request out of the zone to the broker. The broker checks the caller's workload identity, confirms the capability covers the request (method, path, repository), attaches the real credential, calls GitHub, logs the action, and returns the response.
"The token lives only in the broker's zone," Conill said. "Nothing in the agent's memory or filesystem is worth stealing."
The capability sets the scope, not the token
This is the part I found most useful. The token and the permission are separate things. In Edera's Agent Runtime, a capability is a Kubernetes resource that the security team owns. It defines the destination, HTTP method, path patterns, repository, and optionally rate, headers, or request shape.
"So the GitHub token can have write access to fifty repositories, while the capability a given agent claims only permits POST to /repos/acme/payments/pulls," Conill said. Requests outside those bounds get rejected at the broker and never reach GitHub.
Here's a simplified sketch of that idea. It's illustrative pseudocode, not Edera's resource syntax:
capability: open-prs-acme-payments
destination: api.github.com
allow: POST /repos/acme/payments/pulls
credential: held by broker (never enters the agent's VM)
Capabilities also stack. An agent's effective authority is the set of capabilities it holds, not whatever one identity is allowed to do.
Why enforce at the hypervisor
I asked why enforcement sits at the hypervisor instead of inside the workload or in a sidecar. Conill's answer is worth reading in full if you've relied on either one.
"An in-process check runs in the same address space as the thing it is supposed to constrain. If the agent gets code execution, the check is just more memory it can rewrite, and the credential it guards is in the same process."
Sidecars are better, she said, but they usually share a kernel, a network namespace, and often a secret mount with the workload. A container escape or kernel bug puts the attacker next to both the credential and the policy engine.
With Edera, the agent runs in its own MicroVM. Its only path to the broker crosses the hypervisor boundary. "A fully compromised agent can invoke the capabilities it holds, and that's all. It cannot patch the enforcement point, read the secret, or mint new references."
capsudo: a command, not a root shell
The same idea applies to privileged commands. The security team defines a capability, such as "restart the api service," as a Kubernetes resource. The agent's sandbox claims it at creation. Inside the sandbox, the agent sees this:
$ capsudo -S /run/cap/restart-api
If the agent tries something outside that scope, there's no policy to argue with. "It simply has no socket for that operation, so there is nothing to invoke," Conill said. "With capsudo, the agent is never root and never asks."
That design comes from her Alpine work. Alpine moved from sudo to doas because a smaller policy engine is easier to reason about. "Alpine taught me that most security comes from what you leave out," she said. Capabilities apply that thinking to authority: "start with nothing, add exactly what the job needs, and make what's present easy to enumerate."
What adoption looks like
The work splits along lines most teams already have. Security defines capabilities once. Developers claim them when they create a sandbox, declaratively or through the Python SDK. Adding Edera to an existing cluster is a RuntimeClass, not a re-platforming.
On the agent side, sudo calls become capsudo calls, and API calls go through capcurl instead of carrying a token. For most tools, Conill said, that "means removing credential handling rather than adding code."
Capabilities are fixed when a sandbox is created. Edera doesn't inject new ones into a running sandbox. If an agent needs more authority, you create a new sandbox or fork a running one and give each fork different capabilities. Revocation works at runtime.
If a prompt injection gets through
Here's the payoff. A successful prompt injection gets the attacker exactly what the agent had: maybe PR access to one repository and one command. No GitHub token. No other repositories. No root. No path to neighboring workloads.
The broker logs every call with the agent's identity, the capability used, the target, the request, and the result. "Security teams can see that an agent suddenly opened forty pull requests, and they can revoke that capability without rotating a token everyone else depends on," Conill said.
What's available now
Be clear on timing. Today, Edera's Agent Runtime provides isolated sandboxes, scoped command execution through capsudo, and workload identity through SPIFFE/SPIRE. Developers can try it at on.edera.dev, and early access opens November 9. Credential-brokered API access through capcurl, the piece behind the GitHub example, is still in development.
Much of the tooling is open source. capsudo is ISC-licensed, with the C reference implementation on Codeberg and packaged in Alpine. capsudo-rs, the Rust version, is also ISC-licensed and on GitHub. capcurl is 0BSD-licensed and on GitHub. The Python SDK is public.
The one change to make this quarter
I asked Conill what teams putting coding agents into production should do right now, with or without Edera. Her answer was simple.
"Get credentials out of the agent's execution environment. If your agent can read a token, assume an attacker will too."
Put a broker in front of your APIs, even a small proxy you write yourself, and only forward the requests the agent's job needs. Stop running agents with developers' personal tokens. "That single change turns a prompt injection from a credential theft into a bounded incident," she said. "It also forces you to write down what the agent is actually supposed to do, which most teams have never done."
That last line stuck with me. Most agent security problems start before any attacker shows up. They start when nobody decides what the agent is supposed to do. And whoever builds and deploys the agent owns that decision.
