Free checklist · AI audit logging

The AI Audit Logging Checklist

30 checks to make every prompt, response, tool call, and policy decision in your enterprise AI applications reconstructable for auditors, regulators, and incident responders.

No paywall Mapped to SOC 2, HIPAA, GDPR Built for platform, security, and GRC teams
  • Every request names the user and the application behind it
  • Tool calls and MCP invocations are audited with parameters and results
  • Audit logs stay in storage you own, with retention you control
  • Logs stream to your SIEM in near-real-time, with PII redacted

What the checklist covers:

30

Evaluation criteria for audit logging across LLM, agent, and MCP traffic

5

Control areas, from event coverage to access controls and compliance mapping

17

Must-have controls, each flagged so you know what to fix before an audit

4

Regimes mapped: SOC 2, HIPAA §164.312(b), GDPR, and export-control recordkeeping

Inside the checklist

Download the checklist to get:

A working framework your platform, security, and compliance teams can use to evaluate an AI gateway or audit your own AI stack before the auditors arrive.

Download the Checklist

✓

The full 30-point AI audit logging framework

Every criterion grouped by control area, with the question to ask and a must-have or should-have priority.

✓

A three-step rollout plan

Define which events to capture, set retention by compliance regime, and export securely to your SIEM or warehouse.

✓

A compliance evidence map

How audit logs support SOC 2, HIPAA audit controls, GDPR records of processing, and export-control recordkeeping.

✓

A vendor evidence-pack request list

The sample logs, RBAC settings, export configs, and retention settings to ask any AI gateway vendor for during review.

Why it matters

Every AI Request Is Now Audit Evidence

Enterprise AI applications sit between regulated data and external model providers. Every prompt, response, tool call, and policy decision that passes through them is potential evidence for SOC 2, HIPAA, GDPR, ITAR, and internal investigations.

Traditional application logs weren't built for this. They record that an endpoint was hit, not which user's data was sent to which model, which MCP tool an agent called with what parameters, or which guardrail blocked the response. Agents make it harder: a single request can fan out into a dozen non-deterministic steps, and if those steps aren't tied together by one trace, nobody can reconstruct what happened.

Enterprise app user: analyst (SSO) AI agent multi-step workflow AI Gateway logs every request Models + MCP tools providers, servers Your cloud S3 + Delta Lake SIEM · warehouse via OTEL export user identity trace context redact + policy stream audit record One audit record per request who · app · data (redacted) · tool calls · policy hits · cost · versions · trace ID

One request, many hops, one reconstructable record. The checklist defines what that record has to contain and where it should live.

Teams that try to retrofit audit logging onto AI usually hit the same gaps. Logs show a shared API key instead of a user. Payloads are either stored in full, exposing PII to anyone who can read the logs, or not stored at all. Agent steps and tool calls live in separate systems with no shared correlation ID. And the logs sit in a vendor's infrastructure, outside the retention and access policies your auditors expect.

What good AI audit logging looks like

Every request carries the authenticated user, the calling application, and tenant and environment tags. Prompts, responses, tool calls, and agent steps are captured at a level set by data class, with PII redacted at write time. Guardrail hits, budget blocks, and authorization denials are logged with the rule that fired, and every model, prompt, and policy version is stamped so incidents can be reconstructed.

The logs live in object storage you own, with retention and legal holds mapped to your compliance regimes. They stream through OpenTelemetry to your SIEM and data warehouse in near-real-time, and access to them is controlled by role, including scoped, time-bounded access for external auditors.

Logging is centralized at the AI gateway

Instrumenting every application and agent separately leads to inconsistent coverage. Routing LLM, MCP, and agent traffic through an AI gateway gives you one enforcement point where identity, redaction, policy decisions, and trace context are applied the same way for every request.

The AI Audit Logging Checklist turns that standard into 30 criteria you can use to evaluate a gateway or audit your current stack. Download it to find the gaps before your auditors do.

Preview

The five control areas in the AI audit logging checklist

A sample of the criteria in each area. The full checklist includes all 30, with priorities and evaluation questions.

Area 1 · 7 checks

Event coverage

Tool calls and MCP invocations are audited with parameters and results

Guardrail hits, budget blocks, and authorization denials log the rule that fired

+5 more checks

Area 2 · 7 checks

Identity and attribution

The authenticated user or service account is on every request log

Correlation IDs propagate across app, gateway, agent, and provider

+5 more checks

Area 3 · 5 checks

Storage, retention, and ownership

Audit logs can be stored entirely in customer-owned object storage

Retention is configurable per team, app, or data class

+3 more checks

Area 4 · 5 checks

Export and SIEM integration

Traces, metrics, and logs export to OTEL-compatible systems

Logs flow to Splunk, Datadog, Sentinel, or other SIEMs

+3 more checks

Area 5 · 6 checks

Access controls and compliance

Log access is restricted by role: security, ops, audit, developer

PII is redacted from logs at write time

+4 more checks

How to use · 3 steps

Rolling it out

Define events: auth, prompts, responses, tool calls, agent steps, policy decisions, errors

Set retention by regime (SOC 2, HIPAA, GDPR) and investigation needs

Export securely to SIEM or warehouse, with access controls and tamper-evidence

4.7

★★★★★

Gartner Peer Insights

Rated 4.7 on Gartner Peer Insights

Platform teams run TrueFoundry's AI Gateway for LLM, MCP, and agent traffic in production, with OTEL-compliant request logs, traces, and metrics, RBAC-protected log access, and a logging architecture that keeps audit data inside their own cloud.

96%

of reviewers likely to recommend

4.9

ease of deployment and admin

3–4 ms

added gateway latency

AI audit logging checklist FAQ

What is audit logging for AI applications?

Audit logging for AI applications is the practice of recording every prompt, response, tool call, agent step, and policy decision with enough identity, timing, and version context to reconstruct exactly what happened, who acted, what data flowed, and which policies fired. It produces evidence for SOC 2, HIPAA, GDPR, and internal investigations.

What should an AI audit log capture?

At minimum: authentication events, the user and application behind each request, tenant and environment tags, correlation IDs, tool and MCP calls with their parameters and results, guardrail and authorization decisions, configuration changes, and token and cost data. Model, prompt, and policy versions should be stamped on each request so incidents can be reconstructed.

Should prompts and responses be logged in full?

Not always. Capture mode should be configurable by data class and environment: metadata-only, redacted, truncated, or full body. PII should be redacted at write time so investigators can work with logs without being exposed to sensitive data.

How do AI audit logs support SOC 2, HIPAA, and GDPR?

Audit logs provide evidence for SOC 2 monitoring controls, HIPAA audit controls under 45 CFR §164.312(b), and GDPR records of processing. Final compliance depends on scope, configuration, and your own procedures, so logs are one part of the evidence rather than the whole answer.

Can AI audit logs stay inside my own cloud?

Yes. The checklist treats customer-owned storage as a must-have. TrueFoundry's logging architecture writes audit logs to S3 and Delta Lake inside your cloud account rather than vendor infrastructure, with export to SIEMs and data warehouses.

Who should use the AI audit logging checklist?

Platform engineering, security, compliance, and GRC teams evaluating an AI gateway or preparing LLM and agent applications for an audit, a security review, or production in a regulated industry.