AI agents and SOC 2: the audit trail your auditor is about to ask for
Shadow AI feeding customer data into unvetted vendors is now a recurring SOC 2 finding. Here is what auditors are asking about model use, prompt logs, and third-party LLMs — and the minimum that passes.
A year ago, AI came up in a SOC 2 engagement as a curiosity. This year it comes up in the opening meeting, and it comes up as a scoping question: which systems, which vendors, and which data. The most common question compliance teams are asking each other right now is “how do we prove what an AI agent did?” That is exactly the right question, because it is the one the auditor is going to ask.
Why this became a finding category
Two things happened at once. Engineering teams started wiring language models and agents into products and internal tools — customer support, code review, document processing, data pipelines. And employees started pasting customer data into whatever assistant was open in another tab. Both create the same control problem: data leaving your environment to a subprocessor that was never assessed, with no record of what was sent or what came back.
Under SOC 2, that touches confidentiality, privacy (if in scope), vendor management, logical access, and change management all at once. It isn’t a new criterion. It is an old set of criteria applied to a new class of system.
What auditors are asking now
In recent engagements the questions cluster into four groups.
1. Inventory and classification. Which AI models and agents are in use — vendor-hosted and self-hosted, in the product and internally? For each: what data does it receive, who owns it, and what business process depends on it? If the answer is a shrug, that is the finding. Shadow AI is, at root, an incomplete asset inventory.
2. Vendor risk for every third-party model. Each hosted LLM provider is a subprocessor. Auditors expect the same due diligence you would apply to any vendor touching customer data: their SOC 2 report, data-retention and training-use terms, region, breach notification, and whether the contract actually prohibits training on your data. “It’s a big company” is not a vendor assessment.
3. Logging and traceability. For agents that take actions — sending an email, changing a record, running a query — auditors want to see who or what initiated the action, what input it acted on, what it did, and when. Prompt and inference logs, with sensitive fields redacted, retained for a defined period, protected from alteration. If an agent can modify data that feeds a control, its actions are in scope the same way a user’s are.
4. Change management and model lineage. Which model version is in production, who approved the change, and was it tested? A model swap is a production change. A prompt template that governs an agent’s behavior is configuration. Both need the same trail as code.
The minimum that passes
You do not need an AI governance program with a steering committee to get through a SOC 2 audit. You need the controls you already have, extended to cover the new systems.
| Control you already have | Extension for AI |
|---|---|
| Asset inventory | Add every model, agent, and AI vendor, with data classification and an owner |
| Vendor management | Assess each LLM provider as a subprocessor; retain the SOC 2 report and the data-use terms |
| Acceptable-use policy | State plainly what data may and may not go into external AI tools; train on it; make a sanctioned tool available |
| Logical access | Agents get their own identities and least-privilege credentials — no shared API keys, no standing admin rights |
| Logging and monitoring | Log agent actions and model calls; redact; retain; restrict who can alter logs |
| Change management | Model versions and prompt templates go through the same approval and testing trail as code |
| Incident response | Add “data sent to an unapproved AI tool” as an incident category with a defined response |
The shadow-AI problem specifically
The finding I see most often is not a sophisticated one. It is a support rep pasting a customer’s ticket — name, account details, sometimes payment information — into a consumer chatbot to draft a reply. No malice, no policy, no log.
Three things fix it, in order of effectiveness:
- Give people a sanctioned tool. A contracted enterprise assistant with data-use terms you have reviewed. Prohibition without an alternative fails every time.
- Say what the rule is, in writing, and train on it. One paragraph in the acceptable-use policy and ten minutes in security training.
- Watch the network. Block or flag unapproved AI endpoints from managed devices. Not perfect, but it turns an unknowable problem into a monitored one.
What to tell your auditor before they ask
Put a one-page AI inventory in the audit package: the models and agents in use, the vendors, the data each touches, the owner, and which of the controls above covers it. Auditors do not expect perfection here; the field is moving quickly. They expect to see that you know what you have and that it sits inside the control environment rather than outside it. That is the difference between a conversation and a finding.