For many organizations, **SOC 2** compliance is more than just a badge; it's a critical assurance for customers entrusting them with sensitive data. Yet, the rise of AI agents is revealing significant limitations in how this widely accepted framework addresses modern machine identities and their operational nuances. Traditionally, compliance frameworks assume human actors and well-defined processes. However, AI agents operate differently, often with borrowed credentials, unclear ownership, and dynamic behaviors that current **SOC 2 Trust Services Criteria** struggle to capture. Consider a scenario where a production database log shows a senior engineer performing 50 queries at 10:03 AM. While the access review might approve this activity as compliant, the engineer could have been getting coffee, with an AI agent pushing updates in their name. This highlights a critical disconnect: **SOC 2**'s technology-neutral criteria *can* cover AI agents, but they don't *explicitly require* organizations or auditors to treat them as a distinct identity class. This discretion allows new risks to emerge without triggering a single control failure. ## Shifting Sands: Four Assumptions That No Longer Hold The effectiveness of several **SOC 2** access criteria (specifically **CC6.1-CC6.3**) hinges on assumptions about human-centric operations. With AI agents, these assumptions are increasingly outdated: ### 1. Account Approval Before Spawning **SOC 2** mandates user registration and approval before granting login capabilities. For humans, this involves a clear request and approval process. AI agents, however, often emerge as a side effect of other actions – a developer clicking "Allow" on an **OAuth** screen, an **API** key embedded in a config file, or an **MCP server** added to a **JSON** file. Their creation is often implicit, bypassing formal approval workflows. ### 2. Every Account Has a Known Owner Access review procedures typically require a named human to confirm continued access. For AI agents, explicit ownership is frequently absent. Identifying an agent's owner often requires piecing together circumstantial evidence from associated artifacts like keys or repositories, making ownership an educated guess rather than a clear record. **SOC 2** currently treats a guessed owner and a recorded owner identically in review spreadsheets. ### 3. Log Names Pinpoint the Actor This is perhaps the most significant blind spot. AI agents frequently operate using borrowed credentials – a logged-in session, a dev token, or a service account. Consequently, the logs and access reviews will display the human associated with those credentials, not the agent itself. A recent study with **Cloud Security Alliance** revealed that over two-thirds of organizations cannot clearly distinguish AI agent actions from human ones, leading to accurate but ultimately uninformative access reviews. ### 4. Account Capabilities Reflect Expected Actions Least privilege principles assume an account has a permanent job, with access levels tailored to that role. While this holds true for most human roles, an agent's access limits its blast radius but doesn't define its real-time expected actions. These depend on dynamic instructions, context absorption, and autonomous decisions. Checking permissions only provides the widest possible view of what *could* happen, not what the agent is *expected* to do at any given moment. ## Controls Passing Without Coverage These eroded assumptions translate into three **SOC 2** controls that may pass audits while completely missing the risks posed by AI agents: ### Offboarding Gaps (CC6.3) Organizations excel at offboarding human employees through integrated **HR** and **IdP** systems. No such centralized system exists for AI agents. When a human leaves, their associated agents, potentially running on **OAuth** grants or **API** keys, can continue operating undetected unless specifically accounted for. The control isn't broken; it simply doesn't encompass agent identities. ### Vendor Review Blind Spots (CC9.2) **SOC 2**'s vendor management processes (contracting, assessment, annual review) work well for traditional vendors. However, an **MCP server** or an AI agent, while acting on behalf of the organization and processing its data, might arrive via a config file rather than a purchase order. Many such entities may not even be traceable to a named company, making **SOC 2** report collection impossible and creating fundamental compliance issues. ### Nominal Segregation of Duties (CC8.1) Change management principles mandate authorization, testing, approval, and implementation, with segregation of duties requiring different individuals for authoring and approving. When one agent makes a change and another agent reviews it, the separation is merely nominal, even if two distinct identities are involved. The true authorization decision, often residing in a prompt or an external tool, falls outside the audit's scope, with only a pull request serving as evidence. ## The Path Forward The current state suggests that **SOC 2**, while robust for traditional IT environments, is struggling to keep pace with the rapid evolution of AI agents. For **SOC 2** to remain relevant and effective in demonstrating trustworthiness, its framework, and the auditing practices it guides, must evolve to explicitly recognize and manage AI agent identities and their unique operational paradigms. Organizations need to go beyond the checkbox to proactively discover, assign identity to, and appropriately remediate access for every agent within their environment.