Pith. sign in

REVIEW 2 minor 1 cited by

Agent Operating Systems (AOS): Integrating Agentic Control Planes into, and Beyond, Traditional Operating Systems

T0 review · 0 major / 2 minor · reviewed 2026-06-28 · grok-4.3

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read An Agent Operating System integrates an agentic control plane into traditional operating systems to manage long-lived, adaptive AI agents.

desk verdict This is a definitional position paper on Agent Operating Systems that organizes ideas but supplies no implementation, data, or proof that current OSes fall short. read the letter →

arxiv 2606.01508 v1 pith:3QNLMXWL submitted 2026-06-01 cs.CR cs.AI

Ankur Sharma , Deep Shah This is my paper · ORCID
classification cs.CRcs.AI
keywords agentoperatingsystemagenticcontrolplanesystemsAIagentssecurityobservabilityschedulingpolicyenforcement
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper establishes that traditional operating systems, designed for deterministic programs with predictable interactions, face limitations when handling agentic AI systems that reason probabilistically, invoke tools dynamically, and adapt based on feedback. It defines an Agent Operating System (AOS) as an architecture that adds or subsumes an agentic control plane, with explicit decomposition into schedulers, memory management, tool registries, policy enforcement, and observability. The work analyzes how classical abstractions fall short for these workloads and proposes integration models from user-space to distributed planes while mapping concepts to Linux and Windows. A reader would care because the approach aims to ensure agentic computation remains controllable, accountable, and secure rather than relying solely on user-space implementations.

What carries the argument

The agentic control plane, which decomposes AOS responsibilities into schedulers, context and memory management, tool and capability registries, policy and trust enforcement, and observability and audit.

What would settle it

A large-scale deployment of agentic AI workloads that maintains deterministic scheduling, secure isolation, comprehensive auditability, and operator oversight using only existing user-space application mechanisms on current operating systems would falsify the need for an integrated AOS control plane.

Watch

Extended reading notes

Core claim

The paper claims that an Agent Operating System (AOS) integrates an agentic control plane into existing operating systems or subsumes selected responsibilities over time, because agentic AI introduces execution characteristics that stress OS boundaries in scheduling, memory and state management, security, observability, and governance beyond user-space applications, and it supplies a definition, assumptions, non-goals, structured decomposition of responsibilities, limitation analysis, integration models, mappings to Linux and Windows, security implications with agent-specific threat models, and evaluation criteria emphasizing deterministic enforcement, auditability, and operator comprehensib

Load-bearing premise

Agentic AI systems introduce execution characteristics that stress OS boundaries in scheduling, memory and state management, security, observability, and governance beyond what can be handled by implementing agents as user-space applications.

Editorial extensions

If this is right

  • Agent-specific threat models become necessary for security and safety analysis.
  • Evaluation criteria must prioritize deterministic enforcement, auditability, and operator comprehensibility over traditional metrics.
  • Integration models range from user-space runtimes to distributed control planes that may subsume OS responsibilities.
  • Classical abstractions for processes, threads, system calls, files, and permissions require analysis for their limits with probabilistic agent behavior.
  • Mappings of AOS concepts onto Linux and Windows primitives provide concrete starting points for implementation.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • Production systems running many coordinated agents may require shared governance layers that current per-process models do not supply.
  • Hardware or kernel extensions optimized for long-running probabilistic execution could follow from the control-plane requirements.
  • Audit and policy mechanisms defined for AOS might apply to other adaptive systems such as robotic control or automated trading platforms.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit.

Referee Report

0 major / 2 minor

Summary. The manuscript introduces the concept of an Agent Operating System (AOS) as a systems architecture integrating an agentic control plane into (or beyond) traditional operating systems. It supplies a definition of AOS together with explicit assumptions and non-goals, decomposes AOS responsibilities into schedulers, context/memory management, tool/capability registries, policy/trust enforcement, and observability/audit, analyzes limitations of classical OS abstractions for agentic workloads, proposes integration models ranging from user-space runtimes to distributed control planes, maps the concepts onto Linux and Windows primitives, discusses agent-specific security and safety implications, and defines evaluation criteria centered on deterministic enforcement, auditability, and operator comprehensibility. The stated objective is to establish a rigorous systems foundation rather than to replace existing operating systems.

Significance. If the definitional and architectural elements hold, the work supplies a structured starting point for future systems research on controllable, accountable agentic computation. Credit is due for the explicit responsibility decomposition, the concrete mapping of AOS concepts onto existing OS primitives, and the formulation of agent-specific evaluation criteria; these elements are load-bearing for the paper's claim of providing a 'rigorous systems foundation.'

minor comments (2)
  1. Abstract: the single-paragraph abstract introduces many distinct contributions (definition, decomposition, integration models, mappings, threat models, evaluation criteria) without visual separation; a short bulleted enumeration of the main contributions would improve scannability while preserving the paragraph form for the motivation.
  2. The manuscript asserts that agentic workloads stress classical OS boundaries 'beyond what can be handled by implementing agents as user-space applications,' yet supplies no concrete workload trace, scheduling example, or memory-access pattern to illustrate the claimed stress points; adding one illustrative scenario (even if hypothetical) would strengthen the motivation section without altering the definitional nature of the central claim.

Simulated Author's Rebuttal

0 responses · 0 unresolved

We thank the referee for the positive and accurate summary of the manuscript, including recognition of the responsibility decomposition, concrete mappings to existing OS primitives, and agent-specific evaluation criteria as load-bearing elements. The recommendation for minor revision is noted. As the report lists no specific major comments, we have no point-by-point items to address.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity

full rationale

The paper is a high-level conceptual proposal that introduces and decomposes the AOS architecture through definitions, responsibility breakdowns, integration models, and mappings to existing OS primitives. It contains no equations, fitted parameters, derivations, predictions, or load-bearing self-citations. The central claim of 'introducing the concept' is fulfilled directly by the provided definitions and analysis without reducing to any input by construction. This is a self-contained definitional work.

Assumptions & free parameters 0 free parameters · 1 assumptions · 1 invented entities

The proposal rests on a domain assumption about OS limitations for agents and introduces AOS as a new architectural entity without independent evidence or implementation.

assumptions (1)
  • domain assumption Traditional operating systems were designed around deterministic programs, explicit control flow, and human initiated workflows with bounded behavior.
    Stated directly in the abstract as the premise requiring an AOS.
invented entities (1)
  • Agent Operating System (AOS)
    purpose: Integrates an agentic control plane for AI agent workloads
    New postulated architecture introduced to address stated limitations.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Agent Operating Systems (AOS): Integrating Agentic Control Planes into, and Beyond, Traditional Operating Systems." pith.science (2026). https://pith.science/paper/3QNLMXWL

@misc{pith2026260601508,
  author       = {Pith},
  title        = {Pith review of: Agent Operating Systems (AOS): Integrating Agentic Control Planes into, and Beyond, Traditional Operating Systems},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/3QNLMXWL}},
  note         = {Machine review of arXiv:2606.01508}
}
read the original abstract

Traditional operating systems were designed around deterministic programs, explicit control flow, and human initiated workflows. Their core abstractions processes, threads, system calls, files, and permissions assume bounded behavior and predictable interaction patterns. Agentic AI systems introduce a different execution model: long-lived, goal-directed entities that reason probabilistically, invoke tools dynamically, and adapt behavior based on feedback. While agents can be implemented as user-space applications today, their execution characteristics stress OS boundaries in scheduling, memory and state management, security, observability, and governance. This paper introduces the concept of an Agent Operating System (AOS), a systems architecture that integrates an agentic control plane into existing operating systems or, in some models, subsumes selected OS responsibilities over time. We provide a precise definition of an AOS, explicit assumptions and non-goals, and a structured decomposition of AOS responsibilities into schedulers, context and memory management, tool and capability registries, policy and trust enforcement, and observability and audit. We analyze limitations of classical OS abstractions for agent workloads, propose integration models from user-space runtimes to distributed control planes, and map AOS concepts onto Linux and Windows primitives. We present security and safety implications, including agent specific threat models, and define evaluation criteria that emphasize deterministic enforcement, auditability, and operator comprehensibility. The objective is not to replace operating systems wholesale, but to establish a rigorous systems foundation for agentic computation that remains controllable, accountable, and secure at scale.

Figures

Figures reproduced from arXiv: 2606.01508 by the authors.

Figure 1
Figure 1. presents a baseline model of traditional OS mediated execution [PITH_FULL_IMAGE:figures/full_fig_p006_1.png] view at source ↗
Figure 2
Figure 2. AOS as an agentic control plane over an OS [PITH_FULL_IMAGE:figures/full_fig_p007_2.png] view at source ↗
Figure 3
Figure 3. Scheduling loop with progress checkpoints [PITH_FULL_IMAGE:figures/full_fig_p008_3.png] view at source ↗
Figures from the paper (3 more)
Figure 4
Figure 4. Figure 4: Tool mediation and deterministic enforcement [PITH_FULL_IMAGE:figures/full_fig_p010_4.png]
Figure 5
Figure 5. Figure 5: Linux mapping overview AOS components can be realized on Linux using cgroups, namespaces, seccomp, mandatory access control, and eBPF for deterministic enforcement and observability. Controlled egress reduces bypass opportunities [PITH_FULL_IMAGE:figures/full_fig_p013…
Figure 6
Figure 6. Figure 6: Windows mapping overview On Windows, AOS can leverage service models, restricted security tokens, job objects, and ETW to implement deterministic enforcement and traceability, typically through brokered tool execution. 6.3 Comparative Analysis: Linux and Windows For AO…

Discussion (0). Continue with ORCID to comment.

Forward citations

Cited by 1 Pith paper

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score. Full citation record

  1. The Agent Operating System (AOS): A Reference Operating Architecture for Distributed Agentic Systems

    cs.AI 2026-08 conditional novelty 6.0 of 10

    A reference architecture that separates governance (intent, policy, authority, confidence) from coordination (lifecycle, routing, scheduling, assurance) for distributed AI agents.

Reference graph

Works this paper leans on

190 extracted references · cited by 1 Pith paper

  1. [1]

    These contracts assume a specific execution model: deterministic programs invoked by users or services, with explicit control flow and explicit control of I/O

    Introduction and Motivation Operating systems represent one of the most successful abstractions in computing because they provide stable contracts between hardware, applications, and operators. These contracts assume a specific execution model: deterministic programs invoked by users or services, with explicit control flow and explicit control of I/O. The...

  2. [2]

    LLMs and learning components are probabilistic, may be incorrect, and may be adversarially influenced

  3. [3]

    The system boundary must be deterministic in enforcement, audit, and safety decisions

  4. [4]

    Agent reasoning must be separable from execution and side effects

  5. [5]

    1.2 Non-goals:

    Real systems constraints apply latency, throughput, cost, operator simplicity, and failure modes. 1.2 Non-goals:

  6. [6]

    Artificial general intelligence or self-improving autonomous kernels

  7. [7]

    A requirement that the kernel runs model inference

  8. [8]

    A claim that classical OS abstractions should be discarded wholesale

Show all 190 references
  1. [9]

    1.3 Contributions:

    A universal agent framework or application layer. 1.3 Contributions:

  2. [10]

    A precise definition of an Agent Operating System with explicit boundaries

  3. [11]

    A decomposition of AOS responsibilities into lifecycle, scheduling, memory, tool mediation, policy, and observability

  4. [12]

    Integration models ranging from user-space runtime to distributed control plane to partial subsumption of OS functions

  5. [13]

    A mapping of AOS concepts onto Linux and Windows primitives and pragmatic migration paths

  6. [14]

    Security and governance analysis with agent specific threat models and deterministic enforcement requirements

  7. [15]

    This work was conducted as part of the Unified Intelligent Infrastructure workstream at the Open Compute Project (OCP).1

    Evaluation criteria and open research problems for building credible AOS implementations. This work was conducted as part of the Unified Intelligent Infrastructure workstream at the Open Compute Project (OCP).1

  8. [16]

    The objective is not to argue that existing OS abstractions are incorrect

    Limitations of Classical OS Abstractions for Agents This section identifies concrete mismatches between classical OS design assumptions and agent workload characteristics. The objective is not to argue that existing OS abstractions are incorrect. The objective is to show where...

  9. [17]

    Definition of an Agent Operating System This section defines AOS precisely and establishes boundaries to avoid ambiguity about scope, execution, and enforcement. 3.1 Core Definition An Agent Operating System (AOS) is a systems software layer that manages the lifecycle, executi...

  10. [18]

    Agent identity is a principal with scoped authority and a defined lifecycle

  11. [19]

    Goal and task graphs represent intended outcomes and dependencies

  12. [20]

    Capability sets define which tools and actions are allowed, including scopes and bounds

  13. [21]

    Context state is the structured memory view presented to the reasoning plane

  14. [22]

    AOS does not replace processes or threads

    Execution records are append only audit trails for decisions and actions. AOS does not replace processes or threads. It interprets them as execution containers beneath the agent abstraction. 3.3 Separation of Planes AOS enforces a separation between reasoning, execution, and p...

  15. [23]

    The intent is to make responsibilities explicit and testable

    AOS Architecture and Components This section specifies a reference architecture for an Agent Operating System. The intent is to make responsibilities explicit and testable. The reference architecture does not require kernel modifications. It can be realized as user- space serv...

  16. [24]

    The appropriate model depends on risk tolerance, performance constraints, deployment environments, and the required strength of enforcement

    Integration Models AOS can be implemented in multiple ways. The appropriate model depends on risk tolerance, performance constraints, deployment environments, and the required strength of enforcement. This section evaluates several integration models and highlights tradeoffs. ...

  17. [25]

    The goal is to provide an actionable migration path for practitioners and a concrete discussion surface for OS researchers

    Mapping To Existing OSes This section grounds AOS in real primitives and shows how AOS responsibilities can be realized on Linux and Windows without requiring full OS replacement. The goal is to provide an actionable migration path for practitioners and a concrete discussion s...

  18. [26]

    Linux Vs Windows Subsystem Comparison For AOS This section compares Linux and Windows as substrates for implementing AOS responsibilities. The objective is not to rank operating systems broadly, but to identify concrete primitives that enable deterministic enforcement, isolati...

  19. [27]

    UID, GID, supplementary groups

  20. [28]

    Capabilities (fine grained privileges such as CAP_NET_ADMIN)

  21. [29]

    Mandatory access control frameworks (SELinux, AppArmor)

  22. [30]

    PAM and pluggable authentication

  23. [31]

    Namespaces, particularly user namespaces for remapping identities AOS relevance

  24. [32]

    Map agent identity to a stable principal for ownership and attribution, while keeping agent level identity in AOS metadata

  25. [33]

    Use capabilities and MAC to implement least privilege for tool execution sandboxes

  26. [34]

    Linux limitations for AOS

    Use user namespaces to isolate tool execution and prevent accidental privilege inheritance. Linux limitations for AOS

  27. [35]

    delegation for a specific goal

    OS identity is still primarily user and process oriented. It does not model “delegation for a specific goal” as a first-class concept

  28. [36]

    This pushes decision logic into AOS policy and mediation

    Fine grained constraints over parameters of an action are not naturally expressed at the OS identity layer. This pushes decision logic into AOS policy and mediation

  29. [37]

    Windows primitives

    Attribution across chains of processes requires careful propagation of correlation identifiers. Windows primitives

  30. [38]

    Security identifiers (SIDs) and access tokens

  31. [39]

    Privileges within tokens (e.g., SeDebugPrivilege)

  32. [40]

    Access control lists (DACL, SACL) and security descriptors

  33. [41]

    User Account Control and integrity levels

  34. [42]

    Service accounts and managed service identities in enterprise deployments AOS relevance

  35. [43]

    Restricted tokens support strong least privilege execution for tools and side effects

  36. [44]

    ACLs allow object level enforcement, useful for file and registry access boundaries for agents

  37. [45]

    Windows limitations for AOS

    Auditing via SACL and centralized event pipelines support governance. Windows limitations for AOS

  38. [46]

    goal scoped delegation

    As with Linux, “goal scoped delegation” is not a native OS primitive. It must be implemented by AOS as policy and token issuance discipline

  39. [47]

    The OS will not guarantee this unless tool execution is strictly constrained

    Ensuring every agent side effect flows through a mediated broker is an architectural requirement. The OS will not guarantee this unless tool execution is strictly constrained. Key AOS design implication: AOS should define delegation as an AOS level construct that results in OS...

  40. [48]

    Namespaces: pid, mount, net, ipc, uts, user

  41. [49]

    cgroups v1 and v2 (CPU, memory, I/O, pids)

  42. [50]

    seccomp for syscall filtering

  43. [51]

    Linux capabilities and no new privileges flag

  44. [52]

    MAC enforcement: SELinux, AppArmor

  45. [53]

    Containers built from these primitives AOS relevance

  46. [54]

    Run tool execution in sandboxes with minimal syscalls, limited filesystem views, restricted network, and bounded resources

  47. [55]

    Enforce deterministic containment rules independent of model behavior

  48. [56]

    Linux limitations for AOS

    Limit blast radius of injected or erroneous tool requests. Linux limitations for AOS

  49. [57]

    AOS must provide policy generation, testing, and safe defaults

    seccomp and MAC policy creation is complex and error prone. AOS must provide policy generation, testing, and safe defaults

  50. [58]

    Container escape risks exist if policies are misconfigured, so mediation must be defense in depth

  51. [59]

    only mediated tools

    Enforcing “only mediated tools” requires additional constraints at network and API layers. Windows primitives

  52. [60]

    Job objects (resource constraints and process grouping)

  53. [61]

    Windows containers and Hyper V isolation

  54. [62]

    AppContainer and capability-based sandboxing for certain app models

  55. [63]

    Code integrity and application control policies

  56. [64]

    Windows Defender and enterprise controls for execution policy AOS relevance

  57. [65]

    Group tool processes in job objects to enforce CPU and memory caps and enable termination semantics

  58. [66]

    Use Windows containers or Hyper V isolation for high-risk tools

  59. [67]

    Windows limitations for AOS

    Rely on restricted tokens and application control to limit what can execute. Windows limitations for AOS

  60. [68]

    AOS must standardize how tools are packaged and executed

    Sandboxing models vary by subsystem and app type. AOS must standardize how tools are packaged and executed

  61. [69]

    Key AOS design implication: Tool execution should be treated as a controlled workload class with standardized packaging and sandbox profiles per tool category, irrespective of OS

    Some constraints are easier at the enterprise policy layer than at the OS kernel layer, which increases dependence on environment configuration. Key AOS design implication: Tool execution should be treated as a controlled workload class with standardized packaging and sandbox ...

  62. [70]

    CFS scheduler, real time scheduling classes

  63. [71]

    nice values and priorities

  64. [72]

    cgroups CPU quotas and shares

  65. [73]

    I/O controllers in cgroups v2

  66. [74]

    OOM killer and memory pressure signals AOS relevance

  67. [75]

    Enforce bounded reasoning and execution budgets using cgroups for inference workers and tool sandboxes

  68. [76]

    Use separate resource pools for reasoning plane and execution plane to avoid hidden starvation

  69. [77]

    Linux limitations for AOS

    Use memory pressure signals to trigger deterministic degradation such as shrinking context windows or pausing low priority agents. Linux limitations for AOS

  70. [78]

    Goal progress must be tracked and acted upon by AOS

    The kernel schedules threads, not goals. Goal progress must be tracked and acted upon by AOS

  71. [79]

    useful reasoning

    Distinguishing “useful reasoning” from “thrashing” is not visible to the OS. AOS must impose time slice limits and checkpointing

  72. [80]

    AOS should isolate per agent reasoning workers where feasible

    QoS across agents is difficult if all inference runs in a shared runtime process. AOS should isolate per agent reasoning workers where feasible. Windows primitives

  73. [81]

    Windows scheduler priorities and quantum management

  74. [82]

    Job objects for CPU rate control

  75. [83]

    Resource controls in containers

  76. [84]

    I/O prioritization and system resource manager features in enterprise environments AOS relevance

  77. [85]

    Like Linux, use job objects and container controls to bound inference and tool execution

  78. [86]

    Windows limitations for AOS

    Use OS performance counters and ETW signals to detect pressure and enforce throttles. Windows limitations for AOS

  79. [87]

    Fine grained control is often mediated by enterprise policy and management layers

  80. [88]

    AOS must implement checkpoints and progress accounting

    As with Linux, the OS does not understand goal progress. AOS must implement checkpoints and progress accounting. Key AOS design implication: AOS must introduce an agent scheduler that produces resource intents, while the OS enforces low level allocation via cgroups or job obje...

  81. [89]

    netfilter, nftables, iptables for policy enforcement

  82. [90]

    Network namespaces for isolation

  83. [91]

    eBPF based traffic accounting and policy hooks

  84. [92]

    Proxy and gateway patterns at user-space

  85. [93]

    Filesystem controls via mount namespaces and read only overlays AOS relevance

  86. [94]

    Ensure that all external calls from tool sandboxes are routed through controlled egress gateways for logging and policy enforcement

  87. [95]

    Linux limitations for AOS

    Enforce deterministic allowlists, rate limits, and data loss prevention rules at the boundary. Linux limitations for AOS

  88. [96]

    Application-level policies such as per API call auditing require cooperation from mediation layers, not only kernel filters

  89. [97]

    Windows primitives

    Strictly preventing direct outbound calls without a proxy is feasible but operationally delicate and must be tested. Windows primitives

  90. [98]

    Windows Firewall and enterprise network policy

  91. [99]

    Proxy settings, enterprise gateways

  92. [100]

    Windows Filtering Platform for network filtering and inspection

  93. [101]

    ETW network events AOS relevance

  94. [102]

    Similar controlled egress design, with OS policy enforcement plus brokered tool calls

  95. [103]

    Windows limitations for AOS

    Centralized enterprise policy can support strong governance if configured. Windows limitations for AOS

  96. [104]

    Consistency depends heavily on enterprise configuration and managed endpoints

  97. [105]

    Key AOS design implication: Treat network as a side-effecting tool category

    Some applications may bypass proxy settings, requiring stronger broker and sandbox constraints. Key AOS design implication: Treat network as a side-effecting tool category. Require mediated egress by default and treat direct outbound networking from agent sandboxes as a policy...

  98. [106]

    eBPF for syscall, network, and scheduler tracing

  99. [107]

    perf and ftrace for performance

  100. [108]

    cgroup metrics and procfs AOS relevance

  101. [109]

    Correlate OS level events with AOS action ids to form decision lineage

  102. [110]

    Use eBPF and audit logs to detect bypass attempts and unexpected syscalls

  103. [111]

    Linux limitations for AOS

    Record resource usage per agent and per tool for evaluation and billing like accounting. Linux limitations for AOS

  104. [112]

    AOS must propagate stable correlation identifiers into tool processes and logs

    Correlation is not automatic. AOS must propagate stable correlation identifiers into tool processes and logs

  105. [113]

    Windows primitives

    Capturing full decision lineage requires AOS controlled logging of reasoning inputs and outputs, with careful privacy controls. Windows primitives

  106. [114]

    Event Tracing for Windows (ETW)

  107. [115]

    Windows Event Log and auditing policies

  108. [116]

    Performance counters

  109. [117]

    Sysmon in enterprise contexts

  110. [118]

    Service control manager events AOS relevance

  111. [119]

    ETW supports high fidelity event pipelines that can be stitched into AOS audit records

  112. [120]

    Windows limitations for AOS

    Strong enterprise audit posture is feasible when policy is correctly configured. Windows limitations for AOS

  113. [121]

    As with Linux, AOS must ensure correlation id propagation and consistent tool brokering

  114. [122]

    Key AOS design implication: AOS must define a canonical audit schema and correlation protocol

    High volume event streams require careful sampling and retention policies, and AOS should define which events are mandatory for compliance. Key AOS design implication: AOS must define a canonical audit schema and correlation protocol. OS observability enriches but does not rep...

  115. [123]

    This section defines explicit threat models and deterministic mitigations that align with established OS security principles

    Security, Safety, And Governance Implications Agents introduce new threat surfaces and new failure modes. This section defines explicit threat models and deterministic mitigations that align with established OS security principles. 8.1 Threat Model Categories AOS must consider...

  116. [124]

    Prompt and context manipulation: An adversary attempts to influence agent reasoning by injecting malicious instructions into inputs or retrieved memory

  117. [125]

    Tool misuse: An agent invokes tools with harmful parameters or unintended side effects

  118. [126]

    Privilege escalation: The agent obtains broader access than intended through misconfigured delegation or tool chaining

  119. [127]

    Data exfiltration: The agent leaks sensitive data through tool outputs or uncontrolled network calls

  120. [128]

    Supply chain and tool integrity: Tools are compromised or return malicious or misleading outputs

  121. [129]

    Audit evasion: The agent bypasses mediation to avoid logging or enforcement

  122. [130]

    8.2 Stateful and Compositional Attacks Many real-world agent failures are compositional rather than atomic

    Control plane compromise: Adversaries compromise the AOS control plane itself, including policy engines, capability stores, mediation services, or audit infrastructure, thereby bypassing enforcement guarantees. 8.2 Stateful and Compositional Attacks Many real-world agent failu...

  123. [131]

    Deny by default for side-effecting tools unless explicitly allowed by capability

  124. [132]

    Capabilities must be scoped, time bounded, and revocable

  125. [133]

    This must be enforced by OS and network controls, not by convention

    All tool calls must flow through mediation. This must be enforced by OS and network controls, not by convention

  126. [134]

    Policy decisions must produce deterministic reason codes and be logged

  127. [135]

    Output filters for sensitive data classes must be deterministic and applied after tool execution but before external egress where applicable

  128. [136]

    Safe failure modes must prefer denial of side effects under policy engine outages or audit sink failures. 8.4 Prompt Injection as An Untrusted Input Problem Prompt injection should be treated as a form of untrusted input, analogous to user supplied data in traditional OS secur...

  129. [137]

    No side effects

    Read only. No side effects. Tools limited to observation and retrieval

  130. [138]

    Limited and reversible side effects under strict scopes

    Low risk. Limited and reversible side effects under strict scopes

  131. [139]

    Broader actions with full policy, audit, and anomaly monitoring

    Controlled. Broader actions with full policy, audit, and anomaly monitoring

  132. [140]

    Actions require approvals or dual control and may require additional verification steps

    High impact. Actions require approvals or dual control and may require additional verification steps. These levels allow operators to match agent autonomy to system criticality and compliance constraints

  133. [141]

    Related Work and Comparison This section situates Agent Operating Systems relative to established systems mechanisms. The comparison emphasizes what those mechanisms solve, what they intentionally do not solve, and where AOS introduces new requirements, particularly around det...

  134. [142]

    Process level isolation using namespaces and resource controls

  135. [143]

    Reproducible packaging of dependencies and runtime environments

  136. [144]

    Operational primitives for deployment, scaling, and lifecycle management What containers do not provide for agent systems

  137. [145]

    Agent identity as a principal with delegated authority and revocation semantics

  138. [146]

    Deterministic mediation for side-effecting actions beyond OS syscalls

  139. [147]

    Decision lineage, including why an action was taken and under which policy constraints

  140. [148]

    In an AOS design, containers become a containment mechanism, while AOS provides the control plane for goal scheduling, tool mediation, and audit

    Goal progress scheduling, since containers run workloads rather than manage intent Relationship to AOS: AOS can use containers as an execution substrate for tools and agent runtimes. In an AOS design, containers become a containment mechanism, while AOS provides the control pl...

  141. [149]

    Strong isolation at hardware boundaries

  142. [150]

    Independent OS instances per workload

  143. [151]

    Reduced blast radius for compromised kernels or containers What hypervisors do not provide for agent systems

  144. [152]

    Fine grained capability mediation for tool invocation within a VM

  145. [153]

    Cross VM policy enforcement tied to agent identity and delegated authority

  146. [154]

    AOS can schedule tool execution into VMs for stronger isolation

    Unified decision lineage across reasoning and execution components Relationship to AOS: Hypervisors are useful for high-risk tool sandboxes or strict tenant separation. AOS can schedule tool execution into VMs for stronger isolation. However, hypervisors address isolation, not...

  147. [155]

    Declarative desired state for workloads

  148. [156]

    Scheduling based on resource requests and node availability

  149. [157]

    Lifecycle automation and self-healing at the service level

  150. [158]

    Namespace isolation and multi tenancy controls What orchestration does not provide for agent systems

  151. [159]

    Orchestrators schedule pods and containers, not goals and plans

    Goal progress and intent scheduling. Orchestrators schedule pods and containers, not goals and plans

  152. [160]

    Orchestrators do not enforce per action parameter constraints or reason codes

    Deterministic tool mediation. Orchestrators do not enforce per action parameter constraints or reason codes

  153. [161]

    Orchestrators explain placement and lifecycle events, not autonomous action selection within workloads

    Decision lineage. Orchestrators explain placement and lifecycle events, not autonomous action selection within workloads

  154. [162]

    Relationship to AOS: AOS as a distributed control plane can be implemented on top of Kubernetes

    Agent specific governance such as approvals, delegated authority, and bounded autonomy levels. Relationship to AOS: AOS as a distributed control plane can be implemented on top of Kubernetes. In that model, Kubernetes manages where components run, while AOS governs what action...

  155. [163]

    Declarative authorization logic

  156. [164]

    Centralized policy management and auditing hooks

  157. [165]

    Consistent decisions across services What policy engines do not provide for agent systems

  158. [166]

    Policy engines decide to allow or deny, but they do not guarantee execution through a mediated sandbox

    End to end action mediation. Policy engines decide to allow or deny, but they do not guarantee execution through a mediated sandbox

  159. [167]

    Tight coupling to resource accounting and budgets across reasoning and execution phases

  160. [168]

    Relationship to AOS: Policy engines naturally belong in the AOS policy plane

    Built in decision lineage that includes the reasoning context and proposed action chain, unless integrated explicitly. Relationship to AOS: Policy engines naturally belong in the AOS policy plane. However, AOS must extend beyond authorization to include deterministic enforceme...

  161. [169]

    Deterministic enforcement boundaries

  162. [170]

    Capability based tool access with revocation

  163. [171]

    Auditability and operator comprehensibility

  164. [172]

    Frameworks can run within the reasoning plane, while AOS constrains execution and provides governance

    Resource scheduling and isolation across many agents Relationship to AOS: AOS is complementary. Frameworks can run within the reasoning plane, while AOS constrains execution and provides governance. This separation reduces the requirement that application code be perfectly saf...

  165. [173]

    The core question is whether the system remains deterministic, auditable, and secure under probabilistic reasoning and adversarial conditions

    Evaluation Criteria and Open Research Problems Evaluation of AOS should focus on systems properties rather than on model accuracy. The core question is whether the system remains deterministic, auditable, and secure under probabilistic reasoning and adversarial conditions. 10....

  166. [174]

    Many tool calls with mixed read and write operations to measure mediation latency and audit coverage

    Tool heavy workflow. Many tool calls with mixed read and write operations to measure mediation latency and audit coverage

  167. [175]

    Several agents sharing data under strict policy to measure isolation, controlled sharing, and deadlock or starvation avoidance

    Multi agent coordination. Several agents sharing data under strict policy to measure isolation, controlled sharing, and deadlock or starvation avoidance

  168. [176]

    Injection attempts through documents and messages to measure containment and policy resilience

    Adversarial input campaign. Injection attempts through documents and messages to measure containment and policy resilience

  169. [177]

    Reconstruction of actions and policy decisions to measure trace usability and deterministic reconstruction of context views

    Incident response replay. Reconstruction of actions and policy decisions to measure trace usability and deterministic reconstruction of context views. 10.3 Open Research Problems Open problems include agent scheduling theory for goal progress and fairness, memory semantics for...

  170. [178]

    Conclusion And Future Work Agentic systems alter the computational unit from deterministic programs to goal-directed entities with probabilistic reasoning and dynamic tool use. Existing operating systems provide strong low-level primitives for isolation and hardware mediation ...

  171. [179]

    A. S. Tanenbaum and H. Bos, Modern Operating Systems, 4th ed., Pearson, 2014

    2014

  172. [180]

    Silberschatz, P

    A. Silberschatz, P. B. Galvin, and G. Gagne, Operating System Concepts, 10th ed., Wiley, 2018

    2018

  173. [181]

    Kerrisk, The Linux Programming Interface, No Starch Press, 2010

    M. Kerrisk, The Linux Programming Interface, No Starch Press, 2010

    2010

  174. [182]

    Xen and the art of virtualization,

    P. Barham et al., “Xen and the art of virtualization,” Proceedings of the 19th ACM Symposium on Operating Systems Principles (SOSP), 2003

    2003

  175. [183]

    Borg, Omega, and Kubernetes,

    B. Burns, B. Grant, D. Oppenheimer, E. Brewer, and J. Wilkes, “Borg, Omega, and Kubernetes,” Communications of the ACM, vol. 59, no. 5, pp. 50–57, 2016

    2016

  176. [184]

    Docker: Lightweight Linux containers for consistent development and deployment,

    D. Merkel, “Docker: Lightweight Linux containers for consistent development and deployment,” Linux Journal, vol. 2014, no. 239, 2014

    2014

  177. [185]

    A deep dive into cgroups,

    J. Edge, “A deep dive into cgroups,” LWN.net, 2016

    2016

  178. [186]

    Integrating flexible support for security policies into the Linux operating system,

    P. Loscocco and S. Smalley, “Integrating flexible support for security policies into the Linux operating system,” Proceedings of the USENIX Annual Technical Conference, 2001

    2001

  179. [187]

    Russinovich, D

    M. Russinovich, D. Solomon, and A. Ionescu, Windows Internals, 7th ed., Microsoft Press, 2017

    2017

  180. [188]

    Levy, Capability-Based Computer Systems, Digital Press, 1984

    H. Levy, Capability-Based Computer Systems, Digital Press, 1984

    1984

  181. [189]

    eBPF – In-kernel virtual machine,

    A. Starovoitov and D. Borkmann, “eBPF – In-kernel virtual machine,” Linux Foundation Documentation, 2015

    2015

  182. [190]

    Language models are few-shot learners,

    T. Brown et al., “Language models are few-shot learners,” Advances in Neural Information Processing Systems (NeurIPS), 2020

    2020

Pith tools

Reviewed June 28, 2026 · model on record in the stance chip above.