Why not have the application sign its own audit records?

The application that produced the AI decision should not be the system that signs the audit record of the decision. In every other regulated industry, the system under audit cannot be the system generating the audit record. If the application holds the key, the application can sign whatever it wants, including a forged record after the fact. The audit value of the signature comes from the key being held outside the application. The signing layer is structurally separate.

What is the verifier's trust model?

The verifier trusts the public key as the anchor. The verifier does not trust the storage, the application, or the operations team that runs the storage. If the public key is correct and the signature verifies against the content, the record is authentic. The public key's authenticity is established through the channel by which the verifier received it: cloud KMS API, PKI certificate chain, or a published key fingerprint with out-of-band verification.

Can signed audit logs satisfy a chain-of-custody requirement in litigation?

Signed records carry the cryptographic properties that support chain-of-custody arguments in civil and regulatory proceedings. The court or regulator typically accepts signed records as authentic evidence when the signing scheme, the key management, and the verification procedure are documented and the verifier can demonstrate the signature is valid. The supporting documentation (the audit architecture description) is part of the evidentiary package.

How long do signed audit records remain verifiable?

The records remain verifiable as long as the signing public keys are retained and the cryptographic scheme is not broken. Public keys are retained for the records' full retention period (typically the longest applicable regulatory minimum, six months to seven years or more). The cryptographic scheme is sound on the timescales relevant to AI compliance. For very long retention horizons (decades), the scheme may need to be migrated, which is handled by re-signing the records under a new scheme and retaining both signatures.

What is the operational overhead of signing every AI audit record?

Ed25519 signing is fast and the overhead is dominated by the network call to the KMS for the signing operation. With local HSMs and batched signing, the overhead per record is in the low milliseconds. With cloud KMS and per-record signing, the overhead is in the tens of milliseconds depending on the region and the KMS API. The signing happens off the critical path of the AI request (the record is committed in parallel with the prompt being forwarded) so the impact on user-perceived latency is bounded.

Signed Audit Logs for AI Requests: Per-Decision Signing and What Regulators Will Accept

A signed audit log is a log where each record carries a cryptographic signature bound to the record's content at the moment of commit. For AI requests, the signature ties the record to the inspection layer that produced it. A verifier with the inspection layer's public key can confirm that the record is authentic and has not been altered. The verification does not require trusting the storage layer, the application that initiated the AI call, or the operations team that runs the storage. The trust anchor is the signing key, and the signing key is held outside the calling application's blast radius. Application-controlled logs that the application can write, modify, and re-write do not have this property. Regulators looking for per-decision evidence under EU AI Act Article 12, Fannie Mae LL-2026-04, HIPAA audit controls, DORA incident records, and NIST AI agent identity framework all expect records carrying integrity properties of this kind.

I want to walk through the signing schemes used for AI audit records, the key management practices that hold up under audit, the verification flow, and the regulatory regimes the architecture serves.

What "signed" means in this context

A digital signature uses asymmetric cryptography. A private key signs. A public key verifies. The signature is mathematically tied to the content being signed and to the private key. Any modification to the content produces a verification failure. Any signature produced without the private key is detectable as inauthentic.

For an AI audit record, the signed content includes the record's payload (identity, role, policy, classification, model, decision, outcome, timestamp), a sequence number, and a hash of the previous record. The signature covers all of these. The verifier checks the signature against the public key and the content.

The signing happens at the inspection layer. The inspection layer holds the signing key in a hardware security module (HSM) or in a cloud KMS that the calling application cannot reach. The application does not have the key and cannot produce a forged record that passes verification.

Signature schemes used in production

Three families of signature schemes are in mainstream use for audit logs.

EdDSA over Ed25519

EdDSA on the Ed25519 curve is fast, has compact signatures (64 bytes), and is broadly implemented. Signing speeds on modern hardware exceed 100,000 signatures per second per core. The scheme is deterministic, which means the same content under the same key produces the same signature, simplifying caching and re-verification. Ed25519 is the default choice for new deployments unless a specific compatibility constraint requires otherwise.

ECDSA over P-256 or P-384

ECDSA on P-256 (secp256r1) is the most broadly supported scheme. Most HSMs, cloud KMS implementations, and verification libraries support it. The signatures are slightly larger than Ed25519 and the signing is slower, but the interoperability is the broadest. P-384 raises the security level for very long retention horizons.

RSA-PSS

RSA-PSS with SHA-256 or SHA-512 is used in environments where RSA infrastructure is established. The signatures are larger and the signing is slower than the elliptic-curve options, but the scheme is widely accepted and supports detached signature workflows that some legacy auditors expect.

For most new AI audit log deployments, Ed25519 is the default. ECDSA P-256 is the alternative when interoperability with existing PKI is needed. RSA-PSS is appropriate when a regulator or auditor specifically requires it.

Key management practices that hold up under audit

The signing key is the trust anchor. The key management has to satisfy four properties.

Hardware-backed key storage

The signing key is generated inside an HSM or a cloud KMS module and never leaves in cleartext. The HSM signs on request from authorized callers. The cloud KMS equivalents (AWS KMS, Google Cloud KMS, Azure Key Vault HSM-backed keys) provide equivalent guarantees with managed operations. The key material is not exportable.

Separation of duties for key administration

Key administration (creation, rotation, retirement) is performed by a small set of administrators under separation of duties. The administrators are distinct from the operators of the inspection layer. The administration actions are logged and the log is itself tamper-evident under a separate trust anchor.

Key rotation on a documented cadence

Keys are rotated periodically. The rotation overlaps so that records signed under the previous key remain verifiable while new records are signed under the new key. Common rotation cadences run from quarterly to annually depending on the risk profile. The rotation is documented and the public keys for all historical periods are retained.

Public key distribution

The public keys are distributed through a trusted channel. Cloud KMS implementations expose the public key through standard APIs. PKI integrations distribute through certificate chains. Auditors receive the public keys through documented procedures that they can verify against the cloud provider's records or the PKI's transparency logs.

The verification flow

The verification flow runs through four steps.

The verifier retrieves the audit record and the integrity material (signature, sequence number, previous-record hash).
The verifier retrieves the public key for the period the record claims to have been signed in.
The verifier reconstructs the signed content (payload plus sequence plus previous-record hash) and checks the signature against the public key.
The verifier optionally walks the hash chain from a known good anchor forward to the record under review, confirming that no records are inserted, deleted, or reordered.

The verifier is independent of the inspection layer. For regulatory acceptance, the verification can be performed by the regulator's tools, by an independent third-party auditor, or by a verification utility the customer runs against the records.

What the regulatory regimes expect

The regimes the signed audit log architecture serves are consistent in what they ask for.

EU AI Act Article 12 expects records that allow the regulator to identify risk situations and reconstruct what happened. The article does not specify a signature scheme. Article 19 sets the minimum record content. The signed audit log architecture produces records that satisfy both with cryptographic integrity that holds up under regulatory dialogue.

Fannie Mae LL-2026-04 expects audit trails that permit reconstruction of AI-assisted decisions and disclosure on demand. The lender has to produce records the GSE will accept. Signed records carry the integrity properties the GSE's review will require.

HIPAA's audit controls under 45 CFR 164.312(b) require mechanisms to record and examine activity in information systems containing ePHI. The implementing guidance is open to cryptographic integrity and the signed audit log architecture meets the requirement when applied to AI calls involving PHI.

DORA expects firms to reconstruct ICT incidents from records that hold up in supervisory dialogue. The supervisor accepts records signed under documented schemes and properly managed keys.

NIST AI agent identity and authorization framework Pillar 3 calls for action lineage records that support post-hoc investigation. Signed records are the canonical implementation that satisfies Pillar 3.

The architectural placement

The signing happens at the inspection layer, which sits at the AI request boundary. The placement is the architectural choice that makes the property work. If the signing happened in the calling application, the application would hold the key and could sign forged records. If the signing happened in storage, the storage layer would hold the key and the integrity would depend on the storage layer's security posture.

Placing the signing at the inspection layer puts the key in the layer that observes every AI request and produces every record. The application never holds the key. The storage never holds the key. The two layers that interact with the records on read and on retrieve do not have the ability to forge records.

DeepInspect

This is the architecture DeepInspect implements for AI request audit logs. DeepInspect sits inline at the AI request boundary and produces per-decision audit records that are signed at commit using Ed25519 (or ECDSA P-256 where customer infrastructure requires it). The signing keys are held in cloud KMS with separation of duties for key administration and rotation on a documented cadence.

For an auditor or regulator, the records are verifiable on demand using the public key. For an internal investigation, the records support reconstruction with cryptographic confidence. For a customer of a SaaS vendor that has to produce records for its own regulator, the signed records satisfy the customer's audit obligation regardless of the SaaS vendor's posture.

If you are building AI infrastructure for a regulated environment and want signed per-decision audit records, book a technical deep dive at deepinspect.ai.