• conforms_to::[[Conviction Form Contract]]
• in_practice_domain::[[eOS Continuum]]
• authored_by::[[Christopher Allen]]
• has_lifecycle::[[Seed Stage]]↗
• has_curation::[[Working Draft]]↗

Capability Boundaries Are Runtime-Enforced, Not Policy-Checked

The runtime platform enforces capability boundaries at the runtime level, not at the application policy layer. Each agent runs as a privileged identity the runtime checks on every state read, mutation, or invocation. An agent attempting an action outside its capability does not receive a permission error to handle in user code -- the operation rolls back as if it never ran, and there is no half-completed state to clean up.

Why it is held

Capability boundaries that depend on cooperating application code are advisory, not enforced. They work when the code remembers to check; they fail silently when the code does not. In agent infrastructure -- where LLM-driven actors take novel actions, where prompt injection can subvert intent, where tool calls can attempt operations their principals never sanctioned -- "did the application remember to check?" is the failure mode that scales worst with agent volume. Runtime enforcement removes the entire class: the platform checks every operation, regardless of whether the application code thought to.

The runtime-enforcement stance composes with atomicity. The atomic primitive ([[Agent Operations Commit Wholly or Roll Back Wholly]]) treats failure mid-operation as rollback to the pre-operation snapshot; the capability primitive treats out-of-capability operations as one such failure class. Rollback IS the enforcement: the runtime does not signal a permission error and continue; it reverts the operation as if it never ran. Weakening capability separation to "permission error returned to caller" would also weaken atomicity, because partial state reached before the permission check would persist. The two primitives reinforce each other; they are best held together.

The reference runtime provides this via a call-chain introspection mechanism that lets kernel-tier code determine which tier called it. The foundation layer's kernel and system tier macros gate access to privileged operations; a file-access daemon mediates file-level permissions. These mechanisms are part of the foundation layer the MVA adopts, not a policy layer added on top. Capability separation is a runtime primitive in the platform's roots, and it operates with the same all-or-nothing semantics as every other runtime primitive.

Multi-agent settings amplify the value. When agents share state and may attempt mutations on each other's data, the cost of "trust each agent's code to honor capability boundaries" rises with agent count. By the time the system has more agents than any single contributor reads code for, runtime-level enforcement is the only enforcement that operates at the system's scale. Honest scope-of-applicability for the platform (as the anti-pitch Conviction surfaces) acknowledges that this is precisely the workload class where capability separation pays back the platform's other costs.

What it asks

Honoring this Conviction asks the project to defend the runtime-enforcement boundary as the locus of capability checking, not as one check among several application-layer checks.

• MVA tests and demos run within the foundation's tier system, not in flat-permission scaffolding. The hello-world instance and the atomic-operation demonstration operate under the kernel/system/user tier hierarchy that the foundation layer provides. Demos that grant full kernel access "for simplicity" violate the spirit of the primitive even when they don't violate the foundation's macros, because the demo pattern propagates into subsequent demos and into onboarding material.
• Agent identity is a capability set, not just a name. When the downstream agent-identity workstream lands, an agent identity carries the capability tier the runtime evaluates on every operation. Identity that exists only as a label, with capability-checking left to application code, is not what this Conviction commits to.
• HTTP listener request handling runs in a capability tier that scopes mutations. When the HTTP-listener workstream lands, request handlers run under a capability that scopes what the request handler can read and mutate; an HTTP-handler tier escapes neither the atomic envelope nor the capability boundary just because the request originated outside the runtime.
• Decisions introducing privilege-escalation paths must surface the cost. A Decision adding "for development convenience, agent X gets full kernel access in dev mode" or "let request handlers escalate to root tier when serving admin endpoints" must name the platform-fit cost it imposes on this Conviction and weigh it explicitly. Don't trade enforcement for convenience without surfacing the trade.
• Communication distinguishes runtime-enforced from policy-checked. When the project's capability-separation claim is communicated to potential adopters, the distinction between rollback-on-violation (runtime-enforced) and permission-error-returned-to-caller (policy-checked) is the load-bearing detail. The two are sometimes conflated in agent-infrastructure marketing copy that uses "capability separation" for either pattern.

Drift recognition

The Conviction has weakened when the project's outputs treat capability checks as the application's responsibility rather than as the runtime's guarantee.

• Agent code containing "if this fails because of permissions, then ..." branches. The platform's capability primitive treats out-of-capability operations as rollback events, not as recoverable errors. If application code is handling permission errors mid-operation, either the platform's enforcement is being worked around or the platform's primitive has been weakened to error-on-violation. The branch itself is the drift evidence.
• Trusted-code paths or skip-capability-check modes added without explicit cost surfacing. A trusted-code path is itself a capability tier; if a Decision introduces one without naming it as a tier and without surfacing the cost it imposes on this Conviction, the project has drifted. The pattern compounds: once one trusted path exists, subsequent features lean on it for convenience, and the runtime-enforcement boundary erodes one feature at a time.
• "Most agents are well-behaved so we can rely on application-layer checks for the others" framings. The Conviction's stance is that capability boundaries are runtime-enforced regardless of agent behavior, not that runtime enforcement is for the misbehaving agents only. When documentation, design docs, or external communication frame runtime enforcement as a defense-in-depth layer rather than as the layer, the stance has weakened.
• Demo code granting full kernel access for simplicity. Even when no real harm follows in a single demo, the convenience pattern propagates to subsequent demos and into onboarding material. Future demos copy the prior demo's privilege grant; onboarding material shows the capability boundary as something to bypass rather than as the platform's central guarantee. The Conviction asks for the boundary to stay sharp in artifacts that get copied.
• Cumulative drift across multiple sessions. If three or four consecutive sessions add features that operate at the kernel tier without the workstream surfacing the privilege cost, the project has stopped holding the Conviction at runtime even though the Conviction node still exists in the graph. The drift is cultural rather than pointwise -- no single session breaks the Conviction; the pattern across sessions does.

Sources

• The project's agent-runtime value-proposition draft, Section 3 ("What runtime-level primitives look like"), Draft v2 dated 2026-04-25. Carries the capability-separation primitive's articulation: "Each agent runs as a privileged identity in the runtime. The runtime enforces what each identity can read, modify, or invoke. An agent acting outside its capabilities does not get a permission error -- its operation rolls back. Capability boundaries are runtime-enforced, not policy-checked." This Conviction's stance opening paraphrases the upstream paragraph; the runtime-enforced-vs-policy-checked distinction is preserved verbatim because it is the load-bearing detail. Cited by path; not authored as a Reference node per the URL-resolvability principle in the Reference Form Contract.

• The Cloud Server Reference's Mapping section. The eight-primitives table identifies the runtime's call-chain introspection mechanism as the runtime mechanism, the foundation's kernel/system tier macros plus the file-access daemon as the foundation-layer mediation, and notes "Provided; no gaps" for capability separation -- the cleanest implementation grounding among the eight primitives. The Reference is the graph's authoritative anchor for what the foundation provides for this primitive.

Relations

• conforms_to::[[Conviction Form Contract]]

  • Conviction-form node in the eOS-DeepContext graph. Exercises the Contract's Stance plus Why It Is Held plus What It Asks plus Drift Recognition body shape and the prohibitions on has_commitment::, decided_on::, and has_epistemic_status:: in the identity block. The filename uses the held-stance comma form ("X is Y, Not Z") matching the Contract's recommended shapes.

• in_practice_domain::[[eOS Continuum]]

  • The capability-separation primitive is one of eight runtime primitives the eOS-Harness MVA is responsible for grounding in the graph.

• informed_by::[[Cloud Server (Croes, 2012, rev. 2026)]]

  • The Reference's eight-primitives table provides the graph's authoritative framing for what the foundation layer provides for capability separation: the runtime's call-chain introspection mechanism, the foundation's kernel/system tier macros and file-access daemon as the mediation, "Provided; no gaps" status for the MVA. The Reference grounds the implementation-level claims this Conviction's What It Asks section makes about MVA tests, agent identity, and HTTP listener tiering.

• informs_downstream::[[eOS-Harness Minimum Viable Architecture]]

  • The hello-world instance phase and the atomic-operation demonstration phase operate under the foundation's tier hierarchy; both phases inherit this Conviction's stance that the runtime enforces capability boundaries. Future workstreams (agent identity, HTTP listener) carry the Conviction's asks forward as concrete capability-tier definitions.

• composes_with::[[Agent Operations Commit Wholly or Roll Back Wholly]]

  • The capability primitive and the atomic primitive reinforce each other: the runtime treats out-of-capability operations as rollback events, which means the rollback IS the capability enforcement, not an additional concern layered on top. Weakening capability separation to "permission error returned to caller" would also weaken atomicity (partial state reached before the permission check would persist). The composes_with edge marks this load-bearing coupling so future Decisions that touch one primitive surface the cost they impose on the other.

• grounded_in::[[Agent Runtimes Require Native Primitives, Not External Glue]]

  • The meta-Conviction this primitive is one instance of: what is normally a pattern (per-application permission checking, rebuilt with bugs) becomes a primitive in the runtime that every line of agent code can rely on; external identity-middleware patterns (service tokens, JWT-with-scopes, API gateway permission checks) cannot deliver runtime-enforced capability boundaries at the platform level.

• grounded_in::[[Runtime State Is Persistent by Default, Not by Application Discipline]]

  • Capability separation matters because the bounded namespace it protects persists: capability tiers persist with their identities across restart as part of the same state graph, so identity associations do not have to be re-derived from external sources at boot. Without orthogonal persistence, capability separation would be a per-process concern re-established from scratch on every restart rather than a runtime-scope guarantee.