Agents Without an Operating System

In my last essay I described the paradox; every useful AI tool has to see exactly the data we want protected from it, and the only protection is the company’s promise. In this essay I want to explain why that is a structural problem and not a policy problem.

The claim is simple. AI agents today are running without an operating system.

I don’t mean Windows or macOS, I mean the job an OS does. Every era of computing eventually built one because the same problem kept coming back, applications cannot be trusted with raw access to the system underneath, so somebody has to sit in the middle.

Mainframes got time sharing because expensive hardware had to be shared safely, the OS decided who got the CPU and who could see whose files. PCs got Windows and Mac OS because suddenly regular people were running thousands of small applications, so the OS did process isolation and memory protection, you didn’t trust the application, you trusted the OS to constrain it. Servers got Linux, that is what made running untrusted code on shared infrastructure possible at all. Phones got the permissions manifest, an app cannot touch your camera or your contacts unless it declares it and you grant it. And cloud got Kubernetes.

Every time the unit of computation changes, a new OS layer shows up to manage it, every single time.

Agents are the next unit of computation and their shape is different from everything that came before. They run without a human steering them continuously, they persist across sessions, they have memory, they take actions with real consequences, and they talk to each other.

And there is no OS. The agent has the keys. It holds credentials, opens database connections, calls APIs directly, writes files, all with the full authority of whatever account it is wearing, which is usually yours.

We are running every application as root on a 1980s machine. When you write it down like that it is obviously wrong, however nobody treats it as wrong because nothing big has blown up yet.

Let me make it concrete. Give an agent your email today and you do one of two things. Either you hand it your IMAP credentials, and now it can technically read every email you ever received, forever. Or you connect it through OAuth which is better, but the scope is usually something coarse like gmail.readonly, so it can still read every email.

And when the agent gets prompt injected, which we know it will eventually, the attacker is not limited to what you wanted the agent to do. They are limited to what the agent was technically able to do which frankly is everything.

Now compare your phone. A photo editing app cannot read your contacts, and it is not because the app promised, the OS will not allow it. The app can ask, you can grant, and without that grant the data does not exist as far as the app is concerned.

Agents do not have that. There is no layer between the agent and the systems it touches.

A lot of smart people have noticed this. Confidential VMs and confidential GPUs running AI workloads inside hardware attested enclaves. MCP gateways sitting between agents and tools enforcing policy on every call. Tamper evident audit logs. Capability systems that limit agents to declared scoped operations.

There is also an academic paper, Omega, from Bodea, Misono and others at a serious systems group, and it proposes pretty much exactly what an agent OS would look like. Declarative policies enforced outside the agent’s execution context, per action provenance tokens on a tamper evident log, nested isolation for multiple agents on one trusted platform.

So the field is converging, and honestly the term agentic OS is already crowded, companies use it in marketing, papers use it in titles. I did not invent this idea and the people actually building these systems deserve the credit for it.

What I want to argue in the rest of this series is narrower, and I think more useful. The OS framing is right and the primitives are mostly getting built, but the field is wrong about who the user of this OS is, and that mistake is going to slow adoption exactly in the industries that need it the most.

Almost everyone building agent infrastructure is building it for developers. Better SDKs, better orchestration, policies in YAML written by senior platform engineers.

But the people who need to trust this stuff are not developers, they are operators. IT admins and compliance officers, the ones whose job is on the line when an agent does something the company cannot defend in front of a regulator.

An OS that only developers can read is a developer tool. The operating systems that actually shipped at scale became legible to normal people, you do not need to be an engineer to configure your iPhone privacy settings. That is the bar.

In the next essay I will describe what the legible version looks like, and it is an analogy that has nothing to do with computers. Funny thing, a Kong engineering blog about MCP gateways arrived on the same analogy by accident, so I figure the metaphor has legs.

It’s a restaurant, specifically a takeout restaurant.