SOC 2 and AI agents: what auditors will ask about
Your last SOC 2 audit was calm. This year the auditor has read about AI coding agents, and the questions have changed. Agents that run commands, read source code, and resolve credentials on developer machines now sit inside the scope of your control environment, and auditors are learning to ask about them. The questions are predictable. Here is what they will ask, and what a defensible answer looks like.
Who has access to what — and what is watching them?
The access-control criteria require you to know who can reach sensitive data. With agents, the answer is not a person. An agent runs under a developer’s account or a service account, and the commands it runs were decided by a model. Auditors will ask how you distinguish agent-driven access from human access, and how you monitor it. A defensible answer needs an audit trail that records agent sessions as their own actor: what the agent invoked, when, and with what outcome. If your logs cannot tell an agent’s credential resolution from a developer’s, expect follow-up questions.
Where do secrets live, and who can read them?
Auditors will ask about your secret store: where credentials are held, how access is granted, and whether agents can read the store directly. The uncomfortable answer is often “agents have the same keys as the developer, because they run in the same shell.” The stronger design is a broker: agents receive credentials only for the specific command they run, injected at spawn time, and never hold the master secret. Auditors generally accept that pattern because it produces evidence — a per-resolution event — instead of a vague statement that the agent had access to everything.
How are credentials protected in transit and at rest?
Expect questions about encryption of secrets at rest, and about the paths credentials take when an agent uses them. One detail matters: secrets passed through environment variables of a subprocess are visible to anything that reads /proc, so auditors may ask how you avoid putting tokens in command arguments or plain files. Session keys carried through environment variables rather than argv, short-lived tokens, and refresh-token rotation make for cleaner answers.
Is monitoring actually enabled?
SOC 2 common criteria include system monitoring. Auditors will ask what you monitor on agent workstations, and they may ask for evidence: a sample of audit entries, a log of denied actions, proof that secrets were redacted from logs. They will also ask what happens when monitoring fails. A system that keeps running silently without logs is a finding waiting to happen.
Prepare evidence, not promises
Auditors do not take your word; they take configuration, logs, and test results. Before the audit, generate samples: an agent session that resolves a credential and runs a command, the audit entry it produced, and the redacted output. A credential broker like trustless (https://github.com/ikkun1222/trustless) makes this concrete. It reads an existing pass or Bitwarden store, injects secrets into subprocess environments, and writes an audit log of every injection and denial — evidence you can show rather than describe. Its token handling also fails closed: an invalid Bitwarden session key is rejected rather than retried.
The audit is a rehearsal for the incident
A useful side effect: the evidence an auditor asks for is the same evidence an incident investigator will need. If you can answer the auditor’s questions from logs alone, you are also prepared to answer them during an incident.
What would your auditor find if they asked for this quarter’s agent activity log right now?