Why Agents Need a Kernel
A kernel defines the abstractions every program is written against. Chio defines them for agents: authority, execution, spending, and proof.
On this page
Every operating system answers the same questions for the programs it runs: who is acting, on whose behalf, with which rights, for how long, at what cost, and what actually happened. The answers once lived inside each program, as conventions. Operating systems moved them into a kernel, and every program written since is built on the kernel’s abstractions: the process, the descriptor, the permission, the quota, the log.
Agents reopen every one of those questions. An agent is a program whose next action is chosen at run time by a model, from text the agent did not write, and its work crosses machines and organizations that no single operator controls. Answers kept inside the agent, in its prompt or its framework, are only as firm as the text the model reads next.
Chio moves the answers into a kernel. Authority is a signed capability, checked on every call and narrowed with every delegation. Work is a process the kernel supervises, checkpoints, and recovers. Spending is a budget debited before dispatch. Every decision, allowed or refused, ends in a receipt that another organization can verify without trusting yours. A gateway inspects the traffic that passes through it; a kernel defines what an agent is, what it holds, and what it can prove.
Each kernel mechanism has an agent counterpart
A process reaches the hardware only through system calls, and the kernel decides each one against the process’s descriptors and quotas. An agent under Chio reaches tools only through tool calls, and the kernel decides each one against the agent’s capability and budget. The rest of the design follows from that correspondence.
| Operating system | Chio | What the kernel does |
|---|---|---|
| process | agent | Identifies each agent by its own key, so every grant and receipt names one subject: fixer is did:chio:z6MkrT2…8wd. |
| system call | tool call | Receives every operation the agent attempts on one path and dispatches only what it admits. |
| file descriptor | capability | Admits a call only under the signed token presented with it, which names its subject, scope, and expiry. |
| reference monitor | kernel check | Checks the token’s scope, then runs every guard in the operator’s policy before dispatch. |
| quota | budget | Holds the cost of a priced call before dispatch and refuses a call that would pass the grant’s ceiling. |
| audit log | signed receipt | Signs one receipt for each decision, refusals included, that another party can verify offline. |
| IPC between machines | federation | Admits a partner’s delegated work under its own trust rules, and co-signs the receipts with the partner’s kernel. |
Agents are steered by text, so the kernel checks each permitted call
A process runs the code its author wrote. An agent runs whatever plan its model produces from what it reads, and that text can come from anyone: a pull request, a web page, a tool’s answer. A classic kernel assumes a program that holds a descriptor means to use it. A grant that covers a legitimate task also covers whatever injected text asks for inside that task, so Chio cannot make the same assumption.
Guards apply the operator’s policy inside what a grant permits. A path rule refuses a read of .env that the grant’s scope would have allowed; an evidence rule refuses an edit to the tests that judge the agent’s own work. Both act before dispatch, and neither depends on the words that led the model to the call.
Information flow covers what no single call reveals. When a read returns labeled data, the kernel joins the label into the session’s retained state, and it refuses a later send to any destination without clearance for that label, however the agent rephrased what it learned. Beyond Blocklists follows one attack through five rewrites, and Information Flow Across Calls follows one label to a refused public comment.
Authority crosses organizations, so every decision is signed evidence
A classic kernel can trust its own log, because the operator who reads the log also runs the machine. Agent work breaks that symmetry. One organization’s agents act on another’s systems, and a third party may later have to judge what happened. No party can inspect another’s kernel, so the record itself has to carry the proof.
A Chio receipt binds the request, the verdict, and the evidence under the deciding kernel’s signature, and an exported package verifies offline against a key the verifier chose to trust. Delegation crosses the same boundary: a grant handed to a partner’s agent is narrower than its parent, the partner’s kernel applies its own rules on top, and both kernels sign what they decided. Cooperation Across Companies develops what that makes possible.
A kernel for agents keeps four guarantees
Every effect is mediated: the kernel is the only participant that reaches a tool server, and the host closes every other route, such as an API key left in the agent’s environment. Authority only narrows: the kernel admits a delegated grant only when a grant of its parent covers it, and policy can only refuse calls a grant permits. Every decision is signed: allowed or refused, each call ends in one receipt appended before the response returns. Failures close: a guard that errors, an unanswered budget hold, and a failed revocation lookup each end in a refusal before dispatch. The threat model names the assets these guarantees protect and the components a deployment must trust for them to hold.