SOC 2 and AI: Producing Gateway Evidence for the Trust Services Criteria
A SOC 2 audit tests whether your controls operate, and it wants evidence. AI added a category of access to sensitive data that most control narratives do not describe: model calls under a shared key. This piece maps AI gateway records onto the relevant Trust Services Criteria, so logical access and monitoring controls extend to model traffic and produce the artifacts an auditor samples.
A SOC 2 examination does not ask whether you have a policy. It asks whether a control operated over the period, and it wants evidence an auditor can sample. For years, logical access and monitoring controls covered your databases, applications, and infrastructure, and the evidence existed because those systems logged access. AI opened a category the control narrative usually does not describe: employees and applications sending sensitive data to model APIs, authenticated by a shared key, logged as generic service activity if at all.
I want to walk through how AI gateway records map onto the Trust Services Criteria that matter here, so model traffic sits inside the same access and monitoring controls the rest of your environment already satisfies.
The gap a SOC 2 auditor will eventually find
The common criteria include logical access controls, which expect access to be restricted to authorized users and that access to be recorded, and monitoring controls, which expect activity to be observed and reviewed. When an auditor walks the data flows and reaches "and how do staff and services use models," the honest answer at most organizations is that model calls run under a shared key with no per-user record and no content-level policy.
That is a control gap in the exact areas the criteria enumerate. It does not necessarily fail the report today, because scope and control descriptions vary, but as AI use grows it becomes harder to describe your logical access control accurately while a whole class of access to sensitive data sits outside it. My view is that AI traffic should be inside your access-control scope now, on your terms, rather than added under pressure when an auditor points at it.
Mapping model calls onto the criteria
The mapping is direct once model traffic produces the right record.
For logical access, the control expectation is that access is restricted to authorized identities. An enforcement AI gateway binds a named identity to every model call and applies per-route and per-role policy, which is the restriction the criterion asks for, expressed at the request layer. The per-decision record, naming the identity and the policy applied, is the evidence that the restriction operated.
For monitoring, the expectation is that activity is logged and reviewed. The per-decision records are the activity log for AI access, carrying identity, data classification, and outcome, and they can feed the same review process and tooling you already use for other logs. The artifact an auditor samples is a record that shows who accessed a model, with what data class, under what policy, and when.
For change and data handling considerations, policy versioning matters. Because each record carries the policy version in force at the time of the call, you can show not only that a control operated but which version of it governed a given request across the audit period.
Evidence has to be independent of the system it describes
An auditor discounts evidence the audited system could fabricate. Application-written logs sit in a store the application controls and can be edited or selectively omitted, which weakens them as evidence of the application's own behavior. The gateway record is produced by the enforcement point rather than the calling application and committed before the model responds, so it documents the request independently. That independence is what makes it hold up as evidence rather than as self-attestation, and it is the property I would insist on before calling a log audit-grade.
DeepInspect
DeepInspect produces the AI access evidence a SOC 2 examination samples. It runs as a stateless proxy between your applications, staff, agents, and any LLM, binds a named identity to each model call, applies per-route and per-role policy with detection and redaction of sensitive data in the prompt, and writes a tamper-evident per-decision record holding identity, role, policy version, data classification, outcome, and timestamp.
Those records extend your logical access and monitoring controls to model traffic and give an auditor artifacts to sample, produced independently of the applications they document. DeepInspect does not run your SOC 2 program or replace your control framework; it closes the AI access gap inside it. To map your model traffic onto your Trust Services Criteria, book a compliance mapping session.
Frequently asked questions
- Does SOC 2 have AI-specific criteria?
The Trust Services Criteria are written around security, availability, processing integrity, confidentiality, and privacy rather than around specific technologies, so there is no separate AI criterion to satisfy. AI traffic is evaluated under the existing common criteria, particularly logical access and monitoring. The work is not meeting a new AI clause; it is making sure your model calls fall inside the access and monitoring controls you already describe and test, with evidence to match.
- What evidence does an auditor actually want for AI access?
Records that show access to models was restricted to authorized identities and monitored over the period. Concretely, that is a sample of per-decision entries naming the identity behind each call, the data classification of the request, the policy applied, and the timestamp, plus the policy definitions themselves and evidence that logs were reviewed. The point is to demonstrate the control operated repeatedly across the audit window, which is why per-decision records beat a general statement that AI use is governed.
- How does this fit a control we already have for logical access?
It extends the same control to a surface it probably does not mention yet. If your logical access control restricts and logs access to sensitive systems, model APIs carrying sensitive data belong in that scope. Routing model traffic through an enforcement point that binds identity and records each call lets you describe AI access under the existing control rather than writing a separate one, and the records slot into the same evidence collection your auditor already expects.
- Is a shared API key a SOC 2 problem by itself?
A shared key is not automatically a finding, but it undermines the logical access control when it means access cannot be attributed to individual identities. If your control says access is restricted to authorized users and recorded, a shared key that makes every caller indistinguishable is in tension with that description. Putting a per-request enforcement point in front of the key restores attribution without forcing every application to hold its own provider credential.
- Can these records feed our existing SIEM and review workflow?
Yes. The per-decision records generated at the AI request layer can be forwarded to your SIEM and folded into the same monitoring and review process you run for other logs. Because they are produced with identity, policy, and data classification already attached, they arrive richer than a network-level view of the same traffic, which makes both your monitoring and your SOC 2 evidence draw from one consistent source for AI access.