Intentrax Labs

Executive summary

As organizations delegate consequential actions to autonomous AI agents, a gap opens between what an agent claims it did and what can be independently established. Application logs, transcripts, and orchestration traces are all written by the executing system, so they inherit its trust assumptions: to believe the record, you must first trust the party being examined. This paper argues that autonomous execution needs a distinct evidence primitive - a tamper-evident, replay-verifiable artifact produced by an engine separate from the executor, checkable by anyone without access to the runtime that created it. Intentrax is the reference implementation of this primitive under an open verification protocol (AEVN). The artifact it produces is the Autonomous Execution Proof (AEP). This document describes the problem, the properties an execution-assurance primitive must have, and the honest boundaries of what such a primitive does and does not establish. It is written for auditors, insurers, and enterprise buyers evaluating how AI-agent activity can be evidenced. Intentrax is at a pre-revenue, production-beta stage; nothing here should be read as a claim of scale, customers, or regulatory endorsement.

The problem: self-attested execution does not survive scrutiny

The prevailing way to know what an AI agent did is to read what the agent, or its host application, recorded. That record is convenient and useful for debugging, but it is structurally self-attested. The same system that took the action also authored the account of the action, and can in principle edit, omit, or reorder it. For an internal engineering audience this is acceptable. For a downstream party - an auditor reconstructing events, an insurer adjudicating a claim, a counterparty resolving a dispute - it is not, because the account and the actor are the same entity. Monitoring and observability tools do not close this gap; they make self-attested telemetry richer and more searchable, but they remain descriptions the runtime emits about itself. What is missing is not more logging. It is a record whose integrity does not depend on trusting the executor, and whose correctness can be re-established from the outside.

What an execution-assurance primitive must provide

Five properties distinguish an assurance primitive from a log. Independence: the artifact is generated by an assurance engine, not editable by the executing agent, so the actor is not the author of its own evidence. Cryptographic tamper-evidence: the relevant execution facts are canonicalized into a stable byte representation and hashed (SHA-256) to a proof hash, then signed, so any later alteration is detectable. Replayability: a verifier re-derives the governing decision from the recorded inputs rather than reading a stored conclusion, so the outcome is reconstructed, not merely asserted. Policy-bound authority: the proof records the exact policy version and the identity, delegation, and constraints under which the action was permitted. Portable evidence: the artifact is expressible in machine and human-readable forms (JSON, an AEP export format, PDF) that travel to audits, disputes, and claims. Together these turn 'the agent says it did X' into 'an independent engine produced a signed artifact from which anyone can re-derive that X occurred under policy version P, bound to principal A, and confirm the artifact is unaltered.'

The mechanism, in outline

Internally, execution is captured as an ordered trace. That trace is not the external product. It is normalized into an external proof: the Autonomous Execution Proof. The engine is deterministic by construction - no randomness, no dependence on wall-clock time or environment, no hidden external I/O in the decision path - so the same execution inputs yield the same proof hash on any conforming implementation. The governing decision follows a fail-closed model: an action is permitted only if both the execution evidence and the bound authority permit it; otherwise it is denied. This is a deliberate design bias toward more denials rather than false permits. Proofs are recorded in an append-only registry with checkpoints, so the historical record grows but does not silently change. A separate, developer-facing Action Receipt may summarize an event for ergonomics, but it is explicitly non-authoritative and never replaces the canonical AEP.

Independent verification

The defining test of an assurance primitive is whether a party who does not trust the executor can still confirm the record. Intentrax ships a standalone verifier that operates on repository-local artifacts using only hash recomputation. It requires no access to the origin runtime, no network connectivity, and no private key material. It recomputes hashes, re-derives the decision from recorded inputs, and fails closed on authority drift or any inconsistency in the evidence bundle. This 'fail-closed on drift' behavior is central: the verifier's default answer to ambiguous or tampered evidence is to withhold a pass, not to grant one. Verification is thus reproducible by an outside party rather than dependent on the vendor's own systems being online and honest at the moment of the check.

Boundaries and current stage

Honesty about limits is part of the primitive's value. An AEP establishes what was executed, under which policy version, bound to which authority, and that the artifact is unaltered and replayable. It does not certify that the underlying business decision was wise, that an outcome was correct in the world, or that any regulation was satisfied. It is not compliance certification, and this product makes no claim to guarantee compliance, eliminate risk, or provide total security. External evidence ingested as an execution passport is bound to a proof but never replaces it. Intentrax is pre-revenue and in production-beta. The engine has recently begun signing real proofs; the offline verifier is operational. Assurance Levels and a broader trust network are planned and are labeled as such. Live production traffic and mutation are currently blocked pending controlled unlock. AEVN is an open protocol; Intentrax is its reference implementation, not its owner. Market forces such as insurer and auditor demand - not any regulatory mandate - motivate this work.

How to engage

For technical evaluators, the fastest path is the standalone verifier and the published conformance vectors: obtain an evidence bundle, run the offline verifier, and confirm that it recomputes hashes and re-derives the decision without touching a runtime. Developers can integrate an adapter with one command (npx @intentrax/sdk init <adapter>), with several one-command adapters available. For auditors and insurers, the portable AEP export (JSON, AEP-JSON, or PDF) is designed to be dropped into existing evidence workflows and checked independently. We welcome design-partner conversations at this stage and will describe the current state - including the blocks above - rather than a finished platform.

Executive summary

The Autonomous Execution Proof (AEP) is the canonical cryptographic artifact produced by the Intentrax Assurance Engine under the AEVN protocol. It is a tamper-evident, replay-verifiable, audit-ready record of a single autonomous execution event. This paper specifies, at an architectural level, how an AEP is derived, why it is deterministic, how integrity is preserved through canonicalization and hashing, how the governing decision is computed, and how an independent verifier confirms the artifact offline. The intended reader is technical: a security engineer, a platform architect, or a technically literate auditor who needs to understand the primitive well enough to trust - or to challenge - it. Machine-readable schemas and golden vectors are the authoritative source; this document is an explanation downstream of them and does not redefine any locked contract.

From internal trace to external proof

Intentrax separates two artifacts by design. The Execution Evidence Object (EEO) is the internal trace of an execution. The AEP is the external proof derived from it. The EEO exists to capture what happened; the AEP exists to let someone who was not present, and who does not trust the executor, establish what happened. Keeping these distinct is a deliberate architectural choice: it adds a normalization layer but yields portable verification that does not leak internal runtime structure and does not require runtime access to check. An AEP lets an independent verifier determine: what execution evidence was normalized; which principal and authority were bound; which policy version governed the event; which decision was produced; how integrity and replay references were preserved; and whether the proof was subsequently altered.

Determinism as a precondition

Replayable verification is only possible if execution is deterministic. The engine follows a deterministic model: no randomness, no dependence on wall-clock time or environment, and no hidden external I/O inside the decision path. The engine core is implemented against the standard library with no external runtime dependencies, which narrows the surface for non-determinism and supply-chain variance. The consequence is a strong invariant: the same execution inputs produce the same proof hash, independent of when or where the derivation runs. This is what makes cross-implementation and cross-language consistency meaningful - a conforming verifier in another language must arrive at the identical canonical bytes and therefore the identical hash. Determinism is not a performance choice here; it is the property that makes independent replay possible at all.

Canonicalization and the proof hash

Integrity rests on a canonical encoding. Proof content is serialized with ordered keys and a canonical JSON encoding so that semantically identical content always produces identical bytes; the canonical bytes are hashed with SHA-256 to produce the proof hash. Because the encoding is canonical rather than incidental, two systems that agree on the content cannot disagree on the hash. The proof hash is then signed, binding the content to a signing authority and making any post-hoc edit detectable: alter a field, and the recomputed hash no longer matches the signed value. The cost of this approach is a strict, custom canonicalization requirement rather than relying on a language's default JSON serializer - a cost the design accepts in exchange for cross-system determinism. Canonical JSON remains the machine-authoritative form; human-readable companions (certificate, verification report) are required for usability but are explicitly non-authoritative.

The decision model: fail-closed dual gate

The governing decision is computed, not asserted. An action is ALLOWed only if the execution evidence gate and the authority gate both permit it; if either withholds permission, the result is DENY. This dual-gate, fail-closed model biases the system toward denial in ambiguous states, which produces more DENY outcomes than a permissive design but avoids false ALLOWs on incomplete or drifted evidence. Authority is bound explicitly: the proof records the exact policy version that governed the event together with the identity, delegation chain, and constraints under which the action was permitted. Because the decision is re-derivable, a verifier does not read a stored ALLOW/DENY conclusion and take it on faith; it recomputes the decision from the recorded inputs and the referenced policy version, and confirms it matches.

Registry and portable evidence envelope

Recorded proofs are written to an append-only registry with checkpoints. The registry is immutable by design: entries are added, never silently rewritten, which is what makes historical auditability possible at the expense of monotonic storage growth. Each AEP can be packaged into a portable evidence envelope - the canonical AEP plus an Agent bill-of-materials (model, prompt, tool, policy, authority, and delegation references, without requiring raw prompt disclosure) and an Execution bill-of-materials (execution and tenant identifiers, EEO hash, AEP hash, state-machine and step-chain references, and registry references). The envelope is explicitly portable proof only. It carries the human-readable certificate, verification report, and README alongside the machine-authoritative canonical form, and it is designed so a downstream verifier needs no origin-runtime access, no private key material, no network lookup, and no policy re-evaluation service to check it.

Offline verification contract

The standalone verifier defines the trust boundary in operational terms. It uses only repository-local JSON files and SHA-256 recomputation. It does not import the engine's Go packages, call a runtime service, open the network, or require private key material. It recomputes artifact hashes, binds the offline proof-verification report, re-derives the decision, and confirms the evidence bundle is self-consistent - and it fails closed if any artifact is missing, hash-drifted, or misinterpreted as a stronger claim than it makes. The verifier is deliberately conservative about what a pass means. In the current production-beta posture, production-facing evidence bundles resolve to a status that explicitly holds production authority flags - production-ready, production-authorized, runtime-access-required, network-access-required, private-key-material-required - fixed to false. Passing the evidence-bundle check is an integrity verification, not a production go-live authorization. That separation is intentional and is enforced by a negative-vector corpus covering drift, overclaim, and authorization-boundary abuse.

Boundaries, stage, and how to engage

The AEP establishes execution, policy version, bound authority, integrity, and replayability. It does not certify business correctness or regulatory compliance, and this system makes no claim to guarantee compliance, eliminate risk, or provide total security. Ingested external evidence is bound to a proof as an execution passport but never replaces the AEP. AEVN is an open protocol and Intentrax is its reference implementation, not its owner. The engine has recently begun signing real proofs and the offline verifier is operational; Assurance Levels 1-4 and a wider trust network are planned and labeled as such; live production traffic and mutation are currently blocked. To evaluate the primitive directly, run the standalone verifier against a published golden vector, or integrate an adapter with npx @intentrax/sdk init <adapter>. Deeper technical review against the locked schemas and conformance vectors is available to design partners.

Executive summary

Insurers pricing and adjudicating AI-agent risk, and auditors examining AI-agent activity, face the same structural obstacle: the evidence they are handed is usually produced by the party under examination. Logs and transcripts are self-attested, so relying on them requires trusting the entity whose conduct is in question. This paper describes how an execution-assurance primitive - a signed, replay-verifiable Autonomous Execution Proof (AEP) that a third party can check offline - changes what an adjudicator or examiner can independently establish. The practical claim is narrow and deliberate. An AEP lets you confirm, without runtime access and without trusting the executor's logs, that a specific execution occurred, under a specific policy version, bound to a specific authority, and that the artifact you were given is unaltered and re-derivable. This document explains what that supports in adjudication and audit workflows, and - equally important - what it does not.

The adjudication and audit gap

When an AI agent takes an action that later becomes the subject of a claim, a dispute, or an examination, the reconstructing party typically receives application logs and a narrative from the operator. Those records may be accurate. But they are authored by the operator's own systems, which means the examiner cannot distinguish a faithful record from a curated one without independent corroboration. For an insurer this complicates causation and loss adjudication; for an auditor it undermines the assertion that recorded activity is complete and unaltered. Richer monitoring does not resolve this. Observability improves the operator's own visibility, but it produces more self-attested telemetry, not independently checkable evidence. What adjudicators and examiners need is an artifact whose integrity does not rest on trusting the operator, and whose correctness they can re-establish themselves.

What independent verification means here

Independence is operational, not rhetorical. Intentrax provides a standalone verifier that runs on the evidence bundle you are given, using only local files and SHA-256 recomputation. It requires no access to the operator's runtime, no network connection back to the vendor, and no private key material. It recomputes the artifact's hashes, re-derives the governing decision from the recorded inputs and the referenced policy version, and fails closed on any drift or inconsistency. For an examiner, this inverts the usual dependency. Rather than asking the operator to attest that its logs are true, you take the portable proof and confirm it yourself: the signed proof hash matches the canonical content, the decision re-derives, the authority binding is intact, and nothing has been altered since signing. A pass is reproducible by you; it does not depend on the vendor's systems being online or honest at the moment you check.

What the proof lets you establish - and what it does not

An AEP supports specific, bounded assertions. You can establish that an execution event occurred as recorded; which policy version governed it; which principal, delegation, and constraints authorized it; that both the execution and authority gates permitted the action under a fail-closed model (an ALLOW required both gates; otherwise it would have been a DENY); and that the artifact is tamper-evident and replayable. For an insurer, this sharpens questions of whether an action was within authorized scope and policy at the moment it occurred. For an auditor, it supports completeness and integrity assertions grounded in an append-only registry rather than mutable logs. Equally important is what it does not do. An AEP does not certify that the business decision was correct or prudent, does not attest to real-world outcomes, and is not a compliance certification. Intentrax makes no claim to guarantee compliance, eliminate risk, or provide total security. External evidence you may already hold can be ingested as an execution passport bound to the proof, but it never replaces the AEP. Treat the proof as evidence about execution and authority, not a verdict on judgment or law.

Fitting proof into existing workflows

The evidence is designed to travel. Each AEP can be packaged as a portable envelope containing the machine-authoritative canonical JSON, an AEP export (AEP-JSON) and PDF for human review, and human-readable companions - a certificate, a verification report, and a bundle README - alongside an Agent bill-of-materials and Execution bill-of-materials that reference model, policy, authority, and delegation without requiring disclosure of raw prompts. That envelope is intended to drop into an existing claims file, audit workpaper, or evidence-management system. A typical examiner flow: receive the portable bundle from the operator; run the standalone verifier locally; confirm the pass and read the human-readable certificate and verification report; retain the canonical artifact and its hash in the file. Because verification is offline and reproducible, the same check can be repeated later, by a different reviewer, with the same result - a property that matters for defensible adjudication and for audit re-performance.

Current stage and market context

We are candid about maturity because that is what an assurance conversation requires. Intentrax is pre-revenue and in production-beta. The engine has recently begun signing real proofs and the standalone offline verifier is operational. Assurance Levels 1-4 and a broader trust network are planned and labeled as such. Live production traffic and mutation are currently blocked pending controlled unlock, and production-facing evidence bundles are deliberately verified as integrity passes rather than production go-live claims. The motivation for this work is market demand - from insurers, auditors, and enterprise buyers who need to evidence AI-agent activity - not a regulatory mandate. AEVN is an open verification protocol; Intentrax is its reference implementation, not its owner, which means the verification model is not proprietary lock-in. We engage with insurers and auditors as design partners and will always describe the current state, including the blocks above, rather than an idealized platform.

How to engage

The most useful first step for an adjudicator or examiner is hands-on: obtain a sample evidence bundle and run the standalone verifier yourself, confirming that it recomputes hashes and re-derives the decision with no runtime access, no network, and no keys. From there, we can walk through how the portable AEP export maps to your claims file or audit workpaper, and where its bounded assertions do and do not carry weight in your process. For design-partner engagements we can discuss the planned Assurance Levels, the append-only registry model, and how ingested external evidence is bound as a passport without displacing the canonical proof. We do not offer customer references or performance metrics at this stage because there are none to offer honestly; we offer the primitive, the verifier, and a precise account of what each establishes.