How to Run an AI Controls Walkthrough With an External Auditor

What an AI Controls Walkthrough Is, and Isn't

A controls walkthrough, under standard audit methodology (AU-C 500), combines inquiry, observation, and inspection to trace a control activity from its triggering event through system processing to a recorded outcome. Applied to AI agents, this means tracing a specific action, such as a tool call or data access request, from the moment it was initiated through the policy decision that permitted or blocked it, to the log entry that recorded the result.

This is a technical audit exercise, not a general discussion of AI risk posture. Auditors testing operating effectiveness, as required under SOC 2 Type II, will expect evidence that controls functioned consistently across a defined period, not just that they exist. Type I engagements assess design only, at a single point in time. Governance teams should confirm which type of assessment applies before structuring the session, since the evidence bar differs substantially.

No AICPA, ISO, or NIST publication currently defines AI agent runtime controls, such as policy enforcement or tool-call permissions, as named audit categories. Enterprises must translate general access-control and logging requirements from frameworks like ISO/IEC 27001:2022 and NIST SP 800-53 into agent-specific evidence themselves, and document that mapping as part of their own governance record.

Preparing Evidence Before the Session

Runtime Evidence Auditors Typically Request

Given existing framework language, auditors evaluating AI agent controls are most likely to request evidence in four areas. First, policy enforcement records showing that a given action was evaluated against a defined policy before execution, which maps to SOC 2 security criteria and ISO 27001's monitoring requirement under 8.16. Second, least-privilege access evidence for agents, mapping to ISO 27001 controls 5.15 and 8.3 on access restriction, and to the Access Control family in NIST SP 800-53.

Third, tool-call restriction logs demonstrating that an agent was prevented from, or permitted to, invoke a specific tool or system, which should be separable from general application logs so the auditor can trace individual control decisions rather than sift through unrelated activity. Fourth, audit and accountability evidence consistent with ISO 27001's 8.15 logging requirement and the AU control family in SP 800-53, showing that agent activity was recorded and retained. None of these categories are named explicitly as AI-specific requirements in current standards, so the burden is on the enterprise to present agent runtime logs in a way that clearly satisfies the underlying access-control and monitoring language auditors already test against.

Avoiding Common Evidentiary Gaps

• Retain logs for the full review period: point-in-time snapshots are insufficient for Type II testing; logs must be queryable across the entire audit window.
• Separate enforcement logs from application logs: auditors need to trace specific control decisions, not filter them out of general system activity.
• Document your own mapping methodology: since no AI-specific audit standard exists, record how internal controls correspond to external framework clauses as part of governance records.
• Run an internal dry-run first: rehearse the same inquiry, observation, and inspection sequence auditors will use to surface gaps before the external session.
• Fix ownership before the session: determining who answers for a given control during the walkthrough itself signals unclear accountability.

Where Runtime Governance Tooling Fits

The evidence a controls walkthrough requires, policy enforcement decisions, agent identity and permission records, tool-call logs, and least-privilege mappings, is generated continuously by systems that enforce these controls at runtime rather than assembled after the fact. Trussed AI provides runtime governance and security for enterprise AI agents, including runtime policy enforcement, agent identity and permissions, tool approval workflows, and audit logging, which can support the underlying evidence categories described above.

This is relevant to walkthrough preparation because it shifts evidence generation from a manual, pre-audit exercise to a byproduct of normal runtime operation, but it does not substitute for the governance work of mapping that evidence to specific framework clauses and assigning control ownership.