How to cover production AI agents in SOC 2: governance, access, change management and monitoring, with indicative criteria mappings, customer responsibilities and practical audit expectations.
The short answer: if AI agents act in your production environment as part of the service covered by SOC 2, they are part of your in-scope system. Your report should show controls designed for what they actually do. Four domains shape those controls: agent governance and accountability (CC1, CC3), access control (CC6), change management (CC8) and system monitoring (CC7). Agents also need to be reflected in risk and control assessments (CC3, CC4), customer communication (CC2) and the system description.
SOC 2 covers the technology that delivers your service. When agents operate in production, they are a component of that technology. The same Trust Services Criteria apply. What changes is the shape of the controls, because agents don't behave like employees, shared service accounts or traditional software.
This is the practical next layer beneath what SOC 2 should look like for an AI-native company. It focuses on agents operating your service, rather than agents helping you manage compliance.
When a report overlooks agents in production, enterprise security teams can find the gap during due diligence. They are left without assurance over a potentially consequential part of the service, and may ask for additional evidence, controls or commitments. Reviews can slow or stall.
A report that shows agentic risks have been considered, addressed by controls and tested by an independent auditor gives buyers a stronger basis for their decision. It helps your team navigate reviews reliably, without guaranteeing approval. That is the practical connection between report quality, enterprise security reviews and the return on your SOC 2 investment.
Agent governance is the foundation. It defines each agent and its accountable owner. Access, change management and monitoring are then measured against those definitions.
| Domain | What the controls need to establish |
|---|---|
| Governance and accountability | Define each agent, assess its risk and assign an accountable human owner. |
| Access control | Authorised, least-privilege access; a unique identity per agent; periodic review and traceability. |
| Change management | Human-reviewed work stays within existing controls. Agent deployment needs authorisation, testing, review, alerts and rollback suited to its risk. |
| System monitoring | Agent activity is logged; actions outside its boundaries are flagged; agent roles in incident response are governed. |
A large part of SOC 2 covers how an organisation manages its people. Security awareness, policy sign-offs, performance reviews, employment contracts and disciplinary consequences create accountability that supports the rest of the system.
An AI agent is technology. It cannot be disciplined, fired or denied a reference. Those people controls do not create accountability for it. Agent governance fills that gap.
The owner is how human accountability is attached to an agent. The governance record becomes the baseline for its permissions, change authority and monitoring. Those choices are part of your Compliance Shapes, not a generic control template.
An agent with production access should follow the same access principles as employees, contractors and customer users. Existing access controls can often be extended to cover agents, provided they are deliberately applied to them.
Authorised access: approve permissions before granting them, in line with the agent's defined purpose.
Least privilege: limit access to what the agent's role requires.
Periodic review: confirm regularly that the access is still appropriate.
Unique identity: each agent uses its own account, rather than sharing one service account across several agents.
Audit logging and traceability: link each action to the agent that took it, and through the governance record to its accountable owner.
Privileged and emergency access: manage elevated or break-glass access with approval, least privilege, time limits and logging.
The risk is not necessarily that agents need a separate access process. It is that service and agent accounts get missed from user access reviews, or reviewed less carefully.
Test your process against agents directly. Is each agent account reviewed with the same question: is this access still needed? Does someone understand what access it holds and monitor how it is used? If so, agents can be included in the general access controls you already operate.
The principles stay the same: changes are authorised, tested, reviewed and migrated to production in a controlled way. What adapts is where those steps sit, depending on the agent's role.
When a human stays in the loop, an agent may write code while a human takes responsibility for it, reviews it and puts it through peer review and deployment as their own change. Existing controls sit on top of that work. AI-assisted coding alone typically does not materially change the controls described in a SOC 2 report.
When an agent can deploy to production itself, the design needs to address the steps it might otherwise bypass. Consider authorisation before deployment, review immediately after deployment where appropriate, alerts for unexpected changes, and rollback with a defined response time.
Post-deployment review is not a blanket substitute for approval and testing. The acceptable sequence depends on risk, service commitments and the safeguards around the agent. Design the authorisation, testing, review and deployment process deliberately.
If customer users direct or approve changes an agent makes, that shapes the controls your company operates and the responsibilities customers retain. Describe that split clearly, including relevant complementary user entity controls (CUECs). Customers need to understand what they must do for the overall control environment to work.
Agents affect monitoring in two ways: they are something new to monitor, and they may also perform the monitoring.
Monitoring the agents means recording their production actions, monitoring their changes and alerting on behaviour outside the purpose, scope or boundaries in the governance record. The accountable owner should receive and act on that information. That closes the loop between governance and day-to-day operation.
An agent may pick up alerts, investigate them, assess impact and notify customers. Whether controls need to change depends on what it actually does.
| What the agent does | Impact on the controls |
|---|---|
| Performs the same incident steps a human would | The control may remain the same, but the agent’s authority, oversight and evidence still need to support reliable operation. |
| Adds monitoring or on-call coverage alongside humans | An additional control may describe the extra detection or response coverage. |
| Remediates issues by making system changes | Change management applies, including authorisation, review and rollback. |
Defined authority: which steps can the agent take alone, and which must it escalate?
Human oversight: how are triage and impact assessments reviewed?
Customer communication: who approves notifications to impacted customers?
Traceability: are actions logged for post-incident review?
Risk and control assessments (CC3, CC4) should consider the role agents play, their risks and whether controls cover what they actually do. This may mean updating existing assessments rather than introducing a new agent-specific process.
Customer communication (CC2) should explain what role AI plays in the service, relevant risks and the responsibilities customers hold.
The system description (DC 200) should make the role of AI features and agents clear enough for customers to put the risks and controls into context. Include relevant CUECs where customers direct or approve agent actions.
Vendor management (CC9.2) should cover third-party model and AI platform providers. Data handling controls should cover the customer data agents can access and how it is protected, including Confidentiality criteria where that category is in scope. Our Trust Services Criteria guide explains which categories to include.
Covering agents in SOC 2 does not replace AI-specific frameworks. ISO 42001 sets requirements for an AI management system. AIUC-1 is an AI-specific standard addressing areas such as data privacy, security, safety, reliability and accountability. These frameworks explore AI risks beyond what SOC 2 is designed to cover. For the broader operating picture, read What SOC 2 looks like for an AI-native company.
Which additional frameworks you need depends on your service, risks, commitments and customer requirements. The point is not that every company needs all of them. It is that SOC 2 should already address production agents within its scope. An AI-specific framework does not excuse a blind spot in your SOC 2 report. For the decision, read Do AI companies need ISO 42001?. See our ISO 42001 service for the management-system approach.
An agent operating your service is different from an agent helping run your compliance program. Agentic compliance usually changes how controls are operated, where evidence comes from and how auditors gather and test it, rather than the report format or the controls themselves.
The exception is when an agent replaces a control activity outright. If a management review is replaced by an agentic review, the control changes. It needs to be described and tested as an agent-performed control, with governance over that agent.
For the operating architecture, read how to build an agentic compliance program. For evidence collection, read connectors, browser agents and a human in the loop. For independent testing, see who can audit an agentic compliance program.
These mappings follow the 2017 Trust Services Criteria, with revised points of focus in 2022, and the DC 200 description criteria. They are indicative, not a mandatory list of standalone controls. The final mapping depends on your control design, scope and service commitments.
| Area | Control | Criteria | What an auditor looks for |
|---|---|---|---|
| Governance | Agent inventory: purpose, objectives, scope and boundaries | CC1.3, CC2.1 | Each production agent documented and kept current. |
| Governance | Agent risk assessment | CC3.1, CC3.2, CC3.4 | Risks assessed per agent, including additions and changes. |
| Governance | Accountable owner per agent | CC1.3, CC1.5 | A named owner who monitors the agent and can restrict or stop it. |
| Access | Authorised, least-privilege agent access | CC6.1, CC6.2, CC6.3 | Access approved before grant and limited to the role. |
| Access | Unique agent identities | CC6.1 | One account per agent, without shared identities that break traceability. |
| Access | Periodic agent access review | CC6.2, CC6.3 | Agent accounts included in access reviews. |
| Access | Privileged and emergency access | CC6.1, CC6.3 | Elevated access approved, time-bound and logged. |
| Change management | Human-in-the-loop changes | CC8.1 | Agent-written changes reviewed and deployed by a human. |
| Change management | Agent-deployed changes | CC8.1, CC7.2 | Risk-appropriate approval and review, testing, alerts and rollback. |
| Change management | Customer-directed agent changes | CC8.1, DC6 | Responsibilities split clearly, with relevant CUECs. |
| Monitoring | Agent activity logging and alerts | CC7.2, CC7.3 | Actions logged; out-of-scope behaviour flagged to the owner. |
| Monitoring | Agent-performed monitoring or on-call | CC7.2, CC7.3, CC7.4 | Defined authority, human escalation and review of triage. |
| Monitoring | Agent remediation of incidents | CC7.4, CC7.5, CC8.1 | Remediation treated as a change, with authorisation and rollback. |
| Monitoring | Customer incident notifications | CC7.4, CC2.3 | Notifications approved and accurate. |
| Risk and control assessment | Agents included in assessments | CC3.1 to CC3.4, CC4.1, CC4.2 | Agent roles reflected in risk and control evaluations. |
| Communication | AI role, risks and customer responsibilities | CC2.3 | Customers told how AI is used and what they must manage. |
| System description | AI features and agents described | DC1, DC3, DC6 | AI role clear enough to contextualise the controls. |
| Vendors | AI model and platform providers | CC9.2 | Providers assessed and monitored as vendors. |
| Data | Agent access to customer data | CC6.1, C1.1 | Data access limited and protected; C1 applies where Confidentiality is in scope. |
| Agentic compliance | Agent replaces a control activity | CC4.1, CC1.5 | Agent-performed control described, governed and tested. |
Yes, where they operate as part of the production service covered by the report. Scope should reflect the system customers actually rely on, including its AI features and agents.
No. The same Trust Services Criteria apply. What changes is how controls are designed to meet them, because agents behave differently from people and traditional systems.
Start with governance and accountability, access control, change management and monitoring. Reflect agents in risk and control assessments, customer communication, vendor management and the system description too.
It can use a non-human account, but each agent should have its own unique identity. One shared account for several agents breaks traceability between the action, the agent and its accountable owner.
Usually not if a human reviews and deploys the work as their own through existing controls. Additional safeguards are needed when an agent can deploy to production itself.
Buyers may find the gap during due diligence and ask for additional evidence or commitments. Without assurance over production agents, their review may slow or stall.
No. AI-specific frameworks address additional AI risks. Whether you need them depends on your circumstances, but SOC 2 should still cover production agents within its own scope.
Usually it changes how the program operates and how evidence is obtained and tested. If an agent replaces a control activity, such as a management review, that control needs to reflect the change.
Not necessarily when they perform existing steps. Additional coverage may warrant an additional control. When agents remediate incidents through system changes, change management controls apply.
AI agents in production are part of your system. Your SOC 2 report should show that, rather than leaving buyers to work out the implications themselves.
Start with governance: define each agent, assess its risk and give it an accountable owner. Extend access, change management and monitoring so they deliberately cover what it does. Make sure the risk assessment, customer communication and system description tell the same story.
Independent testing then gives enterprise buyers a sounder basis for assessing your service. If you want to discuss what that means for your company, explore SOC 2 audits for AI-native companies or book an intro call.
Former PwC manager, founder of AssuranceLab and former Sensiba partner and Chief Innovation Officer. Now co-founder of Throughline, focused on compliance and assurance for AI-native companies.
SOC 2 for AI-native companies: simpler stacks, agents running the program in your own tools, concise policies, and a report that covers AI in production.
ISO 42001 isn't yet an enterprise requirement. What it covers, how it compares with SOC 2 and AIUC-1, and when it's worth it for an AI company.
Australian companies need a SOC 2 report issued under the AICPA standards by a US-licensed CPA firm, delivered by a strong local team in Australian time zones. Here's how the provider options compare, and what to check.
Experienced CTOs don't choose a SOC 2 audit firm on price or speed. They look for tech stack expertise, a tailored approach, flexible scheduling, responsiveness and year-round partnership, because those factors decide how much time the audit really costs.
What Security, Availability, Confidentiality, Processing Integrity and Privacy each cover, how often they're included, and how to decide which belong in your SOC 2 report.
Which SOC 2 report should come first? Six client cases, practical decision tables and an illustrative 18-month cost comparison explain when to start with Type 1 and when to go straight to Type 2.
How long a SOC 2 Type 2 observation period should be, how to work backwards from a customer deadline, when auditors test, why reports run late and how much buffer to build in.
A category-by-category SOC 2 budget in USD, covering audit fees, readiness, platforms, penetration testing, consultants, internal assessments and operational costs. Learn what is required, what is optional, and what a quote can leave out.
Five signals of real quality in assurance and security, with practical guidance on building a compliance program that supports customer TPRM, repeatable enterprise reviews and revenue growth.
The person leading your SOC 2 audit is the most underrated factor in choosing an audit firm. Companies compare price, timelines and platform integrations, then barely ask who will actually do the work.
SOC 2 is a risk report, not a certificate. Understand how enterprise customers use it, why having a report is only base camp, and how to turn your audit into a trust asset for growing revenue.
What readiness should cover, when to involve your auditor, which gaps matter most, and how readiness, Type 1 and Type 2 can work as one continuous engagement. A practical guide to preparing for a report your customers can rely on.
CPA firm registration, signing licenses and peer review are the starting point, not proof of quality. A practical guide to checking credentials and asking the questions that matter before choosing your SOC 2 auditor.
Neither is better for everyone. The right choice depends on your customers, how you run security and where you are headed. For AI-native and AI-centric companies, SOC 2's flexible criteria usually make it the stronger starting point.
There's a basic psychology behind why most people don't like audits. Fix this, and people are surprisingly happy to do them again.
Enterprise buyers use SOC 2 as an initial qualifier, then look deeper. A quality report is what carries you through that assessment and turns your compliance investment into real trust.
Audit quality isn't service quality, and it isn't only professional standards. The real test is whether a reader of your report thinks: this tells me what I need to know.
Enterprise security teams review you in the background and rarely give feedback. What they look at beyond SOC 2, what counts as a genuine pen test, and how a quality report does the heavy lifting.
Compliance from first principles, the 95% problem, the compliance metadata AI needs, rethinking screenshots, spreadsheets and policies, and why audits should meet clients where they are.