Logs were designed for debugging, not for proof. A log entry tells you what the application claims happened. It does not tell you whether that claim is trustworthy. For regulated environments under the EU AI Act, "the log says so" is hearsay, not evidence.
What logs actually give you
{
"timestamp": "2026-02-13T10:30:00Z",
"agent_id": "agent_trading_bot_01",
"action": "transfer",
"parameters": {"amount": 10000, "currency": "EUR", "destination": "acct_789"},
"result": "success"
}This records WHAT happened. It does not prove WHO authorized it (the agent_id is just a string). It does not prove the record is UNMODIFIED. It does not prove the action was AUTHORIZED by policy.
The three properties auditors need
1. Identity binding
The audit record must be cryptographically tied to a specific agent identity via digital signature, not just a string field that anyone could write.
2. Tamper evidence
Any modification to the record after creation must be mathematically detectable. If someone changes the amount, destination, or timestamp, the signature becomes invalid. You do not need to trust the storage system.
3. Policy attestation
The record must include evidence that the action was evaluated against policy before execution, not just logged after. The policy result is part of the signed payload.
| Property | Traditional Log | Signed Record |
|---|---|---|
| Identity | String field | Digital signature tied to key pair |
| Tamper evidence | None | Signature invalidated by any change |
| Policy proof | Separate system (if exists) | Included in signed payload |
| Third-party verifiable | No | Yes (public key) |
How cryptographic signing works
Instead of just logging what happened, you sign what happened. The agent serializes the action, evaluates it against policy, signs the payload with its private key, then executes. The signed record is stored as tamper-evident evidence. Anyone with the public key can verify it later.
The critical detail is order of operations: policy check and signing happen before execution. This is evidence of a decision that was made and authorized before anything happened.
Why long-retention signing matters
AI agent audit trails carry long retention obligations, at least five years under DORA and the system lifetime plus a reasonable period under the EU AI Act. Classical signatures (RSA, ECDSA) can be challenged on that horizon as larger quantum implementations become available. The NSA's CNSA 2.0 guidance mandates a transition for federal systems by 2035. Records signed today need to remain verifiable across that whole window without a forced migration.
ML-DSA (NIST FIPS 204) is the lattice-based signature scheme NIST published in August 2024 after a seven-year evaluation. Building on it from day one removes the migration burden later.
Asqav signs every agent action with ML-DSA-65, creating audit records that are tamper-evident and identity-bound across the whole retention horizon. Check out our documentation or see how we map to specific regulations.