04 - Governance and claim discipline
Governance decides what an untrusted agent workload may do and what evidence supports a claim. The reported host → operator-core VM → logical realms → agent sandboxes structure is an architecture narrative, not proof that realms isolate workloads or recovery succeeded.
Risk tiers
| Tier | Example public description | Required public evidence before stronger claims |
|---|---|---|
| L0 lab | synthetic checks, no real secrets | static checks, fake values, teardown notes |
| L1 bounded read-only | reads approved inputs and returns summaries | auth denial, tool allowlist, default-deny egress, no raw secrets |
| L2 limited action | invokes approved tools with bounded effects | human approval for writes, scoped credentials, audit events, rollback drill |
| L3 owner-facing | affects a real owner workflow | canary packet, SLO comparison, recovery proof, incident loop |
| L4 client-facing | touches external/client data | tenant/data isolation, external-audit-ready evidence, stronger identity |
| L5 regulated/sensitive | high autonomy or regulated data | compliance review, retention policy, dedicated environment |
The public material remains below production-ready claims. Historical scoped observations and fictional acceptance examples must not be treated as current canary results.
Current governance overlay
Policy review and configuration management govern changes to this example hierarchy. The sandbox is the intended execution boundary; grouping labels do not enforce it. Apply the same acceptance checks with other isolation tools or configuration systems. Keep evidence tied to the boundary and version actually tested rather than transferring historical observations to a new deployment.
Tool and data gates
For agents that expose tools, the tool surface is the attack surface:
- tools are an explicit allowlist;
- denied tools should be absent or fail closed;
- unknown tools fail closed;
- policy load failures stop serving rather than falling back to broad permissions;
- tool descriptions and schemas are treated as injection surfaces;
- sensitive writes require human approval and audit evidence.
Secrets and provider boundaries
A complete future provider-boundary receipt would need to demonstrate a successful governed request with credential resolution at the mediating boundary, as well as absence in the sandbox, fail-closed routing, and non-disclosure in logs or artifacts. The historical receipt here only supports placeholder configuration/environment observations and one failed misroute.
Egress and exfiltration
Default-deny egress is a control objective, not a slogan. A public boundary receipt should name the boundary under test and include denied crossing attempts such as:
- direct outbound network attempts;
- raw-socket or bypass attempts where relevant;
- SSRF-style metadata probes;
- lateral movement attempts;
- external DNS attempts;
- filesystem and privilege checks when those are in scope.
Progressive evidence
Use these terms precisely:
| Term | Meaning |
|---|---|
| Architecture narrative | the design is explained; no runtime behavior is proven |
| Static-validated | public repo checks ran locally or in CI |
| Historical boundary observation | reported negative probes at one named boundary, without current-version or current-runtime claims |
| Production-ready | a real workload produced canary, auth, egress, audit, rollback, and SLO evidence |
Public non-claims
The public docs must not imply:
- live deployment topology;
- customer deployment evidence;
- raw private logs or incident details;
- token values or token shapes;
- production readiness from unit creation alone;
- endorsement by upstream projects beyond public credit and links.
Governance is the discipline that keeps the public case study honest: if a boundary was not measured, say it is pending; if a command was not run, say it was not run; if evidence is private, publish only a newly written sanitized summary with fictional values.