The Ideal OS For AI Is A Message-Passing Microkernel

Every operating system ever built was designed for human users. This agentic era brings with it a novel problem – autonomous software is now acting inside a user's authenticated session.

Linux, Windows, macOS, iOS, and Android make different tradeoffs, but they share one critical tenet: the human is the actor, the software is the tool.

The OS can distinguish users, processes, files, permissions, and applications. It cannot reliably distinguish whether an action came from the human or from an AI agent inside the human's session.

This is breaking the current OS paradigm. An agent does not simply wait for a person to click. It reads untrusted information, decides what matters, and turns language into action. The instruction may begin with the user – but it can be mixed with a webpage, email, repo comment, support ticket, or document.

Traditional operating systems have no native concept of "this was the human" versus "this was software acting with the human's permissions." They can ask which process made a system call, which user owns the session, or which app has a permission. But when an agent uses the user's browser, account, token, or API key, the OS simply sees authorized software.

This is why the OS suddenly matters again – not as a prettier desktop, but as the place where authority is either preserved or lost. When software can act, the deepest question is: who actually authorized the action?

Ambient Authority Is The Wrong Primitive

Modern operating systems are built around applications and permissions. Once an app is running in the user's session, it often receives broad access to the surrounding environment. The system may ask for permission around camera, location, filesystem, or Bluetooth, but the model is still coarse: you grant a capability, and then you trust the app.

This is ambient authority – authority granted in advance, attached to a process or session, and used later in ways the user may not fully understand. It breaks down when the thing holding the permission is also interpreting untrusted text from the world.

Prompt injection shows how quickly ordinary content can become control flow. An email, webpage, or support ticket may be the thing the agent is supposed to summarize; it may also contain instructions the agent is tempted to follow. If those inputs can influence action, data and instruction start to blur.

This is why prompt injection is only part of the problem. The deeper issue is that the injected instruction may inherit the user's authority. If the agent has broad access to GitHub, Gmail, AWS, Slack, Stripe, a password manager, or a wallet, the attacker does not need direct access to those systems. The attacker can influence the agent that already has it.

Operating systems can isolate memory, sandbox apps, restrict files, and protect keys. They can answer whether a process was allowed to do something. They cannot answer whether the human actually granted authority for this action.

AI Needs Messages, Not Permissions

The ideal OS for AI should start from messages and policies, not applications.

Ask GPT, Claude, or another model what OS would make agents safer, and the answer is usually the same: isolated services, message passing, explicit capabilities, and a policy engine. Not a hardened desktop OS. A system where requests are structured before authority is granted.

A message might ask a document service to read a file, a signer to approve a withdrawal, or a deployment service to publish a commit. The system should know who asked, what is requested, what authority is required, and what the human sees before approval.

Message passing forces authority to become visible. Components do not silently reach into each other's memory or inherit the user's entire session. They ask. That request can be inspected, logged, denied, transformed, or turned into a canonical human-readable approval.

But messages alone are not enough. Without policies, the user becomes the policy engine, forced to approve every action. That would fail. The OS should encode rules: small requests can be automatic, while impactful requests require explicit review and approval.

Instead of handing broad "GitHub access" to an agent, the system should force it to request the specific merge, checks, and ticket. Instead of vague "money access," it should prepare a transaction that a separate authority layer can display and approve. Instead of inherited production access, it should request a deploy to a specific environment under a specific policy.

In the old model, authority is granted in advance and hidden inside the session. In the new model, authority is expressed at the moment of action. The request itself becomes the security boundary.

Why A Microkernel?

If messages are the primitive, a microkernel is the natural architecture.

A microkernel keeps the trusted core small. Instead of placing filesystems, device drivers, networking, UI, policy engines, and application logic inside one enormous privileged kernel, it pushes most services into isolated processes. The kernel's job is narrow: isolation, scheduling, memory protection, and communication.

KeyOS is Foundation's message-passing microkernel OS for Passport devices. Its kernel is roughly 9,000 lines – Linux is measured in tens of millions. A kernel that small can be reviewed by a serious team. A kernel measured in tens of millions of lines may be right for a general-purpose computer, but wrong for an authority root.

In today’s computing paradigm, agent security on Linux and other OSes is whack-a-mole. The attack surface is huge, and authority is not native, so containment becomes sandboxes, brokers, browser extensions, EDR rules, audit logs, and policy sidecars bolted on top.

A message-passing microkernel gives us a different path. Services are isolated, communication is explicit, and policy can sit where it belongs: between the request and the authority it needs.

Security Is Not Enough

Hundreds of companies are focused on AI security – but security alone is insufficient.

A secure system can faithfully execute the wrong request. A hardware security module can protect a key while signing the wrong payload. A sandbox can isolate an agent while still giving it the credential it needs to cause harm.

Security protects execution; authority governs permission. AI needs both.

If the same computer reads the malicious email, interprets it, plans the action, renders the approval prompt, and holds the credential, then the human may not be the real authority anymore. The system is asking the compromised environment whether it should be trusted.

That is backwards.

The authority layer should be small, separate, and explicit: it receives structured messages, evaluates policy, displays canonical intent, and requires human approval for actions that matter.

Most actions should remain fast. Nobody wants to manually approve every read, draft, search, or calculation. But when an agent is about to move money, sign code, rotate a key, share a credential, or change production infrastructure, the user deserves a real boundary.

The OS Should Make Intent Canonical

The hard part is not merely isolating processes. The hard part is translating machine action into human intent.

"Allow API call" is not enough. Neither is "Approve tool use" or "Continue?" The approval should say what happens in the language of the consequence: send this amount to this destination, grant this role to this person, deploy this commit to this environment, or share this credential with this service.

That requires more than a signing chip. It requires an operating system built around messages, policies, display, and human approval. The OS has to know what request it is receiving, preserve its meaning across process boundaries, prevent spoofed approvals, and make the action legible before it becomes irreversible.

This is where a microkernel architecture really shines. When each service communicates through explicit messages, the system can attach structure to authority: the agent proposes, the policy engine evaluates, the approval interface displays, and the signing service executes. Each component has a role, and no single component quietly becomes the user.

A Different Kind Of Computer

At Foundation, we have spent years building hardware for self-custody because Bitcoin revealed a simple truth: if the user cannot hold the key, the user does not really control the asset.

AI reveals a broader version of the same truth. If the user cannot control the authority boundary, the user does not control the agent.

This is why we are building Passport and KeyOS as the authority layer for the agentic world. Passport is the hardware root: trusted screen, trusted input, secure keys, and human-readable approvals outside the computer the agent touches. KeyOS is the operating system: isolated apps, explicit capabilities, trusted UI, kernel policy, and human-approved signing.

This is not a prettier desktop, another app platform, or a chatbot with root access. It is a different kind of computing paradigm – one built so high-impact actions pass through a separate, trustable device controlled by the human.

AI agents will act on our behalf. The only question is whether those actions happen through hidden ambient authority, or through explicit requests that a human can understand and approve.

Agents act. Humans must authorize.