Confidence: medium. Evidence: architectures growing; legal unsettled. Last substantive change: 2026-07.
This subsystem owns accountability: how policy becomes something the system actually enforces, and how any outcome can be reconstructed after the fact.
The conclusion
Policy must compile to enforcement points, and every outcome should be reconstructable. For each accepted outcome the factory should be able to say who or what initiated it, which model, harness, and policies acted, what evidence admitted it, and who owns the consequences. Governance by prompt is not governance; governance has to be enforced at the boundary.
How the thinking got here
Terms of service and human approvals gave way to audit logs, then to governance-by-architecture with kernel and runtime enforcement, then to evidence-bearing execution episodes. As agents gained the ability to initiate work, the field learned that agency and accountability decouple: an agent can act, but a human still owns the result, so the result must be traceable.
Credible alternatives, and when each is right
| Approach | Right when |
|---|---|
| Process and prompt policy | low-stakes, high-trust settings |
| Human approval | irreversible or high-consequence actions |
| Policy-as-code | policy must be testable and versioned |
| Kernel-enforced capabilities | policy must hold regardless of the agent |
| Regulator or auditor review | external assurance is required |
Where it fails and what we still don't know
The rationale is strong and the architectures are growing, but legal allocation and standards remain unsettled. Open questions include liability, disclosure, contracting, intellectual-property and license compliance, records retention, audit standards, segregation of duties, and cross-border regulation.
What would change our mind
An accepted audit standard and a settled liability model for autonomously produced software would turn governance from an architecture problem into an established practice.