The OpenClaw mania was striking. It was the first time in my career I felt limited by safety, not by capability.
Most of the conversation about agentic operating systems is happening at the application layer: MCP, LangGraph, agent sandboxes, orchestration platforms. It’s about how to wire agents together and how to contain them when they misbehave. It rarely touches what the operating system itself should know about them.
That gap matters more every month. Personal devices are becoming hosts to agents that run locally. They read your files, triage your email, take actions on your behalf. Many of them never cross a network boundary where a service mesh or an auth token could mediate. For those, the OS is usually the only layer they cross. And it cannot see what they are.
To understand what’s missing, start with what Unix gave us. Not because Unix is the only model, but because it imposed files as the ultimate abstraction. An abstraction that underpins all operating systems today.
Once you have files as your universal abstraction, the next natural question is: who can access them? Unix permissions are the answer.
The elegance of the Unix permission system lies in its extreme simplicity: three classes of accessor (owner, group, everyone else), three types of access (read, write, execute), nine bits in total, and the file itself knows who can touch it. The model has scaled from 1970s timesharing to modern cloud infrastructure because it is simple, composable, and intrinsic to the objects it protects.
But Unix permissions answer one question: “Who can do what to this file?” With agents, the questions are different.
The questions we actually need to answer
Who is this actor acting for? What scope of authority was delegated to it? Can the actor transmit what it reads to someone else? Can it take side effects (sending emails, making purchases, modifying configurations) without a human confirming first? What is the provenance of the action: did a user ask for this, or did another agent trigger it, or is it running on a schedule?
These questions do not fit the existing model because an agent is not a standalone identity. It is not “a new user” in the Unix sense. It is a relationship to an existing user: a delegate with limited authority, acting on someone’s behalf but not to be fully trusted.
Today we force agents into one of three bad boxes. We can run them as the user, which gives them full access to everything, permanent by default. Unacceptable for anything you wouldn’t trust with your passwords and bank accounts. We can run them as a service account, which is safer but loses the delegation relationship entirely; the system no longer knows the agent is acting on Alice’s behalf. Or we can run them as “other,” which is too restrictive to access user files in any useful way.
This isn’t hypothetical. Docker containers run as root inside, mapped to an unprivileged user outside. Safe, but the orchestrator has no idea who asked for the container or what authority was meant to come with it. Kubernetes service accounts authenticate workloads, but they’re identities, not delegations. macOS App Sandbox can restrict what an app touches, but it can’t express “this app is Alice’s delegate, allowed to read her Documents but not exfiltrate from them.” Most real systems fall into one of these three boxes.
An agent is something in between, and we have no good way to represent that.
The mechanisms we’ve built since Unix are designed around identity or containment. Mandatory access controls decide what a process can touch. Containers and sandboxes isolate what it can reach. Service meshes and token-based auth authenticate requests at a boundary. None of them compose. Scope doesn’t attenuate across hops. Attribution doesn’t survive a service call. Confirmation state doesn’t propagate. Without changing these building blocks, an “agentic OS” tends to reduce to sandboxes and policy blobs.
Why files and permissions are no longer enough
Classic permissions assume the security boundary is the filesystem. If you can read a file, the system’s job is done; what you do with that information is your business. This worked because we had strong priors about what programs would do. A text editor reads your files but we trust it not to ship them to an external API. Agents have weaker priors, stranger triggers, and act on ambiguous natural-language instructions. The difference isn’t capability. Any program with read and network access could always have exfiltrated. The difference is predictability. An agent with read access to your documents can, in effect, turn “read access” into “disclosure to the internet,” and the old trust model has no way to anticipate when.
So the question is no longer just “can you read this file?” We also need to ask whether data derived from it can cross a boundary, and whether actions affecting it can occur without human confirmation. The exact mechanism (extra permission bits, labels, capabilities, policy rules) is secondary. The OS needs an information-flow and side-effect model that composes the way permissions do: distributed across objects, inheritable by default, intrinsic rather than bolted on. Otherwise you end up with a centralized policy blob that rots the moment someone forgets to update it.
Delegation must be a primitive
The core claim is straightforward: any operating system that treats agents as first-class actors will need to represent delegation explicitly. The OS needs to be able to say that this process is acting as a delegate of Alice, with a specific scope of authority, under a specific confirmation state, because of a specific trigger. That is not the Unix user model. Unix gives you identity; agents require identity plus delegation context.
A useful mental model is a credential tuple with five elements:
- Actor. The agent instance. Which specific agent is running.
- Delegator. The user on whose behalf it runs. The human who remains accountable for the action.
- Scope. What the agent is allowed to do, and for how long. The ceiling on its authority.
- Confirmation state. Whether a human approved this specific action, or whether the agent is operating autonomously.
- Provenance. What initiated the action: a user command, a scheduled task, another agent’s request.
Scope is where this gets hardest. Unix permissions are action-oriented on a
per-file basis (read/write/execute on /path/to/file); they don’t express
intent. Intent was gated by which app you ran. One app, one purpose. Access to
the app was the scope. You ran mail to send email, grep to search, make to
build. Agents break that model. A single agent drafts, summarizes, queries,
sends. Expressing intent directly at the scope level may not even be tractable,
and every design I’ve looked at starts to wobble.
This is the missing substrate. Not a specification, but the shape of a conversation that’s barely started. If the kernel cannot see these things, every layer above has to reinvent delegation tracking, and most will get it wrong or skip it entirely.
Agent-to-agent composition must be intrinsic
Alice asks her email agent to triage her inbox. The agent reads a vendor invoice, decides it’s legitimate, and hands it off to her payment agent to settle. The payment agent issues the transfer, writes a receipt to the filesystem, and replies to the vendor through the email agent.
One delegator. Two agents. Three hops ending at the filesystem. The question is whether the system can still answer, at the moment the receipt is saved, who authorized this and what they authorized.
With composition built in, it can. The email agent runs under a session scoped
to inbox reads with no side effects. When it delegates to the payment agent, a
new tuple is derived, not copied: Alice remains the delegator (not the email
agent), scope narrows to one transaction under $200 with this vendor, explicit
confirmation is required, and the email agent is recorded as trigger. When the
receipt is written, the audit log captures the full chain:
actor=payment-agent delegator=alice scope=invoice-x trigger=email-agent confirmation=explicit.
The propagation rule here, with Alice remaining the delegator across all hops, is one choice, not the only one. A scheduled background agent probably should delegate onward as itself. An interactive delegate should preserve the original principal. The kernel needs a defined rule, and that rule has to travel with the call.
Without composition, the chain evaporates at every hop. Run the payment agent as Alice and the system sees “Alice wrote a receipt.” Run it as a service account and the delegation to Alice is gone; the system sees “payment-service wrote a receipt.” Leave it to each agent framework to pass the context along and the chain breaks at the first hop that forgets.
Agents calling agents is already how this works in practice. An email agent chains into a payment agent. A coding agent spawns a test runner. A scheduling agent queries a calendar agent. The single-agent case is the toy. The multi-agent chain is the real shape of the problem.
Composition has to be intrinsic to the primitive, not layered on top. Otherwise we’re back to policy blobs, with the same rot: the moment one link in the chain is handled manually, the whole chain breaks.
The agent is a session, not a process
Agents are increasingly not programs you run and exit. They tend to be persistent: watching directories, running long tasks, monitoring events, coordinating with other agents. A modern machine might host Alice’s interactive session alongside three agents: one triaging her email, one handling her payments, one running her home automation. Each has different authority, different lifetimes, different accountability.
A better analogy is the login session, not the process. When Alice logs in, the system creates a session with her credentials, and everything she spawns inherits that context. The session has a lifetime. Login systems like PAM on Linux can attach additional context to it: how she authenticated, what roles she holds, what resources she’s allowed. The session is the unit of accountability.
Agents need the same thing. An agent session should begin with an explicit delegation: Alice grants this agent these authorities for this duration. Everything the agent spawns inherits that context. The session can expire or be revoked. And the system can answer, at any moment, what agent sessions are active, who delegated them, and what they can do.
If agents are real actors, the system has to treat them as such: isolating them from each other, limiting their resources, controlling how they talk to each other and to the network, and being able to attach to them, freeze them, or kill them.
Security needs an observability layer
Audit needs to follow delegation into the kernel. Today’s audit layers (auditd, SELinux, AppArmor, app logs) see uids, not delegation. They can’t distinguish Alice from her agent, an autonomous agent from one awaiting her confirmation, or a direct action from one triggered by another agent.
Userspace attribution is bypassable. The syscall is the only place every action is visible, so that’s where delegation context has to be captured.
What you want:
time=2026-04-21 03:42:17 actor=agent-claude delegator=alice action=write path=/home/alice/projects/config.yaml confirmed=no
time=2026-04-21 03:42:18 actor=agent-claude delegator=alice action=read path=/home/alice/.env share=attempted blocked=yes
Now you can ask who did what, on whose behalf, with what authority, across all agents over any window.
Sandboxes are necessary but insufficient
Most of the industry building agent systems today is building sandboxes. Sandboxes help. They reduce blast radius, and they are necessary. But they solve containment; they do not solve attribution.
Capability systems go further. In research operating systems like seL4, Fuchsia’s Zircon, and Genode, authority isn’t attached to a user identity. It’s a token a process holds. If the token says you can do the thing, you can. If it doesn’t, you can’t. Tokens can be passed to other processes, narrowed to less power, or revoked. There’s no equivalent of “being root” that implicitly grants everything. The closest thing in mainstream OS research to what agents need. But capabilities describe what a process can do. They don’t describe whose behalf it’s acting on, under what confirmation, or at whose trigger. Capability plus delegation context isn’t a combination mainstream OSes have shipped.
Plan 9, the research OS from Bell Labs, showed decades ago that you could give each process its own private view of the filesystem, assembled dynamically from whichever pieces made sense. That’s closer to what we need than anything in mainstream Unix. But custom namespaces give isolation, not delegation. A Plan 9 process has a view of the world; the system still doesn’t know whose behalf it’s acting on.
A sandbox can prevent damage. It cannot make the agent legible to the kernel.
What “agentic OS” should mean
Not an operating system that runs agents. An operating system that understands agents as delegates of users.
Delegation is a primitive, not an application-layer convention every framework reinvents. Information flow and side effects are first-class concerns, not afterthoughts bolted on via sandboxing. Permissions compose intrinsically, the way Unix permissions do. Audit logs preserve delegation chains.
The default trajectory is “agents run with full user permissions forever.” That trajectory is likely to end badly. Our computers are increasingly inhabited by concurrent actors with different trust levels, operating on our behalf but not entirely under our control. The gap between what a program can do and what we intended it to do has rarely been this consequential.
This is less a conversation for agent framework authors or sandbox vendors than for kernel maintainers, capability-OS researchers, the people building Linux’s security modules (SELinux, AppArmor, Landlock), and the teams shipping on-device agents who will likely need these primitives whether the OS provides them or not.
Nine bits told you who could touch a file. The next system will need to tell you who touched it, on whose behalf, and whether they had the authority to do so.