Skip to content

Cryptographic Governance Audit Trail

Wrap agent tool calls with middleware that validates policy before execution and signs each action receipt with a post-quantum signature, forming a tamper-evident append-only chain.

The Compliance Gap

Mutable logs carry no compliance weight. An agent that logs tool calls to a writable file gives no proof the log was not altered after the fact. Regulated environments — finance, healthcare, EU AI Act Article 12 — require evidence that agents operated within defined bounds and that the record cannot be modified retroactively.

A cryptographic audit trail closes this gap: each action produces a signed receipt, and receipts are hash-chained so any modification or omission is detectable on verification.

Architecture: Three-Phase Middleware

Middleware wraps the agent's tool-calling interface. Every tool invocation passes through three sequential phases (nibzard catalog):

graph TD
    A[Tool Call Request] --> B[Phase 1: Policy Validation]
    B -->|Policy rejected| C[Reject + Sign Denial Receipt]
    B -->|Policy approved| D[Phase 2: Tool Execution]
    D --> E[Phase 3: Receipt Signing]
    E --> F[Append to Audit Chain]
    C --> F
Phase Action
Policy validation Check allowed tools, rate limits, data access rules before executing
Tool execution Run the tool normally — no change to tool behavior
Receipt signing Sign the action record (tool name, parameters, result hash, timestamp, policy outcome) with ML-DSA-65 and append to the chain

The chain is tamper-evident by construction: each receipt includes a hash of the previous one. Modifying or omitting any entry breaks the chain — verification fails automatically (asqav-sdk).

Post-Quantum Signatures: ML-DSA

Standard ECDSA or RSA signatures are adequate today but vulnerable to quantum attack. For audit records that must remain verifiable for years or decades, the signature algorithm must stay secure against a quantum adversary.

ML-DSA (FIPS 204) is a module-lattice-based digital signature standard finalized by NIST and used in this pattern's reference implementation (asqav-sdk). The ML-DSA-65 parameter set targets security equivalent to AES-192.

Each signed receipt contains (asqav-sdk):

{
  "signature_id": "sig_a1b2c3",
  "agent_id": "agt_x7y8z9",
  "action": "api:call",
  "algorithm": "ML-DSA-65",
  "timestamp": "2026-04-06T18:30:00Z",
  "chain_hash": "b94d27b9934d3e08...",
  "verify_url": "https://asqav.com/verify/sig_a1b2c3"
}

IETF SCITT Alignment

The append-only signed receipt architecture maps onto IETF SCITT (Supply Chain Integrity, Transparency, and Trust) — an active IETF working group defining how statements (agent actions) are registered with a Transparency Service, which issues receipts as cryptographic proof of registration. Alignment with SCITT enables interoperability with compliance tooling built on the standard.

Enforcement Tiers

Three deployment configurations trade enforcement strength for integration complexity (asqav-sdk):

Tier Mechanism Guarantee
Strong Non-bypassable MCP proxy — signs before and after each tool call Tool cannot execute without a signed bilateral receipt
Bounded Pre-execution gate (gate_action) + post-execution close (complete_action) Approval is cryptographically linked to outcome
Detectable Sign and chain each action post-hoc Tampering or omission is detectable on verification

Strong enforcement has the highest assurance but requires routing all tool calls through a proxy. Detectable enforcement adds minimal latency and suits workflows where post-hoc verification is acceptable.

Implementation: Decorator Pattern

The reference implementation (asqav-sdk) wraps tool functions with a decorator:

import asqav

@asqav.sign
def call_database(query: str) -> dict:
    # tool implementation unchanged
    return db.execute(query)

For multi-step workflows, sessions group related actions into a single verifiable sequence:

with asqav.session() as s:
    s.sign("step:fetch", {"source": "customer_api"})
    s.sign("step:transform", {"records": 150})
    s.sign("step:write", {"destination": "report_table"})

Trade-offs

Factor Impact
Per-call latency Each tool call incurs signing overhead; profiling required for latency-sensitive agents
Key management Requires infrastructure for key generation, rotation, storage, and distribution
Storage growth Audit chain grows linearly with agent activity
Regulatory credibility Tamper-evident receipts carry evidentiary weight that mutable logs do not
Quantum durability ML-DSA receipts remain verifiable against quantum computers; ECDSA receipts do not

This pattern targets compliance-first use cases where regulatory credibility outweighs infrastructure cost. It is not a hardening mechanism — it does not prevent a malicious agent from acting; it produces unforgeable evidence of what the agent did. Pair with Defense-in-Depth Agent Safety for preventive controls.

Regulatory Targets

  • EU AI Act Article 12 — requires record-keeping for high-risk AI systems; signed receipts satisfy this obligation
  • SOC 2 audit trails — demonstrable, tamper-evident action logs support Type II audits
  • Litigation defense — a verifiable chain of agent actions with policy-validation outcomes provides evidentiary proof of compliant operation

The OWASP Top 10 for Agentic Applications 2026 lists insufficient logging and observability as a cross-cutting mitigation requirement, recommending signed, immutable audit logs of agent tool invocations and context changes across multiple risk categories.

Key Takeaways

  • Mutable logs are insufficient for regulated-industry compliance — tamper evidence requires cryptographic signing
  • Three-phase middleware (validate → execute → sign) leaves tool behavior unchanged while producing signed receipts
  • Hash-chaining receipts makes modification or omission detectable without a trusted third party holding the full log
  • ML-DSA-65 (FIPS 204) provides quantum-resistant signatures for long-term regulatory validity
  • IETF SCITT alignment enables interoperability with compliance tooling built on the standard
  • Three enforcement tiers let practitioners choose between maximum assurance and minimum integration friction

Example

A financial agent processes customer transactions. Each tool call passes through the three-phase middleware:

import asqav

# Decorator wraps each tool — no changes to tool logic required
@asqav.sign
def query_account(account_id: str) -> dict:
    return ledger_api.get(account_id)

@asqav.sign
def post_transaction(account_id: str, amount: float) -> dict:
    return ledger_api.post(account_id, amount)

# Multi-step workflow: all steps form a single verifiable session
with asqav.session() as s:
    s.sign("step:validate", {"account_id": "acct_123", "policy": "rate_limit_ok"})
    s.sign("step:query",    {"account_id": "acct_123"})
    s.sign("step:post",     {"account_id": "acct_123", "amount": 500.00})

Each call produces a receipt chained to the previous one:

{
  "signature_id": "sig_c4d5e6",
  "agent_id":     "agt_finance_01",
  "action":       "step:post",
  "algorithm":    "ML-DSA-65",
  "timestamp":    "2026-04-06T18:30:05Z",
  "chain_hash":   "a7f3c912...",
  "prev_hash":    "b94d27b9..."
}

To verify the chain for a compliance audit, a verifier checks that each chain_hash matches the hash of the prior receipt. Any inserted, deleted, or modified entry breaks the hash chain at that point — no trusted log server required.

Last reviewed: 2026-05-27
Feedback