Capability-Based Security for AI Agents

Capability-Based Security for AI Agents

Ask yourself what an AI agent on your machine is actually allowed to do. Not what you’d like it to do — what the system will permit if the agent tries. On almost every setup in use today, the honest answer is: whatever you’re allowed to do. The agent runs inside a process that runs as you, and “you” is a very large grant. Capability-based security for AI agents is the argument that this is the wrong trust model at its root — that an agent should start with the authority to do nothing, and receive narrow, typed, revocable grants for exactly the actions its task requires. It’s an old idea in operating systems research. The actor it was waiting for has finally arrived.

The app-permission model assumes a human is driving

The permission model everyone actually lives under was designed around two comfortable assumptions: the unit of trust is the application, and the entity driving it is a person.

So the questions the system asks are app-shaped and person-shaped. “Allow this app to access your files?” “Allow this app to use the network?” You answer once, usually at install time, usually yes, and the grant persists forever at the granularity of an entire program. From then on, the app operates with what security people call ambient authority — it doesn’t present credentials for each action; it simply acts, and the system checks whether you could have done it. Since you can do nearly everything, so can it.

This was always a coarse arrangement, but it held together because of the second assumption: a human was in the loop, clicking each button, more or less aware of what was happening. The app’s authority was broad, but its actions were throttled by human attention. The grant was the size of a barn door, and a person walked through it one step at a time.

The actor changed. The model didn’t.

Now put an agent in the driver’s seat and watch both assumptions fail at once.

An agent is not throttled by human attention — issuing actions at machine speed is its entire value. And an agent is not a fixed program whose behavior you can audit once and trust forever; it’s a probabilistic system whose next action depends on its context, which includes text it read five minutes ago from a source you’ve never vetted. The security community has a growing catalog of what follows — OWASP’s Top 10 for LLM applications puts prompt injection and “excessive agency” near the top, and excessive agency is really just ambient authority wearing its new name.

The classic term for the resulting failure is the confused deputy: a program with legitimate authority tricked into using it for someone else’s ends. Agents are the most confusable deputies ever built. They can be instructed by anything that can get words in front of them. Hand a confusable actor your full ambient authority and you haven’t built an assistant-shaped tool; you’ve built a very fast intern with your keys, your badge, and a habit of taking directions from strangers.

The industry’s current answer is supervision — watch every step, approve every action. That works, at the cost of the thing you wanted, which was delegation. All-or-nothing trust gives you exactly two settings: babysit, or hope. Neither is a security model. Both are coping strategies for a permission system that has no vocabulary for the thing we’re now asking it to govern.

What capability-based security gets right

Capability systems invert the model’s core assumption. Instead of an actor carrying broad ambient authority checked against an identity, authority lives in capabilities: unforgeable tokens that each designate a specific resource together with specific rights over it. If you hold the capability, you can perform the action. If you don’t, there is no action to attempt — the request isn’t denied so much as impossible to express.

Three properties follow, and each one lands directly on the agent problem.

Default-deny. An actor begins with nothing. Every authority it holds was explicitly granted, which means the complete answer to “what can this agent do?” is “here is the list of what it was handed” — a list you can read, rather than a subtraction problem over everything your account can reach. Least privilege stops being an aspiration written in a policy document and becomes a structural fact.

Typed grants. A capability isn’t “disk access.” It’s append to this log, read this directory, send to this address. The grant carries its own meaning, narrow enough that granting it doesn’t require faith. This matters enormously for a probabilistic actor: you don’t have to predict everything the model might be talked into wanting. You bound what any of it can touch.

Bounded blast radius. When a capability-held agent is confused — and phase-honesty requires saying when, not if — the damage is limited to the authority in its hands. Prompt injection against an agent holding read-access to one folder and append-access to one file is an incident. The same injection against an agent holding your ambient authority is a career event.

None of this is new. Dennis and Van Horn described capabilities for multiprogrammed systems in 1966, and capability operating systems have been built, verified, and largely ignored by the mainstream ever since — because for fifty years the mainstream actor was a human, and humans found ambient authority convenient. It was the right design waiting for a problem painful enough to justify it. Autonomous, injectable, machine-speed actors are that problem.

This has to live at the OS layer

Here’s the part that can’t be papered over with a framework. Capability discipline is only as strong as the layer that enforces it. A capability system implemented inside an agent framework is a polite fiction: the framework can refuse to offer a dangerous tool, but the process underneath still holds your ambient authority, and anything that escapes the framework’s abstractions — a shell command, a subprocess, a clever path — inherits all of it. That’s not defense. That’s a sign that says “please.”

For grants to mean anything, denial has to be enforced below every route the agent can take, which is the same structural argument we’ve made about why agent trust belongs in the operating system: containment is a property of the environment the actor runs in, not of the actor’s good manners. This is the arrangement MagenticOS is built around, and it’s already on the public record: every consequential action passes a typed capability broker — no raw shell, no raw sudo. Default-deny isn’t a mode you enable. It’s the floor.

Capabilities also compose with the other properties an agent-native operating system owes you. A grant you can enumerate is a grant you can audit, which is half of what makes agent work inspectable rather than write-only: the record of what an agent did means more when it sits beside the list of what it could have done. Trust you can state, next to actions you can replay.

The phase-honest caveat, as always: MagenticOS is in alpha, targeting 2026-12-07, and an alpha is a beginning, not a verdict. The claim in this post is not “we have solved agent security.” The claim is that the trust model is decided at the foundation, and we think this is the right foundation — visibly, in the open, where the argument can be checked against the code.

The takeaway

The app-permission model isn’t wrong because anyone blundered. It’s wrong because it encodes assumptions — trusted program units, human-speed actions, attention as the throttle — that agents void completely. Patching it with more prompts and more supervision just relocates the problem to your patience.

Capability-based security replaces the unanswerable question “do you trust the agent?” with one that has an actual answer: what did you hand it? Default-deny by default, typed grants, blast radius you chose in advance. That question belongs in the operating system, because that’s the only layer positioned to enforce the answer. Sixty years after the idea was written down, it finally has its actor.