SOX AI Controls Mapping for the Authenticated LLM Path

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 single screen determines if a public company workflow where an AI system can initiate or transform a transaction and can later approve or summarize it or provide evidence for it when it reaches financial reporting has a usable control record. The SEC Section 404 final rule sets the programme obligation, while PCAOB AS 2201 supplies the control or assessment method. A sox AI controls mapping 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 can touch regulated data or a financially relevant workflow, including the calling application and bypass paths alongside the supplied identity and model destination.
• Test authorization and information-flow policy with requests. Test event content, record integrity, historical retrieval, and exception handling rather than relying on screenshots of configuration pages.
• Keep the boundary explicit. A gateway contributes to authenticated HTTP model traffic; management's Section 404 assessment and materiality, accounting judgment and auditor independence, plus financial statement assertions and remediation ownership remain with their owners.
• Retain the policy version and decision beside the event so a reviewer can reproduce what happened at that time.

Use six fields for every mapping row

Each row needs a requirement and control point, an owner and repeatable test, plus retained evidence and a boundary statement. SEC Section 404 final rule supplies the programme requirement. PCAOB AS 2201 provides the related control language, and SEC Sarbanes-Oxley spotlight supports the assessment or risk method.

The useful rows point to mechanisms rather than products. They say where the decision occurs and what input is needed, then state the expected result and artifact retained. The zero trust for AI guide takes the same approach to identity and policy controls and their audit records.

Identity and access enforcement

Requirement: identify the originating user or workload and restrict each transaction to authorized roles and purposes.

Control point: the identity provider and calling application supply identity context; the inline request point validates it and evaluates policy.

Owner: IAM with the application owner.

Test: run an authorized role and an unauthorized role against the same model route. Then run an expired assertion and confirm the expected result before the payload leaves the enterprise boundary.

Evidence: authentication event and assertion schema; role mapping and policy version; correlation identifier; permit and denial events.

Boundary: proofing and account lifecycle stay upstream. Session compromise and role design also stay upstream. The enforcement point evaluates what the application supplies.

Information flow toward the model

Requirement: govern in-scope information moving to external services and prevent unapproved destinations or data classes.

Control point: request classification and route allowlist before the LLM endpoint, backed by the policy engine.

Owner: the data owner with security engineering.

Test: send synthetic regulated content toward approved and unapproved destinations. Confirm whether policy permits or redacts the content or denies the request, and capture each event.

Evidence: classifier version and route policy; allowlist and test payload description; event identifiers and reviewer; result.

Boundary: unmanaged devices and local models need endpoint or network controls. Direct provider sessions need those controls too. A request gateway sees only traffic that traverses it.

Audit record content and review

Requirement: record events with enough content to support monitoring and assessment as well as investigation and accountability. The applicable set includes access authorization and change approval; segregation of duties and completeness of populations; evidence retention and exception review; control-owner sign-off.

Control point: the per-decision record writer and protected store.

Owner: security operations with the audit owner.

Test: freeze a population for a named UTC window and select a denial. Trace it to the originating principal and policy. Reproduce the query, then alter a copied row and confirm the integrity check fails.

Evidence: manifest and sample row; query and policy snapshot; integrity output and storage permissions; review sign-off.

Boundary: business outcomes and downstream application actions require correlated application records. The tamper-evident audit log guide describes the separate write path.

Change and exception control

Requirement: approve policy changes and limit emergency access. Preserve evidence of exceptions.

Control point: the policy repository and deployment pipeline. Each event carries the runtime rule version.

Owner: AI platform engineering with the control owner.

Test: trace one rule from its ticket and approval through deployment and staged test, then to production events and the rollback record. Repeat for a time-limited exception and confirm expiry.

Evidence: ticket and review; policy diff and deployment timestamp; test result and event sample; expiry and closure sign-off.

Boundary: the gateway records its own policy state. Wider system changes and accounting judgments live in other systems. Organizational approvals live there too.

Incident and assessment support

Requirement: make evidence available for control assessment and incident analysis.

Control point: saved queries and exports from the protected event store, joined to identity and application records.

Owner: the incident lead or assessor with security operations.

Test: produce all events for one principal and one destination, then for one policy version and one sensitive classification in a named window. Time the exercise and record missing joins.

Evidence: query catalogue and drill output; elapsed time and gap register; owners and retest result. The map should show the missing joins in red. Hiding them turns a useful control document into sales material.

Programme obligations outside the request path

Management's section 404 assessment and materiality, accounting judgment and auditor independence, plus financial statement assertions and remediation ownership sit outside the routed LLM transaction. Assign those obligations to the controller and internal audit lead; the financial systems owner and IAM lead; and the AI platform owner, then link their own procedures and evidence. Direct browser traffic and local inference also need explicit compensating controls. So do stolen credentials, unmanaged devices, and opaque vendor inference.

DeepInspect

DeepInspect operates at the authenticated HTTP boundary between users or agents and LLM endpoints. In this mapping it evaluates supplied identity and data context, enforces destination and information-flow policy, inspects responses, and writes per-decision records tied to the policy version that ran.

The organization still owns routing and identity proofing, endpoints and programme judgment, plus management's Section 404 assessment and materiality, accounting judgment and auditor independence, and financial statement assertions and remediation ownership. Book a technical deep dive at deepinspect.ai.