SOX AI Compliance Checklist for Authenticated LLM Traffic

The close binder shows a journal-entry population on the left and an AI-generated reconciliation narrative on the right, but the model-call identity is blank. That blank field decides everything. Any public company workflow where an AI system can initiate, transform, approve or summarize a transaction, or supply evidence for one that reaches financial reporting, needs a usable control record, and that single screen shows whether it has one. The SEC Section 404 final rule sets the programme obligation, while PCAOB AS 2201 supplies the control or assessment method. A sox AI compliance checklist should connect those requirements to the authenticated HTTP request before the payload reaches an LLM.

A polished AI reconciliation with no retained decision record is weaker evidence than the ugly spreadsheet it replaced.

TL;DR

• Scope every AI route that touches regulated data or financial reporting, and record the calling application, the identity, the model destination and the bypass paths.
• Test authorization and information-flow policy with real requests, not configuration screenshots, and test event content and record integrity the same way. Then verify historical retrieval and exception handling.
• State the boundary. A gateway covers authenticated HTTP model traffic, while existing owners retain Section 404 assessment and materiality, accounting judgment and auditor independence, financial statement assertions and remediation.
• Retain the policy version and decision beside each event so a reviewer can reproduce it.

Check 1: freeze scope and ownership

Owner: the programme lead with the system owner.

Pass condition: the inventory names every application and agent that can send in-scope information to an LLM. Each row identifies the business purpose, the authenticated principal type, the model endpoint, the data class, the provider account, the network route, the control owner and any known bypass. The scope decision cites SEC Section 404 final rule and records the rationale for inclusion or exclusion.

Evidence: approved inventory and route diagram, a sample request, the endpoint list, the provider contract reference and a dated sign-off. The diagram should show the application, the inspection point, the model endpoint and the audit store as separate boxes. This is where an opaque vendor feature gets marked as opaque rather than quietly counted as covered.

Check 2: test identity and request authorization

Owner: IAM with the AI platform owner.

Pass condition: an authorized user can reach the approved model route. An unauthorized role is denied, and a request with missing or expired identity context fails closed. The event must preserve the originating person or workload rather than only the shared provider credential. SEC Sarbanes-Oxley spotlight provides the wider risk and control context for that test.

Evidence: identity schema, role mapping, the policy version, three staged request results, and timestamps with correlation identifiers joining upstream authentication to the outbound model call. The AI agent identity guide explains why a service account alone leaves a weak attribution trail.

Check 3: enforce the information boundary

Owner: the regulated data owner with security engineering.

Pass condition: the route blocks or redacts a staged sensitive field sent to a disallowed model endpoint, and records a permitted equivalent on an approved route. Use synthetic content. Name the expected outcome before execution. The selected controls cover access authorization, change approval, segregation of duties, completeness of populations, evidence retention and exception review, each with control-owner sign-off.

Evidence: classification rule, route allowlist, the permit event, the denial or redaction event, the reviewer and the exception ticket. A control description without its failed test belongs in design documentation, not in a completed checklist.

Check 4: prove the record is complete and protected

Owner: security operations with internal audit or compliance testing.

Pass condition: every staged permit, redact, deny and processing error appears in one frozen population. Each row carries the supplied identity, the timestamp, the calling application, the model destination, the data classification, the policy version, the action and the response disposition. A stable event identifier completes the row.

Evidence: population manifest, record schema, protected-store permissions, integrity-test output and the query used to reproduce the export. The tamper-evident audit log guide covers the custody mechanics behind this check.

Check 5: test retrieval and exception handling

Owner: records management with the incident or audit lead.

Pass condition: a reviewer selects an event from the oldest available period, and the team returns the original row with its integrity result, the linked policy and the exception disposition. A second exercise traces an unapproved destination attempt through triage and closure.

Evidence: the timed retrieval result, the archive restoration step if one exists, the exception register, investigation notes and the closure approval. The LLM audit log retention guide separates configured retention from evidence that old records can actually be recovered.

Check 6: record boundaries and compensating controls

Owner: the system owner with enterprise architecture.

Pass condition: the file lists direct browser traffic, local model execution, unmanaged devices and compromised sessions, with vendor-embedded inference that never crosses the governed route listed separately. Each excluded path has a named compensating control and owner.

Evidence: boundary register, endpoint and network control references, vendor assurance evidence and a residual-risk approval. Management's section 404 assessment and materiality stay outside the request gateway's control, and so do accounting judgment, auditor independence, financial statement assertions and remediation ownership. Marking those limits makes the checklist defensible.

DeepInspect

DeepInspect operates between authenticated users or agents and HTTP-based LLM endpoints. For routed traffic it evaluates the identity and policy context supplied by the application, classifies the request, applies a permit or redact decision or denies the request, inspects the response and writes a per-decision record.

That record supports the checklist's authorization, information-flow, population, integrity and retrieval tests. It cannot govern calls that bypass the route, create upstream identity, or perform management's Section 404 assessment or materiality. Accounting judgment, auditor independence, financial statement assertions and remediation ownership stay outside its role. Book a technical deep dive at deepinspect.ai.