Security & Trust
What a security team needs before anything sits in the execution path: what is evaluated, what is and isn’t stored, how audit works, where it deploys, and the enforcement principles. Items that require commercial or legal sign-off are flagged rather than asserted, so this page can be relied on in review.
Deployment architecture
Governance is a pre-execution checkpoint at the tool-dispatch boundary:
The reference service is a stateless container running the pure-Python engine, so it can run wherever your workloads do. These are the architecturally supported patterns:
Managed HTTPS service (e.g. the public reference deployment). Fastest to stand up for pilots.
Run the container inside your own cloud; trajectories are evaluated within your perimeter.
Runs as a container or sidecar in your data centre for workloads that cannot leave the building.
Service in your VPC, called by agents across environments via the same HTTP contract.
Data handling
What the governance layer evaluates, and what it does not.
The proposed tool calls and their arguments — the trajectory — submitted before execution, to evaluate reachability of Ω.
Model weights, training data, prompts, or model internals. Governance is model-agnostic and external to the model.
Nothing by default. The engine is a pure function; the reference service holds no datastore and persists no evaluations. It returns the verdict and emits structured operational logs (verdict, layer, timing) — not the evaluated payload. Per-evaluation engine logging is off by default (log_all=false).
Audit records are produced by the caller/host that wants them (see Audit logging). In a VPC/self-hosted deployment, evaluated payloads never leave your environment.
Audit logging
Every evaluation yields a structured, attributable record. These are the actual fields the engine and console produce:
verdict (ALLOW/BLOCK/ESCALATE), reason, omega_domain, triggered rule, governance layer, reachability_distance, and a deterministic trajectory_hash.
Each record carries a UTC timestamp; evaluation timing (eval_time_ms) is recorded for performance attribution.
Decisions attribute to the specific rule and enforcement layer that fired — not an opaque score — so each action maps to the control it engaged.
The console exports the audit trail as JSON or TXT and supports copy-to-clipboard. The same structured record is available programmatically from the API response.
Records are deterministic and replayable (the trajectory hash is stable across runs), which is what makes them suitable for a regulator-ready audit file. Try it in the live console.
Retention
Default: none. The reference service does not persist trajectories or verdicts; nothing to retain unless you choose to store the returned records.
You own it. Records are emitted to the caller; you store them in your own log/SIEM under your existing retention policy.
On demand — JSON/TXT from the console, or the structured verdict from each API response. No background export.
Because the default posture stores nothing centrally, deletion is governed by your own log store. A managed form would inherit a documented policy.
Security principles
Pre-execution enforcement. The verdict is computed and returned before any tool runs. A trajectory that would reach a forbidden state Ω is intercepted before execution, not flagged after the fact.
Deny-by-default / fail-closed. The engine permits a trajectory only when it can show ℛ(t) ∩ Ω = ∅; otherwise it blocks. A production gate should treat a governance outage as “do not execute” — the runnable integration examples fail closed on transport error.
The planner remains untrusted. The verdict is a pure function of the proposed trajectory, independent of which model produced it. Swapping or upgrading the planner does not change a verdict, and a compromised or hallucinating planner cannot talk its way past the boundary.
Trajectory-level, not per-call. Governance evaluates the reachable set of the whole proposed plan — including source→sink data flow and multi-agent/joint trajectories — so harm that appears only in the combination of individually-admissible steps is caught.
Performance
Governance adds a bounded pre-execution check per action (not per token), so cost scales with the number and shape of governed actions, not model size. Unlike earlier, these are now measured, not estimated: on the benchmark environment a single-step evaluation runs at sub-millisecond median latency.
See the full table, charts, methodology and downloadable report on Enterprise readiness → Operational performance. Production latency depends on your host CPU, concurrency, and transport — re-run the benchmark harness on target hardware for deployment figures.