Read an AI agent vendor's SOC 2 report in a fixed order: the auditor's opinion, the report type and period, the system description, the subservice organisations carved out, the controls assigned to you, and then every exception. For agents, check that the scope reaches the agent runtime and tool connections, and that a model provider is not left untested.
What does a SOC 2 report contain?
A SOC 2 report is an independent auditor's attestation on a service organisation's controls, measured against criteria for security, availability, processing integrity, confidentiality and privacy. Security is always included. Most reports have the same parts:
- The auditor's opinion. Whether the description is fair and the controls were suitably designed and, for Type 2, operated effectively. An unqualified opinion is clean; a qualified one means something material failed.
- Management's assertion. The vendor's own statement about its system and controls.
- The system description. What the service is, its boundaries, infrastructure, software, people, data and processes, plus subservice organisations and complementary controls expected of customers.
- Criteria, controls, tests and results. Each control mapped to the criteria, how the auditor tested it, and whether exceptions were found.
- Other information. Sometimes management responses to exceptions, which the auditor has not verified.
Our explainer on what a SOC 2 report covers for agent platforms sets out the scope questions in more depth.
Who should read it?
Whoever owns vendor risk, with help from someone who understands how the agents will be used. A security reviewer reads for access, encryption and incident response. The business owner of the process the agent will run reads for scope and for what the agents will be able to do. Both should read the exceptions.
Do not let the report stand in for reading the agent. Our answer to whether an agent platform should have a SOC 2 report is yes, but a report is about the vendor's controls, not about whether its agents will do your work well.
What should you look for when the vendor's agents act?
Agent platforms have parts a standard software service does not. Read with these in mind.
Does the scope include where agents act? Some descriptions cover the web application, hosting and support, but leave out the runtime where agents execute and the connectors that reach your systems. If the agents act through components outside the description, the report says nothing about them.
Is the model provider carved out? Most agent platforms use a model provider. In a carve-out, the report excludes that provider's controls, and you need the provider's own assurance. Note also what data the vendor sends to the model provider and whether it is retained.
What complementary controls are yours? Reports list controls the vendor expects customers to run, such as managing your own users, reviewing access and configuring permissions for connections. For agents, that often includes deciding what each agent may do in your systems. If you do not run these controls, the vendor's controls may not achieve their aim.
Does change management cover agent behaviour? Look for controls on changes to agent instructions, prompts, sources and model versions, not only code.
Do logging controls capture actions? Logging of user access is standard. Look for logging of agent actions and the decisions behind them.
What are the exceptions? Every exception tells you a control did not operate as described for some sample. Read each, its cause and the response. An exception in access review or change management on an agent platform matters more than one in, say, visitor sign-in.
How do you turn the report into a decision?
| Requirement | Control | Evidence it leaves |
|---|---|---|
| Opinion is clean | Confirm the opinion is unqualified; escalate any qualification | Review note recording the opinion |
| Evidence is current | Check report type is Type 2 and the period ended close to your review; ask for a bridge letter for any gap | Report period and bridge letter |
| Scope covers agents | Map the agent runtime and connectors you will use to the system description | Scope mapping |
| Carve-outs handled | List subservice organisations, including model providers, and obtain their assurance | Subservice register with their reports |
| Your controls run | Map each complementary control to an owner on your side | Control ownership table |
| Exceptions assessed | Rate each exception for your use and record any follow-up | Exception assessment |
| Agent behaviour proven separately | Test the agents on your own cases before granting authority | Certification results per agent |
The last row is the reason vendor assurance is not enough. Our answer to whether certifying a vendor is the same as certifying an agent explains why, and our guide to what it means to certify an agent covers how.
What will your auditor or supervisor ask about the review?
- Who reviewed the report, and when?
- Did the scope cover the parts of the platform you use?
- How did you deal with carved-out subservice organisations?
- Which complementary controls are you running, and how do you know they work?
- Which exceptions did you consider significant, and what followed?
What does a SOC 2 report not cover?
It does not assess AI governance unless the vendor chose to include such controls; ISO/IEC 42001 is designed for that, as our comparison of ISO/IEC 42001 vs SOC 2 explains. It does not test agents on your cases. It does not certify regulatory compliance. And the vendor's responses to exceptions in the report are not verified by the auditor. Reading the report is a compliance task an agent can help with, but as we argue in agents for regulatory change, the reading is not the judgement.
This is an explanation of the rules, not legal advice; confirm how they apply to you with counsel.
Questions people ask
Can an agent summarise a SOC 2 report for us?
It can extract the opinion, period, carve-outs, complementary controls and exceptions into a checklist, at depth 1 or 2. A person should read the exceptions and decide what they mean for your use.
What is a bridge letter?
A letter from the vendor covering the gap between the end of the report period and today, stating whether controls have changed materially. It is the vendor's statement, not the auditor's.
Should we reject a vendor with exceptions in its report?
Not automatically. Exceptions are common. What matters is which controls failed, how often, why, and whether the cause was fixed.