LLM Audit Trails: How to Log Every AI Request for SOC 2

Why Auditors Care About AI Requests

SOC 2 Trust Service Criteria weren't written with LLMs in mind, but they apply directly. Three criteria are most relevant when your product makes AI calls:

• CC7.2 — Monitor system components for anomalies. You must demonstrate that you detect and respond to deviations in system behavior. An AI model being jailbroken, returning unexpected content classifications, or bypassing policy rules is exactly the kind of anomaly CC7.2 exists to catch. Without structured per-request logs, you can't show evidence of monitoring — only that a service is running.
• CC7.3 — Evaluate and communicate security events. When an incident occurs, auditors want to reconstruct the timeline. Which user? What request? What policy ran? What was blocked or allowed? This requires immutable, queryable event records — not application logs that roll over after 30 days.
• CC9.2 — Vendor and partner risk management. Your LLM provider (OpenAI, Anthropic, etc.) is a subprocessor. You must demonstrate oversight of that dependency. Audit trails that capture what you sent and what came back are a core part of that evidence.

Two privacy regulations add their own requirements on top:

• GDPR Article 30 requires a record of processing activities — including automated decision-making. Every LLM call that processes user data or makes a decision about it (classify, redact, allow/block) is a processing activity that must be documented.
• HIPAA §164.312(b) mandates audit controls for systems that handle ePHI. If any user-submitted data could contain health information, your AI pipeline must maintain activity logs sufficient to enable reconstruction of access.

What to Log on Every LLM Request

A compliant audit record for an LLM call has seven categories of fields. Missing any of them creates a gap an auditor will flag.

Three Approaches (Compared Honestly)

There are three ways to build an AI audit trail. The differences come down to completeness, maintenance burden, and how well the output holds up under auditor scrutiny.

Approach 1: Application-Level Logging

The instinctive solution: add a logger.info() call around each LLM invocation. This has three problems that surface immediately in a SOC 2 audit:

• Fragile by design. Any developer can skip the log call. Any exception swallows it. There's no guarantee every request produces a record — and "best effort" is not a control.
• Structurally incomplete. Application logs capture what your code chose to log. Policy decisions, PII detections, content classifications — these require instrumentation that almost no application log contains.
• Not immutable. Most application log pipelines write to mutable stores or have short retention windows. An auditor asking for records from 14 months ago will often find nothing.

Approach 2: Observability Platforms (Datadog, Splunk)

Datadog LLM Observability and Splunk SIEM can capture LLM request traces. They're better than raw application logs — structured, retained, searchable. The problem is they're optimized for engineering operations, not compliance evidence.

• Expensive at scale. Datadog LLM Observability pricing is per-span. At 1M requests/month, you're looking at hundreds of dollars just for the audit layer — before any policy enforcement.
• Not compliance-native. These platforms show you what happened. They don't show you what policy ran, what was detected, or what action was taken. You'd need to build that instrumentation yourself — which brings you back to Approach 1's problems.
• No policy enforcement. Observability tools tell you after the fact that something happened. They can't block a jailbreak or redact PII before it reaches the model. Audit and control are separate, uncoordinated systems.

Approach 3: Proxy-Layer Audit (Recommended)

Route LLM calls through a policy proxy that sits between your application and the LLM provider. The proxy enforces policy on every request and emits a structured audit event as a side effect — not as optional instrumentation, but as a guaranteed outcome of the request path.

This is what SentinelGate does. Every request through the SentinelGate proxy produces an audit event containing all the fields above: policy decision, detections, outcome, timestamps, tenant ID, and model. The audit trail is complete by construction — not by developer discipline.

SentinelGate Audit Event Schema

Here's what a SentinelGate audit event looks like in its structured form:

{
  "event_id":         "evt_01hwx8k3r9f4n2p5q6m7j",
  "request_id":      "req_9c4e2f1a-bd8c-4e12-a19f-3b7d52890ef1",
  "tenant_id":       "usr_tenant_abc123",
  "timestamp_utc":   "2026-04-23T08:14:22.341Z",
  "model":           "gpt-4o",
  "policy_id":       "pol_healthcare_copilot_v3",
  "policy_version":  3,
  "policy_action":   "redact",
  "detections": [
    { "type": "SSN", "count": 1, "rule_id": "r_pii_ssn" },
    { "type": "PHONE_NUMBER", "count": 2, "rule_id": "r_pii_phone" }
  ],
  "upstream_status": 200,
  "latency_ms":      34,
  "ip_address":      "203.0.113.42",
  "prompt_tokens":   312,
  "completion_tokens": 148
}

Each field maps to a specific compliance requirement. The policy_id and policy_version together prove which version of a control was active — auditors ask this when policy changes happen mid-period. The detections array is structured for querying: you can answer "how many SSNs were detected last quarter" in a single SQL aggregate.

Implementation: Routing Through SentinelGate

One base URL change. Your application code doesn't change — no new SDK, no new logger, no instrumentation. Every request that goes through SentinelGate automatically generates a compliant audit record.

# Route to SentinelGate instead of api.openai.com
curl -i https://sentinelgate.polsia.app/v1/chat/completions \
  -H "Authorization: Bearer sg_live_your_key" \
  -H "Content-Type: application/json" \
  -d '{"model":"gpt-4o","messages":[{"role":"user","content":"Hello"}]}'

# Response includes audit headers:
X-SentinelGate-Request-Id: req_9c4e2f1a-bd8c-4e12-a19f-3b7d52890ef1
X-SentinelGate-Policy-Action: allow
X-SentinelGate-Policy-Id: pol_default_v1
X-SentinelGate-Latency-Ms: 28

The response headers give you the audit event ID so your application can correlate its own logs to the SentinelGate audit trail. Store the X-SentinelGate-Request-Id in your application database alongside the operation that triggered the LLM call.

Python: Extracting Audit Events

from openai import OpenAI
import requests

# Point to SentinelGate — no other code changes needed
client = OpenAI(
    api_key="sg_live_your_api_key",
    base_url="https://sentinelgate.polsia.app/v1"
)

# Make the call — audit event is created automatically
response = client.chat.completions.create(
    model="gpt-4o",
    messages=[{"role": "user", "content": user_input}]
)

# Retrieve structured audit events for a time range
def get_audit_events(api_key, since_iso, until_iso):
    headers = {"Authorization": f"Bearer {api_key}"}
    r = requests.get(
        "https://sentinelgate.polsia.app/api/audit",
        headers=headers,
        params={
            "since": since_iso,
            "until": until_iso,
            "limit": 1000
        }
    )
    return r.json()["events"]

# Pull last 90 days for auditor export
events = get_audit_events(
    "sg_live_your_api_key",
    "2026-01-01T00:00:00Z",
    "2026-04-01T00:00:00Z"
)

Node.js: Extracting Audit Events

import OpenAI from 'openai';

// Point to SentinelGate — no other code changes
const client = new OpenAI({
  apiKey: 'sg_live_your_api_key',
  baseURL: 'https://sentinelgate.polsia.app/v1'
});

// Pull audit events for a compliance window
async function getAuditEvents(since, until) {
  const res = await fetch(
    `https://sentinelgate.polsia.app/api/audit?since=${since}&until=${until}&limit=1000`,
    { headers: { 'Authorization': 'Bearer sg_live_your_api_key' } }
  );
  const data = await res.json();
  return data.events;
}

// Generate compliance summary for auditor
async function generateComplianceReport(since, until) {
  const events = await getAuditEvents(since, until);

  const summary = {
    period: { since, until },
    total_requests:   events.length,
    allowed:          events.filter(e => e.policy_action === 'allow').length,
    blocked:          events.filter(e => e.policy_action === 'block').length,
    redacted:         events.filter(e => e.policy_action === 'redact').length,
    pii_detections:   events.filter(e => e.detections.length > 0).length,
    policies_active:  [...new Set(events.map(e => e.policy_id))],
    avg_latency_ms:   Math.round(
      events.reduce((s, e) => s + e.latency_ms, 0) / events.length
    )
  };

  return summary;
}

// Output ready to hand to your auditor
const report = await generateComplianceReport(
  '2026-01-01T00:00:00Z',
  '2026-04-01T00:00:00Z'
);
console.log(JSON.stringify(report, null, 2));

Retention Policies for Compliance

Retention requirements vary by framework. Set your SentinelGate audit retention to the longest period any applicable framework requires:

• SOC 2: No mandated retention period, but auditors typically look back 12 months for a Type II report. Industry practice is 24 months minimum.
• GDPR: Retention must be "no longer than necessary" — but for audit trails documenting compliance decisions, Article 5(2) accountability principle justifies 3 years.
• HIPAA: §164.530(j) requires audit logs to be retained for six years from creation date. Non-negotiable.
• SOC 2 + HIPAA combined: Set to 6 years. Covers everything.

Preparing the Auditor Export

When your SOC 2 auditor requests evidence for the AI monitoring control, you need to provide structured data they can verify — not a screenshot, not a dashboard export, not a CSV of application logs.

The compliance report script above produces a JSON summary. For a Type II audit, supplement it with:

1. Full event log export for the audit period. Use the /api/audit endpoint with pagination (offset + limit=1000) to pull all records.
2. Policy configuration snapshots. Export your active policy at the start and end of the audit period — policy version numbers in the audit events let auditors verify which version ran at any given time.
3. Block/redact event detail. Filter for policy_action: "block" and policy_action: "redact" events and export separately. Auditors assessing CC7.2 monitoring effectiveness focus on anomaly detection — blocked and redacted events are the evidence.
4. PII detection summary. Aggregate by detections[].type for the period. Demonstrates that personal data in AI calls is being identified and handled per your stated controls.

Compliance Mapping: SOC 2 × SentinelGate Audit Features

Here's how SentinelGate's audit trail maps to the specific criteria your auditor will evaluate:

What Auditors Actually Ask

Based on what security teams report from SOC 2 Type II audits covering AI systems, these are the specific questions that come up — and how the SentinelGate audit trail answers each:

• "Show me evidence that AI requests are monitored for anomalies." → Export of blocked and redacted events from the audit period. Filter by policy_action != "allow" and export as CSV or JSON.
• "Which control was active on [specific date]?" → Query audit events for that date and extract policy_id and policy_version. Version numbers prove the exact control configuration.
• "Were any jailbreak attempts detected?" → Filter detections[].type == "JAILBREAK" for the audit period. Count, timestamps, tenant IDs.
• "How do you ensure personal data isn't sent to the LLM unredacted?" → Show PII detection aggregate for the period — SSN, email, phone, credit card counts — plus redaction event records.
• "What is your retention policy for AI audit records?" → SentinelGate's append-only storage with configurable retention. Point to your retention configuration and the immutability guarantee.