Technical Foundations

Version 0.1 — March 2026 — Design Specification

This document describes the cryptographic primitives, evidence integrity model, trust boundaries, and boundary enforcement design that underpin Ambit Authority. It is a design specification — not a certification claim. Where independent verification is planned, it is noted explicitly.

Definitions

Evidence record — the tamper-evident artefact produced for every governance decision, containing the action, actor, target, policy reference, delegation state, outcome, and integrity hashes.
Action boundary — the enforcement point between autonomous intent and consequential side effect in a downstream system.
Trust boundary — the perimeter within which cryptographic keys, policy artefacts, and evidence records are held. For Authority, this is the customer environment.

Cryptographic Primitives

Authority uses a small, deliberate set of cryptographic primitives. The design favours well-understood constructions over novelty.

Hashing

▎

SHA-256 for all content hashing: policy identity, request fingerprints, evidence record chaining, argument hashing, and response hashing. All hash inputs are canonicalised to deterministic byte representations before hashing. Security assumptions follow the standard SHA-256 collision resistance and preimage resistance properties as defined in NIST FIPS 180-4. Record format and canonicalisation are versioned so future revisions can introduce new algorithm identifiers and verification rules without invalidating previously issued records.

Integrity Signatures

▎

HMAC-SHA256 for delegation and approval token signing and verification. Signature comparison uses constant-time evaluation to prevent timing side-channels. Evidence record integrity is provided separately through hash chaining (see below), not HMAC signatures.

Canonicalisation

▎

All structured data is canonicalised before hashing: sorted keys, compact separators, UTF-8 encoding with deterministic escaping. Byte-identical inputs produce byte-identical hashes. The canonicalisation specification is itself versioned — changes are subject to the constitutional amendment process (Clause 10).

Timestamps

▎

UTC ISO-8601 with millisecond precision and Z suffix. Wall-clock timestamps are informational. Evaluation timing uses monotonic nanosecond clocks at the enforcement point. Record ordering is established by sequence numbers and hash chaining rather than wall-clock synchronisation.

Current design boundary. Authority’s cryptographic model is scoped to single-trust-domain deployments where the signing secret is held within the customer environment. This model does not require asymmetric signatures (RSA, ECDSA, Ed25519), external timestamping authorities (RFC 3161), hardware security modules, or a cryptographically authenticated time authority. Authority does not currently claim cryptographically authenticated wall-clock time; wall-clock timestamps are informational, and evaluation ordering is established via sequence numbers and hash chaining. These extensions are designed for multi-party and cross-domain verification scenarios and will be introduced as deployment models require them.

Evidence Record Integrity

Every governance decision produces an evidence record. The integrity model is designed so that tampering with any record is detectable, and so that the complete decision history can be verified independently.

Record Structure

Each evidence record captures:

Action: what was requested — action type, boundary, privilege classification, target object, and a SHA-256 fingerprint binding the request to its content.
Actor: the principal that initiated the action.
Policy: the policy evaluated, referenced by version and content hash — not by name or pointer. The hash ties the decision to the exact policy text in effect at evaluation time.
Delegation: the delegation in effect — scope constraints, validity window, revocation status, and token identity.
Decision: the outcome (ALLOW, DENY, or ESCALATE), the rule chain that produced it, and the matched rule identifier.
Evidence hashes: independent SHA-256 hashes of the request, arguments, context, and response — each verifiable against source data.
Timing: nanosecond-precision durations for rule evaluation, token validation, receipt assembly, and total handling time.

Hash Chaining

Evidence records are cryptographically chained. Each record hash is computed over a canonical representation of the record payload together with the previous record hash and the sequence number.

Let $R_n$ be the record obtained by inserting the fields $\text{prev\_hash} = h_{n-1}$ and $\text{seq} = n$ into $\text{payload}_n$ at the top level before canonical serialisation. The record hash is:

h_n = \text{SHA-256}\bigl(\text{canonical\_json}(R_n)\bigr)

The chain begins with a genesis anchor:

h_0 = \texttt{0}^{64}

where $\texttt{0}^{64}$ denotes the 64-character hexadecimal string of zeros used as a sentinel genesis anchor. $\text{canonical\_json}$ denotes deterministic JSON serialisation with sorted keys, compact separators, and fixed UTF-8 encoding.

This construction has three properties:

Modifying any historical record invalidates all subsequent hashes.
Reordering records breaks the sequence binding.
Inserting or removing records produces a detectable discontinuity.

The chaining mechanism is deterministic: identical inputs produce identical chains. This supports independent reconstruction and cross-system verification.

Request Fingerprinting

Each action request is fingerprinted using SHA-256 over a canonical representation of the actor, action type, boundary, target, arguments, delegation scope, and the policy hash in effect. The fingerprint binds the decision to the exact request content — a different request under the same policy produces a different fingerprint. Approval tokens carry this fingerprint and are validated against it: an approval for one request cannot be replayed against a different request.

Token Architecture

Delegation and approval are expressed as signed tokens, not inferred from identity or role. The HMAC signing key is held within the customer environment and is not transmitted outside the trust boundary.

Delegation Tokens

▎

Grant scoped authority to act. Each token carries a unique identifier (JTI), subject, scope constraints (permitted actions, tools, paths, domains), and a validity window (nbf/exp). Delegation can only narrow scope. A delegated token cannot grant permissions broader than the token from which it was derived.

Approval Tokens

▎

Record human consent for specific actions. Each token is bound to a request fingerprint — the approval is valid only for the exact request it was issued against. Approval tokens carry their own JTI, approver identity, and validity window.

Replay Protection

▎

Approval token JTIs are marked as used after an ALLOW decision. A used JTI cannot produce a second ALLOW. Delegation tokens can be revoked before expiry; revocation status is checked at evaluation time. Expired entries are cleaned up automatically.

Signature Verification

▎

Tokens are signed with HMAC-SHA256 and verified using constant-time comparison. An invalid signature produces DENY — there is no fallback to unsigned evaluation.

Trust Boundaries and Threat Model

Authority’s threat model is scoped to governance integrity at the action boundary. It does not attempt to address all security concerns in an autonomous AI deployment — it addresses the specific concern that consequential actions execute without authorisation evidence.

Trust Boundary

Authority operates within the customer’s trust boundary. The signing secret, policy artefacts, delegation tokens, and evidence records are held within the customer environment. Ambit does not hold or manage customer HMAC secrets or token-signing material.

The trust boundary assumes:

The customer environment is not fully compromised. An attacker with root access to the host running Authority can tamper with anything — this is true of all software controls and is out of scope.
The HMAC signing secret is protected by the customer’s operational security practices (secrets management, access controls, rotation).
The runtime that calls Authority does so via the provided SDK, gateway, or sidecar integration. Runtimes that bypass the integration bypass governance — this is addressed below under boundary enforcement.

In-Scope Threats

Unauthorised Action Execution

▎

An autonomous system executes a consequential action without a governance decision. Authority addresses this by requiring a decision before execution and producing an evidence record for every evaluation.

Decision Record Tampering

▎

An actor modifies historical evidence records to conceal or alter governance decisions. Hash-chained evidence records make tampering detectable. Modification of any record invalidates the chain from that point forward.

Token Replay

▎

An actor reuses a valid approval token to authorise a different action or the same action a second time. Request fingerprint binding prevents cross-request replay. JTI tracking prevents same-request replay.

Delegation Scope Escalation

▎

A delegated actor attempts to act beyond the scope granted by their delegation. Delegation tokens carry explicit scope constraints (actions, tools, paths, domains) evaluated at decision time. Scope can only narrow through delegation chains.

Expired or Revoked Authority

▎

An actor uses a delegation or approval token after it has expired or been revoked. Validity windows are checked at evaluation time. Revocation status is checked before the decision is rendered. Absent, expired, or unverifiable credentials produce DENY.

Policy Drift

▎

The policy in effect at decision time diverges from the policy the organisation believes is current. Evidence records bind decisions to policy by content hash, not by name or version label. The hash is independently verifiable against the source policy artefact.

Partial Evidence Suppression

▎

An attacker attempts to delete or suppress evidence records after execution. Hash-chained records make gaps detectable — a missing record breaks the chain. Completeness monitoring via Observatory identifies missing entries independently of the enforcement path.

Evidence Forking

▎

An attacker attempts to produce an alternate evidence chain to conceal or rewrite decision history. Sequence binding and hash chaining make forks detectable. Divergent chains are detectable when continuity is checked against an independently held prior state, checkpoint, or mirrored evidence stream.

Out-of-Scope Threats

Full host compromise. An attacker with root access to the host can tamper with Authority, its configuration, its evidence records, and its HMAC secrets. This is a deployment security concern, not a governance control concern.
Model-layer attacks. Prompt injection, jailbreaking, and adversarial inputs that manipulate model reasoning are outside the governance boundary. Authority governs the action that results from reasoning, not the reasoning itself.
Denial of service. Authority is designed to fail closed: unavailability produces DENY, not bypass. This is a deliberate availability trade-off. Availability engineering (redundancy, failover, load management) is a deployment concern addressed per integration.
Side-channel extraction. Timing-based extraction of signing keys or policy content via observation of Authority’s evaluation behaviour. Constant-time signature comparison mitigates the primary vector. Broader side-channel resistance is a deployment hardening concern.

Boundary Enforcement and Anti-Bypass

Governance that can be bypassed is not governance — it is advice. Authority’s placement and enforcement model are designed to make bypass structurally difficult, not merely contractually prohibited.

Consequence-Path Placement

Authority sits on the consequence path — the execution path between autonomous intent and downstream side effect. The integration patterns (SDK, gateway, sidecar) each place the governance decision at the point where the action would produce a consequence: a database write, an API call, a message sent, a file modified.

This is a structural property, not a policy property. The governed runtime does not choose whether to call Authority — the integration is configured so that the execution path passes through it. Bypassing governance requires modifying the infrastructure configuration or execution path itself, which is an auditable operational change.

Evidence Gaps as Signals

Every governed action produces an evidence record. A gap in the evidence trail — an action that executed without a corresponding record — is a detectable governance failure. This is the anti-bypass invariant: bypass produces absence, and absence is observable.

This requires that evidence records are monitored for completeness. Observatory is designed to perform this function — identifying gaps, anomalies, and missing records in the decision ledger. Completeness verification is independent of the enforcement path.

Cooperative vs. Non-Cooperative Runtimes

Authority’s enforcement model assumes a cooperative integration: the runtime routes actions through the governance boundary. This is the realistic deployment model for enterprise autonomous AI systems, where the organisation controls the runtime configuration.

For non-cooperative runtimes — systems that could route actions outside the governed path — the anti-bypass strategy is consequence-side enforcement: placing governance at the downstream system (database, API, service) rather than at the agent runtime. This moves the enforcement boundary to infrastructure that the organisation controls regardless of agent behaviour.

Both patterns are supported by the same Authority evaluation engine. The integration point changes; the governance primitive does not.

Maturity and Verification Status

This section distinguishes what is implemented, what is designed, and what is independently verified.

Implemented

▎

SHA-256 hashing with canonical JSON. HMAC-SHA256 token signing and verification. Hash-chained evidence records. Request fingerprinting with approval binding. Replay protection via JTI tracking. Delegation scope enforcement (actions, tools, paths, domains). 22-rule evaluation chain with deterministic ordering. Nanosecond-precision timing instrumentation. Fail-closed default on all validation paths.

Designed, Not Yet Implemented

▎

Asymmetric signatures (Ed25519 or ECDSA) for multi-party verification scenarios. External timestamping authority integration (RFC 3161). Hardware security module support for key storage. Persistent append-only ledger with cryptographic commitment (currently scoped to Observatory). Key rotation with versioned secrets.

Independently Verified

▎

None of the above has been independently audited or formally verified. Independent cryptographic review and penetration testing are planned as the product matures through design partner evaluation. Certification status will be published on the Security page when available.

Ambit is currently accepting design partners for structured evaluation. If your organisation has technical due diligence requirements, contact us to discuss under NDA.