Sample Audit Report
Exactly what a customer receives from a Runtime Governance Audit, shown as an illustrative redacted example. This is a representative template — a fictional client, not a real engagement.
- Illustrative sample. Fictional client (“Northbank”). Figures are illustrative, not a guarantee. A real report reflects your systems and your defined Ω.
Executive summary
Risk level: Critical. The autonomous treasury-operations agent can reach three catastrophic states from normal operation. The most severe permits funds movement to an unverified destination with no human approval.
Findings: 3 reachable Ω states (1 Critical, 2 High). Existing controls reduce likelihood but leave the forbidden states reachable.
Business impact: single-event reachable exposure modelled at £0.0B+; regulatory exposure under FCA / AML. Illustrative, not a guarantee.
Reachability findings
Ω-01 · unauthorized_transfer (Critical). Trajectory: read_file(payment_queue) → transfer(destination.verified=false). Affected assets: Banking APIs, Payment Systems. Threats: T01, T04.
Ω-02 · limit_breach (High). Trajectory: transfer(amount > £00,000, approver=none). Affected assets: Payment Systems. Threat: T04.
Ω-03 · data_exfiltration (High). Trajectory: read_database(customers) → http_request(external). Affected assets: Customer Records, CRM Data. Threat: T02.
Technical analysis
Why blocked / where risk emerged. Each finding is a trajectory whose reachable set intersects Ω. Ω-01 emerges at the transfer step because the destination is unverified; the existing RBAC and post-hoc monitoring controls do not make the state unreachable — they only observe it after settlement.
Evaluation occurs at the execution boundary, pre-action. Legitimate operations (e.g. an approved vendor payment) route through cleanly; only trajectories that reach Ω are intercepted.
Recommended remediation
1. Define Ω for treasury operations (unverified-destination transfer, unapproved limit breach, customer-data egress).
2. Place Runtime Governance at the agent’s tool-call boundary; enforce pre-execution interception for Ω-bound trajectories.
3. Require verified-destination + approval invariants on all transfer actions.
4. Route customer-data reads through internal sinks only; deny external egress.
Governance outcome
BLOCK — Ω-01, Ω-02, Ω-03 trajectories denied before execution.
PERMIT — approved vendor payments and internal workflows execute unchanged.
ESCALATE — borderline transfers above policy threshold routed for human approval with a full audit record.
What you receive — Runtime Safety Assessment
No ambiguity about what the engagement buys.
If material Ω exposure is identified, the typical next step is a Limited Pilot (£250K–£750K+, 30–60 days) that validates interception on your own traffic, followed by Integration, an Annual Runtime Governance™ License (£75K–£500K+ / yr), and an Advisory Retainer (£35K–£100K+ / mo) that keeps Ω current as models, tools, and regulations change.
Indicative engagement scales only. Final commercial terms are determined following assessment and deployment review. The “+” symbol denotes that figures are not ceilings.