Authority, execution and evidence in operational AI systems
Operational AI becomes governable when authority, execution and proof are separate layers. Combining them inside one agent makes permission expansion and self-verification difficult to detect.
- Published
- 1 Aug 2026
- Reading time
- 8 min
- Author
- James L. Britton
The control plane decides what may happen
A reasoning system can propose work, but it should not silently define its own authority. Policy, tenant context, approvals, capability scope and acceptance criteria belong to a control layer outside the execution runtime.
This preserves a clear answer to four questions: who requested the action, what was authorised, which target was in scope and what proof is required for acceptance.
Capabilities are narrower than software availability
Installing a package or exposing a runtime does not grant operational permission. A capability registry defines the bounded action an agent may perform, including its inputs, target, limits and approval state.
Typed host bindings are preferable to raw credentials. The runtime receives the result of an authorised operation rather than inheriting the secret that makes the operation possible.
Use the least complex runtime that completes the work
Deterministic functions remain the default. Durable workflows handle waiting and retries. Lightweight runtimes support files, code and related operations. Full sandboxes are reserved for native binaries, browsers and heavier isolation requirements.
- Direct function
- Durable workflow
- Lightweight agent runtime
- Full sandbox
- Dedicated infrastructure
Execution success is not system correctness
The final layer records inputs, decisions, capability calls, changed resources, approvals, checks and verified outcomes. That record must remain portable across runtime vendors.
The governing principle is simple: the control plane determines what may happen, the capability registry defines how it may happen, the runtime executes it, and the evidence graph proves what happened.