The Operating System That Was Not a Resource Manager

On June 19, 2026, a seven-author preprint from Zhao and colleagues filed with arXiv under Computer Science: Cryptography and Security proposed a structural reframing of the operating system itself. The paper calls the design AgenticOS. The central claim is stated plainly in the abstract: the traditional OS should be reframed from a "resource manager" into an "intent filter." The paper is eleven pages. It introduces four architectural layers, three named system components, and an admission model. It does not arrive at a market product. It arrives at an architectural claim that lands at the center of a governance gap the current procurement apparatus has not yet specified.

The structural claim

Traditional operating systems arbitrate access to resources: CPU cycles, memory pages, file descriptors, network sockets. The permission model is object-level. The OS asks whether the requesting process holds the right to the object. It does not ask why the process wants the object, or whether the action the process intends to compose from that object is within any authorized scope.

For human-authored software, that model has held. A spreadsheet application requests file-read access because it needs to open a file. The action is legible in the resource request. For an LLM-driven autonomous agent, the June 19 arXiv preprint by Zhao and colleagues notes that the same model fails: "Once an agent runtime is compromised through prompt injection or malicious tool outputs, an attacker can compose POSIX-style resource primitives into behaviors far beyond the user's task authorization." The agent requests file-read access, network access, and code execution access separately. Each request clears the permission check. The composed behavior does not.

AgenticOS addresses this by shifting the authorization unit. Instead of requesting low-level resources directly, agents submit structured intent declarations. The OS receives the declared intent, validates it against a manifest, and synthesizes from that validated intent a least-privilege environment containing only the capabilities required to execute the declared intent. Capabilities are not pre-granted. They are generated at runtime, scoped to the manifest, and expire with the intent.

The four-layer architecture carries this claim into implementation. The Ghost Kernel is the lowest layer, handling OS-native capability primitives and information-flow enforcement. The Logic Shutter sits above it, mediating the translation from declared intent to generated capability set. The Agent Capsule is the isolated runtime container in which the agent executes within the bounds the Logic Shutter produced. The Semantic Boundary Gateway governs cross-agent and cross-system communication, enforcing that information leaving one capsule does not violate the flow constraints of another. Above all four layers, the Intent ABI defines the structured interface through which an agent's declared intent is submitted. The Manifest-Only Runtime enforces that an agent capsule may only use what the manifest names. The Weaver component generates the capability environment from the validated intent and manifest.

The admission model for AgenticOS-native Skills governs how external tool capabilities enter the system: not as pre-authorized tool bindings, but as admitted Skills that pass the same manifest validation before the agent can invoke them.

Governance reading

The governance gap this architecture addresses has been named in three prior pieces in this arc.

The June 22 paper on intent-governed tool authorization by Zhu and Wang (arXiv 2606.22916), covered as V035, introduced the IGAC protocol: server-side authorization, intent certificates, and a monotone narrowing rule under which authority only decreases as a task is decomposed. The structural argument of IGAC is that the authorization decision should sit off the agent. AgenticOS makes the same argument one layer down: the authorization decision should sit in the OS itself. The intent certificate IGAC names needs somewhere to live at execution time. AgenticOS is the proposed habitat.

The May 18 paper by Christodorescu, Fernandes, Jha, and colleagues (arXiv 2605.18991) argued that the model is an untrusted component and that security must live in the surrounding system. AgenticOS operationalizes that argument: the surrounding system is the OS layer, and the mechanism is the intent filter. The model submits an intent. The OS treats the model as untrusted and validates the intent against the manifest before generating any capability.

The procurement gap is visible from the same angle. EO 14409, signed June 22, constructs a procurement floor for cryptographic posture. It binds covered contractors to FIPS-incorporated algorithms and creates a 270-day clock for CISA to publish the minimum elements of a cryptographic bill of materials. That floor is defined at the artifact level: which algorithms a product uses. It does not define a floor at the runtime level: what capability a deployed agent may compose from OS-level primitives once it is running. The CISA five categories of agentic AI risk (C1-C5) name privilege escalation, data exfiltration, and prompt injection as risk classes. None of the five categories currently names an OS-level intent filter as the required control surface.

AgenticOS is not itself a procurement specification. It is an architectural claim that the procurement floor for agentic AI, when it arrives, will need to name a layer below the model and below the tool-authorization protocol: the layer at which declared intent is validated against a manifest and capabilities are synthesized only for that intent. The paper names that layer. The procurement instrument that would bind a contractor to implement it does not yet exist.

The AISI Engineering Playbook, released June 18, treated the evaluation substrate as a separate governance object: not the model under evaluation, but the environment in which the model is evaluated. AgenticOS treats the OS itself as a governance object: not the application running on the OS, but the layer that decides what the application may compose. The structural logic is the same. The artifact that governance must specify is no longer the endpoint capability. It is the substrate that produces endpoint capabilities on demand.

What composes with this

The composition chain across this arc is tightening. The May 20 heartbeat-bound credential paper by Deochake and Saurabh (arXiv 2605.20704) bounded the zombie-credential window cryptographically: when a parent agent stops issuing heartbeats, descendant credentials expire within a deterministically bounded window. That protocol operates at the identity layer. AgenticOS operates at the capability layer. Together they sketch a substrate in which agent credentials expire on schedule and the capabilities those credentials unlock are manifest-scoped at the OS level. The two papers do not cite each other. Their structural arguments compose.

The V035 IGAC intent certificate protocol sits between them. IGAC issues a narrowed authorization certificate that the agent carries into execution. AgenticOS synthesizes the capability environment from the manifest that certificate names. The certificate carries the intent. The OS validates and executes. The three-layer stack has no current procurement specification above it.

The agent meltdown results from Jha and colleagues (arXiv 2605.19149) showed that 64.7% of agent rollouts produced meltdowns triggered by benign errors, and that over half were not reported to the user. The agent did not know it had failed; the operator did not know either. AgenticOS would not prevent meltdowns at the policy level. It would, however, produce an audit trail: every intent declaration, every manifest validation, every capability generation event is logged at the OS layer. The meltdown remains invisible to the user. It becomes visible in the OS audit log. Whether that audit log is currently within scope of any evaluation or procurement requirement is the open question the paper leaves unanswered.

The Five Categories risk taxonomy from CISA names five structural concerns about agentic AI: inappropriate resource access, data exfiltration, action without human oversight, prompt injection enabling privilege escalation, and accountability gaps. AgenticOS addresses the first, third, and fourth of those categories at the OS layer. The second requires the Semantic Boundary Gateway to enforce information-flow constraints at the output. The fifth, accountability, requires the audit trail to be interrogable by an external function. The paper describes the audit trail. It does not describe who reads it, under what authority, or whether any current governance framework requires the reading.

What remains on the table

• When a procurement specification for agentic AI eventually names the OS layer as a required control surface, will it specify the intent-filter model, the manifest-only runtime, both, or will it defer to a certification body that has not yet been constituted?
• The Weaver capability generation component synthesizes capabilities at runtime from validated intent. What authority determines what the manifest may name? If the manifest is authored by the same party that deploys the agent, the manifest validation is self-certifying. If the manifest is authored by a third party or a procurement officer, the intent-filter model gains external accountability. The paper does not specify who writes the manifest.
• The Semantic Boundary Gateway enforces information-flow constraints across agent capsules. Those constraints must be derived from somewhere: a policy document, a contract, a classification marking. The paper names the enforcement mechanism without naming the policy source. Does the policy source exist in any current governance framework?
• IGAC (V035) issues intent certificates that name a narrowed authorization scope. AgenticOS validates intent against a manifest. Are those two documents the same artifact under different names, or are they two distinct objects that must be reconciled at execution time?
• The CISA five categories do not currently name the OS layer as a required control surface. When the categories are revised or extended, what evidence would constitute a procurement threshold for an OS-level intent filter?

The loop closed around an oversight function that was never instrumented.