Key Takeaways
SOC 2 has no separate rules for AI agents. Auditors apply the same AICPA Trust Services Criteria to them, and in 2026 they are reported to probe three things: what data is minimised before it reaches a model, how model context is audited, and how sensitive data is redacted in tool calls. Governed identities and logs answer most of it.
- Criteria: the 2017 Trust Services Criteria with revised points of focus (2022) still apply. Nothing AI-specific has been added.
- What changed: the examination. Agents, model vendors and service accounts now get questioned under access, change and vendor criteria.
- Biggest gap: agents running on shared or personal credentials, with no log that ties a tool call to a person.
- Effort: an agent inventory and evidence mapping takes weeks, not quarters, if the data platform already logs access.
The first thing to know is what has not changed. The AICPA’s current criteria document is the 2017 Trust Services Criteria (With Revised Points of Focus, 2022), covering security, availability, processing integrity, confidentiality and privacy. It contains no AI-specific criteria. Any vendor selling you a “new SOC 2 AI standard” is selling something the AICPA has not written.
The second thing is that auditors have moved anyway. Accounting firm Aprio put it plainly in a September 2026 analysis: the criteria did not change, but the examination did. It maps AI expectations onto the existing common criteria, from AI use policies under CC1 and CC2 through model change control under CC8 and model-provider terms under CC9.
For a mid-market company selling software or services, that creates a practical problem. Your customers’ security questionnaires now ask about your agents, and your auditor will ask how you know what those agents did. If agent activity is scattered across a model provider’s console, an app log and a data warehouse with no shared identity, you cannot answer either question with evidence.
Did the AICPA Change the Trust Services Criteria for AI?
No. As of October 2026 the operative document is still the 2017 criteria with the 2022 revised points of focus. The 2022 revision updated guidance, not the criteria themselves. SOC 2 is criteria-based, so it was always meant to cover any system that processes customer data, and an agent is a system that processes customer data.
That matters for scoping. If an agent touches in-scope data or runs inside your in-scope system, it is in scope. You do not get a pass because the component is new, and you do not need a special framework to bring it in. You need to show that the same controls you claim for people and services also hold for agents.
How Do the Existing Criteria Apply to an Agent?
The table maps the common criteria an auditor is most likely to test against agent systems, the question you should expect, and the lakehouse evidence that answers it. Criterion groupings follow the AICPA document; the agent questions reflect the Aprio analysis and our own reviews.
| Criterion | What the auditor asks about agents | Lakehouse evidence that answers it |
|---|---|---|
| CC1, CC2 Control environment and communication | Is there an AI use policy, and were people trained on it? | Published policy, training records, a named owner per agent |
| CC3 Risk assessment | Are agent-specific threats named, or folded into generic IT risk? | A risk register with rows for prompt injection, tool misuse and data leakage |
| CC6 Logical access | Which identity does each agent use, and what can it reach? | One service principal per agent, Unity Catalog grant listings, quarterly access review |
| CC7 System operations | How do you detect an agent behaving abnormally, and respond? | Usage baselines, alerts on departures, incident playbooks with agent scenarios |
| CC8 Change management | How are model and prompt changes approved and tracked? | Model registry versions, deployment approvals, versioned prompts in source control |
| CC9 Risk mitigation and vendors | What do your model providers retain, and under what terms? | Provider data terms on file, subservice organisation decisions documented |
| Confidentiality and Privacy categories | Is sensitive data kept out of prompts and tool outputs? | Column masks, governed tags, gateway guardrail policies and their block logs |
What Are Auditors Reported to Probe in 2026?
A 2026 SOC 2 guide from Strac reports that auditors increasingly ask three questions about AI controls. Each one maps to a specific build on the data platform.
How is data minimised before it reaches the model? The honest answer for most teams is that the agent reads whatever its credential can read. The better answer is that the agent queries a curated gold view that exposes only the columns the task needs, with masks on anything sensitive. On a lakehouse, that is a view plus attribute-based policies on governed tags, and the grant listing proves it.
How is the model context audited? The auditor wants to know what went into a prompt: the retrieved documents, the rows, the system instructions. Logging requests and responses to governed tables gives you that record. The Databricks gateway documentation describes inference table logging of requests and responses to Unity Catalog Delta tables, which puts context records next to the data they came from.
How is sensitive data redacted in tool calls? Tool calls are where an agent writes to a ticket, sends a message or calls an API. Redaction belongs in a policy layer that inspects calls before they leave, with every block recorded. A guardrail that nobody logs is a control you cannot evidence.
Where Do Agent Systems Fail a SOC 2 Walkthrough?
These five problems compound. Each one makes the next harder to see, so fix them in this order.
- Agents run on someone’s personal token. The access review covers people, so the agent is invisible to it. Every log entry names an employee who never made the call.
- Several agents share one service account. Even with a non-human identity, you cannot attribute an action to a specific agent, so CC6 and CC7 evidence collapses into one undifferentiated line.
- Agents read raw tables. Minimisation is impossible to demonstrate when the credential can see the whole silver layer, PII columns included.
- Prompts and models change without a ticket. A prompt edit can change what an agent does as much as a code release. If it skips change management, CC8 has a hole that an auditor can find in one sample.
- Logs live in three places on three clocks. Model calls sit with the provider, tool calls in an application log, data reads in the platform audit. Reconstructing one agent run takes days, which tells the auditor your detection and response control exists on paper only.
The pattern behind all five is the same one I see in process work: the agent was automated before the process around it was defined. Assess first, then automate.
What Evidence Does a Governed Lakehouse Already Produce?
More than most teams expect. If your platform runs Unity Catalog with per-agent service principals, three evidence streams already exist. Grant listings show what each identity can reach. Lineage shows which tables fed which outputs. Audit records show who read what and when.
Two cautions keep that evidence honest. First, on Databricks the audit log system table, system.access.audit, is labelled Public Preview in current docs, with a default 365-day retention. Describe it accurately to your auditor, and keep your own retained copy if your observation period needs it. Our guide to audit log retention covers how to size and protect that copy. Second, evidence only counts if it is complete. A gateway that governs half your agent traffic produces evidence about half your agents.
The agent-specific threats deserve their own register rows. The OWASP GenAI Security Project published the Top 10 for Agentic Applications on 9 December 2025, and it makes a sound starting list for CC3. We map each of those risks to a data control in our breakdown of the OWASP Top 10 for Agentic Applications.
What Should Your First 30 Days of Agent Audit Prep Cover?
Thirty days is enough to move from “we have some agents” to an evidence package you can walk an auditor through.
- Days 1 to 5: inventory. List every agent, chatbot, coding assistant and MCP server touching in-scope systems. Record the owner, the identity it runs as, the data it reads and the tools it calls.
- Days 6 to 10: identities. Move each agent onto its own service principal. Retire personal tokens and shared accounts, and record the change.
- Days 11 to 15: narrow access. Point agents at curated gold views, apply masks to sensitive columns, and export the grant listing as your CC6 evidence.
- Days 16 to 20: logging. Route model and tool calls through a governed layer that writes requests, responses and blocks to tables joined on identity and time.
- Days 21 to 25: change and vendors. Put prompts and model versions under change control, and file each model provider’s data retention terms.
- Days 26 to 30: dry run. Pick one agent and replay one day of its activity from prompt to table read. If that takes more than an hour, fix the gap before the auditor finds it.
If you would rather have the identities, policies and evidence tables built than written up, our lakehouse security team designs and implements them on the platform you already run. This is general information, not audit or legal advice; your CPA firm makes the call on scope and on whether your controls meet the criteria.
Frequently Asked Questions (FAQs)
Does SOC 2 have specific criteria for AI agents?
No. The AICPA has not published AI-specific Trust Services Criteria. Auditors apply the existing 2017 criteria, with the 2022 revised points of focus, to any system that processes customer data, and that includes agents and the models they call.
Are AI agents in scope for a SOC 2 audit?
If an agent runs inside your in-scope system or touches in-scope data, it is in scope. The auditor will test it under the same access, operations, change and vendor criteria as any other component.
What evidence do auditors want for agent access?
Expect requests for an inventory of agents and their identities, a listing of what each identity can reach, and a recent access review. One service principal per agent makes all three straightforward to produce.
Do model providers count as subservice organisations?
It depends on what they do with your data and how your system description treats them, which is a scoping call for your auditor. Either way, keep their data processing and retention terms on file under your vendor management controls.
Can a lakehouse make us SOC 2 compliant?
No platform makes you compliant. A governed lakehouse produces evidence: grant listings, lineage, access records and call logs tied to identities. Your controls, your policies and your auditor’s testing decide the outcome.