Yes, if it serves regulated businesses. A SOC 2 report is an independent attestation on a service organisation's controls for security, availability, processing integrity, confidentiality and privacy, and customers' vendor reviews expect it. But it answers a narrower question than buyers often assume: whether the platform's controls work, not whether its agents act correctly.
Who needs it, and what does it show?
SOC 2 is an attestation report by an independent auditor on controls at a service organisation. It is organised around trust services criteria: security, availability, processing integrity, confidentiality and privacy. The organisation chooses which criteria are in scope, with security always included. A report can describe whether controls were suitably designed at a point in time, or whether they also operated effectively over a period; buyers in regulated sectors usually want the second.
An agent platform that hosts customers' agents, holds their data and connects to their systems is a service organisation in exactly this sense. Banks, insurers and healthcare buyers will ask for the report during due diligence, and many will not proceed without it. What the report covers for platforms is set out in SOC 2 for AI agent platforms: what the report covers.
This is an explanation of the rules, not legal advice; confirm how they apply to you with counsel.
What does SOC 2 miss when the system is an agent that acts?
SOC 2 tests the controls described in scope. If the platform describes access control, change management, encryption and incident response, the auditor tests those. Agents add questions SOC 2 does not ask unless the platform puts them in scope:
- Does each agent stay within its permitted actions? An agent with valid credentials can still do the wrong thing.
- Is each agent fit for its job? SOC 2 does not test whether an agent's answers are grounded or its decisions sound.
- Are some actions blocked for every customer? A platform may decide certain actions are never available to any agent. That rule is part of the platform floor, and SOC 2 will only test it if it is described as a control.
- What happens when the model changes? Change management in SOC 2 usually covers the platform's code, not a model provider's update.
Processing integrity is the criterion closest to agent behaviour: completeness, validity, accuracy and authorisation of processing. A platform that includes it, and describes its agent action controls as part of it, gives buyers far more than a security-only report.
What should be in scope, and what stays with the customer?
| Control | In the platform's SOC 2 | The customer's responsibility |
|---|---|---|
| Platform access control and encryption | Yes | Their own user access |
| Enforcement of agent limits at the moment of action | Should be, under processing integrity | Setting their own limits |
| Logging of every agent action | Yes | Reviewing logs |
| Model provider changes | Should be, under change management | Re-testing their agents |
| Whether an agent is right for a job | No | Testing on their own cases |
SOC 2 reports list complementary customer controls, things the customer must do for the platform's controls to work. For agents, that list should include setting limits and reviewing held actions.
An illustrative example
Take a regional bank evaluating two agent platforms. Both have SOC 2 reports covering a period, both clean. The bank's third-party risk team reads them. The first covers security only: access, encryption, change management. The second also covers processing integrity, with tested controls showing that every agent action is checked against the customer's limits before execution, that held actions cannot run without a named approver, and that platform-wide prohibited actions were refused throughout the period.
The bank chooses the second, and still asks for evidence about agent behaviour that no SOC 2 can give: results of testing the agents on the bank's own cases.
What else should buyers ask for?
SOC 2 is a baseline, not a full answer. Buyers should also ask how agents are tested before they act, how limits are enforced, and what management system governs AI risk. The comparison with an AI management standard is set out in ISO/IEC 42001 vs SOC 2 for an AI agent platform. The full regulation map is in AI agent regulation, mapped to controls.
Where Pryme fits
Pryme enforces five bounds on every action at the moment of action and files every verdict in an append-only record. These are controls an auditor can test over a period. Attest certifies each agent's capability on the customer's own cases, which answers the behavioural question a SOC 2 report leaves open.
Questions people ask
Is a SOC 2 report required by law?
No. It is a market expectation, not a legal requirement. Regulated buyers ask for it because their own rules require them to oversee service providers.
Is ISO/IEC 27001 an alternative?
It is a certification of an information security management system, often accepted alongside or instead of SOC 2, depending on the buyer's market. Neither tests agent behaviour.
How often should the report be renewed?
Buyers expect reports covering recent periods, renewed on a regular cycle. A gap between periods raises questions in due diligence.