Enforcement before high-risk actions run
Verdict sits between agent intent and execution. It applies policy and approvals before high-risk actions run, then records each decision.
At a glance
From intent to evidence
Every side-effecting tool call is evaluated in the policy gateway before it runs. When policy requires human steps or repairs first, the compliance harness sits between the gateway and execution. If there are no outstanding obligations, execution follows the gateway directly. Each decision is recorded in the evidence plane.
Agent intent
Proposed tool call + arguments
Policy gateway
Synchronous Rego / OPA
If obligations apply
Compliance harness
Consent, disclosure, approval, repairs
Execution
Downstream tool or system
Evidence plane
Signed, versioned decision record
Order reads left to right (or top to bottom on small screens). The harness is a real step only when policy requires it; otherwise the path is gateway, then execution, then evidence. ALLOW, DENY, and REQUIRE_CHANGES are spelled out in the steps below.
Enforcement in the audit view
The same decision that blocks or repairs a tool call is what GRC and audit can pull into their evidence workflow, not a second log stream that drifts from policy.
Illustrative · decision trace (audit-style)
What reviewers see: tool call, synchronous outcome, and policy version before raw execution logs.
| Time (UTC) | Tool | Gateway | Policy |
|---|---|---|---|
| 14:02:01.442 | request_refund | REQUIRE_CHANGES | banking/default@v1.2.0 |
| 14:02:01.509 | request_refund | ALLOW | banking/default@v1.2.0 |
| 14:02:01.610 | post_case_note | ALLOW | banking/default@v1.2.0 |
Production exports include bundle digest, harness events, and signatures in the same evidence model used for second-line review.
From the action map to execution
These three steps are what platform and risk teams validate first in a working session.
- Step 1
Map risky actions
Mark the steps that move money, refunds, credentials, or regulated data. These are the actions reviewers care about most.
- Step 2
Decide before execution
Each action is checked against policy before it runs. Verdict returns ALLOW, DENY, or REQUIRE_CHANGES with clear next steps.
- Step 3
Trigger required human steps
When policy requires it, run consent, disclosure, approval, or secure input before execution.
Evidence, policy lifecycle, and rollout
Once the core path is clear, teams usually focus on audit artifacts, safe policy change, and how you graduate from shadow to enforcement.
- Step 4
Store signed evidence
Every decision is written to a tamper-evident record with policy version and bundle digest.
- Step 5
Update policy safely
Ship new Rego bundles without redeploying agents, then replay policy on saved traces before go-live.
- Step 6
Roll out from shadow to enforce
Start in shadow mode, then enforce as confidence grows across tools and workflows.
Where to go next
Pick the path that matches your buying committee, then come back here when you need the mechanism spelled out.
Validate on real traces and SOPs, not slides
Bring the owners who sign off on risk. We use the live product to show enforcement, harness, and evidence in the same language your stack and SOPs already use.