This post is for informational purposes only and does not constitute legal or compliance advice. SOC 2 scope and evidence requirements vary by engagement — consult your auditor or compliance counsel for obligations specific to your organisation.
Quick answer: SOC 2 doesn't have AI-agent-specific controls yet — but agents touching production data fall under CC6 (Logical and Physical Access), CC7 (System Operations), and CC9 (Risk Mitigation). Auditors want the same evidence they'd want from a human: controlled provisioning, least-privilege access, audit logs, and a revocation process. The gap is that most teams haven't applied these controls to their agents.
What SOC 2 auditors are actually looking for
SOC 2 Type II audits are evidence audits. Your auditor isn't evaluating whether your architecture is clever — they're evaluating whether you can demonstrate that access to production systems is controlled and reviewable over the audit period.
For human users, that evidence is well understood: user accounts provisioned through an IAM system, access reviews on a cadence, offboarding procedures, MFA on production systems, logs of privileged access.
For AI agents, the same questions apply:
- Who (or what) has access to production systems?
- How was that access provisioned?
- Is access scoped to what's actually needed?
- What happens when access should be removed?
- Can you show me a log of what was accessed and when?
If your agents have access to production systems and you can't answer those questions with evidence, that's a finding.
Mapping agent access to CC6 (Logical and Physical Access)
CC6 is the criteria set most likely to surface agent-related findings. It covers how access to systems and data is controlled. The relevant sub-criteria:
CC6.1 — Logical access security software, infrastructure, and architectures. The control objective is that access is restricted to authorised individuals. For agents, "authorised" means: does this agent have a named identity? Is there a defined access profile? Is that profile checked at runtime?
Shared API keys fail this control. If three agents use the same key, there's no meaningful access restriction at the agent level — the key is either valid or it isn't. A per-agent scoped token maps cleanly to this control: each agent has a named identity, the identity is backed by a policy, the policy is enforced.
CC6.2 — New internal and external users are registered and authorised. Auditors interpret "users" functionally — an agent calling production systems is a user of those systems. Evidence expected: provisioning records showing the agent was explicitly registered with defined scope, not just "we gave it the same key we use for everything else."
CC6.3 — Access is modified or removed when no longer required. This is the revocation control. Evidence expected: a process for removing access when an agent is deprecated or when a task is complete. With shared keys, you have no process — revoking access means rotating a key that everything uses. With per-agent tokens, revocation is a discrete action: delete the access profile, access is cut, everything else keeps running.
CC6.6 — Logical access security measures restrict unintended access. This is the least-privilege control. Evidence expected: access is scoped to what the function requires. An agent with read access to GitHub, write access to Vercel staging environment variables, and no production access is demonstrably least-privilege. An agent using a developer API key is not.
For a practical guide to building per-agent access profiles that satisfy these controls, see AI agent permissions.
Mapping to CC7 (System Operations)
CC7 covers monitoring and detection — how you identify and respond to anomalies. The relevant sub-criteria:
CC7.2 — The entity monitors system components for anomalies. For agents, this means: can you detect when an agent is doing something unexpected? Audit logs that record every credential request — which agent, which service, which operation, timestamp — give you the detection surface. Without per-agent audit logs, you can't distinguish normal agent behaviour from an agent that's been prompt-injected or has drifted from its intended task.
CC7.3 — Identified security events are evaluated and responded to. Evidence expected: a process for responding to detected anomalies. Revocation is your response mechanism. If you detect an agent making unexpected API calls, you can cut its access immediately without rotating underlying credentials. That's a demonstrable incident response capability.
Mapping to CC9 (Risk Mitigation)
CC9 covers how you identify and manage risk from third parties and business processes. CC9.2 specifically — assessing vendor and partner risk — increasingly applies to AI tool vendors.
If your engineers are using Cursor, Claude Code, or Windsurf with access to production systems, those tools are third-party systems with access to your infrastructure. Auditors who are up to speed on current tooling will ask how access granted to AI coding tools is controlled.
The framing that holds up in audit: each AI tool has a named access profile, access is scoped to what's needed for the task (not developer-level access to all production systems), and access is revocable independently of underlying service credentials.
Audit logs as evidence
The evidence question is where most agent setups fail in practice, not because access is misconfigured but because access isn't logged at the right level.
What an auditor needs to see from logs:
- Who — which agent made the request (named identity, not "the shared key")
- What — which service was called, which operation was performed
- When — timestamp with enough precision to reconstruct a timeline
- Authorised or denied — whether the request was within the agent's defined scope
A server-side log that records "Stripe API called at 14:32:01" doesn't satisfy CC6 evidence. A log that records "Cursor agent (identity: cursor-staging, profile: stripe-read-only) called Stripe /v1/customers — authorised" does.
This is why the credential broker layer matters for audit purposes — it's the place where per-agent identity, access policy, and action are all present simultaneously and can be logged together. See IAM for AI agents for how the broker layer fits into the overall architecture.
The approval gate as a compensating control
For high-risk agent actions — production deployments, data exports, schema changes — a human-in-the-loop approval step is a demonstrable compensating control under CC6 and CC7.
The framing: the agent proposes an action, the action is held pending human review, a named person approves or rejects, the outcome is logged. This gives you:
- A reviewable record of high-risk operations (CC7.2 monitoring)
- Evidence of human oversight for sensitive access (CC6.6 least privilege)
- An audit trail that maps actions to authorising individuals (CC6.1 access restriction)
Approval gates aren't required by SOC 2 — but they're strong evidence of a mature control environment, and auditors responding to AI-related findings will respond well to them as compensating controls.
What to document for your audit
Practical documentation for SOC 2 readiness with AI agents:
Agent access inventory. A list of every agent with production or external-service access: agent name, access profile, scope, provisioning date, owner. Treat this like your user access list.
Access review cadence. A scheduled process to review agent access profiles — quarterly is standard. Document that you've reviewed, that access is still appropriate, and that inactive agents have been deprovisioned.
Provisioning and deprovisioning procedures. Written process for adding a new agent (what profile is created, who approves scope) and removing an agent (how access is revoked, what's verified after revocation).
Incident response for compromised tokens. A documented process: detect anomaly → revoke agent access profile → verify revocation → investigate → remediate. The revocation step should be fast (immediate, not "rotate the key across all affected systems").
Audit log retention. Logs of agent credential access retained for the audit period (typically 12 months for Type II). Log format should include identity, operation, timestamp, and authorisation outcome.
See the AI agent security checklist for a broader list of controls that align with this documentation.
The honest state of things
No SOC 2 auditor will cite you for "using AI agents" — agents aren't a finding on their own. The finding is "systems with access to production data have uncontrolled, unscoped, unlogged access." That finding looks the same whether it's a human contractor using a shared admin key or an AI agent using a shared API key.
The controls that make agent access auditable are the same controls that make agent access safe: per-agent identity, scoped access profiles, runtime enforcement, and revocation. The SOC 2 framing just makes the business case for those controls clearer to teams that have been deferring them.
The timing also matters. SOC 2 Type II audits evaluate evidence over a period — typically 12 months. Controls implemented the week before fieldwork began don't satisfy the operating effectiveness requirement. Agent access controls need to be in place and producing evidence — logs, access reviews, provisioning records — for the full audit period. The best time to implement them is before your observation period starts.
Gazebo's security model is built around the four controls SOC 2 auditors want to see for agent access: named identities, per-identity access profiles, audit logs at the credential request level, and one-click revocation. For how this maps to your specific agent setup, see the agents page. If your agents handle protected health information, the HIPAA Technical Safeguards map to the same controls — see HIPAA and AI agents for the specific §164.312 mapping.