AI penetration testing checklist for evidence-led tests

What belongs in an AI penetration testing checklist?

The checklist must cover operational controls and security outcomes. Authorization and scope protect the organization and the target. Agent configuration determines which actions are possible. Evidence review determines whether an output becomes a finding. Retesting determines whether remediation actually closes the original path.

A checklist is not a promise that a model will behave safely. It is a set of gates enforced by the surrounding system and the security team. Keep decisions, owners, and artifacts in the engagement record so a reviewer can see what was approved and why.

• Written authorization and named engagement owner.
• Exact assets, accounts, exclusions, and testing window.
• Model, tool, credential, and network boundaries.
• Approval policy for impact-bearing actions.
• Evidence and artifact ownership after the run.
• Finding, remediation, and retest definitions.

How do you define authorization and scope?

Record who authorized the test, which legal entity owns each target, the permitted time window, and the exact domains, IP ranges, applications, APIs, and cloud accounts in scope. List exclusions explicitly. A bare instruction such as “test production” is not a usable scope.

Translate the authorization into machine-readable task boundaries. The agent should see an allow list, a deny list, and a rule for ambiguous assets. Link the authorization record to the task so an operator can resolve an unexpected host without relying on chat history.

1. 01
   Authorize

   Store the named approver, written permission, target owner, and testing window.

2. 02
   Enumerate

   List domains, hosts, apps, APIs, accounts, and roles covered by the test.

3. 03
   Exclude

   Record third-party systems, destructive paths, personal data, and forbidden actions.

4. 04
   Enforce

   Mirror scope in asset allow lists, network policy, and task-level rules.

How should targets and test identities be prepared?

Use dedicated test accounts with only the permissions required for the scenario. Record the role, tenant, and starting state for each identity. If production data is reachable, define how personal or regulated records will be avoided and how screenshots or logs will be redacted.

Prepare a baseline for the target: deployed version, feature flags, seed data, network position, rate limits, and known findings. A baseline lets reviewers distinguish a real change from an environment difference and prevents workers from spending time repeating already-solved paths.

• Dedicated accounts and least-privilege credentials.
• Known deployment version and feature configuration.
• Representative data with sensitive records excluded or synthetic.
• Reachable and unreachable networks documented separately.
• A clean starting state for retesting.

How do you configure agent tools and approvals?

Classify each tool and action by potential effect. Read-only discovery can use a lower-friction rule. State changes, credential access, bulk extraction, and lateral movement require a stronger gate or an outright deny rule. The model prompt is not a security boundary; the control plane must enforce the decision.

Choose the model provider, network egress, tool versions, retry behavior, output limits, and approval owner before the run. Test the rules with a harmless request. A guardrail that has never blocked a test is an untested assumption.

What should operators monitor during an AI pentest?

Watch task progress, tool calls, approval requests, outbound traffic, model errors, loop detection, and budget consumption. The goal is not to read every token. It is to detect a run that is outside scope, repeating a dead end, creating unexpected load, or accumulating sensitive data.

Define stop conditions before execution: a critical service error, a rate-limit breach, an unexpected target, a destructive request, or a model loop. The operator must be able to pause the task, revoke credentials, and preserve the evidence gathered to that point.

• Alert on new hosts or domains outside the allowed asset set.
• Track approvals and pending sensitive actions in real time.
• Monitor error rate and response latency for target impact.
• Retain evidence before stopping or restarting a task.

How do you validate and document findings?

Separate confirmed vulnerabilities, unresolved hypotheses, and informational observations. For a confirmed issue, preserve the role, preconditions, request or command sequence, raw output, observed impact, and evidence timestamp. A summary written by the model is not a substitute for the underlying artifact.

Assign an owner and a remediation status only after validation. Impact-bearing findings need a human review before further exploitation. Keep the original evidence immutable so the retest can compare the same path after the fix.

• One owner for evidence quality and one owner for remediation.
• Explicit state: confirmed, hypothesis, observation, or false positive.
• Raw artifacts linked to the finding and task.
• Severity justified by observed impact and preconditions.

How do you retest and close the testing loop?

Replay the original path after remediation with the same role and context. Record the new deployment version, timestamp, requests, commands, and response differences. If the fix changes the preconditions instead of the vulnerable behavior, explain the compensating control.

Close the finding only when the original exploit path no longer reproduces and adjacent variants have been checked. Preserve the original evidence and retest artifact together. Then update the asset graph, task template, and checklist with the lesson so the next run starts from better context.

1. 01
   Freeze

   Record the deployed fix, configuration, and environment before retesting.

2. 02
   Replay

   Run the original artifact sequence with the same role and preconditions.

3. 03
   Compare

   Attach before-and-after evidence and inspect adjacent paths for regressions.

4. 04
   Close

   Record the reviewer, result, remaining risk, and final finding state.

What is the minimum safe AI pentest workflow?

The minimum workflow is explicit authorization, scoped credentials, enforced tool boundaries, approval for sensitive actions, preserved artifacts, human validation, and retesting after remediation. Each control has a named owner and leaves a record.

A complete checklist converts autonomous activity into an accountable security process. It also gives the next run better evidence and stronger scope instead of starting from an empty prompt.