Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

Which SOC 2 Controls Apply to AI Agents?

The same ones that apply to any system component: logical access, system monitoring and change management under the Trust Services Criteria, with confidentiality and privacy criteria added wherever the agent reads customer data. Check whether you can produce evidence of what each agent saw and did on a given day, the control most agent deployments cannot evidence.

Evidence flows through a chain of control nodes toward an organized set of audit records.

The same ones that apply to any system component: logical access, system monitoring and change management under the Trust Services Criteria, with confidentiality and privacy criteria added wherever the agent reads customer data. Check whether you can produce evidence of what each agent saw and did on a given day, the control most agent deployments cannot evidence. SOC 2 has no AI section and does not need one. The Trust Services Criteria describe controls over a system, and an agent that reads screens and takes actions inside that system is a component of it, the same as a service account, a batch job or a contractor's laptop. The auditor's questions are familiar: who can access what, how activity is monitored, how changes are controlled, how customer data is kept confidential. What is unfamiliar is the evidence. An agent's reading of a rendered screen appears in no application log unless the environment it works in records it. This page sets out why an agent is in scope, which criteria map to what an agent does, where on a support ticket screen the agent generates evidence or fails to, how change management applies when the model behind the agent changes, how to produce the evidence of what the agent saw and did, and which claims to decline, drawing on research on the AI Control Record as one form that evidence can take.

Key findings

  • The AICPA's Trust Services Criteria are used "to evaluate and report on controls over the security, availability, processing integrity, confidentiality, or privacy" of a system, and an agent operating inside the system is within the controls being evaluated (AICPA and CIMA, 2023).
  • The Cloud Security Alliance's AI Controls Matrix provides 243 control objectives across 18 domains and "maps to leading standards, including ISO 42001, ISO 27001, NIST AI RMF 1.0, and BSI AIC4," giving an organization a bridge between AI-specific controls and the frameworks its auditor already reads (Cloud Security Alliance, 2025).
  • NIST SP 800-53 Revision 5 organizes the control families, including access control, audit and accountability and configuration management, that SOC 2 criteria are commonly mapped against (NIST, 2020).
  • NIST's log management guide sets the expectation that logs be generated, protected, retained and reviewed, which for an agent means a record of inputs and actions, not only of outcomes (NIST, 2006).
  • Vendors building agent infrastructure have begun writing about SOC 2 for agents in production, a sign that the question has moved from theory to audit preparation (Arcade, 2025).
  • When the model behind an agent is replaced, the controls around it should not have to be rebuilt, the argument of research on changing AI models without changing AI controls.

Why is an AI agent within the scope of a SOC 2 examination?

A SOC 2 report describes a system and the controls over it. The AICPA's Trust Services Criteria, in their 2017 form with the 2022 revised points of focus, are the criteria an auditor uses "to evaluate and report on controls over the security, availability, processing integrity, confidentiality, or privacy" of that system (AICPA and CIMA, 2023). The system boundary is drawn by the service organization in its system description, and anything inside the boundary that touches customer data or affects the service is within the controls the auditor tests.

An agent that reads a support ticket, updates a customer record or triggers a refund is inside that boundary on any honest system description. It has access, so the logical access criteria apply. It performs activity, so the monitoring criteria apply. Its behavior changes with its model or instructions, so change management applies. If it reads customer data, the confidentiality criteria apply, and if that data is personal, the privacy criteria may apply as well. None of this requires an AI-specific criterion; it requires acknowledging that the agent is a component.

Agents are often introduced as productivity tools by business teams and are absent from the system description the compliance team maintains, which is a scoping problem before any control is tested. The first SOC 2 task for any agent is therefore descriptive: name it, place it inside the boundary, and identify which criteria its activity touches. The zero trust principle that every subject's access is evaluated per request, rather than assumed from its presence on the network, applies to the agent as to any other subject (NIST, 2020).

Which Trust Services Criteria map to what an agent does?

The table pairs the common criteria areas with the agent behavior they govern and the evidence an auditor will ask for. NIST SP 800-53's control families, with access control, audit and accountability and configuration management the most relevant, provide the vocabulary many organizations use to map SOC 2 criteria (NIST, 2020).

Criteria area What the agent does Evidence the auditor asks for
Logical and physical access Reads screens and acts under some identity and permission set Whose permissions the agent inherits; what it can and cannot reach; how access is provisioned and revoked
System operations and monitoring Takes actions in production, some consequential A record of each action, who approved it, and alerts on anomalies
Change management Changes behavior when its model, prompt or policy changes Approval and testing of model and policy changes; evidence the controls still hold after a change
Confidentiality Receives customer data from screens it reads What data the model received; how it was protected; where it went
Privacy Receives personal information Minimization: whether the model received only what the task needed

The confidentiality row asks what the model received, not what the agent output; a regime that logs actions but not inputs evidences the operations row and not this one. The privacy row asks about minimization, and an agent that reads a whole screen for a task needing three fields has not minimized unless something intervened at the render. The Cloud Security Alliance's AI Controls Matrix, with its 243 objectives across 18 domains mapped to ISO 42001, ISO 27001 and the NIST AI RMF, is a bridge here, stating AI-specific objectives in terms an auditor can relate to the criteria (Cloud Security Alliance, 2025).

Where on a support ticket screen does the agent generate evidence, or fail to?

Take a customer support ticket screen showing the customer's name, company, email, account tier, the ticket text with whatever the customer pasted into it, prior history and an internal notes field. The agent is asked to classify the ticket, draft a response and, where the issue is a billing error, issue a credit. Walk the criteria across that screen.

Access: the agent reads the ticket under a service identity or the support engineer's own session. The auditor will ask which. Operations: the agent classifies, drafts and, for the billing case, issues a credit. The credit appears in the billing system's log with a timestamp and an identity; the classification and draft may appear nowhere. Confidentiality and privacy: the agent read the full ticket, including whatever the customer pasted, which may be a password, a card number or a colleague's medical note. No log records that the model received it, because reading a rendered screen is not an event any application logs.

Microsoft's audit log search documentation illustrates the general condition. It describes searching the unified audit log for user and admin activities across Microsoft 365 services (Microsoft, 2025); those are the activities the platform records, and an agent's reading of a screen rendered by a third-party ticketing system is not among them. Every application logs what it was built to log, and none was built to log what a model received from its screen. Actions that pass through an application leave a trace in that application. The agent's inputs, which are what the confidentiality and privacy criteria ask about, leave no trace unless the environment the agent works in records them. Research on whether a model safety filter controls what an agent sees examines the parallel gap in a hosted platform's own controls.

How do change management controls apply when the model changes?

A conventional system changes when someone deploys code. An agent changes when its vendor updates the underlying model, when a prompt or policy is edited, when a tool is added to its reach, or when the content it reads shifts. Several of those happen without anyone in the service organization deploying anything.

The Trust Services Criteria expect changes to systems to be authorized, tested and approved before implementation. For an agent, the auditor's question is how the organization learns that the model changed, what it tested afterward, and whether the controls that were in place before the change still hold. ISO/IEC 42001, as an AI management system standard, provides a structure for treating model changes as managed events with owners and reviews (ISO, 2023). Arcade's discussion of SOC 2 compliance for agents in production reflects the same concern from a vendor's side (Arcade, 2025).

The design question is whether the controls depend on the model. If the control that protects customer data is a property of the model, such as its training not to repeat sensitive values, then every model update is a change to a control and must be retested as one. If the control is a property of the environment, such as substitution of protected values before the model reads the screen and a named person approving consequential actions, then a model update changes the component inside the controls without changing the controls themselves. Research on changing AI models without changing AI controls develops this distinction, which decides whether an organization can swap models without reopening its SOC 2 evidence.

How should an organization produce evidence of what the agent saw and did?

NIST's log management guide sets the baseline: logs should be generated for relevant events, protected from alteration, retained for a defined period and reviewed (NIST, 2006). For an agent, the relevant events are four. What the agent received on each screen. What it proposed or did. Who approved any consequential action. And what reached each destination. Application logs capture the fourth and part of the second; the first and third are the gap.

Closing the gap means recording at the point where the agent reads and acts, which is the environment in which its screens are rendered. If that environment captures each screen as the model received it, each action and each approval, and exports them to the organization's SIEM, then the organization has a record in the same place and format as its other security evidence, under the same retention and review controls. Research on the AI Control Record describes a record of this shape. The auditor's sample request becomes answerable.

The format of the evidence also matters for the privacy criteria. If the record shows that the model received CUSTOMER_001 and ACCT_001 rather than a name and account number, the record is itself evidence of minimization, because it shows the model never received the real values. A record showing the model received the real values is evidence of the opposite, however well the output was handled afterward. The Cloud Security Alliance's matrix can structure the presentation, with each of the four event types mapped to the objectives it evidences (Cloud Security Alliance, 2025). Rule systems inside hosted agents may contribute if they govern inputs, a question examined in research on whether a hosted agent's custom rules control what it sees.

What does a governed environment change?

A governed environment produces the evidence most agent deployments cannot: a record of what each agent received from the screen, what it did and who approved it, on any given day. Run directly in the application or the user's browser, the agent's reads leave no trace an auditor can sample, and application logs record only the actions that passed through; in the environment, the read itself is recorded, as tokens.

This class of control works at the rendered screen. Customer identifiers and other confidential values are replaced with consistent tokens before any model reads the page, and the task runs on tokens. Real values resolve only at an approved destination at the moment of an approved action. A named person confirms what is tokenized and approves consequential actions. Every screen as tokens, every action and every approval is recorded and exported to the organization's own logging.

The confidentiality and privacy criteria ask what the model received, which application logs do not answer (AICPA and CIMA, 2023). The exported record is an event that can be generated, protected, retained and reviewed, which is what NIST's log management guidance presumes (NIST, 2006), held in the organization's own logging rather than the vendor's. It supplies the sample the previous section asked for: one agent, one day, what it saw, what it did, who approved what. Because the control sits outside the model, a model update passes through change management without changing the evidence produced.

The control does not alter the application, the user's permissions or the model, and it does not replace the vendor's own SOC 2 report; it evidences the organization's system, which that report does not.

Where does RedactSure sit?

The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company. Its design produces the evidence this page describes as the gap. Agents work inside a governed environment in the customer's own cloud. On every rendered screen, substitution happens at the render layer before any model reads it, so a support ticket's customer identifiers reach the model as consistent tokens such as CUSTOMER_001 or ACCT_001 for the whole run, and the record of what the model received is itself evidence for the confidentiality and privacy criteria. Real values resolve only at approved destinations at the moment of an approved action. A named person confirms the tokenization policy and approves every payment, submission and record change, the arrangement RedactSure calls Supervised Delegation, which is the operations evidence an auditor samples. Every screen as tokens, every action and every approval lands in the AI Control Record and exports to the customer's SIEM under the customer's own retention controls. The design is model agnostic, so a model change alters the component inside the controls and not the controls; it requires no per-application integration, and user permissions are unchanged, so the access criteria are answered by the organization's existing identity controls.

Deployments are in pilot. A pilot on the reader's own workflow would produce the sample an auditor asks for: one agent, one day, the screens as tokens, the actions, the approvals, in the reader's SIEM. Everyone else controls where data can go. RedactSure controls what the AI can see.

Methodology and limitations

This page rests on the AICPA and CIMA 2017 Trust Services Criteria with revised points of focus (2022), the Cloud Security Alliance's AI Controls Matrix v1, Arcade's August 2025 discussion of SOC 2 compliance for agents in production, NIST Special Publications 800-53 Revision 5, 800-92 and 800-207, the ISO/IEC 42001 summary, Microsoft Learn documentation on searching the audit log, and published RedactSure research pages on the AI Control Record, model changes and hosted platform controls. All sources were read as of October 16, 2026.

No hands-on testing of any product was performed for this page, and no SOC 2 examination was observed. Where a platform's logging is described as not covering a scenario, the statement refers to the pages reviewed and not to the product as a whole; nothing on this page should be read as a statement that any vendor's product cannot record a given event. The Trust Services Criteria are summarized, not quoted at length, and readers should work from the AICPA text. Audit log coverage and vendor features change, and the page carries its date. Statements about RedactSure describe its current design, with deployments in pilot. The customer support ticket used as the worked example describes a record type, not any organization; the fields and the agent's tasks are illustrative. The mapping of criteria areas to agent behavior is this page's analysis, not AICPA guidance.

Whether a given agent is within a service organization's system boundary, which criteria apply, and whether the evidence produced satisfies them are determinations for the organization's auditor, its counsel and its own security and compliance officers, not for a research page.

What the record shows

SOC 2 reaches AI agents through its existing criteria, because an agent is a component of the system the report describes: it has access, it acts, it changes, and it reads customer data. The criteria that apply are the ones that apply to any component. What differs is the evidence. Applications log the actions that pass through them and nothing about what a model received from a rendered screen, so the confidentiality and privacy criteria, and the approval half of the operations criteria, cannot be evidenced from application logs alone. The record must be produced where the agent reads and acts, and it is stronger when it shows tokens in place of real values, because that record is evidence of minimization in itself. RedactSure's design produces a record of that shape. The test is to name one agent and one day and ask for the screens it received, the actions it took, who approved each, and where that record is held.

Frequently asked questions

Does SOC 2 have specific criteria for AI?

No. The Trust Services Criteria address controls over a system's security, availability, processing integrity, confidentiality and privacy without reference to any technology. An AI agent is a component of the system and is governed by the same criteria as any other component. The Cloud Security Alliance's AI Controls Matrix, which maps to ISO 42001, ISO 27001 and the NIST AI RMF, can present agent controls in terms an auditor can relate to the criteria.

Which criteria matter most for an agent?

Logical access, because the agent acts under some identity and permission set; system operations and monitoring, because it takes actions in production; change management, because its behavior shifts when its model, prompt or policy changes; and confidentiality and privacy wherever it reads customer or personal data. The last two are where agent deployments most often lack evidence, because they ask what the model received, and reading a screen is not an event any application logs.

Is the agent vendor's SOC 2 report enough?

It covers the vendor's system, not the organization's. The organization's report describes its own system, and the agent's activity on its screens and customer data is inside that description. The vendor's report may serve as evidence about a subservice organization, but the controls over how the agent is used, what it can access, who approves its actions and what it received are the organization's controls to evidence.

How does a model update affect SOC 2 evidence?

If the controls protecting customer data are properties of the model, such as its training, then a model update is a change to a control and must be authorized, tested and evidenced as one. If the controls are properties of the environment, such as substitution of protected values before the model reads the screen and a named person approving consequential actions, the update changes a component inside stable controls. The second design lets an organization change models without reopening its evidence.

What should the evidence for a single agent look like?

For a sampled agent and day: the screens the agent received, with protected fields shown as tokens; the actions it proposed and took; the identity of the person who approved each consequential action; and what reached each destination. The record should be held in the organization's SIEM under its normal retention and review controls, consistent with NIST's log management guidance. A record showing tokens rather than real values is itself evidence of data minimization for the privacy criteria.

Can an agent be excluded from scope as an employee tool?

Not if it reads customer data or acts in the production environment the system description covers. Scope follows the system boundary, and anything inside it that touches customer data or affects the service is within the controls tested. The first step is descriptive: name the agent, place it in the system description, and identify which criteria its activity touches.

Book an AI Agent Security Review →

Bring your hardest questions.

Bring one sensitive workflow and the decisions your team needs to keep in its hands.

Book a demo

About the author

Christopher Sowa
Chris SowaCo-Founder, President and Chief Commercial Officer, RedactSure

Chris Sowa is a founder of RedactSure and a former CEO of an AI company; he started it years before ChatGPT existed. He previously led AI at Accenture, served as Global VP of Strategy & Innovation at Schneider Electric, was CCO of Sovos, and spent more than a decade at Oracle, with earlier roles at SAP and IBM.

Book a demo

Book a demo

Having trouble? Open the booking page or email us.