AI Agent Audit Trails and Verifiable Execution Receipts

Short answer: SovereignClaw produces a verifiable AI agent audit trail by emitting a signed Authority Receipt for every governed action — binding the intent IR hash, policy version, decision, risk tier, adapter identity, tenant scope, and outcome into an append-only Merkle ledger. Each receipt is signed with Ed25519 and is externally verifiable without access to any private key, so auditors and downstream systems can confirm exactly what an agent did, under which policy, and on whose authority.

Every governed action should leave evidence. Most agent stacks log a prompt and a tool call after the fact, which proves an agent tried something, not that the system authorized it. SovereignClaw instead emits a signed Authority Receipt tied to the frozen intent, the policy that ran, the adapter that executed, the tenant it ran for, and the result — a record produced as part of execution rather than reconstructed from logs afterward. The receipts are portable and externally verifiable, which is what turns “we have logs” into evidence an auditor can independently trust.

This audit model is a direct consequence of how the runtime is built: the AI agent runtime governance platform gates execution at the boundary, and the receipt is the artifact that boundary leaves behind. To see where the receipt is generated in the pipeline, review the seven-stage execution path; for the formal guarantee behind it, read Security Property S8, Receipt Verifiability. The design is documented in the research record and DOI-registered on Zenodo. Patent applications pending: USPTO 76395580 · 74981727 · 74483691 · 73809451 · 72763061.

What an Authority Receipt contains

An Authority Receipt is a structured record emitted at the final stage of the pipeline, when a permitted action runs through an adapter that is cryptographically bound to that exact execution. It is not a log line written by the model — it is produced by the kernel and describes the authority under which the action ran. Each receipt carries:

Intent (IR hash) — the SHA3-256 hash of the canonical SovereignIR, the byte-stable representation of the proposed action. Identical intents produce identical hashes, so the receipt unambiguously identifies what was requested.
Policy version — the versioned, cryptographically hashed policy bundle that evaluated the action, so the receipt records exactly which rules were in force.
Decision and rationale — allow, deny, escalate, or approval, with the reasoning the deterministic policy engine produced.
Risk tier — T0 observe, T1 standard, T2 elevated, or T3 sovereign, derived from independently inferred facts rather than from anything the model asserted.
Approval state — for T2 and T3 actions, whether the required threshold signatures (for example, 2-of-3) from verified operators were collected.
Adapter identity — the specific adapter the action was bound to, so a receipt can never be confused with execution against a different tool.
Tenant scope and correlation ID — the isolation boundary the action ran within and the stable identifier that threads it through downstream systems.
Execution outcome — the result of the bound execution, completing the record of what actually happened.

How a receipt is signed and externally verifiable without private keys

Authority Receipts are signed with Ed25519 and appended to a Merkle ledger that only ever grows. The combination matters: the signature proves the receipt came from the kernel, and the append-only Merkle structure proves the receipt has not been altered, reordered, or dropped after the fact. Tampering with any earlier receipt changes the Merkle root, which breaks verification for the whole chain.

Verification does not require any SovereignClaw secret. A third party can re-canonicalize the intent and re-derive the SHA3-256 IR hash, check the Ed25519 signature against the public key, and confirm the receipt’s inclusion against the published Merkle root — all using public information. That is what makes the trail externally verifiable: trust comes from cryptography that anyone can re-run, not from trusting SovereignClaw’s word or its private keys.

Denied-action evidence and replay resistance

A verifiable trail has to account for what an agent was refused, not only what it did. In SovereignClaw, refusal is mechanical: an unauthorized action receives no execution path because the adapter is unreachable without a valid gate artifact bound to the IR hash, policy bundle, adapter identity, and nonce. The model can comply; the kernel does not. The denial — with its decision, rationale, risk tier, and policy version — is still captured as evidence.

Because monotonic policy makes any Deny final and no decision can be silently downgraded, the trail cannot be quietly walked back. Every execution also consumes a unique nonce, so replayed or time-of-check/time-of-use attempts are rejected and visible rather than slipping through as duplicate activity. The result is an audit record that distinguishes authorized execution, denied intent, failed approval quorums, and rejected replays — not just successful calls. For the policy decisions that produce these outcomes, see AI agent policy enforcement.

Routing receipts into SIEM, audit, and compliance record-keeping

Evidence is only useful if it lands where reviewers already work. Authority Receipts are portable and carry stable correlation IDs and tenant scope, so they thread agent activity through existing tooling: a single correlation ID ties a proposed intent, its decision, any approval, and its outcome together across systems. Compliance metrics export in both JSON and CEF, which lets teams ingest agent execution evidence into a SIEM and correlate it with the rest of their security telemetry.

Against record-keeping frameworks, SovereignClaw supports the evidence side of the obligation:

SOC 2 — signed, tamper-evident receipts and policy bundle exports map to logging, monitoring, and change-control criteria, giving auditors a receipt chain rather than reconstructed logs.
HIPAA — receipts provide PHI access records in which every data-touching action is tier-classified, policy-evaluated, and receipt-verified, helping operationalize access-logging requirements.
EU AI Act — receipts and execution logs help operationalize the record-keeping, logging, and human-oversight obligations for high-risk systems by capturing automatically generated evidence of authorization and outcome.

SovereignClaw supports and helps operationalize these record-keeping requirements and provides evidence for them; it does not replace the surrounding compliance program. For the full framework mapping, see the compliance coverage page.

Enterprise evaluation checklist

When comparing an audit trail against the bar a regulator or security team will actually hold it to, ask:

Is each record signed, or merely written to a log that a privileged process could edit?
Can the trail be verified by a third party without handing over private keys?
Does the record bind the exact policy version and adapter identity, so you know which rules ran and what they ran against?
Are denied and refused actions captured as evidence, not just successful calls?
Is the structure append-only and tamper-evident, so after-the-fact edits are detectable?
Do receipts carry tenant scope and correlation IDs that survive ingestion into your SIEM and audit pipeline?

SovereignClaw is engineered to answer yes to each of these. The receipt model is one of nine formal security properties (S1–S9) verified across 20 Rust crates with 829+ tests, and the receipt guarantee itself — S8 Receipt Verifiability — is what makes the audit trail externally checkable rather than self-asserted.

Request Early Access

Frequently Asked Questions

What is an Authority Receipt?

An Authority Receipt is the signed evidence record SovereignClaw emits for every permitted AI agent execution. It binds the intent (IR hash), policy version, decision and rationale, risk tier, approval state, adapter identity, tenant scope, correlation ID, and execution outcome into a single record, signed with Ed25519 and written to an append-only Merkle ledger. This satisfies Security Property S8, Receipt Verifiability.

Is the SovereignClaw audit trail externally verifiable without access to private keys?

Yes. Authority Receipts are signed with Ed25519, and the append-only Merkle ledger is externally verifiable using public keys and the published Merkle root alone. Auditors and downstream systems can re-derive the canonical SHA3-256 IR hash, check the signature, and confirm ledger inclusion without any access to SovereignClaw private keys.

Does the audit trail capture denied and unauthorized actions?

Yes. A denied action receives no execution path — the adapter is unreachable — but the decision, rationale, risk tier, and policy version are still recorded as evidence. The audit trail therefore shows both what executed and what was refused, including failed approval quorums and replay attempts rejected by nonce uniqueness.

How do SovereignClaw receipts map to SOC 2, HIPAA, and EU AI Act record-keeping?

Authority Receipts provide tamper-evident evidence that supports SOC 2 logging and monitoring controls, HIPAA-aligned PHI access records, and EU AI Act record-keeping and logging obligations for high-risk systems. SovereignClaw helps operationalize these record-keeping requirements; it does not replace the surrounding compliance program.

Can Authority Receipts be ingested into a SIEM or audit pipeline?

Yes. Receipts are portable and carry stable correlation IDs and tenant scope, so they route into SIEM, log analytics, and audit workflows. Compliance metrics are exported in JSON and CEF formats, letting teams correlate agent executions with existing security telemetry.