Ambit Authority
Ambit Authority enforces a deterministic governance decision at the action boundary — before any consequential action commits. Every evaluation is a pure function of policy, delegation, and action context: identical inputs produce identical decisions and byte-identical evidence records.
The execution boundary is the commit point — actions are applied to external state only after successful authorisation.
This is not monitoring. It is not observability. It is enforcement — evaluated and recorded before the action takes effect.
Authority is cross-runtime by default. Enterprises run multiple agent runtimes, model providers, and toolchains; governance tied to a single vendor or a single runtime produces inconsistent decisions and inconsistent evidence.
Decision Outcomes
Every evaluation produces one of three outcomes:
Decision precedence is strict: DENY overrides ESCALATE, ESCALATE overrides ALLOW. Governance is conservative by default.
Escalation is proportional friction — reserved for high-impact or ambiguous actions. The goal is not to block autonomy; it is to make delegation defensible without creating an approval queue that grows without bound.
How Decisions Are Made
Authorisation is a deterministic function of policy, delegation, and evaluation context. Every decision is evaluated against two inputs: organisational policy and delegated authority.
An autonomous system requests to execute an action (send message, write data, transfer funds, modify infrastructure).
Authority checks: is there a valid delegation? Does policy permit this action? Both must be satisfied. A valid delegation does not override policy. A permissive policy does not substitute for delegation.
Authority produces one outcome: ALLOW (action proceeds), DENY (action blocked), or ESCALATE (human approval required). Decision precedence is strict: DENY overrides ESCALATE, ESCALATE overrides ALLOW.
Before the action executes, an evidence record is committed to the append-only decision ledger: what was requested, by whom, under which policy, with what outcome, and why.
Enforcement Architecture
Authority's enforcement guarantees are structural, not behavioural. They follow from where Authority sits in the execution path and how it integrates with downstream systems — not from runtime configuration or application-level conventions. Four properties define the architecture.
Consequence-Path Placement
Authority sits on the consequence path — the execution path between intent and side effect. The runtime does not choose whether to call Authority; the execution path is constructed so that it passes through it. Bypass requires modifying infrastructure configuration, not application code — an auditable operational change.
The Choke-Point Guarantee
Authority is not an interceptor that should be called. It is a choke point that must be called — because the path to consequence does not exist without it. In consequence-side deployment, the downstream system (database, API, service) cannot be reached without passing through Authority. The alternative is not "skip governance" — it is "change the infrastructure."
Evidence Gaps as Governance Failure
Every governed action produces an evidence record. If an action executes outside Authority: no decision exists, no evidence record exists, no hash chain entry exists. A state change without a corresponding decision is an observable governance failure. Bypass produces absence, and absence is detectable. Observatory performs independent completeness verification against the decision ledger.
What Authority Does Not Guarantee
Authority does not claim: prevention under full host compromise; control over systems outside the configured boundary; correctness of model reasoning; protection against denial of service (it fails closed — unavailability produces DENY, not bypass). It governs execution authority, not intent. Full threat model is in Technical Foundations.
In practice, this means Authority sits between the agent and the downstream system. The agent submits intent; Authority evaluates policy and delegation, renders a decision, and commits the evidence record before the action reaches the tool or API. There is no direct path.
Decision Evidence Record Example
The example below shows the fields captured for a single decision, including policy hash, delegation state, evaluation timing, and an integrity signature. Values are synthetic and illustrative. Operational evidence records also include additional contract-reference metadata that binds each decision to the exact governance contract in effect at decision time.
- action
- data.provision
- action_hash
- sha256:e3b0c44298fc1c14…
- principal
- ops-agent-03
- target
- staging-db-07
- policy
- org/platform/data-provision-v2
- policy_hash
- sha256:a1b2c3d4e5f67890…
- delegation_id
- del-8k3m-9n2p
- delegation_valid
- 2026-01-10T00:00Z → 2026-02-10T00:00Z
- delegation_scope
- data.provision — staging only, no production sources
- decision
- ALLOW
- basis
- Policy match: data.provision permitted under org/platform/data-provision-v2. Delegation valid and active. Target within staging scope.
Evidence Records are designed output, not a logging byproduct. Each record is bound to the versioned governance contract active at decision time — eliminating post-hoc reinterpretation and policy drift. Each evidence record is signed with an HMAC-SHA256 integrity signature that makes tampering detectable. The decision ledger is append-only and tamper-evident, and is structured to survive incident review and regulatory inquiry. Over time, it becomes the system of record for autonomous authority inside the organisation.
Deterministic Authorization Evaluation
Identical inputs produce identical decisions and byte-identical receipts. This is what makes governance verifiable — not an assertion, but a replayable property.
Safe Read — Agent reads customer data — read actions require no delegation and resolve through the default allow policy rule.
decision = evaluate(actor, action, target, delegation, approvals, policy_hash, contract_hash) - actor
- agent_support_1
- action
- customer.read
- target
- customer/cust_001
- matched_rule
- default_allow
- request_fingerprint
- 8f3123837e38…a4da08bf6d86
- record_hash
- b314adec9883…23b917620cfd
- prev_hash
- 000000000000…000000000000
a7e3f19b204c…a1b3c5d7e9f0 a7e3f19b204c…a1b3c5d7e9f0 Missing Delegation — Agent attempts a privileged action without presenting a delegation token — denied at the delegation rule.
decision = evaluate(actor, action, target, delegation, approvals, policy_hash, contract_hash) - actor
- agent_support_2
- action
- refund.issue
- target
- order/ord_1001
- matched_rule
- delegation_required — missing_delegation
- request_fingerprint
- 79b24be40154…71b604c9cc09
- record_hash
- f217c28f898c…878613e75a17
- prev_hash
- f8197c53b3dd…2e4692331ea4
c2d4e6f8a0b1…c7d9e1f2a4b6 c2d4e6f8a0b1…c7d9e1f2a4b6 Approval Required — Destructive action with valid delegation but no approval token — escalated to require human approval.
decision = evaluate(actor, action, target, delegation, approvals, policy_hash, contract_hash) - actor
- agent_ops_1
- action
- customer.delete
- target
- customer/cust_002
- matched_rule
- destructive_needs_approval — approval_required
- request_fingerprint
- dc7b7852eaa0…e0e0b0c9322b
- record_hash
- d38eecef8e6a…63f54ff402040
- prev_hash
- a4e60ea8d488…c4eab7b34cf8
Replay Blocked — Same approval token presented on a second request — denied by the single-use cryptographic replay guard.
decision = evaluate(actor, action, target, delegation, approvals, policy_hash, contract_hash) - actor
- agent_ops_1
- action
- customer.delete
- target
- customer/cust_002
- matched_rule
- approval_replay — approval_jti_reused
- request_fingerprint
- dc7b7852eaa0…e0e0b0c9322b
- record_hash
- fc225176f65f…e8668c1b2d69
- prev_hash
- 58cb912d4561…98bcc00d4abe
Pre-computed from a verified Ambit Authority evaluation run. Receipts are byte-identical under replay.
Enforcement Placement
Authority operates at the action boundary — the enforcement point between autonomous intent and consequential action. It integrates with agent runtimes at the point where execution produces side effects, deploying as an SDK wrapper, tool boundary, or local enforcement service within the customer environment.
Gateways move requests. Authority decides whether the underlying action is authorised under a delegation and policy, and records why. If you already have a gateway, Authority can integrate with it — but it is a decision layer, not a traffic layer.
Authority enforces governance at six enforcement planes — surfaces where autonomous action produces consequences:
Execution Layer
Access Control
Boundary Control
Control Surfaces (Non-Authoritative)
The enforcement point varies by integration. The invariant does not. Different architectures place the valve in different locations; the primitive stays the same — decide before execution, produce evidence.
Authority occupies a narrow position in the stack. What it excludes defines it as much as what it includes.
Why Existing Tools Are Not Enough
Enterprises already deploy identity management, logging, guardrails, and governance frameworks. Each addresses a legitimate concern. None of them governs the action boundary.
Each of these tools addresses a legitimate concern. None of them answers the question that autonomous systems create: was this specific action, at this specific moment, authorised under a specific policy by a specific delegation of authority?
Technical Characteristics
What's Implemented
Ambit in the Agent Runtime Stack
The AI stack is converging around distinct layers: agents that reason and plan, runtimes that execute and orchestrate, data systems that persist state, and infrastructure that governs, secures, and observes.
Ambit operates at the governance layer. It does not execute workflows, orchestrate tool calls, manage agent memory, or scale compute. Those are runtime responsibilities.
Authority integrates with agent runtimes at the action boundary — the point where a runtime is about to produce a side effect in a downstream system. The runtime handles execution. Authority handles permission. The decision is rendered and recorded before the side effect occurs.
This separation is architectural, not incidental. Runtimes that embed governance produce vendor-coupled decisions and leave no independent evidence trail. A governance layer that is independent of the runtime produces consistent decisions and portable evidence — regardless of which runtime executes the action.
Runtimes execute. Authority governs. Observatory explains.
Authority decides. Observatory explains.
Observatory deep-dive