Veridom ACE · Agentic AI Control Environment

You can roll back a database. You cannot unsend the money.

Every agent you put into production eventually proposes an action that leaves the system — a payment, a filing, a discharge, a disconnection. The moment it executes, it is real. ACE decides whether it was allowed, before it runs.

evaluating…
Blocked actions leave proof too

01 · The control loop

What happens to one agent action, the moment it happens.

A dashboard shows activity. A monitor shows performance. ACE shows whether the boundary held — for one specific action, at the moment it was attempted.

01

Agent proposes an action

Issue a refund, approve a facility, release a record.

02

ACE checks the boundary

Evaluated against the policy in force, deterministically.

03

Authority is verified

Is an accountable actor bound — with authority in range?

04

Execution is permitted or blocked

If blocked, the action does not run. At all.

05

Record sealed & verifiable

Proof exists before anyone asks for it.

That is the product: not the block, the proof of the block.

02 · The engine

One engine. No industry required.

ACE has no concept of banking or medicine — only of an action, a boundary, an accountable actor, and a permission. You are looking at the engine with no domain loaded. Change the action, then load a sector and watch the same rules resolve against a different policy file.

An agent proposes a facility approval.

Autonomous to £500,000. Above that, a bound Senior Credit Officer is required.

Exposurecredit_decision_support
£650,000
autonomous
escalate
03,000,000
credit_decision_support◈ Sealed
action
boundary
routing_state
authority
execution
action_executed
reason_code
policy
trace_hash

Did not change

The engine. Three axes, evaluation order, hash chain, verification — identical in all five.

Did not change

The guarantee. Same inputs, same policy, same outcome. Deterministic, every time.

Did change

One JSON file. Thresholds, hard-block conditions, and which roles count as authority.

That file is the only part of ACE that knows what industry you are in.

03 · The on-ramp

Put a boundary around any agent action with one decorator.

No re-architecture, no SDK swallowing your stack. You wrap the function that performs the action — ACE decides whether that function is permitted to run at all.

@gateway.controlled_action(
    action_type="issue_refund",
    workflow="customer_resolution"
)
def issue_refund(context):
    # your existing function — unchanged
    return payments.refund(context)

If BLOCKED

Your function never runs. ACE returns a decision envelope explaining which boundary applied and why authority failed.

If PERMITTED

Your function runs exactly as before, and its output is folded into the sealed record.

Either way

An Audit Trace is written and hash-chained to the record before it. Refusals are sealed too.

Verify from the shell

VERIFIED or FAILED, exit code 0 or 1. No vendor round-trip required.

Python, standard library only, zero external dependencies. The boundary lives in a JSON policy file you own and version alongside your code.

04 · Why your existing stack doesn't cover this

Your tools can tell you what the agent did. None of them decide what it may do.

Tracing, evals, guardrails and dashboards all watch. Watching is useful — and none of it sits in the execution path.

Observe

  • whathappened
  • whenafter
  • outputa report
  • on breachan alert

Produces an excellent record of the thing you did not prevent.

Permit

  • whatis allowed
  • whenbefore
  • outputa decision
  • on breachno execution

ACE is a gate, not a lens.

Routing state

AUTONOMOUS · ASSISTED · ESCALATED

Who was supposed to be involved in this action.

Authority binding

BOUND · AUTHORITY_UNBOUND · EXEMPT

Whether an accountable human actually attached. A human can be present without being authorised.

Execution permission

PERMITTED · BLOCKED

What was allowed to happen. Three separate facts, never collapsed into one.

05 · The proof record

Don't trust the record. Verify it.

Search by decision ID, retrieve the sealed record, verify its integrity, export it. No access to any internal system required — not yours, not ours.

ACE-2026-0806-a3f1c9Sealed ✓
actionissue_refund
amount£4,200
boundaryautonomous ≤ £1,000
routing_stateASSISTED
authorityAUTHORITY_UNBOUND
executionBLOCKED
action_executedfalse
policyRESOLUTION v2 · 9f2c…41aa
previous_hashsha256:1a2858c1…0654ff75
trace_hashcomputing…

Recompute the trace hash

SHA-256 over the canonical record, recomputed from the record itself.

Recompute the chain link

Each trace incorporates the previous trace's hash. History cannot be rewritten quietly.

Match the policy fingerprint

The exact policy in force is hashed into the record, so the rule cannot be edited after the fact.

Run verification to check this record's integrity.

This check runs live in your browser — the same SHA-256 recomputation any third party performs against a sealed record. Every ACE record is tamper-evident: alter one field and the hash no longer matches.

The boundary

Which rule applied to this action.

The authority

Who was accountable — or that nobody was bound.

Execution permission

Permitted or blocked.

Execution status

Whether the action actually ran.

Policy fingerprint

The exact policy in force, hashed.

Verification result

Integrity, confirmable by anyone.

Produced at the moment of decision. Verifiable years later.

06 · What ACE is

Three surfaces. Policy in, enforcement at runtime, evidence out.

01Configuration

Boundary Studio

Risk, compliance and domain teams define autonomous limits, assisted thresholds, escalation conditions, hard-block rules and accountable-authority roles — turning policy intent into a machine-readable file the Gateway enforces.

02Runtime enforcement

ACE Gateway

Intercepts proposed agent actions before execution, evaluates them against the active policy, and returns a control result. If the action exceeds the boundary and no valid accountable actor is bound, ACE blocks execution — and still seals the record.

03Audit & query

Evidence Console

Search by decision ID, retrieve the sealed record, verify integrity, export as JSON or Markdown. It answers one question: can this organisation prove what happened for one specific AI-taken action?

Five Watchtowers turn autonomy boundaries into executable control logic

Runtime gates
WT-ACE-01

Autonomy Boundary Guardian

Routes actions that exceed approved autonomy toward more control.

WT-ACE-02

Authority Binding Verifier

Blocks execution when assisted or escalated actions lack valid accountable authority.

WT-ACE-03

Prohibited Condition Hard Block

Stops actions where a domain's non-negotiable condition is unresolved — an unresolved sanctions flag, an incomplete clinical review, an unverified citation, a vulnerable occupant.

WT-ACE-04

Evidence Completeness Guard

Prevents agents acting on missing, stale, or incomplete evidence.

WT-ACE-05

Boundary Proof-Point Export

Produces the decision-boundary proof record for audit, risk, or board review.

Watchtowers may only move toward more control — never less.

07 · The ask

Test one action boundary.

One workflow, one boundary, one authority model, one evidence readout — in four weeks.

One workflowOne autonomy boundaryOne authority modelOne evidence readout

One condition: you can name the action. A refund an agent may propose but never issue. A record it must not delete alone. A message it may draft but not send.

OMP™

ACE is built on the Operating Model Protocol — Veridom's open decision-time evidence architecture, published as IETF Internet-Drafts and archived with a permanent DOI.

Read the protocol