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

Agent Code Containment Stacks Five Axes, Not One

Code that agents run on the eOS runtime platform -- their skills, their decision logic, their tool implementations -- sits inside five independent containment mechanisms that each carry a different bound: language constraint (the DSL cannot express dangerous operations), location constraint (agent code lives only in agent-owned objects, never in privileged runtime layers), invocation constraint (agent code is only entered through the event system, not by direct calls from arbitrary code), capability separation (what agent code can reach in the runtime is mediated by the privilege layer), and atomic rollback (any error in agent code reverts the entire operation). To break out, agent code would have to defeat all five mechanisms simultaneously; no single attack surface offers that, which is why the stack is substantially stronger than any single contemporary platform provides for user-supplied code in a multi-tenant runtime.

Why It Is Held

Each of the five axes is independently comparable to what a serious sandbox offers, and each addresses a different failure mode. The language constraint prevents agent code from expressing operations the DSL was not designed to express -- no raw memory access, no escape to the host language, no system call surface. The location constraint prevents agent code from running in privileged runtime layers; the kernel and system tiers are inaccessible to user-tier code regardless of what the language permits. The invocation constraint prevents agent code from being entered by arbitrary callers; only the event system can dispatch into agent objects, which means an attacker who has not subscribed to events cannot reach the code. The capability separation primitive ([[Capability Boundaries Are Runtime-Enforced, Not Policy-Checked]]) bounds what agent code can reach when it does run -- privileged objects, kernel-tier files, and resource-quota mutations are mediated by the privilege layer, not by trust in the agent. The atomic rollback primitive ([[Agent Operations Commit Wholly or Roll Back Wholly]]) ensures that even if agent code reaches a state mutation, an error in the operation reverts the entire operation; no partially-applied state changes survive, no manual cleanup is required.

The stacking is what makes the architecture distinctive. Single-axis sandboxes are common -- a process boundary, a language sandbox, a permission system -- but each protects against one class of failure and assumes the other axes are not under attack. Stacked containment changes the cost calculus for an attacker: defeating language constraint puts them in a location they cannot run from; defeating location puts them in front of an invocation constraint that prevents direct entry; defeating invocation puts them inside a capability layer that bounds what they can reach; defeating capability still leaves them inside an atomic envelope that rolls back any partial state. The five mechanisms are independent -- breaking one does not weaken another -- so an attack must succeed against all five rather than against the weakest.

The comparative-platform claim is load-bearing for this Conviction's stance. WebAssembly with WASI offers a process-like sandbox and capability separation -- two of the five. Lua embedded in game engines offers a sandbox (language constraint) -- one of the five. Erlang offers lightweight processes (location-like) and supervision-restart (recovery rather than rollback) -- a different two of the five. None of the contemporary platforms widely deployed for user-supplied code in multi-tenant runtimes stacks all five. The five-axis architecture is structurally distinctive, not stylistically preferred. This is the safety story for LLM-generated code specifically: LLMs make mistakes, and the runtime must contain the mistakes rather than relying on the LLM to be careful or on the developer to manually validate every generated artifact.

This Conviction is held because the safety story for agent code -- including LLM-generated agent code -- depends on independence of the containment mechanisms. A safety architecture that collapses two axes into one (e.g., a runtime that uses the same enforcement layer for capability and invocation) becomes single-axis under attack on that shared mechanism. The five-axis claim asks the project to defend the independence of each mechanism; weakening or merging them does not just reduce the count, it surrenders the structural property that makes the stack stronger than the sum of its parts.

What It Asks

Honoring this Conviction asks the project to defend each of the five axes as an independent layer rather than as a stylistic preference about safety architecture.

• Architectural Decisions adding agent-code paths must surface which axes they touch and which they preserve. A Decision that introduces a new path for agent code to enter the runtime (a new event type, a new direct-call interface, a new privileged operation accessible to agent tier) must name explicitly which of the five axes the path engages and whether the path adds any new attack surface. The default disposition is that all five axes apply to all agent-code paths; trading any axis for a particular path requires the cost (a reduction in containment depth) to be named.
• Capability tier assignment for agent objects is a load-bearing Decision, not a default. Agent code's capability tier (which capability tier it loads into; what files and objects it can read and mutate) is the parameter that determines what the capability axis bounds the code to. Assigning agent code to a higher tier than the agent's user-facing role requires erodes that bound. Workstreams that introduce new agent objects must specify the tier at design time, not default to whichever tier the demo tooling happens to run at.
• The platform's demonstration sequence exercises the language, location, capability, and atomicity axes directly, with invocation-constraint validation following as the event-dispatch primitive matures. A demonstration path that exercises only these four axes in their happy paths has validated four of the five; the invocation axis requires a deliberate try-to-call-from-outside test once the event-dispatch surface lands.
• Documentation distinguishes "sandbox" from "five-axis containment" in load-bearing communication. When the project's safety architecture is communicated to potential adopters, the comparative-platform table is the load-bearing detail. Soft-pedaling the distinction -- describing the platform as "running agent code in a sandbox" or "providing standard isolation" -- conflates the five-axis stack with single-axis or two-axis platforms whose isolation surface is structurally different. The held framing is more specific: five independent axes, stacked, comparable to no single contemporary platform.
• Adversarial agent code is the threat model. The Conviction's stance is held against an adversarial threat model -- agent code that may have been generated by an LLM that hallucinated unsafe operations, or that may have been shaped by an attacker through prompt injection, or that may simply have an off-by-one error in a security-relevant path. The five axes contain the consequences of all three failure modes uniformly, because each axis bounds a structural property rather than relying on the agent code's good behavior. Workstreams designing agent-code paths must reason about adversarial inputs, not just well-intentioned agents.

Drift Recognition

The Conviction has weakened when the project's outputs treat agent-code containment as a single-axis or two-axis property, or when proposed paths erode the independence of the axes.

• Workstreams that propose agent-code paths bypassing axes without surfacing the cost. A workstream that adds a direct-call interface from external services into agent objects (bypassing the invocation constraint), or that loads agent code at a privileged tier without naming the elevation (eroding capability separation), or that introduces a non-atomic state-mutation path for agents (eroding atomic rollback), has stopped honoring the Conviction in practice. The proposals are not forbidden; the bypass cost surfacing is required.
• "Sandbox" framings replacing "five-axis containment" framings. Documentation, onboarding, or comparative-positioning material that describes the platform's safety architecture as "a sandbox" or "process isolation" or "standard multi-tenant isolation" has shifted the held position. The held position is more specific: five independent axes, stacked, each addressing a different failure mode. The naming distinction is load-bearing for the comparative-platform claim.
• Two axes collapsed into a shared enforcement mechanism. A Decision that merges capability separation with invocation constraint by using the same machinery for both, or that fuses language constraint with location constraint by tying the DSL's expressiveness to where the code lives, reduces the count of independent axes. The Conviction's structural property depends on independence -- five axes that all rely on the same enforcement layer is not five axes; it is one axis with five interfaces.
• Demonstrations that exercise only one or two axes and claim "five-axis containment validated". Validation of the architecture requires exercising each axis with a deliberate-failure case for that axis, not exercising one axis well and claiming the others are present. Until each axis has a deliberate-failure validation, the architectural claim is partially validated; communication should reflect that.
• Cumulative cross-session drift. No single session breaks this Conviction; the pattern across sessions does. If several consecutive rounds of work quietly merge axes, bypass individual containment mechanisms, or describe the architecture as a single-axis sandbox without surfacing the cost, the project has drifted from holding the Conviction even though no individual change was the breaking point.

Relations

• conforms_to::[[Conviction Form Contract]]

  • Exercises the Contract's Stance plus Why It Is Held plus What It Asks plus Drift Recognition body shape. The filename uses declarative SVO comma-form preserving "five" as the load-bearing count and "not one" as the contrast against single-mechanism sandboxes.

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

  • The five-axis containment claim depends on the platform carrying each axis as a primitive rather than as an external integration: language constraint is in the DSL, location constraint is in the runtime tier hierarchy, invocation constraint is in the event-dispatch primitive, capability separation and atomic rollback are runtime-enforced. External-infrastructure alternatives cannot deliver independence of the axes at the platform level because the integration glue between them becomes a shared enforcement layer that collapses the count. Currently a ghost link; the diagnostic Conviction has not yet migrated.

• composes_with::[[Capability Boundaries Are Runtime-Enforced, Not Policy-Checked]]

  • The capability axis of this Conviction's five-axis stack IS the capability-separation primitive. The composes_with edge marks the load-bearing dependence: the five-axis stack is structurally weaker if that axis is policy-checked rather than runtime-enforced, because the independence of the capability axis from the language, location, and invocation axes depends on its enforcement being at a different layer. Weakening capability separation would weaken this Conviction's structural-property claim.

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

  • The atomic-rollback axis of this Conviction's five-axis stack IS the atomicity primitive. The composes_with edge marks the load-bearing dependence: the five-axis stack is structurally weaker if that axis is best-effort or recovery-based rather than atomic-rollback-based, because partial state surviving an error gives an attacker leverage that atomic rollback denies. Weakening atomicity would weaken this Conviction's structural-property claim.

• contrasts_with::[[eOS-Harness Is the Wrong Runtime Platform Without Platform-Pain]]

  • The pair sits at adjacent positions in scope-of-applicability framing. This Conviction names the safety architecture that justifies adoption when agent code is adversarially-shaped or LLM-generated -- the five-axis stack contains mistakes the agent makes. The anti-pitch Conviction names workloads where the safety architecture offers no value because the workload does not run adversarially-shaped code (e.g., trusted in-house code, single-tenant deployments). Together they bound the safety-fit space. Currently a ghost link; the anti-pitch Conviction has not yet migrated.