Technical Foundations

Version 0.3 — September 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 your deployment 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

▎

Ed25519 for delegation tokens. Ed25519 or canonical (low-S) P-256 for approval tokens; a P-256 credential also requires a separately countersigned registration. Ed25519 for authenticated evaluation time, revocation-status attestations, and ledger-head attestations. Authority verifies each token against the configured public key of the trust root the token names, so the verifier holds no material that can mint a token. Unprefixed legacy HMAC tokens fail closed. Envelope seals accept Ed25519 or a legacy HMAC-SHA256 seal, and the require_seal posture accepts Ed25519 only. Evidence record integrity is provided separately through hash chaining (see below), not 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. In constitutional mode, the evaluation timestamp is produced by an explicitly identified, authenticated time authority and bound into the evidence record with authority identity, trust root, confidence window, and attestation. Operational durations still use 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 private signing keys, attestation keys, policy artefacts, and evidence records are held within your environment. Authority verifies tokens with public keys only. The reference runtime includes an Ed25519-attested time authority and a signed, freshness-bounded revocation store for constitutional mode. It does not claim independent third-party time notarisation, hardware security module key custody, or delegation chains that cross organisational trust domains. Those deployment choices can bind to the same time-authority and revocation-status contracts when an organisation requires external trust roots.

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.
Runtime authority: the evaluation timestamp authority, trust root, attestation, revocation source, revocation freshness bound, and revocation attestation where constitutional mode requires them.
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 Authority decision point needs only public keys to verify tokens, so it holds no key that can mint one. Where the private signing keys are kept, and how they are protected, is a deployment decision. Revocation is resolved before evaluation and carried into the evidence record with freshness and verification metadata rather than hidden behind a live boolean lookup.

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 an approval for one specific request. Each token is bound to a request fingerprint and to the ESCALATE record it answers — the approval is valid only for the exact request it was issued against. Approval tokens carry their own JTI, an approver label, and a validity window. A signature proves control of the approval credential; it does not prove which person approved.

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 resolved before evaluation. In constitutional mode, revocation status must include source, as-of timestamp, freshness bound, trust root, and attestation; stale, missing, or unverifiable revocation status produces DENY.

Signature Verification

▎

Delegation tokens verify with Ed25519 only, and approval tokens with Ed25519 or P-256. Each token names a trust root, and Authority checks the signature against that root's configured public key. An unprefixed legacy HMAC token, an unknown trust root, or 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 your organisation’s trust boundary. Private signing keys, attestation keys, policy artefacts, delegation tokens, revocation state, and evidence records are held within your environment. Ambit Systems does not hold or manage your signing keys or attestation keys.

The trust boundary assumes:

Your 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.
Private signing and attestation keys are protected by your 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 resolved before the decision is rendered and must satisfy its declared freshness window. Absent, expired, stale, 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 any keys held on that host. 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. Authority verifies tokens with public keys, so its timing cannot reveal a token-signing key, and legacy HMAC seal values are compared in constant time. 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. Ed25519 delegation tokens and Ed25519 or P-256 approval tokens, verified against configured public keys. Hash-chained evidence records with Ed25519 ledger-head attestation. Request fingerprinting with approval binding. Replay protection via JTI tracking. Delegation scope enforcement (actions, tools, paths, domains). Ed25519-attested time authority for constitutional mode. Signed, freshness-bounded revocation status for constitutional mode. Deterministic rule chain evaluated in fixed order, ending in default deny. Nanosecond-precision timing instrumentation. Fail-closed default on all validation paths.

Designed, Not Yet Implemented

▎

External timestamping authority adapters such as RFC 3161 or Roughtime. Hardware security module support for key storage. Enterprise revocation backends beyond the reference signed-file store. Persistent append-only ledger custody outside the local deployment. Key rotation with versioned keys.

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 Systems is currently accepting design partners for structured evaluation. If your organisation has technical due diligence requirements, contact us to discuss under NDA.