The questionnaire arrives as a new tab in a spreadsheet you have answered for years. Row 214 asks you to describe your controls over AI systems with access to customer data. Row 215 asks for an inventory. The security team attaches the AI acceptable-use policy, writes "Yes, see policy" and moves on. Three weeks later the customer's reviewer follows up: please provide the list of AI agents in production, the approval record for each one's access, and an example of an action your controls blocked.
That follow-up is where most programs stall, and a SOC 2 examination goes the same way once agents are in scope. The auditor does not ask whether you have an AI policy. They ask for the population of changes to agent access during the period and select items from it. If that population lives in chat threads and people's memory, there is nothing to sample. Below are the questions reviewers actually ask, with the answer that holds up.
"We have an AI policy. Why isn't that enough?"
Because a policy is design, and auditors test operation. A SOC 2 Type 2 report makes the distinction explicit: the auditor's opinion covers whether controls were designed appropriately, were in operation on a specified date and were operating effectively over a specified period [2]. A policy saying agents need approval for sensitive actions is design. Twenty approval records drawn from across the period, each naming the approver and the action, are operation.
The frameworks say the same in their own terms. ISO/IEC 42001, the AI management system standard, describes a system to be established, implemented, maintained and continually improved, and applies to any organization that provides or uses AI-based products or services [3]. The NIST AI RMF describes outcomes rather than documents, such as mechanisms being in place to inventory AI systems [4]. Each reviewer is looking for the mechanism and its output.
An auditor samples items from a complete population and asks for a dated record of each. Agent programs usually fail at the population, because there is no full list to sample from, or at the evidence, because screenshots are not tied to an item or a date.
Agent programs fail at one of two steps. A sample only means something if it comes from a complete population, so an auditor who cannot get a list of every agent, or of every access change, cannot test anything downstream. And a screenshot of a settings page shows the configuration today, not on the date of the change the auditor picked.
| Question | What the reviewer is testing | Evidence that satisfies it | Weak answer |
|---|---|---|---|
| Which AI agents do you run, and who owns each? | Completeness of the inventory | Inventory with owner, purpose, model, credentials and data classes, reconciled monthly against discovery of keys, app grants and AI usage in code | A spreadsheet last edited at launch |
| What can each agent access, and who approved it? | Least privilege and authorized changes | Per-agent tool and credential list with a change history naming requester, approver and date, plus a quarterly access review sign-off | "Access is restricted by the system prompt" |
| Which actions need a person, and did that happen? | Human oversight operating as designed | Approval rules as configuration, approval records for sampled actions with approver, arguments and outcome, and records of actions blocked for lack of approval | A policy saying sensitive actions are reviewed |
| How do you know when an agent misbehaves? | Monitoring coverage and response | Alert rules, the share of agent traffic they cover, and sampled alerts traced to closed triage tickets | "Our model provider monitors for abuse" |
| How do you handle AI incidents? | A working incident process for AI-specific failures | Incident procedure with AI categories, a log of AI incidents and near misses, and one tabletop record from the period | The general incident policy, unchanged |
| Which vendors use AI on your data or act in your systems? | Third-party risk coverage | Vendor register with an AI flag, review records for AI features and vendor agents, and contract terms on training use and subprocessors | The vendor's marketing page on AI safety |
"How do I know this list of agents is complete?"
Show a reconciliation, not just a list. The NIST AI RMF asks for mechanisms to inventory AI systems, resourced according to organizational risk priorities [4], and the reviewer's real question is completeness. Each month, compare the inventory with what you can discover independently: AI provider keys in your organization accounts, AI apps granted access in your identity provider, model SDKs and MCP configurations in your repositories. Record each difference and what you did about it. A reconciliation that found two unregistered agents and closed them is better evidence than one that never finds anything. Include the agents you bought and the ones contractors brought: they act with your credentials and belong in the population.
"Show me who approved this agent's access, and when."
List what each credential can actually do, not what it was meant to do, then show every change during the period with its requester, approver and date, and a periodic review in which the owner confirmed the access is still needed. Never offer system-prompt instructions as an access control. An auditor who accepts them as a control will test them, and they will fail.
"Pick an action that needed a person. Where is the record?"
This is the question with the most room for overclaiming. The record should show what was requested, including its arguments, who approved it, when, and what happened next. Without the arguments, a reviewer cannot tell whether the person approved the action that actually ran. Include the negative case too: an action that needed approval, did not get it and was blocked. MANAGE 2.4 in the NIST AI RMF asks for mechanisms to supersede, disengage or deactivate AI systems whose outcomes are inconsistent with intended use [4]. Approval and block records are the everyday form of that mechanism.
"How would you know if an agent misbehaved?"
Answer with coverage, not dashboards. MANAGE 4.1 calls for post-deployment monitoring plans that are actually implemented [4]. A dashboard screenshot shows that a dashboard exists. Coverage shows what share of agent traffic passes through the controls that raise alerts, and which agents sit outside them. Then trace three or four sampled alerts from detection to a closed ticket.
"What counts as an AI incident here?"
You do not need a separate AI incident process, but the one you have needs AI categories: a prompt injection that changed an agent's behavior, data disclosed through an agent, an agent action nobody authorized, and an agent that could not be stopped. MANAGE 4.3 asks that incidents and errors be communicated to relevant AI actors and that processes for tracking, responding to and recovering from them be followed and documented [4]. A near-miss log is persuasive because it shows the categories are in use.
"Which of your vendors run AI on our data?"
GOVERN 6.1 calls for policies and procedures that address AI risks from third-party entities, and MANAGE 3.1 for regular monitoring of third-party AI risks with controls applied and documented [4]. Flag in the vendor register which vendors run AI on your data or act in your systems, and attach the review record and resulting contract terms for each. A vendor agent that acts inside your systems belongs in the agent inventory as well.
Evidence assembled for the audit is the expensive kind
Tallis, a fictional 600-person billing software company heading into its second SOC 2 Type 2 period (the figures are illustrative), first answered with policies. When asked for the inventory, an approval record and the population of agent access changes, two engineers spent nine working days assembling them by hand, and found a marketing agent running on a personal API key, a contractor's coding agent with write access to the release branch, and two tool changes with no recorded approver. It then spent eight weeks making its controls produce their own records, and when fieldwork came, the population was an export and the sample was drawn in an afternoon.
Agent decisions, approvals, access changes and discovery scans write to one retained store as they happen, scheduled reviews add sign-offs, and saved queries turn the store into the package an auditor asks for.
- Record at the decision point. Each agent action produces one record: who acted, what was attempted, the decision, the rule that made it and the approver, if any. A record written by the control is stronger evidence than a log line the agent wrote about itself.
- Keep records append-only and retained past the end of the audit period, plus the time the auditor needs to sample. A Type 2 report covers a period of time [2], and a sampled item can come from any day in it.
- Save the queries. The access-change population, the approval sample and the monitoring coverage figure should each be a saved, versioned query, so next year's evidence is produced the same way.
- Schedule the reviews. A monthly inventory reconciliation and a quarterly access review, each with a sign-off record, turn two of the six questions into routine output.
- Record exceptions with an owner and an expiry date. Auditors accept a documented, time-limited exception far more readily than an undocumented permanent one.
Intertrace sits inline between agents and the models, tools and MCP servers they call, and records every decision as a structured event with who acted, what was attempted, the decision, the rule and layer that made it, and the evidence; events can be exported to your SIEM for retention. Approvals are recorded with the approver, and exceptions are named, scoped to one agent and expire. Read-only discovery of cloud accounts, repositories, identity-provider AI-app grants and AI provider keys supports the monthly reconciliation.
"Can we say we are 42001-ready?"
Not unless someone qualified said so. SOC 2 reports against the AICPA Trust Services Criteria, which cover security, availability, processing integrity, confidentiality and privacy [1]. Agents need no new criteria: they are systems and non-human users that logical access, change management, monitoring and vendor management already reach. ISO/IEC 42001 adds a management system for AI [3], and the NIST AI RMF organizes outcomes into govern, map, measure and manage [4]. One body of evidence can serve all three if each record is mapped to the controls it supports.
A mapping table shows reviewers where to look. It is evidence for their review, not an attestation. Only a CPA firm's opinion attests to SOC 2 controls, and only an accredited certification body certifies an ISO/IEC 42001 management system. Phrases such as "aligned with" or "42001-ready" invite the follow-up question of who said so, and the honest answer is usually that you did. The same applies to compliance pack exports from any tool, including Intertrace's: they are evidence for your auditor, not compliance.
Audit yourself before they do
Write one approved answer to each of the six questions, each pointing to its evidence rather than to a policy, so different people stop answering the same row differently. Then ask a colleague to play the auditor. They request the agent population and the access-change population for last quarter, pick three items from each, and ask for the dated record behind every one. Time it. If any item takes longer than an afternoon, or ends at a screenshot, you have found your first finding before the auditor did.
