There’s a lot of excitement about agentic operating systems right now, and most of it is happening at the application layer: agent frameworks, sandboxing tools, orchestration platforms. But if we’re serious about an OS for agents, we need to ask what primitives the operating system itself should provide.
Because we live in a unix world where files are the ultimate abstraction, agents
To answer that, we have to start with Unix. Not because it’s the only model, but its 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, three types of access, nine bits, and the file 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 attenuated 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 typically run as root inside the container, mapped to an unprivileged user outside—safe, but the orchestrator has no idea who asked for this container or what authority they meant to grant it. Kubernetes service accounts authenticate workloads to the cluster, but they’re identities, not delegations; there’s no built-in concept of “this pod is acting on behalf of user X with scope Y.” macOS App Sandbox can restrict what an app can touch, but it can’t express “this app is operating as Alice’s delegate with permission to read her Documents folder but not exfiltrate from it.” Every real system falls into one of the three boxes.
An agent is something in between, and we have no good way to represent that. If you try to think about an “agentic OS” without changing these building blocks, you end up with sandboxes and policy blobs. You end up containing agents rather than making them legible to the system.
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. Agents blur this boundary by default, because they can exfiltrate by their very nature: sending content to an API, embedding sensitive data in responses, copying information into less-protected locations, communicating with other agents. An agent with read access to your documents can, in effect, turn “read access” into “disclosure to the internet.”
So the question is no longer just “can you read this file?” We also need to ask whether data derived from that file can cross a boundary, and whether actions affecting that file can occur without human confirmation. You can treat those as extra permission bits, as labels, as capabilities, as policy rules. The exact mechanism is secondary to the point: the operating system 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.
This is not a new idea in the research literature. Systems like HiStar and Flume explored decentralized information flow control two decades ago, tracking taint through the system so you could enforce policies like “data derived from this secret file cannot reach the network.” The ideas exist. What’s missing is their integration into mainstream operating systems in a way that’s simple enough to actually use—the way Unix permissions are simple enough to actually use.
Delegation must be a primitive
The core claim is straightforward: an operating system cannot be agentic if it cannot represent delegation. 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. The actor is the agent instance—which specific agent is running. The delegator is the user on whose behalf it runs—the human who remains accountable for the action. The scope defines what the agent is allowed to do and for how long—the ceiling on its authority. The confirmation state indicates whether a human approved this specific action or whether the agent is operating autonomously. And the provenance records what initiated the action—a user command, a scheduled task, or another agent’s request.
This is the missing substrate. If the kernel cannot see these things, nothing else composes cleanly. Every layer above has to reinvent delegation tracking, and most of them will get it wrong or skip it entirely.
The agent is a session, not a process
Here is where the “new primitive” argument becomes unavoidable. Agents are not just programs you run and exit. They are increasingly persistent: watching directories for changes, running long tasks in the background, monitoring events, scheduling future actions, coordinating with other agents. A modern machine might have Alice’s interactive session in one corner, an agent watching her projects for changes and running builds in another, a second agent handling home automation, a third monitoring her email for things that need responses.
The right 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—it begins when she authenticates and ends when she logs out or the session times out. PAM modules can attach additional context: which authentication method was used, what roles apply, what resources are available. 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 delegation context. The session has a lifetime that can expire or be revoked. And the system can answer, at any moment, “what agent sessions are active, who delegated them, and what can they do?”
If agents are real actors in the system, the system needs to understand them as such. That means process isolation, resource limits, job control, IPC boundaries, network rules, and the ability to inspect and control them—attach to see what they’re doing, freeze them, kill them if necessary. This is not “sandboxing” in the sense the industry currently uses the term. This is legibility. It’s the difference between a process being a black box the system contains and a process being a first-class citizen the system understands.
The audit trail is the killer feature
If an agent runs as the user, the operating system cannot distinguish between “Alice did this,” “Alice’s agent did this,” “Alice’s agent did this autonomously,” and “Alice’s agent did this because another agent asked it to.” When you lose that attribution, you lose the ability to do security operations. You cannot write reliable detections because you cannot distinguish human actions from agent actions. You cannot do incident response because you cannot reconstruct what happened. You cannot answer basic compliance questions because the audit log is lying to you by omission.
What you want is an audit log that preserves the full delegation context:
time=2026-01-28 03:42:17 actor=agent-claude delegator=alice action=write path=/home/alice/projects/config.yaml confirmed=no
time=2026-01-28 03:42:18 actor=agent-claude delegator=alice action=read path=/home/alice/.env share=attempted blocked=yes
Now you can ask the questions that matter. What files did any agent touch this week? What actions did agents take without human confirmation? Did any agent attempt to exfiltrate data from sensitive paths? Which agent introduced this change, and on whose behalf, and did they have the authority to do so? This is the difference between “agents are contained” and “agents are governable.”
Sandboxes are necessary but insufficient
Everyone building agent systems today is building sandboxes, and sandboxes help—they reduce blast radius, and they are necessary. But sandboxes are not an answer to the operating system design question. They solve containment; they do not solve attribution.
Plan 9 showed decades ago that namespaces could be first-class—each process could have its own view of the filesystem, composed dynamically. That’s closer to what we need than anything in mainstream Unix. But namespaces give you isolation; they don’t give you delegation. A Plan 9 process has a view of the world, but the system still doesn’t know that this process is acting on Alice’s behalf with attenuated authority. The insight we need to borrow from Plan 9 is that the process’s relationship to resources should be explicit and configurable. The insight we need to add is that the process’s relationship to users should be equally explicit.
Sandboxes also invert the elegance of Unix permissions. Instead of policy living on the objects it protects, you maintain it externally in configuration files and policy engines. Inheritance becomes brittle because the sandbox doesn’t know about filesystem hierarchies. Attribution disappears unless you build it yourself. Enforcement becomes a bespoke, centralized blob rather than something intrinsic to the system.
A sandbox can prevent damage. It cannot make the agent legible to the kernel. The difference is the difference between a prison and citizenship: a prisoner is controlled by walls, while a citizen is defined by rights and responsibilities the system itself understands and enforces. An agentic OS is not an OS that contains agents well. It is an OS where agents are a fundamental category of actor—defined, constrained, and audited as delegates.
What “agentic OS” should mean
Not “an operating system that runs agents.” An operating system that understands agents as delegates of users.
That means delegation is a primitive, not an application-layer convention that every agent framework reinvents. Information flow and side effects are first-class concerns, not afterthoughts bolted on via sandboxing. Permissions and policy compose intrinsically, the way Unix permissions do, rather than accumulating in central policy stores. Audit logs preserve delegation chains so you can always answer the question of who did what on whose behalf.
The current trajectory is “agents run with full user permissions forever.” That trajectory ends badly. Our computers are increasingly inhabited by multiple concurrent actors with different trust levels, operating on our behalf but not entirely under our control. Never before have we had software that can take meaningful autonomous action with the full authority of a user. Never before has the gap between what a program can do and what we intended it to do been so consequential.
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 were allowed to share what they found.