idea-scout triage — AgenticOS / intent-oriented secure OS (issue #770)

Closes the daily idea-scout candidate #770 (tools/idea_scout.py, filed 2026-06-25). The scout judges whether a candidate is new and on-topic; this note is the human triage it hands off — adopt, defend against, or cite as prior art (see docs/idea-scout.md). Verdict: prior art to cite — AgenticOS reaches fak’s exact founding premise (resource+permission fails; a compromised runtime composes primitives past task authorization → move the boundary to intent-mediated capability) from the OPPOSITE implementation bet (rebuild the OS into a four-layer kernel). It is the strongest OS-altitude validation of fak’s thesis, and its four required properties map onto shipped fak seams that realize them in userspace. The four-layer OS-rebuild architecture and Weaver capability synthesis are NOT adopted.

Source: https://arxiv.org/abs/2606.21129 — “AgenticOS: An Intent-Oriented Secure Operating System Architecture for Autonomous AI Agents”, Zhen Zhao, Yu Zhang, Yanpeng Zhu, Jia Wang, Songqiao Tao, Xin Cheng, Jiexin Gao (submitted 2026-06-19). Read from the arXiv abstract via WebFetch on 2026-06-26; this is a surface read of the abstract, not a paper audit or a reproduction (the abstract names the architecture and primitives but reports no evaluation numbers).

The paper, in one pass

The diagnosis is fak’s, verbatim at a different altitude: OS security built on “resource exposure plus permission checks” breaks for LLM agents that plan, use tools, reach the network, and run code, because once the 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. Permission checks gate each primitive in isolation; the harm is in the composition, which no per-resource check sees.

The fix is to reframe the OS from a “resource manager” into an “intent filter”: instead of requesting low-level resources directly, agents submit structured intent declarations, from which the system synthesizes a least-privilege environment with mandatory mediation, auditing, and information-flow constraints. AgenticOS consolidates delegable, auditable software capabilities into OS-native ones rather than replacing every application. The implementation is a four-layer architecture — Ghost Kernel, Logic Shutter, Agent Capsule, Semantic Boundary Gateway — plus four primitives: the Intent ABI, a Manifest-Only Runtime, Weaver-based capability generation, and an admission model for AgenticOS-native Skills.

Where fak actually stands

This is, by thesis, the most on-target paper the scout has surfaced: AgenticOS and fak state the same security argument and reach the same conclusion. The lens that resolves it is the build axis: AgenticOS rebuilds the OS so intent mediation is native; fak refuses to touch the OS and instead promotes the tool call to a syscall it adjudicates in a single userspace binary. Same boundary, opposite implementation bet.

AgenticOS frame fak’s position
Diagnosis: “resource exposure + permission checks” fails; a compromised runtime composes POSIX primitives beyond task authorization fak’s founding premise, verbatim. fak’s floor is default-deny on capability the model “can’t talk past” (TestFoldDefaultDenyEmptyPolicy, internal/adjudicator / internal/policy), precisely because per-call permission alone does not bound composition. Independent OS-research confirmation that the resource+permission model is the wrong boundary for agents — the same argument fak’s floor has always made (cf. the CLAWAUDIT “the runtime IS the boundary” prior art, #585).
Reframe OS “resource manager” → “intent filter”: agents submit structured intent declarations → system synthesizes a least-privilege environment ≈ fak’s policy manifest + adjudicator. The deployable capability floor is a declarative, version-tagged JSON manifest loaded at runtime (--policy FILE, internal/policy, POLICY.md) — the adopter declares which capabilities the agent’s task needs; k.Decide admits a call against that floor and denies by structure otherwise. The “intent declaration → least-privilege env” shape is the manifest → adjudicated-call shape at userspace altitude.
Three required properties: mandatory mediation, auditing, information-flow constraints fak realizes all three without a new OS. Mediation: every tool call crosses the one in-process syscall boundary — no spawned hook, no bypass (TestNoOsExecOnHotPath, the process-fusion claim in CLAIMS.md). Auditing: the hash-chained decision/witness journal (fak guard journal; dos commit-audit / dos verify over the ledger). Information-flow: result-admit quarantine makes poisoned tool outputs non-load-bearing (k.AdmitResult, internal/normgate rank-5 canonicalize-and-rescan), with the pre-send internal/wirescreen redactor and the ifc.SinkGate egress floor (internal/tracesink) bounding outbound flow.
Four-layer architecture (Ghost Kernel, Logic Shutter, Agent Capsule, Semantic Boundary Gateway) The opposite implementation bet — not adopted. fak is one statically-linked userspace Go binary, not a new OS with privileged kernel layers an adopter must run. fak’s “Semantic Boundary Gateway” analogue is internal/gateway (a userspace proxy), but there is no Ghost Kernel / capsule layer to rebuild. fak’s whole positioning is one-binary-one-surface: you can drop fak in front of Claude Code or an MCP client today; you cannot drop a new OS kernel in front of them.
Intent ABI · Manifest-Only Runtime · Weaver capability generation · admission model for native Skills Each maps to a lighter-altitude fak seam, except the synthesis layer. Intent ABI ≈ the frozen, additive-only internal/abi (machine-checked by TestABIGoldenFreeze, guarded by internal/architest). Manifest-Only Runtime ≈ the runtime JSON policy manifest above. Admission model for Skills ≈ fak’s leaf extension model — a typed, build-time-checked Go registration (tools/new_leaf.py, internal/registrations), reviewed code admitted at build time. Weaver synthesizes capabilities from intent; fak does not synthesize capabilities — it admits reviewed leaves — so that generation layer has no fak surface and is not adopted.

So fak and the paper share the whole vocabulary — agents, tools, prompt injection, intent, least privilege, mediation, audit — and sit on the same side of the trust boundary (both protect the operator from a compromised agent runtime). They differ only on where the mediation lives: in a rebuilt OS, or in a single binary in front of the agent. That is a positioning contrast, not an adversarial one.

The sharp, honest insight

AgenticOS is the strongest external evidence yet that fak’s founding bet is correct: an OS-security research group, working independently, diagnosed the same failure (“resource exposure + permission checks” cannot bound a compromised agent’s composition of primitives) and prescribed the same cure (move the boundary from resource+permission to intent-mediated capability). Where it is most useful to fak is as a four-property acceptance checklist an agent security architecture must meet — mandatory mediation, auditing, information-flow constraints, least-privilege synthesis — against which fak can be measured. fak passes all four in userspace, without an OS rewrite, which is exactly the contribution CLAIMS.md names: every primitive is established/emerging and the contribution is the ASSEMBLY (the 0/29-NOVEL discipline) — a fused, fail-open, witness-gated kernel with the tool call promoted to a syscall. AgenticOS makes intent mediation native to the OS; fak’s claim is that you get the same four properties at the tool-call seam without asking the adopter to run a new kernel.

The matching honest fence: the two are not equivalent in reach. An OS-native intent filter mediates every syscall a compromised process can issue, including code execution and raw resource access below the tool-call layer; fak mediates the tool-call seam it fronts. A capability the agent exercises outside the calls that cross fak’s boundary — arbitrary code the agent runtime executes locally with no tool-call mediation — is the residual that an OS-altitude design like AgenticOS targets and fak’s userspace floor does not reach. fak’s bet is that the tool-call seam is the right deployable place to defend (portable, zero-deps, in front of any agent), accepting that an OS-level filter covers a strictly larger primitive set at a strictly larger adoption cost.

Triage decision

Action: close #770 as triaged → prior art cited (the strongest OS-research validation of fak’s intent-over-resource-permission thesis, with a four-property checklist fak meets in userspace) + the opposite-implementation-bet named as a positioning scope boundary (fak = one userspace binary at the tool-call seam; AgenticOS = a rebuilt OS that mediates a strictly larger primitive set at a strictly larger adoption cost); the four-layer OS-rebuild architecture and Weaver capability synthesis are explicitly NOT adopted (this note). No code change in this increment: tools/idea_scout.py surfaced and scored the candidate correctly (topic prompt-injection-defense, score 50 — a real, on-topic, high-relevance hit), and the right small artifact for a research/security triage is the recorded verdict + the component-by-component mapping, not an OS rebuild fak’s positioning deliberately refuses.

Next step (the smallest honest follow-on, if pursued): a one-line cross-link in docs/explainers/one-binary-one-surface.md naming AgenticOS as the OS-altitude foil — same four properties (mandatory mediation, auditing, information-flow constraints, least-privilege synthesis), reached without an OS rewrite — so the positioning doc records the contrast it implicitly draws. Filed as its own scoped edit to the explainer lane, not built in this triage increment.