SOC 2 evidence for AI agents

Security questionnaires and audit walkthroughs have started asking for SOC 2 evidence for AI agents, and the questions turn out to be unexciting. They are the access-control questions reviewers have always asked, pointed at a new kind of caller.

That is the good news, because your existing control narrative largely transfers. The awkward part is that the artifacts were built for humans clicking things in a browser, and the caller here is a model acting on somebody's behalf.

This is where each artifact comes from, and where the gaps are. Certification status is not something this post can speak to; that is on the security page, which is the thing to cite.

SOC 2 evidence for AI agents, in four questions

Stripped of framework-specific language, a reviewer wants:

1. Who could reach what? The access model, as configured, at a point in time.
2. Who decided that, and when? The authorization trail for access grants themselves.
3. What actually happened? The activity record.
4. What happened when somebody left? Deprovisioning, demonstrated rather than described.

If AI access in your organization is happening by copy and paste, all four have the same answer, which is that there is no artifact. Not a weak one. Question three in particular produces nothing at all, because pasting into a chat box leaves no trace anywhere in your estate. That is worth stating internally in those terms, because it is the fact that makes the project fundable.

If the access runs through a governed path, each question has a specific source.

Question one: who could reach what

The evidence is the access model, and it has three layers that a reviewer will want kept apart.

Roles say what somebody can do to the system: manage members, write governance rules, read the audit log, run tools at all. Each person holds exactly one role, which turns out to matter a lot in a walkthrough. When roles stack, answering "what can this person do" means combining several grants, and a reviewer watching you do that arithmetic live is a reviewer forming an opinion. One role per person makes it a lookup.

Sharing says which connected accounts and shared toolboxes somebody has been given. The rule worth stating explicitly, because reviewers ask it in one form or another: a member sees only what they own or what was explicitly shared with them, and no administrative permission silently widens that listing. Administrators included.

Restrictions say which systems and which individual operations a role or a person may reach. This is the layer that answers the question a reviewer is actually driving at, which is whether the boundary is the system or the operation. Being able to say that the support role can read tickets and cannot delete them, and to show the rule, is a materially better answer than showing that support has helpdesk access.

There is a fourth thing worth demonstrating rather than describing: what the person actually receives. A restricted tool is never advertised, so the tool list a given person's client is handed is the effective access, resolved. Showing that in a walkthrough is more convincing than showing configuration, because it is the output rather than the intent.

Question two: who decided

Grants are themselves actions, and they are recorded like any other: invites, role changes, restriction edits, shares, connection creation, token issuance, single sign-on and provisioning configuration. Filterable by actor, by category and by time, which is the shape a sample request arrives in.

Two details that come up.

Actor attribution survives the actor. A departed member's identifier still resolves, rendered as a former member rather than dropped or left as a raw id. A trail with unattributable entries in the sampled window is a finding, and it is usually caused by a well-meaning deletion.

Support access is attributed as support access. When our staff act while impersonating a user in your organization, the entry says so. It used to appear as your own administrator doing it, which is a log telling you something false about your own organization. Worth asking any vendor how their impersonation shows up in your trail, because the default answer in this industry is that it does not.

Question three: what happened

This is the question with the most new surface, and the one worth preparing a real export for rather than a screenshot.

Per tool call, the record carries the operation and tool, the specific connected account it reached, the classification of the operation, whether it was approved, the outcome, and an error code when it failed.

Five properties a reviewer will probe, and what to say:

One entry per attempt, including failures. A trail of successes cannot answer what somebody tried and was prevented from doing, which is the question a control is meant to evidence. A policy refusal is also kept distinct from a call that reached a third party and failed there, since only one of those two demonstrates your control working.

The account is the one actually reached. Taken from the execution rather than from the request, because those can differ when an app has several accounts connected. An entry naming the app and not the account cannot support a scoping claim.

AI actorship is a field. Recorded at the time of the action, from the code that knows, as one of a closed set of actor kinds. Not inferred later from a user agent. If you intend to make any control statement that distinguishes human from assistant activity, this is the property that supports it, and inference does not.

Argument values are not logged. Names and counts, never values. Reviewers occasionally expect full request capture; the answer is that an audit trail accumulating a second copy of customer data is a larger problem than the one it solves, and the names carry the investigative value.

Third-party error text does not reach the trail. Failed calls carry two separate error strings, one for the caller derived from the vendor's response and one for the trail that is never derived from it. This matters more than it sounds because the trail is org-visible, readable by the in-product assistant, and forwarded to whatever destination you configure, so a vendor's error body reaching it is third-party payload leaving through the log pipe.

On isolation: each organization's logs live in their own tenant, and that separation is enforced structurally rather than by a filter in each query. The distinction is worth making because a dropped filter leaks and a wrong tenant returns nothing, and only one of those is a failure you find.

On export: events forward to your own destination so this lands in the collection you already run. Datadog is implemented. Splunk HEC and Microsoft Sentinel are accepted in configuration but are not delivering yet, and you should not build a control around them until they are.

On timing: the trail is eventually consistent, so an entry can take a moment to appear. It is also never allowed to fail the action it describes, which is why it can be queued.

Question four: deprovisioning

The one most often described and least often demonstrated, and increasingly the one reviewers ask to see performed.

Two mechanisms, with genuinely different timing, and being precise about which is which reads as competence rather than as a caveat.

On the next call, no cache: revoking a client authorization, removing a member, suspending a member. Removal and suspension revoke every live authorization in the same transaction as the membership change, so there is no window where the membership is gone and a token still works.

About two minutes: changing a role, editing a restriction. These resolve through a short cache.

Both are defensible. Presenting them as one number is not, and a reviewer who finds the difference themselves will wonder what else was rounded.

The other half of deprovisioning is connections. Removing somebody whose connected account a shared toolbox still points at is refused until each one is explicitly transferred or deleted, which turns a silent breakage into a recorded decision. A privately connected account is never transferable at all and is deleted instead. That mechanism is worth walking a reviewer through, because it evidences a control that most organizations describe and cannot show. It is covered in detail in offboarding someone who left an agent behind.

The gaps, said out loud

Raise these yourself. A gap you disclose is a scoping note; the same gap found by a reviewer is a finding.

Organization deletion leaves a log residue. Tearing down an organization removes the rest of the workspace but has no path to purge its log tenant, and the deletion reports that residue by name rather than returning success. If you have a retention or erasure commitment that depends on complete removal, this is the sentence to put in front of your privacy counsel now.

Residency is not uniform across regions. Two of the three regions pin compute and storage to a jurisdiction. The third is a placement preference and is best-effort. If a customer contract promises regional residency, check which of the two you are in rather than assuming the region name settles it.

Not every operation classified as a write is equally reversible. The scope ladder treats deletes as the destructive tier. A vendor's own archive or revoke operation, exposed under a custom method name, sits in the write tier, because guessing destructiveness from a name would make every benign archiver demand the most alarming scope. If a specific operation matters to a control, restrict it by name rather than relying on the tier.

What to have ready

Before the walkthrough:

1. A current export of roles and restrictions, with one worked example of a role that is deliberately narrow.
2. A screenshot of a real tool list from a restricted person's client, next to the rule that produced it.
3. A raw activity export covering a real window, not a demonstration workspace. Check it includes failures.
4. One offboarding, performed end to end, with the refusal and the resolution visible.
5. The gaps above, written down, with what you do about each.

The control model those artifacts come from is described in how roles and restrictions compose, and the record shape behind item three in what an AI audit log has to capture. For current certification status and reports, the security page is the source.