SOC 2 Controls for AI Agents and MCP: What Auditors Test (2026)

If your AI agents can call tools, or you connect an assistant such as Claude or ChatGPT to internal systems or a compliance platform through the Model Context Protocol (MCP), this is what a SOC 2 auditor is likely to test and the evidence to keep. The AICPA has no criteria specific to agents or MCP, so the mapping here is our reading of the existing ones.

Does SOC 2 cover AI agents?

Yes, when the agent is part of the system your report describes. The Trust Services Criteria state outcomes, not technologies. An agent that reads customer data, changes records or runs code in production falls under the same access, monitoring, change and vendor criteria as any other actor in that system. Controls for models, training data and shadow AI (staff using unapproved AI tools), and the choice between SOC 2, SOC 2+ and ISO 42001, are covered in our guide to SOC 2 controls for AI risks.

As of 13 October 2026, the AICPA’s SOC page still lists the 2017 Trust Services Criteria with revised points of focus from 2022, and no exposure draft of revised criteria. The AICPA’s AI-specific SOC publication is Technical Q&A 9561, listed on 11 September 2026, which addresses a service organization’s use of AI in SOC 1 and SOC 2 examinations. The AICPA describes its Technical Q&As as nonauthoritative. For what it means for your scope, see SOC 2 for AI companies and the AICPA’s AI guidance.

Start with scope. An agent inside your product, an agent your engineers use to operate production, and an assistant your compliance lead connects to a GRC platform raise different questions with your auditor. An internal experiment with no access to in-scope systems or customer data can sit outside the boundary, but write down why, and revisit the decision when its access changes.

“SOC 2 for AI agents” is also a common nickname for AIUC-1, a separate certification for agents, covered in the last section.

Which SOC 2 criteria apply to an AI agent with tool access?

Mostly the Common Criteria: CC6.1 to CC6.3 for the agent’s identity and permissions, CC7.2 and CC7.3 for monitoring its actions, CC8.1 for changes to prompts, tools and MCP configuration, CC9.2 (or the subservice-organization rules for model providers) for model and MCP vendors, and CC3 for the risk assessment. Processing Integrity and Confidentiality apply only if they are in your report.

This table is our reading of the 2017 criteria, not an AICPA mapping. It builds on LBMC’s May 2025 table, one of the few CPA-firm mappings to cite criterion numbers, which ties generative-AI risks to CC6.1 to CC6.3, CC6.6, CC6.8, CC8.1, CC9.2 and PI1.1 to PI1.4. It also draws on Schellman’s November 2024 guidance, which names CC6 access controls, CC8.1 and CC9.2 for AI systems. Both were written for generative AI, not for agents that act through tools, so the approval, tool-call and MCP rows extend them. Your auditor may map a control to different criteria, and the control and its evidence matter more than the number.

A system prompt that says “never delete” is an instruction, not an access control. A-LIGN’s May 2026 guidance on governing AI agents draws the same line: an agent should “lack the technical ability” to take an action it is not authorized to take. An auditor tests what the agent’s permissions allow, so remove tools and scopes the agent does not need rather than asking it to avoid them.

For the controls that apply to every SOC 2 system, not only AI, see the controls auditors check first and the full SOC 2 controls list mapped to evidence.

How does an auditor test an AI agent’s controls?

The same way as any other control: pick a population, sample from it and look for evidence that the control worked each time. For an agent, the population is usually its tool calls or its high-risk actions over the period. That makes the log listing them the first thing to get right, because a sample from an incomplete log proves little.

A Type 1 report looks at design on one date: the agent inventory, the permission configuration, the written approval rule, the logging setup and the vendor reviews. A Type 2 report also tests operation across the observation period: sampled approvals, access reviews that include agent identities, change tickets for prompt and tool changes, and alerts that were investigated.

A walkthrough of one agent action often runs backwards from the outcome:

1. Pick a record the agent created, changed or deleted.
2. Find the matching tool call in the log.
3. Check which identity made the call, and for whom.
4. Confirm that identity was granted that permission through the normal access process.
5. If the action needed approval, find the approval and check it came before the action.

A missing step is an exception. With agents, the usual one is an action that no log entry or approval ties to an authorized identity, often because the call came from a client outside the logged path.

Questions to settle with your auditor before fieldwork:

• Which agents and MCP connections sit inside the system boundary, and why the rest are excluded.
• Whether model providers and third-party MCP servers are treated as ordinary vendors or as subservice organizations under the carve-out or inclusive method. A public CPA-firm summary of TQA 9561 says it handles third-party AI providers through that existing framework.
• Which population they will sample for agent actions, and what makes a log acceptable as complete.
• Whether Processing Integrity is in scope for anything the agent produces.
• How they will treat evidence that an AI agent or assistant uploaded or edited in your compliance platform.

If your current firm has not audited agent controls before, compare SOC 2 auditors that work with AI companies and ask each one these questions.

Is an MCP server in scope for your SOC 2?

MCP is a protocol, so it cannot be SOC 2 compliant on its own; a SOC 2 report covers an organization’s system. Whether an MCP server is in scope depends on who runs it and what it can reach. Three cases cover most deployments.

You run an MCP server for your customers. It is part of your product and belongs in your system description. The MCP specification defines an OAuth-based authorization framework, so expect CC6 questions about how clients authenticate and what each token can do, CC8.1 questions about changes to tool definitions, and CC7.2 questions about monitoring calls. OWASP’s guide to secure MCP server development (February 2026) is a practical checklist for the engineering side, though it is not a SOC 2 requirement.

Your product’s agents call third-party MCP servers. Each server is a vendor under CC9.2, and the list of servers your agents may use is an access control under CC6. Keep an allowlist and connect nothing outside it. OWASP’s guide to using third-party MCP servers (November 2025) covers the risks specific to this case, such as poisoned tool descriptions and prompt injection.

Your staff connect an assistant to internal tools or to your compliance platform. This is not automatically in scope; it comes into scope when the assistant reaches in-scope systems or customer data. Mind the data path: with a hosted assistant, whatever the server returns is sent to the assistant’s model provider, such as Anthropic for Claude or OpenAI for ChatGPT, so that provider belongs on your vendor list.

Connecting your compliance platform’s MCP server

A compliance platform is a special case because it holds the evidence your auditor reviews. As of 12 October 2026, Vanta, Drata, Sprinto and Secureframe each offer an official MCP server that can write as well as read:

• Vanta’s hosted server is in public preview (some of Vanta’s own pages call it beta). It can create and update risks, upload policy documents, and create, update or delete privacy records and risk registers. Vanta’s FAQ says access mirrors the connecting user’s role.
• Drata’s server can create, update and delete evidence, risks and vendors. An administrator sets up the OAuth configuration and its scopes, and Drata’s setup guide says a user’s effective access is the overlap of those scopes and the user’s Drata role.
• Sprinto’s server reads and writes across controls, policies, evidence, risks, vendors and audits. None of its tools is named as a delete, though it can archive, close and disable records. Sprinto’s docs require admin or editor-level access to connect and say actions follow the user’s role.
• Secureframe’s server documents 112 tools that mirror its API, with deletes limited to comments, knowledge-base entries and some system security plan records; controls, risks, frameworks and policies are read-only. Secureframe’s MCP docs say actions are limited to the connecting user’s permissions.

Only Drata says actions taken through its MCP server are logged, and none of the four says in its setup documentation where those actions are recorded. Drata’s AI page says its MCP has “full audit logging”. Vanta, Sprinto and Secureframe say MCP actions are tied to the connecting user, which shows who acted rather than where the action is logged. Until a vendor documents it, keep the record on your side, in the assistant’s admin logs or an MCP gateway between the assistant and the server, and ask the vendor in writing.

This matters because an assistant with write access can change the evidence your auditor tests. If it can upload or delete evidence (Drata documents both), expect the auditor to ask who made each change, and have a record they can rely on.

None of the four servers is read-only by design. If you want a read-only assistant, the documented limit on Vanta, Sprinto and Secureframe is the connecting user’s role; on Drata, the administrator can also leave write scopes out of the OAuth configuration. Details and sources for each platform: Vanta’s MCP server and who can connect it, Drata’s MCP server: admin-set scopes and roles, Sprinto’s MCP server and its role limits, and the side-by-side of compliance platforms’ MCP servers compared by access and logging.

How do you show what an AI agent did (the audit trail)?

With a tool-call log that records each action, the identity that took it, on whose behalf, and the result, kept for the whole Type 2 period and protected from editing. SOC 2 prescribes no log format and no retention period. The auditor needs a record complete enough to sample from and reliable enough to trust.

Each entry should let someone reconstruct the action without asking the engineer who built the agent:

• the agent’s identity and version, and the model version it ran on;
• the person, ticket or scheduled job it acted for, and the session;
• the MCP server and tool name, with the tool version where available;
• the input parameters, redacted where they carry confidential data;
• the result, including the IDs of records it created, changed or deleted;
• a reference to the approval, where the action needed one;
• a timestamp from a trusted clock.

AIUC-1’s control on restricting unsafe tool calls (D003) lists close to the same fields as typical evidence for a tool-call log: the originating MCP server, tool name, tool version, input parameters and timestamps for each call.

Completeness is where agent logs usually fail. If engineers can run an assistant from their laptops with their own tokens, those calls bypass any central log. Route agent traffic through one path you control, such as a gateway, a proxy or the agent runtime itself. Then reconcile that log against the target system’s own records periodically, so you can show the auditor it holds the whole population.

Keep the log where the agent cannot edit or delete it, and limit access to the people who review it. Append-only storage helps; signed, tamper-evident entries are stronger evidence but are not a SOC 2 requirement. Prompts and tool inputs often contain customer data, so the log itself falls under your confidentiality and privacy controls. Where the full text is not needed for a control, store a hash or a redacted copy.

Logging duties under the EU AI Act are a separate question that depends on whether your system counts as high-risk under that law; this guide covers SOC 2 only.

Does a person need to approve agent actions?

No SOC 2 criterion requires it. If your risk assessment or customer commitments say certain actions need a person’s sign-off, that sign-off becomes a control, and the auditor will sample approvals to check it happened every time.

Decide which actions need approval before you build the workflow. Deleting or exporting data, changing access, sending messages to customers and moving money are common candidates. Enforce the rule in the tool layer, where the call waits for an approval token, rather than in the prompt. Each approval record should show who approved, when, and exactly what was approved. An approval clicked by the same person who asked the agent to act is weaker evidence than one from a second person.

Where an agent only needs to look things up, a read-only identity is simpler than an approval queue: there is nothing to approve and less to sample.

AIUC-1 treats approval the same way. Its mandatory tool-call control lists tool allowlists and a tool-call log as expected evidence, and human-approval workflows for sensitive operations as optional evidence. Compliance platforms’ own built-in agents state their approval rules differently from one another, so check each agent’s documentation rather than assuming a person signs off.

Are AI-specific criteria coming, and do you need AIUC-1 as well?

Possibly, but nothing is published yet. Some firms expect a revision of the Trust Services Criteria that covers AI, but the AICPA has published no draft. AIUC-1 is a separate certification for AI agents, designed to sit alongside SOC 2 rather than replace it.

KPMG’s 22 September 2026 webcast says changes to the criteria are expected, including for emerging technologies such as AI. IS Partners wrote on 16 September 2026 that the earliest implementation is likely 2027. Until the AICPA publishes an exposure draft, prepare against the 2017 criteria your auditor will actually use.

AIUC-1 certification typically covers specific agents or products rather than a whole company. The Artificial Intelligence Underwriting Company maintains it, and its own documentation says it avoids duplicating frameworks such as SOC 2. Its April 2026 release added the MCP controls SOC 2 does not spell out: agents may connect only to approved MCP servers, MCP server environments can be sandboxed (a supplemental control, B006.3), tool-call authorization and logging extend to MCP tool calls, and monitoring of third-party access became mandatory. The standard is revised every quarter, on 15 January, April, July and October.

AIUC-1 is worth considering when enterprise customers ask how your agent behaves under attack or how often it gets things wrong, questions a SOC 2 report is not designed to answer. For a SOC 2 report alone, the controls above are what your auditor will look at. For the certification and its process, see AIUC-1 compared with SOC 2, and which firms can audit it.

Two free control catalogues are useful inputs to the risk assessment, though neither is a SOC 2 requirement: the OWASP Top 10 for Agentic Applications (December 2025), which lists risks such as tool misuse and identity and privilege abuse, and the Cloud Security Alliance’s AI Controls Matrix v1.1 (June 2026).