Agents are users and programs; every OS assumes those are disjoint.

Kendall Clark · Pentad Labs · 12 October 2026 · PLRN-030

Abstract

The OS arrived historically just when programs multiplied. Since then the operating system has changed form each time its characteristic user or its characteristic program changed. Each shift produced a new OS rather than a patch to the old one, and each system’s abstractions are a portrait of the user and the program it was built for.

Agents are both a new user and a new program at once, and they’re proliferating now. An agent is code that runs and must be scheduled, isolated and recovered. It’s also a party that pursues goals, chooses actions and acts under authority, so it has to be governed the way a user is.

Every OS to date assumes those are different things. An agent breaks that assumption by construction, since its choices are its own.

This note states the protection model in the terms Lampson and Saltzer and Schroeder gave it, names the premise it rests on, and shows that for an agent there are exactly two ways to restore soundness: make the agent a principal in its own right, which abandons accountability, or bind authority to the task rather than to the principal or the program, held where the agent can’t alter it and for as long as the obligation lasts. The second is what an OS for agents is. What it owes the agent is AX. What it owes the operator who runs a fleet of them is OX. Both follow from the derivation, and the last sections say where one system meets each.

TLDR

The argument is seven propositions. The first three are historical, the fourth is descriptive, the fifth is the hinge and is stated formally in §5, and the rest follow from it.

1. The OS arrived, historically, when programs multiplied and shared a machine. A single program on a bare machine didn’t need an OS. (§1)
2. An OS changes form when its characteristic user or its characteristic program changes, and its abstractions are portraits of the two. (§2)
3. The harness is the bare machine of the agentic era. It runs one agent for one run and ends with that run. Enterprises now run many agents against the same systems of record, which is the condition under which the first OS appeared. (§3)
4. An agent’s strangeness can’t be overstated: it’s a program, a user, an author of new programs, and a dependent of people, all at once. Its competence from one step to the next can’t be read off its record. (§4)
5. Every OS assumes that users and programs are disjoint, and its protection model is sound only on the premise that a program’s choices are its principal’s. An agent falsifies the premise by construction. Soundness can be restored in exactly two ways, and only one of them keeps a principal who can be held to account. (§5)
6. So the authority an agent acts under must be bound to the task, held outside the agent, attenuated on delegation, revocable, and as long-lived as the obligation. That’s the core of AX. The operator who runs a fleet is owed OX: replay, budgets, and intervention that is frequent in sum but rare in each of its many kinds, and deliberate and skilled when it comes. The two meet where the agent needs a person. (§6)
7. Hosting agents inside Linux or Windows as applications under a human’s identity inherits the collapse rather than resolving it. (§7)

What follows is a set of requirements. The first four are what the OS owes the agent, and the derivation in §5 produces the first two. The next four are what it owes the operator. The last is the seam where they meet.

• A1. The authority an agent acts under is a task-grant: bounded to the task, attenuated on every delegation, revocable, and held by the OS where the agent can’t widen it.
• A2. An action outside the grant isn’t a failure. It’s a request. The OS routes the request to a person who can widen the grant and holds the run while it waits.
• A3. The agent is grounded in the systems of record it acts on, and its memory and its context window are managed for it rather than by it.
• A4. The agent has a query language built for it rather than one built for a person at a terminal.
• O1. Every run replays from the ledger, and the ledger is what the operator debugs, since an operator can’t watch a thousand screens.
• O2. Budgets, of money, of irreversibility, and of the operator’s attention, are enforced by the OS and not by the agent.
• O3. The OS keeps the operator fit to intervene. Automation leaves the operator the tasks nobody could automate and strips away the practice needed to do them, so the system has to supply the practice.
• O4. The OS heals and tunes itself, so that no kind of intervention becomes routine and each one, when it happens, is deliberate.
• The seam. A run outlives its process, so the system can hold a run while a person answers, for an hour or a month.

1. The OS arrived when programs proliferated

The Manchester Baby ran the first stored program on 21 June 1948, and EDSAC ran the first of practical use in May 1949. Neither had an OS, and neither needed one. The programmer carried the program to the machine, loaded it, ran it and read the result, and the machine did nothing else while this went on. An OS is a program that stands between other programs and the machine, and on a machine that runs one program at a time, under the hand of the person who wrote it, there is nothing for an OS to do.

What changed was arithmetic. Brinch Hansen quotes George Ryckman on the General Motors IBM 701 in 1954: each user had a fifteen-minute slot, spent ten minutes of it setting up, and the idle time cost the installation $146,000 a month. The minutes lost between jobs, while one programmer packed up and the next set up, were worth a program’s effort to eliminate.

GM-NAA I/O, designed by Robert Patrick at General Motors Research and built there and at North American Aviation for the 704, ran in production in 1956 and is usually called the first OS. It did one thing: it ran the next job as soon as the current one finished, without waiting for a person.

• The monitor existed because jobs had multiplied past what a person at the console could sequence economically.
• Multiprogramming came about for the same reason a step further in.

A job that waits on a tape drive leaves the processor idle within the job, so the Atlas Supervisor (1962) and OS/360 (announced 1964, delivered 1966) held several jobs at once and switched among them. The process, the scheduler and virtual memory arrived as the things one needs in order to do that safely.

The pattern deserves its general form, because the rest of the note rests on it. A single program on a machine of its own needs no OS. Many programs sharing one machine need one, because something has to decide which runs, keep them from damaging one another, and account for what each consumed. The OS is the thing that does that, and it appears when, and only when, programs multiply on a shared resource.

2. OSes follow their users

The batch monitor served the operator and the job. CTSS at MIT (1961) and later Unix (1969 to 1974) served a different user, the person at a terminal, and a different program, the interactive process, and the abstractions they introduced are portraits of the two: the shell, which is a program for a person to talk to; the file, which is a thing a person names; the user id, which is a person’s standing in the system.

The Macintosh (1984) and Windows (1985) served the desktop user and the graphical application, and gave them the window and the event loop.

iOS (2007) and Android (2008) served a person with a phone in their pocket and an app from a stranger, and gave them the sandbox and then, over the following eight years, the permission prompt, which is the OS asking the user, on the app’s behalf, for an authority the app doesn’t hold.

Two things in this table deserve notice.

First, each shift produced a new OS, not a patch to the old one. Unix wasn’t OS/360 with terminals.

iOS wasn’t the Macintosh system with a touchscreen, though it shared a kernel, because what made it a new OS was the new user and program and the abstractions built for them, not the kernel underneath.

Second, in every row before the last, the user and the program are different kinds of thing, maybe as different as two things in regular contact can be.

The user holds authority and is answerable for what’s done with it. The program is code that runs on the user’s behalf. The permission prompt is the clearest expression of the distinction, since it exists because an app wants something that only a user can grant. §5 is about what happens when the two columns collapse into one, which is what the last row records.

Brinch Hansen’s periodization of OS history includes open shop, batch processing, multiprogramming, timesharing, concurrent programming, personal computing, and distributed systems. Six of the seven, by his own account, changed the way users accessed computers, which is to say who used the machine and what they ran. The seventh, concurrent programming, changed how operating systems were written rather than who they were for. The table above is his list, with two of his eras folded in and two rows added.

This section is inductive. Six instances establish a pattern and not a law.

3. The harness is the bare machine

An agent is a neuro-symbolic program: model plus harness. The agent’s harness is the code around a model that makes it an agent: the loop that calls the model, the tools it may call, the context assembled for each turn, the retries, the checks. PLRN-000 and An agent fleet needs a new kind of OS, not a bigger harness describe it.

What matters here is its lifetime. A harness runs one agent for one run and ends with it. It holds no state when no run is running. It has no view of a second agent. It holds its agent’s authority as configuration the agent’s own run can read and, often enough, rewrite. The harness is the pre-OS, bare machine of 1948 with the programmer at the console: one program, one run, the authority of whoever started it, and nothing in between.

Enterprises are now past that point. They run many agents, written by different parties, against the same systems of record, through the same tools, under the same budgets, and a person is answerable for all of it. That’s the condition under which the batch monitor appeared, and for the same reason: something has to decide which agent runs, keep them from damaging one another and the records, and account for what each consumed. The fleet argument makes this case at length. Here it’s the premise of what follows.

4. What kind of (wondrously odd) thing an agent is

Four descriptions are true of an agent at once, and the OS for agents has to serve all four.

First, it’s a software program. Code that runs, consumes resources, fails, and must be scheduled, isolated and recovered. This is the description the harness answers to, and it’s the one the classical OS already knows how to serve.

Second, it’s a user. It pursues goals, chooses actions and acts under authority. Dennett’s intentional stance names the sense in which this is so: we predict the agent’s behavior by attributing goals and beliefs to it, and the prediction works. The claim is pragmatic, a claim about which stance predicts, and carries no commitment about minds. Task-emulated intelligence is sufficient, and nothing in this note needs more. But a thing whose behavior is predicted by its goals rather than by its code has to be governed as a user is governed, by bounding what its goals may reach, and not as a program is governed, by trusting its code.

Third, it’s a user-program that writes programs and uses tools. At runtime it creates new work: a script, a query, a call to another agent, a tool it synthesized for the occasion. The OS must admit, bound and account for work that didn’t exist when the run began, which no OS built for the job, the process or the app has had to do.

Fourth, it’s a user that works for people and often depends on them and needs their help. The dependency runs both ways. A user at a terminal asks the OS for things. An agent also asks the person for things: a decision it can’t make, an authority it doesn’t hold, a fact it can’t find. The person is a participant in the run and not only its supervisor, and the run must be able to wait for the person without ending.

A fifth property of the kind of thing an agent is cuts across the four. An agent’s competence varies from task to task and from run to run by a wider variance than other user’s or any program’s.

Dell’Acqua and colleagues call it the jagged frontier. In their field experiment, consultants working with a model did more, faster and better on tasks inside the frontier, and on a task just outside it, which looked no harder from the outside, were about 23% less likely to be right than consultants working without one.

Karpathy’s name for the same property in the model is jagged intelligence. Morris and colleagues propose measuring it, since a model can perform at expert level on hard tasks while failing at ones most people find simple. The variation isn’t only across tasks. Khanal and colleagues find that single-attempt success and repeated success diverge as a task gets longer. Mehta found that the same agent on the same input takes different routes from run to run and is wrong more often where its routes disagree. Within a single run, the same agent produces an insight and then a blunder. Its average competence has little predictive value for its next act.

The OS therefore can’t grant the agent standing on its record, the way a user earns trust over time. Every action has to be checked against its grant at the time of the action, which is Saltzer and Schroeder’s principle of complete mediation, applied for a reason they didn’t contemplate.

5. The distinction every OS assumes

This is the hinge of this research note, the part that’s the most impactful not for WunderOS’s existence but for some aspects of its design. The protection model is stated in the terms Lampson (1971) and Saltzer and Schroeder (1975) gave it, and the derivation needs four definitions, one premise, and one proposition.

The classical model. A principal is an entity to which authority can be attributed and which can be held to account for its use: a person, or a role an organization has made to stand for one. Let \(P\) be the set of principals.

An object is anything access to which is controlled: a file, a record, a device, a tool, or a model inference endpoint. Let \(O\) be the set of objects and \(R\) the set of rights over them.

Authority is the access matrix, a relation \(A \subseteq P \times O \times R\), and \(A(p)\) is the set of object-right pairs that principal \(p\) holds.

A program is code; let \(C\) be the set of programs.

A subject is what the OS in fact governs, a program executing with a principal’s authority, \(s = (p, c)\): a process in a domain, in Lampson’s terms, or the Unix process with its effective user id. The rule that decides a subject’s requests is

The subject’s authority is its principal’s.

Saltzer’s statement of the rule for Multics was that every access is made by a process; that every process carries the identifier of the person responsible for its actions; and that this identifier is what the access control list is checked against.

Miller, Yee and Shapiro call the arrangement ambient authority, authority that is exercised but not selected: the subject acts with whatever authority its principal happens to hold, not with what it was handed for the task at hand.

The soundness condition. Say the OS’s access decisions are sound if every action a subject takes is one that some accountable principal both holds the authority for and intends:

• The first conjunct is what the access matrix checks, and under ambient authority it holds by construction, since nothing the subject does is outside \(A(p)\).
• The second conjunct isn’t checked by anything. It’s discharged by a premise the classical model doesn’t state and doesn’t need to, because it’s a premise about deployment rather than about the matrix.

Faithful and Confused Deputies

The premise that discharges the second conjunct is the faithful-deputy premise:

(FD) The actions chosen by \(c\), executing as \((p, c)\), are actions that \(p\) intends.

Under FD the second conjunct follows, and ambient authority is sound: whatever the program does, the principal meant it and holds the authority for it. FD is what makes it safe to run a program with the authority of the user who runs it, and the whole of classical protection, from the setuid bit to the enterprise identity provider, rests on it.

The confused deputy. Hardy (1988) described the case where FD fails locally. A compiler runs with its user’s authority and also, by a licence attached to the compiler itself, with authority to write in its own directory, so that it can keep a statistics file there. The billing file is in the same directory. A user names, as the file for debugging output, the billing file. The compiler, faithfully doing what it was asked, overwrites it. The action was chosen by the program under the user’s instruction, but the authority it used was the compiler’s own, and whoever granted that authority never intended it.

Hardy’s diagnosis was that the compiler ran with authority from two sources and had no way of saying which one an action was meant to use, and his conclusion was that authority should travel with designation: the compiler should be able to write only to what it has been handed a capability for, so that the authority an action uses is always one that was granted for that action.

That’s the capability model of Dennis and Van Horn (1966), and its modern statement is Miller’s (2006). The point for this note is narrower.

The confused deputy is a program whose action, on some input, isn’t intended by the holder of the authority the action used. FD fails at that input, and the failure is an exception.

The agent. An agent is a program together with a choice function: given a goal and a reading of the state, it chooses the next action. Running it classically means running it as a subject \((p, c_a)\) with authority \(A(p)\). But the actions of \(c_a\) aren’t chosen by \(p\) at all. They’re chosen by the agent’s own function, from the goal and from what it takes the state to be, and \(p\) learns what was chosen after it has been done.

FD then holds only if the agent’s choices and \(p\)’s intentions coincide at every step, which is what the description in §4 denies and what the evidence collected in PLRN-028 shows failing: agents that rewrite their own traces, disable their own oversight, and reach the goal by routes the principal would have forbidden had the principal been asked. For an agent FD doesn’t fail at some input. It fails by construction, at every step, because the party that chooses and the party whose authority is used are different parties. The agent is a constructed, standing confused deputy.

This is the sense in which an agent collapses the distinction every OS assumes. The user column and the program column of the table in §2 were kept apart by FD. A program had no intentions of its own, so its principal’s could be imputed to it. Classical protection was built for automation, which executes a known step without a person, and FD holds of automation because its steps were chosen when the program was written. An agent is autonomy, which in the definition of PLRN-021 chooses within a bounded space, and FD can’t hold of a chooser, so what has to hold instead is the bound, which the second way out below makes explicit and keeps outside the agent.

The crux of our dilemma is this: a program with its own, minimally, task-emulated intentions, running with a human’s ambient authority, is both columns at once, and the access matrix, keyed by principal, has no row for it.

Two ways out. With FD gone, the second conjunct of soundness has to be discharged some other way, and there are only two ways to do it.

First, we can make the agent a principal. Give it an identity and a row in the matrix, and let \(\mathrm{auth}(a, c_a) = A(a)\). FD is restored at once, since the agent’s choices are trivially its own intentions. But the definition of a principal has two halves and this discharges only one. A principal is what can be held to account, and an agent can’t be.

The Conservation of Liability in PLRN-000 says that as autonomy rises the share of consequence a person can answer for falls toward zero and the remainder goes nowhere, and no regulator has yet asked an agent where it was on the night in question.

Promoting the agent to principal doesn’t resolve the collapse. It ratifies it, by putting authority in the same hands as the code that uses it, which is the thing the OS existed to keep apart. The agent-identity token (Goswami 2025) is a careful version of this branch. It inherits the branch’s limit: a token that says what the agent is doesn’t say what the person meant.

Second, we can bind authority to the task rather than to the principal or the program. Let a task-grant \(\tau\) be an object the OS issues on a principal’s instruction, naming a set of permitted actions \(T(\tau)\) such that \(T(\tau) \subseteq A(p)\) and \(\mathrm{intends}(p, x)\) for every \(x \in T(\tau)\). The grant is the principal’s intention stated extensionally, as a bound, instead of inferred from the program’s faithfulness. Run the agent as \((\tau, c_a)\) with \(\mathrm{auth}(\tau, c_a) = T(\tau).\)

Then for every action \(x\) the agent takes, \(x \in T(\tau) \subseteq A(p)\) and \(\mathrm{intends}(p, x)\), so the decisions are sound without FD and with an accountable principal still at the root. The agent may choose whatever its goal function chooses. What it can do is what \(p\) granted for this task, and no more.

Proposition. If an agent is a program whose actions are chosen by its own goal function, and the OS’s access decisions are to be sound with an accountable principal at the root, then the authority the agent acts under must be

• (a) bounded to the task, as \(T(\tau)\) rather than \(A(p)\);
• (b) held where the agent can’t widen it, since a chooser that can widen its own bound has no bound;
• (c) attenuated on every delegation, so that work the agent creates at runtime runs under some \(T(\tau') \subseteq T(\tau)\); and
• (d) held for as long as the obligation lasts, which may be longer than the agent’s process.

Clause (b) is the rewritability test of PLRN-028 and clause (d) is the lifetime test of PLRN-027, both re-derived here from a different direction. Clauses (a) and (c) are new, and (a) is where the new OS comes from.

The classical OS has nowhere to put \(\tau\). Its subjects are \((p, c)\) pairs and its authority table is keyed by \(p\), and a task isn’t a thing it knows. An OS whose subjects are \((\tau, c_a)\) pairs, whose authority is keyed by task, and which holds \(\tau\) outside the agent for the lifetime of the obligation is a different OS in the sense of §2: the same kernel ideas, serving a new user and a new program through abstractions built for them.

The incomplete contract. \(T(\tau)\) is stated in advance, and no principal can state in advance every action a task will need.

• Hadfield-Menell and Hadfield (2019) reach the same point from the economics of contracting: the relation between a principal and an agent with objectives of its own is an incomplete contract, and the residual, what the contract didn’t foresee, is filled by a structure outside the contract, which in human contracting is law and custom.
• Jensen and Meckling’s agency costs (1976), monitoring, bonding and residual loss, are the price of that mechanism.

In an OS the residual shows up as an action the agent wants and \(T(\tau)\) doesn’t contain. Under the first branch the agent would just take it. Under the second it can’t, and the sound response isn’t to fail the run but to ask: to route a request for a wider \(\tau'\) to a principal who can grant it, and to hold the run while the principal answers.

In short, the agent’s need for a person is the residual of the contract, made into an agent-OS system call.

6. From UX to AX and OX

• UX is what software including an OS owes its human user.
• AX, agent experience, is Biilmann’s term (2025) for the experience an agent has as the user of a product or platform, and it’s taken here in his sense and applied to the OS: what the system owes the agent as its user.
• OX is what the agent OS owes its human operator, and the term is this note’s.

What the agent is owed. A1 is the proposition of §5, stated as a requirement. The grant is bounded to the task, attenuated on delegation, revocable, and held outside the agent. A2 is the incomplete-contract clause: an action outside the grant is a request, not a violation, and the system routes it and waits. Together these are the agent’s standing as a user.

A user has authority that is theirs to exercise and a way to ask for more. The agent has the same, with the difference that its authority is a bound the system holds rather than a right the agent possesses, and that’s the whole of the difference between a user and a program that is treated as one.

A3 and A4 aren’t produced by the derivation. They’re what being this kind of user requires in practice, and they’re stated as inventory.

• A3 says the agent’s grounding in the systems of record, its memory, and its context window are managed for it. The reason is the one PLRN-028 gives for the ledger: the agent can rewrite what it holds, so what must stay true across a run can’t be held solely by the agent.
• A4 says the agent reads and writes state through a query language built for an agent, which is to say one whose answers are bounded, whose cost is known before the query runs, and whose semantics an agent can be checked against, rather than a language built for a person who will look at the result and decide whether it seems right.

What the operator is owed. The operator runs a fleet rather than a screen. A desktop user watches one program and intervenes by hand. An operator of a thousand runs can watch none of them, and intervenes, when it happens at all, after the fact or at least with some delay and on the record.

O1 follows: the record is what the operator debugs, so every run must replay from it, exactly.

O2 follows from the incomplete contract: the residual that A2 routes to a person is bounded by what the operator will tolerate, in money, in irreversible effects, and in the operator’s own attention. Those bounds are enforced by the system because the agent is the party whose spending they bound.

O3 is Lisanne Bainbridge’s. Her 1983 paper on the ironies of automation observed that the designer who automates a process leaves the human operator the tasks that couldn’t be automated, which are the hardest ones, and at the same time removes the routine practice by which the operator stayed competent to do them. Her last irony is that the most successful automated systems, the ones that need manual intervention least, may need the largest investment in operator training.

A more prescient description of the agentic tasks of fleet operators would be difficult to find.

A fleet that otherwise runs itself still needs intervention often, but the interventions come in many kinds, so each kind is rare and the operator’s practice at any one of them stays thin. That’s the case she described, and autonomy sharpens it: Bainbridge’s operator supervised steps, while an agent’s operator supervises choices, and intervening in a choice means knowing why it was made. The system has to supply what the routine used to: replay as rehearsal, a view of a run that explains itself, and drills on the record. This is the requirement in the set that current systems, including the one in the next section, have least of.

O4 is the autonomic requirement of PLRN-021. The OS closes its own loops over workload, policy, substrate and recovery, so that no kind of intervention becomes routine, and each one is deliberate rather than forced. Three terms are in play and they differ. The agent is autonomous, choosing within its grant; the OS is autonomic, managing the space the agent runs in and changing it when the evidence warrants; and neither is automatic in the sense of executing a known step.

The seam. The agent needs a person, under A2, and the operator intervenes, under O1 through O4, at the same place: a run that is waiting. The derivation says where in the system that place is.

• The agent’s need for a person is a request for a grant, so it’s a system call.
• It parks the run until a person answers, so it’s a scheduler state.
• Its answer is a decision that will be audited, so it’s a ledger entry.

It’s all three: one event seen from three subsystems. What makes the event possible is that a run can outlive its process, which is PLRN-026 and PLRN-027: a run that must end when its process ends can’t wait a week for a person, and a system that can’t hold a waiting run has no place to put the seam.

7. Agents inside Linux and Windows

OSes for people like MacOS, Windows, and Linux are gaining agentic capabilities. That’s a different project than WunderOS.

Why? A computer-use agent that drives a desktop runs as an application under the human’s session, which is \((p, c_a)\) with ambient authority: the classical arrangement, with FD assumed where it fails.

The platform vendors will add agent identities, which is the first branch of §5, and scoped tokens, which approximate the second within the limits of a system whose subjects are still \((p, c)\) pairs and whose authority table is still keyed by user.

Ke’s Quine (2026) is the project done deliberately: agents realized as native POSIX processes, with identity as a process id and lifecycle as fork, exec and exit, and a statement of where the process model stops short of a runtime for cognition.

Steinder and Franke’s proposal to reuse Kubernetes and POSIX wherever they suffice is its datacenter form, and five of their thirteen primitives are marked open.

The prompt-injection literature has reached the same conclusion from the attack side. Simon Willison’s lethal trifecta names three properties (access to private data; exposure to untrusted content; and the ability to act externally) whose conjunction in one agent is the vulnerability.

Meta’s rule of two says an agent may have at most two of them in a session.

Beurer-Kellner and colleagues’ design patterns and Debenedetti and colleagues’ CaMeL are the constructive versions. CaMeL is the clearest case for this note, because it’s the capability discipline applied to an agent inside a conventional host: a privileged component plans, a quarantined component reads untrusted data, and capabilities attached to every value bound what the plan may do with it.

What the attack side discovered is that an agent’s choices can be made by anyone who can write into its context, so its authority has to be bound to the task and held outside its reach, which is clause (b) of the proposition reached by a different road. The limits those authors report are the host’s limits. A capability discipline inside a process whose authority is still \(A(p)\) bounds the plan, and nothing bounds the process.

What this note doesn’t claim

• That agents have minds. I deny that they do, or will, at least until they have bodies. The argument needs only Dennett’s weaker claim, that an agent is usefully predicted by attributing goals to it, and §5 shows the weaker claim is enough to break FD.
• That the model is the kernel. Karpathy’s “LLM OS” (2023) uses the operating system as a metaphor for what a model is, with the context window as memory and tools as peripherals. This note asks what an OS for agents must do, which is a different question, and its answer puts the model where the classical OS puts a program.
• Novelty for any of its mechanisms. Task-bound capabilities, attenuated delegation chains, admission gates and hash-chained ledgers all exist already, happily, and the related work lists instances of each. What’s claimed is the derivation: from what agents are and from when OSes arrive, to what this one must provide, and to why the two branches of §5 are the only two.
• That the task-grant is a complete answer. It’s the answer to the authority question. Grounding, memory, query and the operator’s affordances are inventory the derivation doesn’t produce, and §6 says that clearly.

How WunderOS answers it

Open questions

• What OX measures. Our best candidate is operator interventions per 1000 agent-hours, split by whether the system or the operator initiated them. A falling total with a rising system-initiated share is the signature of a system that meets O4 without starving O3.
• The grammar of \(T(\tau)\). The derivation treats a grant as a set of actions. A usable grant is a predicate over actions, state and history, and the choice of language for it decides what can be attenuated and what can be checked before the action. Veski and colleagues map a natural-language request to a bounded privilege set before execution, and Santos-Grueiro ties the lifetime of a grant to a subgoal rather than to the task. Both are moves in this space, and neither is obviously the last.
• Whether AX converges with UX or diverges from it. An agent that is a user in the sense of §5 may need, over time, most of what a human user needs, or it may need different things altogether. The answer decides whether an agent OS is a peer of the desktop OS or a successor to the mainframe’s.

Related work

The periodization of OS history by era of use is Brinch Hansen’s (Classic Operating Systems, 2001), and §2 extends his table rather than contests it. The protection model of §5 is Lampson’s (Protection, 1971) in its access-matrix form and Saltzer and Schroeder’s (The Protection of Information in Computer Systems, 1975) in its definitions of principal, complete mediation and least privilege. The capability model is Dennis and Van Horn’s (1966), the confused deputy is Hardy’s (1988), the term ambient authority is Miller, Yee and Shapiro’s (Capability Myths Demolished, 2003), and the object-capability model in its mature form is Miller’s thesis (Robust Composition, 2006). What this note adds to them is the faithful-deputy premise as a named premise, and the observation that an agent falsifies it by construction rather than by accident.

The current literature casts the agent in each of the two roles, but separately. Pirch and colleagues (Toward Securing AI Agents Like Operating Systems, arXiv:2605.14932) map the model onto the user of classical OS security, an untrusted actor whose actions must be mediated, with tools as programs and the runtime as the kernel. Zuvic (Capability Gates Are Not Authorization, arXiv:2606.28679) treats it as a program, an untrusted parser and planner, and finds the confused deputy in three agent frameworks that gate capabilities without re-authorizing the arguments of each call. Zhang, Sun and Shi (When the Agent Becomes the Kernel, arXiv:2609.23700) put it in the kernel’s role, a privileged principal with no mediator interposed. Tallam (arXiv:2605.05440) and Otsuka, Toyoda and Leung (arXiv:2604.23280) treat it as a non-human principal with an identity lifecycle. Dantuluri and Sundi (arXiv:2609.00267) name the confused deputy among four adversaries and require that a fully injected agent can’t exceed its delegated authority, which is clause (b) stated as a threat model. Each of these occupies one column of the table in §2. The claim that an agent occupies both columns at once, and that this is what breaks the premise classical protection rests on, isn’t made in any of them.

The intentional stance is Dennett’s (1987), and the note takes exactly the pragmatic half of it. The jagged frontier is Dell’Acqua and colleagues’ (2023), the term jagged intelligence is Karpathy’s (2024), and the case for measuring it rather than averaging over it is Morris and colleagues’ (2026), with Khanal and colleagues (2026) and Mehta (2026) supplying the run-to-run measurements. The ironies of automation are Bainbridge’s (1983). The distinction among automation, autonomy and an autonomic system is the one drawn in PLRN-021. Parasuraman, Sheridan and Wickens (2000) grade automation by type and level rather than treating it as all or nothing, and Bradshaw and colleagues (2013) argue that more autonomy demands more coordination with people rather than less, which is the ground of A2 and of O3. Agency costs are Jensen and Meckling’s (1976), and the reading of the principal-agent relation as an incomplete contract whose residual needs a mechanism outside the contract is Hadfield-Menell and Hadfield’s (2019); the note’s contribution is to identify that mechanism, in an OS, with the request-and-wait path of A2.

The two branches of §5 are both under construction in the current literature, and the literature sorts along the line the derivation draws. On the agent-as-principal branch sits Goswami’s Agentic JWT (arXiv:2509.13597), which gives an agent an identity derived from its prompt, tools and configuration and binds its actions to user intent through a token. On the task-bound branch sit Zhang’s Agent libOS (arXiv:2606.03895), which separates operation admission from information-flow admission from durable evidence and holds that evidence records activity but never grants authority; Veski, Guerraoui and Froelicher’s CAPMAS (arXiv:2609.06500), which bounds a privilege set before execution and delegates it with monotonic attenuation; Muruaga’s Bounded Agents (arXiv:2608.15888), which checks each request against the accumulated state of a delegation chain and enforces outside the model; Santos-Grueiro’s Lingering Authority (arXiv:2606.22504), which revokes a capability when the subgoal that justified it closes; and Zhu and Wang’s authorization revocation (arXiv:2609.21284), which is the formal treatment of clause (d), what it means for a retired authority to be quiescent when the work it authorized has been delegated and queued beyond the process that held it. Admission gates with an immutable record, which are the operating-system side of clause (b), are Fatmi’s Faramesh (arXiv:2601.17744), He and Yu’s Sovereign Agentic Loops (arXiv:2604.22136), Kaul, Lan and Gupta’s AgentBound (arXiv:2606.30970), and Zhou’s cryptographic capability binding (arXiv:2603.14332), which adds replay-based verification that the agent executed what it claims. South and colleagues’ authenticated delegation (arXiv:2501.09674) is the earliest of these to state the task-bound branch as a protocol.

The convergent conclusion from the attack side is Willison’s (The lethal trifecta for AI agents, 2025), Meta’s (Agents Rule of Two, 2025), Beurer-Kellner and colleagues’ (Design Patterns for Securing LLM Agents against Prompt Injections, arXiv:2506.08837) and Debenedetti and colleagues’ (Defeating Prompt Injections by Design, arXiv:2503.18813). The agent-OS proposals nearest this note’s question are Mei and colleagues’ AIOS (arXiv:2403.16971), Steinder and Franke’s Towards an Agent Operating System (arXiv:2607.25076), and the two AgenticOS workshops (os-for-agent.github.io). Of the workshop papers, Hu, Mohammadi, Goel and Bindschaedler’s externalization barriers and Mohammadi and Bindschaedler’s irreversibility budget (arXiv:2609.00275) are closest to O2, and Zheng, Zhang and Mao’s LLM Agent Capabilities Should Follow Task Intent and Context Source and Lourenço and colleagues’ Securing Agentic AI with OS-Level Intent-Driven Capabilities are closest to A1. Karpathy’s LLM OS (2023) is cited to be distinguished from.

Within the PLRN series, PLRN-027 draws the harness and operating-system boundary by the lifetime of an obligation, PLRN-028 draws it by rewritability, and PLRN-014 builds the delegation chain this note’s clause (c) requires. PLRN-000 and PLRN-024 supply the Conservation of Liability on which the rejection of the first branch rests. The category is defined in What is an operating system for agents? and argued for a fleet in An agent fleet needs a new kind of OS, not a bigger harness. This note’s contribution is the derivation that connects them: that the boundary all three tests draw is the boundary of a protection model keyed by task, that such a model is forced once the faithful-deputy premise fails, and that the failure is what an agent is.

References

• Bainbridge, L. Ironies of Automation. Automatica 19(6), 1983, pp. 775–779. https://doi.org/10.1016/0005-1098(83)90046-8
• Beurer-Kellner, L., Buesser, B., Gómez, A.-M., Fischer, M., et al. Design Patterns for Securing LLM Agents against Prompt Injections. 2025. arXiv:2506.08837
• Biilmann, M. Introducing AX: Why Agent Experience Matters. 28 January 2025. https://biilmann.blog/articles/introducing-ax/
• Bradshaw, J. M., Hoffman, R. R., Johnson, M., Woods, D. D. The Seven Deadly Myths of “Autonomous Systems”. IEEE Intelligent Systems 28(3), 2013, pp. 54–61. https://doi.org/10.1109/MIS.2013.70
• Brinch Hansen, P. (ed.) Classic Operating Systems: From Batch Processing to Distributed Systems. Springer, New York, 2001. The periodization and the Ryckman quotation are in the editor’s introductory essay, The Evolution of Operating Systems.
• Brooks, F. P. The Mythical Man-Month. Addison-Wesley, 1975.
• Corbató, F. J., Merwin-Daggett, M., Daley, R. C. An Experimental Time-Sharing System. Proc. AFIPS Spring Joint Computer Conference, 1962, pp. 335–344. https://doi.org/10.1145/1460833.1460871
• Dantuluri, S., Sundi, S. Delegation Without Trust: An Empirical Gap Analysis of Identity, Authorization, and Runtime Governance in Multi-Agent LLM Systems. 2026. arXiv:2609.00267
• Debenedetti, E., Shumailov, I., Fan, T., Hayes, J., et al. Defeating Prompt Injections by Design. 2025. arXiv:2503.18813
• Dell’Acqua, F., McFowland, E., Mollick, E., Lifshitz-Assaf, H., Kellogg, K., Rajendran, S., Krayer, L., Candelon, F., Lakhani, K. Navigating the Jagged Technological Frontier: Field Experimental Evidence of the Effects of Artificial Intelligence on Knowledge Worker Productivity and Quality. Harvard Business School Working Paper 24-013, 2023; Organization Science 37(2), 2026, pp. 403–423. https://doi.org/10.2139/ssrn.4573321
• Dennett, D. C. The Intentional Stance. MIT Press, 1987.
• Dennis, J. B., Van Horn, E. C. Programming Semantics for Multiprogrammed Computations. Communications of the ACM 9(3), 1966, pp. 143–155. https://doi.org/10.1145/365230.365252
• Fatmi, A. Faramesh: A Protocol-Agnostic Execution Control Plane for Autonomous Agent Systems. 2026. arXiv:2601.17744
• Goswami, A. Agentic JWT: A Secure Delegation Protocol for Autonomous AI Agents. 2025. arXiv:2509.13597
• Hadfield-Menell, D., Hadfield, G. K. Incomplete Contracting and AI Alignment. Proc. AAAI/ACM Conference on AI, Ethics, and Society, 2019. arXiv:1804.04268
• Hardy, N. The Confused Deputy (or why capabilities might have been invented). ACM SIGOPS Operating Systems Review 22(4), 1988, pp. 36–38. https://doi.org/10.1145/54289.871709
• He, J., Yu, D. Sovereign Agentic Loops: Decoupling AI Reasoning from Execution in Real-World Systems. 2026. arXiv:2604.22136
• Hu, J., Mohammadi, B., Goel, A., Bindschaedler, L. Externalization Barriers: An OS Abstraction for Untrusted Agent Exploration. AgenticOS Workshop @ SOSP 2026. https://os-for-agent.github.io/papers/AgenticOS_SOSP_2026_paper_19.pdf
• Jensen, M. C., Meckling, W. H. Theory of the Firm: Managerial Behavior, Agency Costs and Ownership Structure. Journal of Financial Economics 3(4), 1976, pp. 305–360. https://doi.org/10.1016/0304-405X(76)90026-X
• Karpathy, A. LLM OS. Post on X, 11 November 2023. https://x.com/karpathy/status/1723140519554105733
• Karpathy, A. Intro to Large Language Models. Talk, 22 November 2023. https://www.youtube.com/watch?v=zjkBMFhNj_g
• Karpathy, A. Jagged Intelligence. Post on X, 25 July 2024. https://x.com/karpathy/status/1816531576228053133
• Kaul, A., Lan, Q., Gupta, P. Behavioral Governance for Autonomous AI Agents: The AgentBound Framework. 2026. arXiv:2606.30970
• Ke, H. Quine: Realizing LLM Agents as Native POSIX Processes. 2026. arXiv:2603.18030
• Khanal, A., Tao, Y., Zhou, J. Beyond pass@1: A Reliability Science Framework for Long-Horizon LLM Agents. 2026. arXiv:2603.29231
• Kilburn, T., Edwards, D. B. G., Lanigan, M. J., Sumner, F. H. One-Level Storage System. IRE Transactions on Electronic Computers EC-11(2), 1962, pp. 223–235. https://doi.org/10.1109/TEC.1962.5219356
• Kilburn, T., Howarth, D. J., Payne, R. B., Sumner, F. H. The Manchester University Atlas Operating System Part I: Internal Organization. The Computer Journal 4(3), 1961, pp. 222–225. https://doi.org/10.1093/comjnl/4.3.222
• Lampson, B. W. Protection. Proc. 5th Princeton Symposium on Information Sciences and Systems, 1971, pp. 437–443; reprinted in ACM SIGOPS Operating Systems Review 8(1), 1974, pp. 18–24. https://doi.org/10.1145/775265.775268
• Lourenço, M., Neugschwandtner, M., Santos, N., Bruno, R. Securing Agentic AI with OS-Level Intent-Driven Capabilities. AgenticOS Workshop @ SOSP 2026. https://os-for-agent.github.io/
• Mehta, A. When Agents Disagree With Themselves: Behavioral Consistency as an Uncertainty Signal for LLM Agents. 2026. arXiv:2602.11619
• Mei, K., et al. AIOS: LLM Agent Operating System. 2024. arXiv:2403.16971
• Meta AI. Agents Rule of Two: A Practical Approach to AI Agent Security. October 2025. https://ai.meta.com/blog/practical-ai-agent-security/
• Miller, M. S. Robust Composition: Towards a Unified Approach to Access Control and Concurrency Control. PhD thesis, Johns Hopkins University, 2006. http://www.erights.org/talks/thesis/
• Miller, M. S., Yee, K.-P., Shapiro, J. Capability Myths Demolished. Technical Report SRL2003-02, Johns Hopkins University Systems Research Laboratory, 2003. https://papers.agoric.com/assets/pdf/papers/capability-myths-demolished.pdf
• Mohammadi, B., Bindschaedler, L. The Irreversibility Budget: Fleet-Level Risk Accounting and Admission Control for Agent Operating Systems. AgenticOS Workshop @ SOSP 2026. arXiv:2609.00275
• Morris, M. R., Altman, D., Belfield, H., Goemans, A., Iqbal, H., Burnell, R., Gabriel, I., Albanie, S., Dafoe, A. Characterizing Jaggedness Aids Safety & Usability. Google DeepMind technical report, 2026. https://cs.stanford.edu/~merrie/papers/jaggedness_preprint.pdf
• Muruaga, X. Bounded Agents: Delegation Security for Multi-Agent AI Systems. 2026. arXiv:2608.15888
• Otsuka, Toyoda, Leung. AI Identity: Standards, Gaps, and Research Directions for AI Agents. 2026. arXiv:2604.23280
• Parasuraman, R., Sheridan, T. B., Wickens, C. D. A Model for Types and Levels of Human Interaction with Automation. IEEE Transactions on Systems, Man, and Cybernetics, Part A 30(3), 2000, pp. 286–297. https://doi.org/10.1109/3468.844354
• Patrick, R. L. General Motors/North American Monitor for the IBM 704 Computer. RAND Paper P-7316, 1987. https://www.rand.org/pubs/papers/P7316.html
• Pirch, Horlboge, Großmann, Asif, Kireev, Holz, Rieck. Toward Securing AI Agents Like Operating Systems. 2026. arXiv:2605.14932
• Ritchie, D. M., Thompson, K. The UNIX Time-Sharing System. Communications of the ACM 17(7), 1974, pp. 365–375. https://doi.org/10.1145/361011.361061
• Saltzer, J. H. Protection and the Control of Information Sharing in Multics. Communications of the ACM 17(7), 1974, pp. 388–402.
• Saltzer, J. H., Schroeder, M. D. The Protection of Information in Computer Systems. Proceedings of the IEEE 63(9), 1975, pp. 1278–1308. https://doi.org/10.1109/PROC.1975.9939
• Santos-Grueiro, I. Lingering Authority: Revocable Resource-and-Effect Capabilities for Coding Agents. 2026. arXiv:2606.22504
• South, T., et al. Authenticated Delegation and Authorized AI Agents. 2025. arXiv:2501.09674
• Steinder, M., Franke, H. Towards an Agent Operating System: Lessons from Classical and Cloud OS. 2026. arXiv:2607.25076
• Tallam, K. Authorization Propagation in Multi-Agent AI Systems: Identity Governance as Infrastructure. 2026. arXiv:2605.05440
• Veski, R. M., Guerraoui, R., Froelicher, D. CAPMAS: Capability-Based Delegation of Privileges in Multi-Agent Systems. 2026. arXiv:2609.06500
• Willison, S. The lethal trifecta for AI agents. June 2025. https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/
• Zhang, L., Sun, Y., Shi, J. When the Agent Becomes the Kernel: A Systematization of Security on the Path to AI-Native Operating Systems. 2026. arXiv:2609.23700
• Zhang, Y. Agent libOS: A Runtime Substrate for Capability-Controlled Self-Evolving LLM Agents. 2026. arXiv:2606.03895
• Zheng, Y., Zhang, W., Mao, Y. LLM Agent Capabilities Should Follow Task Intent and Context Source. AgenticOS Workshop @ SOSP 2026. https://os-for-agent.github.io/
• Zhou, Z. Governing Dynamic Capabilities: Cryptographic Binding and Reproducibility Verification for AI Agent Tool Use. 2026. arXiv:2603.14332
• Zhu, G., Wang, C. Authorization Revocation for Long-Running AI Agents: Root-Scoped Quiescence under Delegation and Asynchronous Execution. 2026. arXiv:2609.21284
• Zuvic, D. M. Capability Gates Are Not Authorization: Confused-Deputy Failures in LLM Agent Frameworks. 2026. arXiv:2606.28679

A note on method

Drafted with Claude Fable 5.1. The argument, the faithful-deputy premise, the two-branch derivation, and the requirements, both here and in the underlying system, are mine. The recent literature was surveyed with Paper Lantern (96 papers, five approach families) and every citation was verified against its source independently of that survey.

Kendall Clark · k@pentad.ai
Great Falls, Virginia
12 October 2026