Ambit Authority

Ambit Authority makes governance decisions at the action boundary — the point where an autonomous system’s intent becomes a consequential action in a downstream system. Before any action executes, Authority renders an explicit decision: ALLOW, DENY, or ESCALATE to a human approver.

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.

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.

What Authority Is

✓

A Governance Control Plane

Makes decisions at the action boundary where autonomous intent becomes consequential action.

✓

Pre-Execution Enforcement

Renders explicit decisions (ALLOW, DENY, or ESCALATE) before any action takes effect.

✓

Cross-Runtime by Default

Works across agent runtimes, model providers, and toolchains. Governance is not coupled to any single vendor's execution model.

✓

Policy-Driven and Delegation-Bound

Decisions are based on explicit policy and delegated authority, not learned behaviour.

✓

Evidence-Producing by Design

Creates append-only decision evidence records for audit and incident review.

✓

Structural Enforcement

Operates at the enforcement boundary; bypassing governance requires bypassing the boundary itself.

What Authority Is Not

✗

Not an Agent Runtime or Orchestration Layer

It does not execute workflows, manage agent state, or scale compute. Agent runtimes handle execution and orchestration; Authority governs the boundary where their actions take effect.

✗

Not a Gateway or Traffic Layer

Gateways move requests; Authority decides whether the underlying action is authorised under a delegation and policy, and records why.

✗

Not Model-Layer Guardrails

It operates at the action boundary, not the reasoning layer. Model guardrails constrain what an AI can propose; Authority governs what actions are authorised to execute.

✗

Not IAM or Observability

It is not a replacement for identity and access management or an observability platform. IAM controls resource access; Authority governs delegated authority for actions. Observability records what happened; Authority records governance decisions before execution.

✗

Not Self-Learning

It does not learn, adapt, or optimise its own behaviour. Its decisions are policy-driven and delegation-bound. Changes to governance require explicit human action.

Decision Outcomes

Every evaluation produces one of three outcomes:

ALLOW

▎

The action proceeds. The decision and its basis are recorded.

DENY

▎

The action is blocked. The decision and its basis are recorded.

ESCALATE

▎

The action is held pending human approval. The approver receives full context: what is being requested, by whom, under which policy, and what the expected downstream action will be.

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

Every decision is evaluated against two inputs: organisational policy and delegated authority.

Request Arrives

An autonomous system requests to execute an action (send message, write data, transfer funds, modify infrastructure).

Evaluate Policy + Delegation

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.

Render Decision

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.

Record Evidence Record

Before the action executes, a evidence record is committed to the append-only decision ledger: what was requested, by whom, under which policy, with what outcome, and why.

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.

Agent

intent

Authority

1 Evaluate policy + delegation 2 Render decision: ALLOW | DENY | ESCALATE 3 Commit receipt (append-only)

synchronous · before execution · eval time recorded

Tool / API

consequential action

Authority enforces governance at multiple planes:

Execution Layer

Tool Execution

▎

Intercept tool calls at the execution valve (MCP tool servers, tool gateways).

Model Output

▎

Evaluate action plans (including tool-call plans) before any downstream execution.

Runtime Control

▎

Control orchestration decisions: routing, retries, delegation, escalation.

Code Execution

▎

Govern sandboxed code execution — external effects only via approved host functions.

Access Control

Data Access

▎

Govern retrieval and access to enterprise data sources (databases, documents, indexes).

Memory Operations

▎

Govern reads and writes to agent long-term memory, including retention and deletion.

Identity Binding

▎

Bind actions and approvals to authenticated identities and delegated authority.

Boundary Control

Network Egress

▎

Control outbound requests and egress paths (domains, SaaS APIs, exfiltration routes).

Telemetry Egress

▎

Control telemetry egress (logs, metrics, traces) to prevent sensitive-data leakage.

The enforcement point varies by integration. The invariant does not: no downstream action executes without a governance decision and a evidence record. Different architectures place the valve in different locations; the primitive stays the same — decide before execution, produce evidence.

Why Existing Tools Are Not Enough

⊘

IAM

Identity and access management controls which systems can authenticate and what resources they may reach. It does not model delegated authority. It cannot express that an agent may send external messages only during an active incident, only to the affected customer, only for 48 hours, and only if a security approver has confirmed the scope. IAM answers "can this identity access this resource." It does not answer "was this action authorised under this policy at this moment."

⊘

Logs

Logs and observability platforms record what happened. They are essential, but they are retrospective. They capture events after execution. They do not capture the governance decision that preceded execution: which policy was evaluated, what delegation was in effect, and whether the action was allowed, denied, or held for human approval. An audit requires more than a record of events. It requires a record of decisions.

⊘

Model Guardrails

Model-layer guardrails constrain what an AI model can generate or propose. They operate before the action boundary, at the reasoning layer. They do not govern what happens when a model's output becomes an action in a downstream system. A guardrail may prevent a model from generating a harmful instruction. It does not prevent a well-formed instruction from being executed without proper authority.

⊘

AI Governance Frameworks

AI governance frameworks typically address model risk, bias, and compliance at the organisational or model lifecycle level. They do not operate at the action boundary. They do not make real-time ALLOW, DENY, or ESCALATE decisions. They do not produce the per-action evidentiary record that a regulator, auditor, or incident reviewer requires.

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

Structural Enforcement

▎

Bypassing governance requires bypassing the enforcement boundary itself — not merely ignoring a policy recommendation. Every governed action produces a evidence record committed to an append-only ledger. A gap in the evidence trail is a detectable governance failure.

Synchronous Evaluation

▎

Policy evaluation completes before the action proceeds — there is no asynchronous pattern. The governance decision is rendered and the evidence record committed before any consequential action executes. Each evidence record records evaluation duration measured by monotonic clock at the enforcement point.

Measured Latency

▎

Governance timing is measured per decision and reported as p50, p95, and p99 percentiles. Governance cost is explicit and characterised — organisations can make informed decisions about enforcement placement based on measured numbers, not estimates.

Fail-Closed Design

▎

If policy evaluation fails, the decision is DENY. If delegation cannot be verified, the decision is DENY. If no policy matches the requested action, the decision is DENY. Availability may be affected. Governance integrity is not.

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 Requested

The consequential operation that was requested, with its content hash for verification.

Actor

The system or principal that requested the action.

Policy Version

The policy that was evaluated, referenced by version and content hash.

Governance Decision Record Example

decision_id: 7f2a91c3-4e8b-4a2f-9d1c-6b3e8f0a2d5e
timestamp: 2026-01-15T09:23:41.127Z
policy_eval: 0.08 ms
governance: 0.26 ms
action: refund.issue
action_hash: sha256:e3b0c44298fc1c14…
principal: support-agent-07
policy: org/finance/refund-v3
policy_hash: sha256:a1b2c3d4e5f67890…
delegation_id: del-8k3m-9n2p
delegation_valid: 2026-01-10T00:00Z → 2026-02-10T00:00Z
delegation_scope: refund.issue ≤ 500 AUD
decision: ALLOW
basis: Policy match: refund.issue permitted under org/finance/refund-v3. Delegation valid and active. Amount within scope ($127.50 ≤ $500 AUD).
integrity: hmac-sha256:f7e6d5c4b3a29180…

Synthetic data for illustration. Not from a live system.

Delegation

The delegation that was in effect at evaluation time, including validity period and scope constraints.

Decision Rendered

The outcome: ALLOW, DENY, or ESCALATE.

Basis

The reasoning and context for the decision.

Evidence Records are designed output, not a logging byproduct. 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.

Authority decides. Observatory explains.

Observatory deep-dive