The state of SOC 2 readiness for organizations operating AI in production

SOC 2 has become a baseline expectation for organizations selling technology services into enterprise markets. The Trust Services Criteria provide a comprehensive framework for evaluating controls over security, availability, processing integrity, confidentiality, and privacy. The framework was developed over many years and is widely understood.

It is also a framework that, in its standard application, leaves several gaps when applied to organizations operating AI-driven products. The criteria are written at a level of generality that accommodates many architectures, but the supporting control libraries and the typical interpretations of those criteria reflect an era of human-driven workflows and well-defined service boundaries. Organizations developing or operating AI agents, AI assistants, or other autonomous systems often discover during audit preparation that several areas require more thought than the standard readiness templates suggest.

Below are five areas that consistently warrant additional attention. Each maps to existing Trust Services Criteria. The work is to identify how those criteria apply to architectures that include AI agents and to design controls accordingly.

Logical access at the agent boundary

The Common Criteria related to logical access (CC6.1, CC6.3) establish requirements for authentication and authorization. In traditional architectures, these requirements apply at the boundary between human users and applications. AI agents introduce a new boundary, the one between the agent and the systems or tools it accesses on behalf of users.

An AI agent acting on behalf of a user has its own identity and credentials. Without explicit design, the agent may have effective permissions broader than the delegating user. The control objective is straightforward: the agent's effective authority should be the intersection of its own scope and the delegating user's permissions, never the union. Implementing this requires explicit logic at the authorization layer rather than reliance on the traditional user-application authorization boundary.

Tool authorization at the tool boundary

For agent-based systems, the tool boundary is where decisions become effects. An agent may decide to send an email, modify a record, transfer funds, or call an external service. The Common Criteria expect these actions to be authorized in accordance with established policy. In traditional architectures, the authorization decision happens when a human initiates the action through an application interface. In agent-based architectures, the authorization decision moves to the agent-tool interface and requires its own controls.

Effective controls in this area typically include explicit allowlisting of tools by agent class, authorization checks at the tool boundary using both agent identity and originating user context, and additional confirmation requirements for actions with high blast radius such as deletions, financial transactions, or external communications.

Audit trail at the semantic layer

The Common Criteria related to monitoring activities (CC4.1, CC7.2, CC7.3) require organizations to maintain logs sufficient to support detection and response. For AI systems, infrastructure-level logs alone are typically insufficient. When an agent produces an unexpected output or takes an unintended action, reconstructing what happened requires logging beyond API calls and authentication events.

An adequate audit trail for an AI system captures the inputs received, the instructions in effect, the context retrieved, the reasoning trace where available, the tool calls made, and the outputs produced. The standard for forensic readiness is the ability to reconstruct any specific user interaction with sufficient detail to investigate questions that may arise weeks or months later.

The training data boundary

Confidentiality criteria require organizations to protect information designated as confidential. For AI organizations, one of the most consequential applications of these criteria is the question of whether customer data is used for model training. Enterprise customers increasingly require explicit commitments that their data is not used to train the vendor's models, and this commitment needs to be both contractually defined and technically enforced.

Auditors look for documentation of the training data boundary policy, contractual language reflecting that policy, and technical controls preventing inadvertent inclusion of customer data in training pipelines. The default position should be that customer data is not used for training unless explicitly opted in, and the technical controls should make that default reliable rather than dependent on operational discipline.

Retrieval and access control

Retrieval-augmented generation introduces a control consideration that does not exist in pre-AI architectures: the retrieval layer must enforce the requesting user's access rights at the document level. Without this control, an agent can become an unintended path to information the user is not authorized to access. The agent retrieves a document on the user's behalf, and the document contains content the user could not access through direct channels.

The audit pattern in this area involves tracing user queries through the retrieval layer, verifying that returned documents are within the requesting user's authorization scope, and confirming that sensitivity-classified content is filtered appropriately. Vector stores and embedding indexes are derivative data and warrant the same access control treatment as the primary data they were derived from.

Approaching readiness

The most effective readiness preparations begin with an explicit mapping of the organization's AI architecture to the Trust Services Criteria. This mapping identifies where standard control templates fall short and where additional design work is needed. The work is not exotic. It involves identifying the boundaries that AI introduces, applying the criteria to those boundaries, and implementing controls that are demonstrable and operationally maintained.