Trust boundary
Security
How Zorai secures autonomous work through governance, structured verdicts, approvals, provenance, critique, and containment.
What security means
Zorai security is not a thin approval prompt in front of shell execution. It is a governance and trust architecture around transitions, side effects, provenance, isolation, critique, operator authority, and auditability.
Security is a control plane
Execution substrate
Reports what happened or what is about to happen.
Orchestration plane
Manages runs, stages, lanes, retries, and advancement.
Governance plane
Decides whether advancement is allowed, constrained, deferred, denied, or isolated.
Audit layer
Preserves provenance and operator-visible history for later inspection and trust.
Security starts before execution
Zorai evaluates risk before side effects occur. Policy inputs, sandbox availability, critique preflight, approval requirements, and provenance readiness checks all happen before the system treats a risky action as admissible.
Governance acts on transitions
One of the most important design ideas in Zorai security is that governance applies to transitions, not only to raw commands.
- run admission
- lane admission
- stage advancement
- retry
- blocked-to-resumed
- compensation entry
- final disposition
Risk and blast radius
Risk is structural rather than cosmetic. Zorai considers destructiveness, scope, reversibility, privilege, externality, and concurrency. Blast radius is compositional: lane-local, stage-wide, and run-wide.
Structured verdicts
| Verdict | Meaning |
|---|---|
allow | Proceed normally. |
allow_with_constraints | Proceed only under declared limits. |
require_approval | Operator approval is required. |
defer | Execution cannot proceed yet. |
deny | Execution must not proceed. |
halt_and_isolate | Stop and isolate the work. |
allow_only_with_compensation_plan | Proceed only with explicit mitigation obligations. |
Approvals are bound, not generic
Approvals are expected to bind to real execution conditions: target scope, risk rationale, attached constraints, freshness/expiry, and policy fingerprint. If the target set, privilege posture, command family, or environment facts materially change, prior approval should be considered stale.
Sandboxing, containment, and compensation
Sandboxing is part of governance, not an afterthought. The policy layer can require sandbox use, network restriction, narrowed filesystem scope, serial-only execution, restricted retries, or manual resume. When constraints cannot be honored, Zorai should escalate rather than silently proceed.
The runtime is also designed to express more realistic outcomes than simple success/failure: blocked, contained, compensated, partially compensated, or break-glass execution under elevated scrutiny.
Critique and provenance
Zorai already ships an adversarial self-critique layer with advocate, critic, and arbiter roles. It can challenge risky plans before execution, propose safer rewrites, or require explicit confirmation when risk remains high.
Provenance is also part of admissibility. The system should be able to show who initiated the action, what policy inputs were evaluated, what verdict was returned, what approval authorized it, and what actually ran.
Operator best practices
- Treat approval as scoped and potentially stale, not as blanket permission.
- Inspect destructive mutations, surprising network access, and widened target sets carefully.
- Use goal runners when you want visible approvals, checkpoints, and durable state around risky work.
- Read blocked or escalated states as useful signal, not as noise.
For the deeper approval semantics layer, see Governance.