SOC 2 for AI Agents in Production: The Controls Auditors Will Look For

If AI agents act in your production environment as part of the service your SOC 2 report covers, they are part of your in-scope system. There are no special "AI criteria" in SOC 2. 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 post is for engineering teams running agents in production who want to know what a SOC 2 auditor will expect. It's written from the auditor's side.

The short version

Four domains shape agent controls:

• Governance and accountability (CC1, CC3)
• Access control (CC6)
• Change management (CC8)
• System monitoring (CC7)

Agents also need to show up in your risk and control assessments (CC3, CC4), your customer communication (CC2) and your system description.

Why it matters for enterprise deals

When a report ignores agents in production, enterprise security teams can spot the gap during due diligence. They're left without assurance over a potentially consequential part of your service, and they'll ask for more evidence, controls or contractual commitments. Reviews slow down or stall.

A report that shows agentic risks were considered, controlled and independently tested gives buyers a much stronger basis for saying yes.

Domain 1: Agent governance and accountability

A big chunk of SOC 2 is about managing people: security awareness, policy sign-offs, performance reviews, employment contracts and consequences. That creates accountability for everything else.

An AI agent can't be disciplined, fired or denied a reference. People controls don't create accountability for it. Agent governance fills that gap:

• Define every agent. Keep an inventory with its purpose, objectives, responsibilities, scope and boundaries.
• Assess the risk of each agent. Document what it can do, what it can affect and the risks that follow. Revisit when agents are added or changed.
• Assign an accountable owner. A named person who understands the agent's role, monitors its behaviour and can restrict or stop it.

That governance record becomes the baseline for the agent's permissions, change authority and monitoring.

Domain 2: Access control

Agents with production access should follow the same access principles as everyone else:

• Authorised access: permissions approved before they're granted, in line with the agent's purpose.
• Least privilege: only what the role requires.
• Periodic review: confirm the access is still appropriate.
• Unique identity: one account per agent. Don't share a single service account across several agents.
• Audit logging and traceability: every action links to the agent that took it, and through the governance record to its owner.
• Privileged and break-glass access: approved, least-privilege, time-limited and logged.

The common failure isn't that agents need a separate process. It's that service and agent accounts get missed from user access reviews, or reviewed less carefully. For each agent account, ask the same question you ask for people: is this access still needed, and does someone understand and monitor it?

Domain 3: Change management

The principles don't change: changes are authorised, tested, reviewed and promoted to production in a controlled way. What changes is where those steps sit.

Human in the loop. An agent writes code, a human reviews it and ships it through peer review and deployment as their own change. Existing controls sit on top. AI-assisted coding alone typically doesn't materially change the controls described in a SOC 2 report.

Agent deploys to production itself. Now the design has to cover the steps it might otherwise skip: authorisation before deployment, review immediately after where appropriate, alerts for unexpected changes, and rollback with a defined response time.

Post-deployment review isn't a blanket substitute for approval and testing. The right sequence depends on risk, service commitments and the safeguards around the agent.

If customer users direct or approve changes an agent makes, describe that split clearly in your report, including the relevant complementary user entity controls (CUECs).

Domain 4: System monitoring

Agents affect monitoring in two ways: they're something new to monitor, and they may do the monitoring.

Monitoring agents means logging their production actions, tracking their changes and alerting on behaviour outside the purpose and boundaries in the governance record. The owner receives and acts on those alerts.

If agents take part in incident management:

Four questions to answer for autonomous incident response:

1. Defined authority: which steps can the agent take alone, and which must it escalate?
2. Human oversight: how are its triage and impact assessments reviewed?
3. Customer communication: who approves notifications to impacted customers?
4. Traceability: are its actions logged for post-incident review?

Beyond the four domains

• Risk and control assessments (CC3, CC4) should reflect the role agents play. Usually that means updating existing assessments, not inventing a new process.
• Customer communication (CC2) should explain the role AI plays in the service, the relevant risks and what customers are responsible for.
• The system description (DC 200) should make AI features and agents clear enough for customers to put the controls in context.
• Vendor management (CC9.2) should cover your model and AI platform providers.
• Data handling should cover the customer data agents can access, including Confidentiality criteria if that category is in scope.

Indicative criteria mapping

These follow the 2017 Trust Services Criteria (with 2022 revised points of focus) and the DC 200 description criteria. They're indicative, not a mandatory list. Your mapping depends on your control design, scope and commitments.

Production agents vs agentic compliance

An agent operating your service is different from an agent helping run your compliance program. Agentic compliance usually changes how controls are operated and how evidence is collected and tested, not the controls themselves.

The exception: when an agent replaces a control activity outright. If a management review becomes an agentic review, the control changes. It needs to be described and tested as an agent-performed control, with governance over that agent.

Quick FAQ

Can an AI agent use a service account? It can use a non-human account, but each agent should have its own identity. A shared account breaks traceability between the action, the agent and its owner.

Do AI coding assistants change SOC 2 change management? Usually not, if a human reviews and deploys the work as their own. You need more safeguards when an agent can deploy to production by itself.

Does SOC 2 replace ISO 42001 or AIUC-1? No. AI-specific frameworks address risks beyond what SOC 2 is designed for. But an AI framework doesn't excuse a blind spot in your SOC 2 report.

The bottom line

AI agents in production are part of your system, and your SOC 2 report should show it rather than leaving buyers to work it out. Start with governance: define each agent, assess its risk and give it an accountable owner. Then extend access, change management and monitoring to deliberately cover what it does.

Originally published on the Throughline blog. Throughline is a registered CPA firm that audits AI-native companies for SOC 2, ISO 27001 and ISO 42001.