Watch governance decide — one action at a time

Every consequential action an autonomous AI system takes, evaluated before it executes — and sealed into a tamper-evident ledger after. Pick the scenario that matches your stack.

Looking for the full multi-step story? See the end-to-end proof of enforcement →

Allow, deny — and escalate

Ambit renders three decisions, not two. The hardest actions aren’t blocked — they’re escalated to a human, with the approval bound to the exact request.

Demo video coming soon

Full decision model Human-in-the-loop approval

Agent deletes a customer record

For Risk, compliance, and platform owners

Some actions cannot be quietly allowed or denied. An agent proposes to delete a customer record. Without justification it is denied; once justified and judged critical, Authority does not decide alone — it escalates for human approval. That approval is bound to the exact request by cryptographic fingerprint, so it authorises this action and no other. Reuse it, and the replay is denied.

DENY No justification
ESCALATE Critical — human approval required
ALLOW Approval bound to the exact request
DENY Approval reused — replay denied

By enforcement boundary

Each boundary is a point where an autonomous action meets the real world. One named scenario per boundary — insurance where the stakes are regulated, DevOps where engineers have lived the failure.

Demo video coming soon

01 Tool boundary Payments authorisation

Agent issues a customer refund

For Payments and fintech platform owners

An agent proposes a refund. Without a valid delegation it is denied before any money moves; with a scoped, time-bound delegation, the same refund is allowed, executed, and sealed to the ledger. The difference is not the tool — it is whether the authority to act existed first.

DENY No delegation
ALLOW Scoped delegation

Demo video coming soon

02 Data boundary Privacy and purpose limitation

Field-level access to claimant data

For Privacy, data protection, and compliance leads

An agent reads claimant fields to verify identity. Identity fields in scope are allowed; the instant the request reaches for bank-account data, it exceeds the delegation and is denied. Same tool, different fields, different decision — access to a record is not access to every field in it.

ALLOW Identity fields, in scope
DENY Adds bank-account data

Demo video coming soon

03 Memory boundary Session isolation and state integrity

Context bleed across an agent fleet

For Platform teams running multi-agent systems

A fleet of coding agents shares a memory store. Writing within an agent’s own session scope is allowed; reading another agent’s context under the same delegation is denied. One agent’s reasoning cannot be silently contaminated by another’s.

ALLOW Own session scope
DENY Cross-session read

Demo video coming soon

04 Network boundary Egress control and data sovereignty

Claim submission to an external insurer

For Security and data-sovereignty owners

An agent sends a claim to an external API. Authority weighs both destination and payload: an approved partner in scope is allowed; an unknown destination — or a sensitive payload — is denied. Authorising the action is not authorising everything it could carry across the boundary.

ALLOW Approved partner, in scope
DENY Unknown domain or sensitive payload

Demo video coming soon

05 Code-execution boundary Code and supply-chain governance

Coder agent runs generated tests

For Platform, DevTools, and build-security teams

A coding agent generates a script and asks to run it. Sandboxed code with safe imports is allowed; network imports, or a shell outside the permitted language set, are denied before execution. An agent cannot widen its own privileges by writing them into the code it runs.

ALLOW Sandboxed, safe imports
DENY Network imports or shell

Demo video coming soon

06 Runtime boundary Least privilege and blast-radius containment

Deploy agent promotes a release

For Platform, SRE, and infrastructure teams

A deploy agent runs tests and promotes a release within its delegated scope — allowed. Reach outside it — a system path like /etc/passwd, or an undelegated cluster — and the action is denied. Being able to reach a resource is not being authorised to use it: containment is not authorisation.

ALLOW Scoped rollout
DENY Out-of-scope path or cluster

Beyond single actions

A firewall checks one action at a time. These show what only governance can: denying a dangerous sequence, escalating an outsized consequence, and proving every decision after the fact.

Demo video coming soon

Composition Multi-step exfiltration

Read here, send there — denied as a sequence

For Security architects and red teams

Two reads and an external send, each allowed under its own delegation. Ambit denies the composition: a sensitive read then an external send in one session — across HTTP, MCP, and A2A — is a pattern no per-action gate can see. The risk lives in the sequence, not in any single step.

ALLOW Each action on its own
DENY Read-then-external-send, composed

Demo video coming soon

Consequence boundary Irreversible, externally-binding actions

A refund too consequential to auto-approve

For Risk and operations owners

Delegation valid, behaviour normal — and still escalated. When the consequence is critical, irreversible, and externally binding, Ambit escalates for a human before execution. Escalation is not only for missing authority; it is for consequences too large to commit unreviewed.

ALLOW Routine refund
ESCALATE Critical, irreversible, externally binding

Demo video coming soon

Evidence Tamper-evident audit

Replay the decision; break the chain

For Audit, risk, and assurance

Every decision is sealed into a hash-chained ledger. Re-run any record against the same policy and ontology and it reproduces the identical decision — proven, not asserted. Tamper with a record and the chain breaks on verification.

Outside the decision path

Not every governance signal should become an Authority outcome. Model-output signals stay on a separate plane so ALLOW, DENY, and ESCALATE remain the complete decision set.

Demo video coming soon

Model signal plane Financial conduct

Financial disclaimer filtering

For Compliance and conduct teams

This demo is deliberately non-authoritative. It shows output-side signals: required disclaimers, model selection for regulated contexts, and review flags. Authority does not render an enforcement decision here. This is the honesty boundary in Constitution Clause 8: separate planes stay separate.

With Observatory

Authority decides; Observatory learns and measures. The companion plane turns behaviour into policy-usable facts and tells you whether your governance — and your human approvers — actually hold up.

Demo video coming soon

Authority + Observatory Policy-required behavioural baseline

A refund that requires a clean baseline

For Security and risk executives

Policy can require an action to carry a fresh, normal behavioural baseline. Observatory learns the baseline and publishes a provenance-bound fact; Authority enforces the policy over it. An actor with a critical baseline is denied — not because Authority judged its behaviour, but because policy required a fact it could not supply.

ALLOW Fresh normal baseline
DENY Critical baseline — policy unmet

Demo video coming soon

Observatory analytics Approval assurance

Are your humans actually reviewing?

For CISOs and audit leads

Escalation only works if a human truly reviews. Observatory measures it over the evidence ledger — approval latency, rubber-stamp rate, escalation quality — turning “a human approved” into “a human reviewed, in this many seconds, at this rate.”

How every decision ends

Each decision — ALLOW, DENY, or ESCALATE — is sealed into a cryptographically chained, append-only ledger. Tamper any record and the chain breaks. Verification is one command, and the evidence is reconstructable without the originating system. If a decision cannot be replayed to produce an identical result, it is not governance — it is a claim.

Request a trial See how it integrates