The seven-step plan
1.Recognize agents as in-scope system components
SOC 2 scope covers the systems that process, store, or transmit your in-scope data. An autonomous agent with access to that data — or to the systems holding it — is a system component, full stop. Add every agent (MCP servers, CI bots, LLM tool-callers, service accounts) to your system description and data-flow diagrams.
2.Map agents to the right Trust Services Criteria
Agents land squarely in the Common Criteria: CC6 (logical and physical access) for who/what can do what, and CC7 (system operations) for monitoring and incident response. If agents can change infrastructure or code, CC8 (change management) applies too. Knowing the mapping tells you which evidence the auditor will request.
3.Give each agent a unique identity (CC6.1)
CC6.1 expects identification and authentication of users — and an agent is a user of your systems. Shared keys break this. Issue each agent its own credential so access is attributable and revocable per agent, and so an access review can actually account for every non-human identity.
4.Enforce least privilege for agents (CC6.3)
CC6.3 is about authorizing access based on roles and least privilege. Agents accumulate scope over time exactly like service accounts, so scope each one to the minimum it needs and re-review on a cadence. An over-privileged agent is the same finding as an over-privileged employee.
5.Log and monitor agent activity (CC7.2)
CC7.2 requires monitoring system components for anomalies. Record every agent run — what it did, when, with what result — to a tamper-evident store, and watch it. Agent run logs are access logs; they belong in the same monitoring program as the rest of your infrastructure.
6.Detect and respond to agent anomalies (CC7.3–CC7.4)
Define what 'abnormal' looks like for each agent (a failed or stalled run, a missed cadence, a spike in actions, a new action type) and have a response path when it fires. A prompt-injected or compromised agent shows up here first — if you're watching.
7.Produce the evidence the auditor will ask for
For agents, that's: an inventory of non-human identities, their scopes and last access review, and a sample of monitored run logs showing detection and response. Assemble it continuously; reconstructing six months of agent activity the week before fieldwork is how teams fail a Type 2.
Agent Watch turns agent activity into evidence
KollGuard's Agent Watch gives each agent a unique identity, records every run as a tamper-evident, hash-chained heartbeat, and alerts on health and drift — then maps it to CC6/CC7. The result is exactly the SOC 2 evidence auditors ask for: who your agents are, what they can do, and proof you monitor what they actually do.
Frequently asked
- Do AI agents fall under SOC 2?
- Yes, if they touch in-scope data or systems. An autonomous or semi-autonomous agent is a system component and a non-human user, so it falls under the Common Criteria — primarily CC6 (logical access) and CC7 (system operations/monitoring), and CC8 (change management) if it can change code or infrastructure.
- What SOC 2 evidence do auditors want for AI agents?
- An inventory of agents (non-human identities), each agent's scope and the date of its last access review, and monitored run logs that show anomaly detection and response. In short: who the agents are, what they can do, and proof you watch what they actually do.
- How do I monitor AI agents for SOC 2?
- Give each agent a unique identity, record every run to a tamper-evident log, and alert on health and behavior drift (CC7.2–CC7.4). KollGuard's Agent Watch does exactly this and maps each agent's activity to the relevant Trust Services Criteria, so the run history doubles as audit evidence.
- Is an over-privileged agent a SOC 2 finding?
- It can be. CC6.3 expects least-privilege authorization. An agent holding broad or stale permissions it does not use is the same control gap as an over-privileged employee, and an auditor sampling access will treat it the same way.