AI Governance Audit Trail: Cryptographic Decision Certificates for Regulatory Compliance

Regulators examining AI systems in financial services, healthcare, and insurance increasingly demand more than log files. They want to know that every AI decision was governed at the time it was made, that the governance policy in force is documented, and that the record cannot be altered retroactively. Conventional application logs fail all three tests. This document explains why, and how CoreGuard's HMAC-SHA256 signed AI decision certificates provide a tamper-evident, independently verifiable AI governance audit trail that satisfies examiner requests under SR 11-7, the EU AI Act, and HIPAA. For integration instructions, see the CoreGuard Integration Guide.

1. Why Paper-Based Audit Logs Fail

When a bank examiner or healthcare auditor asks "show me how your AI made this decision," the instinctive answer is to pull a log file. In practice, log-based AI audit trails fail for four structural reasons:

Mutability Without Detection

Flat log files — whether stored on a filesystem, in an S3 bucket, or in a logging platform like Splunk or Datadog — are mutable by any party with write access. A log record can be edited, deleted, or backdated with no forensic trace, unless the logging infrastructure itself maintains a separate integrity layer. Most logging infrastructures do not. An auditor cannot distinguish between an authentic log and a reconstructed one.

Logging Is Voluntary

Standard application logging is written by developers, not by the governance layer. A developer decides which events to log, at what level, and with what fields. The log entry for a decision records what the developer chose to capture — not necessarily the complete set of facts the governance system evaluated. Governance policies can change between decisions with no record in the log. This is not an audit trail; it is a narrative selected by the party being audited.

No Proof of Enforcement

A log entry that says "decision: ALLOWED" proves only that the string was written. It does not prove the governance policy was evaluated before the AI system acted, that the evaluation result was enforced, or that the policy version stated in the log was the version actually applied. In regulated industries, the difference between a decision that was governed and a decision that was logged as governed is the difference between compliance and a violation.

Non-Portability Across Systems

Log files are in proprietary formats specific to the logging platform. A regulator who receives a Splunk log export cannot verify it without access to the Splunk infrastructure that produced it. A cryptographic certificate is a self-contained JSON object that can be verified by anyone who holds the published verification key — no access to the issuing system required.

2. How HMAC-SHA256 Signed Certificates Work

HMAC (Hash-based Message Authentication Code) with SHA-256 provides a cryptographic guarantee that a data record has not been altered since it was signed, and that it was signed by a party holding a specific secret key.

The process CoreGuard uses for each decision:

1. Evaluate — the governance engine evaluates the proposed action against the active policy set and produces a decision object containing all material facts
2. Canonicalize — the decision object is serialized to a canonical byte string (RFC 8785 JSON Canonicalization Scheme: fields sorted alphabetically, no whitespace, Unicode-normalized) so that byte-identical input always produces byte-identical output
3. Sign — HMAC-SHA256(canonical_bytes, signing_key) is computed; the resulting 256-bit digest is hex-encoded and embedded in the certificate as hmac_signature
4. Chain — the previous_certificate_hash field contains the SHA-256 hash of the immediately preceding certificate, creating a hash chain analogous to a blockchain. Any gap or reordering in the chain is detectable
5. Persist — the signed certificate is written to immutable storage before any response is returned to the caller

3. Anatomy of a CoreGuard Decision Certificate

Every CoreGuard decision produces a complete certificate. Below is an annotated example for a loan approval decision:

{
  // ── Identity ──────────────────────────────────────────────────────
  "certificate_id":    "cert_01HX9KQZP8JVNW4T3MRBCF0YE",   // ULID — globally unique, time-ordered
  "request_id":        "req_01HX9KQZP8JVNW4T3MQA9B2CD",
  "organization_id":   "org_abc123",
  "environment":       "production",

  // ── Timing ────────────────────────────────────────────────────────
  "evaluated_at_utc":  "2026-05-05T14:32:17.841Z",             // RFC 3339 with millisecond precision
  "evaluation_latency_us": 312,                                  // microseconds

  // ── Policy ────────────────────────────────────────────────────────
  "policy_set":        "lending_v1",
  "policy_version":    "1.4.2",                                  // semver — pinned at evaluation time
  "policy_hash":       "sha256:a3f8c2...",                        // SHA-256 of the policy pack bytes

  // ── Input ─────────────────────────────────────────────────────────
  "action_type":       "loan_approval",
  "user_id":           "u_7f3a9b",                               // hashed — no PII in certificate
  "action_hash":       "sha256:8b1d4e...",                        // SHA-256 of the full action payload
  "context_hash":      "sha256:2c9f71...",                        // SHA-256 of the context payload

  // ── Decision ──────────────────────────────────────────────────────
  "status":            "ALLOWED",                                 // ALLOWED | BLOCKED | MODIFIED
  "risk_level":        "LOW",                                     // LOW | MEDIUM | HIGH
  "violations":        [],                                         // empty for ALLOWED decisions
  "modifications":     null,                                       // populated for MODIFIED decisions only
  "rules_evaluated":   14,
  "rules_triggered":   0,

  // ── Chain of Custody ──────────────────────────────────────────────
  "sequence_number":        1047823,                             // monotonically increasing per org
  "previous_certificate_hash": "sha256:f2a01b...",               // links to prior cert — hash chain

  // ── Cryptographic Proof ───────────────────────────────────────────
  "canonical_payload_hash": "sha256:7e3d9c...",                   // SHA-256 of the JCS-serialized record above
  "hmac_signature":         "3a8f2c1b9e4d...",                   // HMAC-SHA256(canonical_payload, signing_key)
  "signing_key_id":         "cg-sign-v3"                         // identifies the key version used
}

Key design choices to note:

• No PII in the certificate body — user identity is represented as a hashed user ID; the action and context payloads are stored separately and referenced by hash. This means the certificate can be shared with regulators without disclosing personal data, while still allowing the original payload to be retrieved and matched against the certificate for verification.
• Policy version is pinned at evaluation time — the policy_version and policy_hash fields record exactly which policy was active when the decision was made. A policy update the next day does not retroactively change any certificate.
• The hash chain is per-organization — sequence_number and previous_certificate_hash form a hash chain within your organization's certificate stream. Any deletion or insertion of certificates breaks the chain and is immediately detectable.
• ULID identifiers are time-ordered — certificate IDs use the ULID (Universally Unique Lexicographically Sortable Identifier) format. This allows certificates to be sorted by creation time using standard lexicographic ordering, without requiring a separate timestamp index.

4. Chain of Custody for AI Decisions

Regulatory frameworks like SR 11-7 require that financial institutions maintain a complete and accurate model governance trail covering development, validation, and ongoing monitoring. For AI systems making real-time decisions, the audit trail must capture each individual decision, not just aggregate statistics.

CoreGuard implements chain of custody through three complementary mechanisms:

Hash Chain (Per-Certificate Integrity)

Each certificate's previous_certificate_hash field contains the SHA-256 hash of the immediately preceding certificate in the organization's stream. This creates a linked list of certificates where any modification to a past certificate invalidates all subsequent hashes. The chain can be verified independently using the published verification key and does not require access to the CoreGuard API.

Sequence Continuity (Gap Detection)

The monotonically increasing sequence_number field allows auditors to detect deleted certificates: a gap in sequence numbers (e.g., jumping from 1047823 to 1047826) indicates that certificates 1047824 and 1047825 were removed from the stream. This detection works even if the hash chain is re-forged from the gap point.

Policy Version Pinning (Retroactive Change Prevention)

The policy_version and policy_hash fields lock each certificate to the exact policy pack that was active at evaluation time. Policy updates are recorded as new versions, not as modifications to existing policies. An auditor can retrieve the exact policy pack that produced any certificate using GET /v1/policy-sets/{policy_set}/{policy_version}.

5. Presenting Certificates to Regulators

When a regulator, examiner, or internal audit team requests evidence of AI governance decisions, CoreGuard supports three delivery modes:

Online Verification via EVE Proof

The EVE Proof portal at https://eveaicore.com/proof allows any party to submit a certificate and receive a real-time verification result with a signed attestation. This is the lowest-friction path for individual certificate queries from examiners who want to spot-check a sample of decisions during an examination.

Offline Verification via Published Key

EVE Core publishes the CoreGuard verification key at a well-known URL (https://eveaicore.com/.well-known/coreguard-verify-key.json). Any party who downloads this key can verify any CoreGuard certificate offline using the algorithm described in the API Reference — no internet connection to the CoreGuard API is required at verification time. This is the preferred method for bulk production requests where thousands of certificates are being verified.

Bulk Export for Examination Packages

The export API at GET /v1/certificates/export packages all certificates for a specified time window into a signed manifest suitable for regulatory submission:

curl -X GET \
  "https://api.eveaicore.com/v1/certificates/export?from=2026-01-01&to=2026-03-31&format=signed_manifest" \
  -H "Authorization: Bearer $COREGUARD_API_KEY" \
  -o coreguard_q1_2026_export.json

# The export is a JSON manifest containing:
# - metadata: organization_id, export_range, total_certificates, export_generated_at
# - chain_integrity: sequence_start, sequence_end, gaps_detected, chain_valid
# - certificates: [...] array of full certificate objects
# - manifest_signature: HMAC-SHA256 over the entire manifest

6. Integration with SIEM Systems

CoreGuard decision certificates are designed to be first-class citizens in a security information and event management (SIEM) pipeline. Two ingestion paths are available:

Real-Time Webhook Delivery

Configure a webhook endpoint to receive signed JSON events for every decision.evaluated, decision.blocked, and certificate.issued event. Each webhook delivery is signed with HMAC-SHA256 using your COREGUARD_WEBHOOK_SECRET — verify the signature before indexing. See the Integration Guide webhook section for implementation details.

Scheduled Batch Import

For SIEM platforms that prefer pull over push, the export API supports incremental batch retrieval by timestamp or sequence number:

from eve_coreguard import CoreGuardClient
import os, json
from datetime import datetime, timedelta, timezone

client = CoreGuardClient(
    api_key=os.environ["COREGUARD_API_KEY"],
    endpoint=os.environ["COREGUARD_ENDPOINT"],
)

def import_to_siem(last_sequence: int) -> int:
    # Retrieve all certificates after the last-imported sequence number
    page = client.list_certificates(after_sequence=last_sequence, limit=1000)
    for cert in page.certificates:
        siem_client.index_event(
            index="coreguard-decisions",
            event=cert.to_dict(),
            timestamp=cert.evaluated_at_utc,
        )
    return page.last_sequence_number

# Called by your scheduler (cron, Airflow, etc.) every minute
last_seq = state_store.get("coreguard_last_sequence", default=0)
new_last_seq = import_to_siem(last_seq)
state_store.set("coreguard_last_sequence", new_last_seq)

CoreGuard has pre-built connectors available for:

• Splunk — EVE Core Add-on for Splunk (available on Splunkbase); maps certificate fields to CIM fields; includes a prebuilt dashboard for decision volume, block rate, and policy violation trends
• Elastic SIEM — Logstash pipeline configuration and Kibana index template; includes detection rules for certificate chain breaks and anomalous block-rate spikes
• Microsoft Sentinel — ARM template and Logic App connector for webhook ingestion; maps to Sentinel's AI governance data table schema
• Generic SIEM — the JSON certificate schema is fully documented in the API Reference; all fields use standard data types suitable for any log management platform

7. Audit Method Comparison

The following table compares the audit properties of conventional AI logging approaches against CoreGuard cryptographic certificates: