An AI agent audit checklist should test who owns the system, which identity and authority it uses, where policy and human approvals constrain execution, and whether a reviewer can verify the resulting evidence. Copy the 10 review steps below into an audit workpaper, add a sample reference to each row, and record the result against the stated pass criterion.
Copyable 10-control AI agent audit checklist
For each row, capture the sampled system, execution, release, or incident identifier. A pass requires evidence that covers the selected sample and review period.
| # | Control area | Copyable review step | Evidence request | Pass criterion | Failure signal |
|---|---|---|---|---|---|
| 1 | Inventory and named ownership | Select an in-scope agent and reconcile it to the production inventory and accountable owner. | Inventory record, intended purpose, deployment scope, owner, risk tier, and last review date. | The deployed agent and its current owner appear in the approved inventory with a current scope and review date. | The agent is absent, duplicated, assigned to a team alias, or described with an outdated purpose. |
| 2 | Agent identity and delegation | Trace the agent identity and every delegated identity used during one sampled execution. | Service identity, credential issuer, delegation chain, session claims, expiry, and actor mapping. | Each action resolves to an authenticated agent or human identity and a bounded delegation path. | Shared credentials, unresolved actors, unbounded delegation, or missing expiry records appear in the sample. |
| 3 | Permissions and tool access | Compare effective permissions with the approved tool, MCP server, API, and data boundary policy. | Entitlement snapshot, tool catalog, MCP authorization, data scopes, exceptions, and access review. | Effective access matches the approved least-privilege scope and each exception has an owner and expiry. | Unused broad access, unapproved tools, stale exceptions, or production data access outside the approved boundary is present. |
| 4 | Human approval and override | Sample a gated action and verify the approval, approver authority, context presented, and override path. | Approval policy, request payload, decision record, approver identity, timestamps, and override log. | The action waits for the required authorized decision and preserves the complete approval context. | Self-approval, approval after execution, missing context, or an unusable stop and override mechanism appears. |
| 5 | Runtime policy enforcement | Reperform a policy decision for an allowed action and a blocked action using the recorded inputs and policy version. | Policy source, version, evaluation inputs, decision output, enforcement response, and test record. | The runtime enforces the recorded result consistently and the blocked test cannot reach the protected action. | Policy exists only as guidance, evaluations are missing, or a denied action still executes. |
| 6 | Execution lineage | Trace one business outcome from request through reasoning, tool calls, approvals, outputs, and side effects. | Correlation ID, inputs, model and prompt versions, tool calls, policy decisions, approvals, outputs, and timestamps. | The evidence reconstructs the complete execution in order and ties every side effect to its authorizing decision. | Broken correlation, missing tool results, mutable timestamps, or an unexplained side effect prevents replay. |
| 7 | Release and change evidence | Select a production change and trace authorization, testing, deployment, and post-release review. | Change request, code and configuration versions, test results, approver, deployment record, and rollback evidence. | The deployed version matches the approved artifact and required tests and approvals precede release. | Untracked prompt or policy changes, version mismatch, absent tests, or release before approval appears. |
| 8 | Incident response and revocation | Walk through a recent incident or exercise and verify containment, credential revocation, escalation, and recovery. | Alert, incident timeline, actions taken, revoked access, communications, root cause, and remediation owner. | The team can stop the agent, revoke its authority, preserve evidence, and track remediation to closure. | Revocation depends on manual discovery, evidence is overwritten, escalation ownership is unclear, or access remains active. |
| 9 | Retention and evidence integrity | Verify a retained execution record against the applicable schedule and its integrity proof. | Retention rule, legal or policy basis, evidence manifest, hash or signature, storage controls, and deletion record. | Records remain available for the required period and an independent verifier can detect alteration. | Undefined retention, incomplete manifests, unverifiable records, or deletion outside the approved process appears. |
| 10 | Sample selection and independent verification | Define the population, reproduce the sample selection, and independently verify the evidence for each selected item. | Population extract, sampling method, seed or selection logic, sample list, exceptions, and verifier results. | A reviewer can reproduce the population and sample and reach the recorded result from the exported evidence. | Management-selected examples, incomplete populations, irreproducible sampling, or evidence that depends on privileged system access appears. |
Set the scope and sample before testing
Start with a defined audit period, named system boundary, responsible owner, and complete execution population. Record the selection method before inspecting individual results. Risk-based samples can include high-impact actions, policy denials, human overrides, production changes, incidents, and a reproducible random selection from routine executions.
Map every exception to the control owner, affected population, severity, remediation date, and follow-up evidence. This creates a usable findings register and keeps isolated evidence gaps separate from population-wide control failures.
Preserve evidence that another reviewer can verify
Export the sampled records with a manifest that identifies source systems, collection times, versions, checksums or signatures, and known limitations. Keep the original identifiers so a reviewer can reconcile each artifact to the source population.
The enterprise audit framework provides the complete audit method. The audit-trails guide defines the execution record and replay path used by several checklist rows.
Frequently Asked Questions
What should an AI agent audit checklist include?
Include inventory and ownership, identity and delegation, permissions, approvals, runtime policy enforcement, execution lineage, release evidence, incident response, retention and integrity, and reproducible sample selection. Every item needs an evidence request, pass criterion, and failure signal.
How should an internal auditor sample AI agent activity?
Define the full population and period first. Select high-impact actions, denials, overrides, changes, incidents, and a reproducible sample of routine executions. Preserve the selection logic and reconcile every selected item to source evidence.
What makes AI agent audit evidence independently verifiable?
A reviewer needs stable identifiers, complete execution lineage, source and collection metadata, the applicable policy and software versions, and integrity proofs such as hashes or signatures. The export should support verification from the evidence package itself.
Key Takeaways
Use this checklist as the control-testing workpaper for the scoped sample. Record each result, attach the referenced evidence, route exceptions to named owners, and schedule follow-up testing against the remediation evidence.