Put the AI pentester in a test cell

Imagine an agent finds an “import from URL” feature in a staging SaaS application. It proposes an SSRF test, follows the response into a new host, and keeps exploring because the next page looks relevant. The reasoning may be impressive. The operation is still a failure: the agent expanded scope on its own.

An AI pentest agent should be a planner inside a controlled toolchain, not a shell account with a prompt that says “stay in scope.” Give it verified application context, narrow tools, and evidence-producing tasks. Keep authorization, scope, network reach, credentials, and destructive actions outside the model’s control.

That design does not replace a professional penetration test. It makes selected parts of one faster to repeat and easier to inspect.

Decide what “AI penetration test” means before buying a tool

Teams often mix together different jobs:

• AI as the tester: an agent maps a conventional web application or API, forms hypotheses, selects security tools, interprets responses, and drafts findings.
• AI as the target: a red-team harness probes an LLM application for prompt injection, data leakage, unsafe tool use, policy bypass, or failures that emerge across a conversation.

The toolchains overlap at the reporting and governance layers, but the tests do not. A web scanner does not tell you whether a support agent can be manipulated into revealing another customer’s records. An LLM probe does not tell you whether the same service has broken object-level authorization on its REST API.

The OWASP GenAI Red Teaming Guide treats model evaluation, implementation testing, infrastructure assessment, and runtime behavior as distinct parts of the job. For ordinary SaaS controls, the stable OWASP Web Security Testing Guide and OWASP ASVS remain stronger starting points than an open-ended agent prompt. They give the test a defined coverage model and explicit requirements.

Use both tracks when the SaaS product contains AI features. Do not let the novelty of the model hide the ordinary web, API, identity, tenancy, and cloud boundaries around it.

The test cell is a policy boundary, not just a staging URL

Before the agent sends a request, the application owner and security lead should approve a machine-readable engagement manifest. NIST’s security-testing guidance puts planning, legal and policy considerations, safe execution, evidence handling, analysis, and reporting around the technical work; those controls still apply when software chooses the next test NIST SP 800-115.

A useful manifest looks more like a firewall policy than a prose prompt:

targets:
  hosts:
    - "staging.example.test"
  accounts:
    - "security-test-admin"
    - "security-test-member"

allowed:
  - "passive inspection"
  - "authenticated crawling"
  - "approved request replay"

requires_human_approval:
  - "active vulnerability scan"
  - "file upload"
  - "out-of-band callback"
  - "state-changing request"

blocked:
  - "scope modification"
  - "production access"
  - "credential extraction"
  - "persistence"
  - "denial-of-service testing"

The enforcement layer must check the destination after DNS resolution and redirects, not merely compare the agent’s original URL with a list. It should also restrict outbound network access, available HTTP methods, tool inventory, credentials, and callback domains. The agent may propose a broader test. It must not be able to grant itself permission.

Use test tenants with synthetic data and accounts representing the application’s real roles. Resettable state matters because even a correctly scoped request can send mail, fire a webhook, consume inventory, alter billing state, or trigger downstream automation. PortSwigger warns that security-testing software can damage targets and should only be used where the owner has authorized the test and accepted the risk Burp Suite documentation.

The same rule applies to secrets. Issue credentials for the test run, scope them to the selected tenant and role, and revoke them when the run ends. The agent should receive a handle that its tool layer exchanges for a credential, not the raw secret. The deeper design is covered in Give your agent a key, not the keyring.

Put deterministic tools underneath the agent

The agent is useful at choosing a path through evidence. It is a poor place to implement HTTP parsing, browser state, scan checks, rate control, or audit logging from scratch. Mature tools already do those jobs and leave artifacts a tester can reproduce.

Tool	Where it fits	Let the agent do	Keep outside the agent
OWASP ZAP Automation Framework	Repeatable web and API baseline in CI or a test environment	Propose an automation plan, classify alerts, and identify coverage gaps	Approved target context, authentication config, active-scan policy, and pass/fail thresholds
Nuclei	Focused, template-based checks for known exposures or a finding the team wants to retest	Select from an allowlisted template set and turn a confirmed finding into a regression check	Template review, disruptive-test exclusions, rate controls, and result verification
Burp Suite with Burp AT	Human-led investigation of web and API behavior	Map a defined target, inspect traffic, form hypotheses, replay requests, and assemble evidence	Scope, enabled tools, approval rules, sensitive-data decision, and final finding validation
PyRIT	Structured red teaming of a generative-AI application	Run approved attack scenarios, apply configured prompt converters, and use configured scorers	Test objectives, target credentials, data retention, scorer validation, and safety review
garak	Broad probing of a model or dialog endpoint for unwanted behavior	Run selected probes and preserve failing interactions	Probe selection, endpoint isolation, interpretation, and product-level impact analysis

ZAP’s Automation Framework expresses the target environment, authentication, and ordered scan jobs in a configuration file. That makes it suitable for a reviewed baseline the agent can invoke without inventing scanner behavior.

Nuclei templates encode requests, matchers, and extractors in YAML, which makes a confirmed check portable. ProjectDiscovery also notes that community templates can produce false positives and that some fuzzing templates may cause denial of service, so “run everything” is not a safe agent policy Nuclei Templates FAQ.

Burp AT is a current example of the stronger architecture: the agent works through Burp’s tools, while Burp checks ordinary tool calls against scope and configured permissions and captures HTTP activity for review. That boundary has an important exception: PortSwigger says custom code run through Burp AT’s scripting tools can send requests outside Burp scope. Disable those tools when scope must be a hard boundary; per-tool approval settings apply only in Manual mode.

Burp AT is a commercial, cloud-assisted product rather than a neutral standard. Its trust documentation says that requests, responses, attached resources, tool calls, and tool results may be sent through PortSwigger’s AI infrastructure without redaction. It also says conversation and audit data are retained indefinitely, provider processing occurs in US data centers, and customers cannot select a processing region Burp AI trust and data handling. A team that cannot accept that data path and retention policy should use a different setup.

For an AI feature itself, PyRIT provides separate concepts for targets, attacks, prompt transformations, and scoring. That separation is useful because a generated attack and its success judgment should not be collapsed into the same opaque model call. Microsoft’s documentation also shows both deterministic and LLM-based scorers; probabilistic judgments still need validation against the application’s real policy and expected behavior PyRIT scoring.

garak supplies probes and detectors for model and dialog-system failures such as prompt injection, leakage, jailbreaks, and unsafe outputs. It is not a substitute for testing the web application, API authorization, or business workflows that surround the model.

Encode skills that produce reviewable work

An agent “skill” should be a small procedure with a clear input, output, allowed tool set, and stop condition. It should not be a persona such as “act like an elite hacker.” Start with skills that improve discipline:

Scope gate

Read the engagement manifest, normalize the requested destination, and refuse any request whose host, account, method, or tool is not allowed. Return the rejected action and policy reason. This skill is useful, but the tool gateway must repeat the check because instructions are not a security boundary.

Role and tenant map

Build a matrix of routes and business actions against test identities. Compare what the same object looks like to an owner, another tenant, a lower-privilege user, and an unauthenticated user. The OWASP API Security Top 10 separates object-, property-, and function-level authorization failures; a single “check access control” prompt is too vague to cover them.

Controlled request mutation

Start from a captured baseline request, change only the relevant element, replay it through the approved proxy, and compare status, headers, body, timing, and downstream side effects. Stop when the next mutation would cross scope or change durable state without approval. This produces better evidence than asking the model to improvise a large batch of payloads.

Finding evidence packager

Require the affected asset, preconditions, sanitized request and response, observed result, expected result, impact hypothesis, relevant standard or control, reproduction instructions, confidence, and remediation owner. Preserve raw tool output separately. A fluent narrative without reproducible evidence is not a finding.

Remediation retest

Replay the smallest confirmed proof against the fixed build, run the corresponding regression template where one exists, and record both the expected block and nearby valid behavior. A fix that blocks the proof but breaks a legitimate workflow is not complete.

AI tool-abuse scenario

For products with an agent or copilot, place approved adversarial text in content the product is expected to read. Test whether it can change tool choice, cross tenant boundaries, expose hidden context, or take an action without the required approval. Keep the target data synthetic and the downstream tools stubbed or reversible. This is where PyRIT or garak can complement, but not replace, application-specific test logic.

Store these skills in version control. Review tool names, arguments, expected evidence, and failure behavior. Pin the scanner and template versions used for an engagement. A skill that silently downloads a new payload set during a run has changed the test after approval.

Make the agent earn the next action

The operating loop should be evidence-gated:

• A human approves the manifest, test identities, tool set, data path, and stop conditions.
• Deterministic discovery imports the OpenAPI description, authenticated traffic, route inventory, and prior findings.
• The agent turns that evidence into a coverage map against WSTG, ASVS, or the API Security Top Ten.
• The agent proposes a focused test with its target, preconditions, expected signal, side effects, and rollback.
• The policy layer allows, blocks, or sends the tool call for human approval. The decision model in Decide which agent tool calls need human approval is a useful companion.
• The approved tool executes and stores raw traffic. The agent may explain the result, but it cannot edit the original evidence.
• A qualified tester reproduces material findings and decides severity. Confirmed proofs become regression checks where practical.

This loop is deliberately slower than full autonomy. Approval should sit at the transitions where a request becomes active, state-changing, externally visible, or hard to reverse. Passive parsing and coverage bookkeeping can proceed without interruption.

Know when the agent is the wrong tool

Do not use an AI pentest agent against a system you do not own or have explicit authorization to test. Do not use a cloud-hosted agent when the test data cannot leave your controlled environment. Do not use one as the sole assessor for a release where independent testing, contractual certification, or specialized human expertise is required.

Conventional alternatives remain strong:

• Run a reviewed ZAP plan or commercial DAST scanner for repeatable baseline coverage.
• Hire an independent penetration tester for adversarial depth, business-logic testing, and an external view of risk.
• Use code review, SAST, dependency scanning, infrastructure scanning, and threat modeling earlier in delivery; a pentest is not a substitute for secure development.
• Use a deterministic integration test when the expected security behavior is already known.
• Keep a human in Burp for ambiguous logic and use AI only to explain traffic, organize evidence, or suggest the next hypothesis.

The costs are not limited to model usage. Someone must maintain the test environment, synthetic identities, scope policy, approved templates, data-retention rules, tool gateway, evidence store, and evaluation set. False positives still consume engineering time. False negatives are worse because an articulate report can make incomplete coverage look authoritative.

Review the setup whenever the application adds a host, role, integration, AI model, tool, memory store, or data processor—and whenever a scanner, template library, or agent service changes behavior. The standards give you the testing map. The tools provide repeatable mechanics. The agent can help navigate both, but it should never be the authority that decides where it is allowed to attack.