AI penetration testing that proves what is exploitable

What is AI penetration testing?

AI penetration testing is an offensive security workflow where an AI system decides which next test is most useful, invokes security tools, interprets their output, and adapts its plan. A useful system connects each finding to the request, response, command, or exploit evidence that supports it.

That makes AI pentesting different from asking a chatbot for a vulnerability list. The agent has a target, a scope, tools, guardrails, and a persistent record. It also differs from a one-off manual engagement because the same workflow can run again after a deployment, a new asset appears, or a vulnerability is patched.

ARTEX approaches the workflow as an isolated lab exercise with an asset graph and an exploration graph. The planner maintains the next objectives while workers explore assets and record what they observe. Human approval remains available for sensitive actions.

• The target must be owned by the operator or covered by written authorization.
• Scope, exclusions, and destructive-action rules should be defined before a run starts.
• Every serious finding needs reproduction evidence, not only a model-generated narrative.
• The workflow should produce a retest result after the remediation is applied.

How does an AI agent run a penetration test?

A practical AI pentest follows a closed loop. The system first extracts the authorized scope, then maps reachable assets and application behavior. From there it forms hypotheses about weaknesses, selects tools, executes the least invasive test that can confirm or reject each hypothesis, and writes the evidence back into its working context.

The evidence loop matters more than raw autonomy. When a request succeeds, the agent needs enough context to explain where it went, what changed, and whether the result proves exploitability. When a test fails, that result should also be retained so the next worker does not repeat the same dead end.

1. 01
   Scope

   Identify domains, applications, IP ranges, accounts, and explicit exclusions.

2. 02
   Map

   Build an asset inventory and connect discovered services to likely attack paths.

3. 03
   Hypothesize

   Turn observations into testable claims about authentication, access, injection, or exposure.

4. 04
   Validate

   Run focused tools and preserve the requests, outputs, and resulting state.

5. 05
   Record

   Attach the finding to its task, asset, commands, traffic, and confidence level.

6. 06
   Retest

   Re-run the same path after remediation and record whether the issue still reproduces.

How is AI pentesting different from a vulnerability scanner?

A vulnerability scanner is optimized for broad signatures and repeatable checks. An AI pentesting agent is optimized for a sequence of decisions across a live application. The scanner asks whether a known condition exists; the agent asks what effect one observation has on the next possible test.

Neither model is automatically better. Scanners are fast, cheap, and useful for broad hygiene checks. AI agents can connect context across pages, APIs, authentication flows, and tool output, but they need tighter guardrails because their behavior is less deterministic.

What evidence should an AI pentest produce?

A credible report lets another engineer understand and reproduce the issue without trusting the model. At minimum, it should identify the affected asset, summarize the security impact, show the request sequence, preserve relevant tool output, and state whether the action was performed against production or an isolated environment.

The report should separate confirmed vulnerabilities from hypotheses and informational observations. Severity labels are useful only after reproduction. A finding that depends on an authenticated role should record that role and the preconditions that made the action possible.

• Scope and exclusions used for the run.
• Affected asset and endpoint, including the relevant request and response.
• Commands or tool calls that produced the evidence.
• Preconditions, privileges, and steps required to reproduce the issue.
• Confidence, impact, and remediation hypothesis.
• Retest status after the fix is deployed.

How do you run AI pentesting safely?

Start with an owned lab environment or a tightly scoped staging deployment. Define a deny list for destructive paths, require approval for sensitive commands, and record outbound traffic. Do not treat an LLM prompt as a security boundary.

ARTEX records traffic, exposes command activity, and supports interception rules and approval records. Those controls are operational aids, not a substitute for legal authorization, change control, or senior review of critical findings.

• Use a dedicated test workspace whenever the target could contain customer data.
• Set rate limits and exclude destructive HTTP methods or business actions.
• Review model credentials, network egress, and tool permissions before the run.
• Keep production changes reversible and time-box active testing.
• Escalate impact-bearing findings to a human security owner before further exploitation.

What should a credible AI pentesting workflow include?

Evaluate the complete engagement path, not only the agent demo. A credible workflow starts with authorization and scope, makes execution observable, keeps evidence connected to the finding, supports remediation ownership, and can repeat the original test after a fix. These are operational requirements that remain useful even when the underlying model changes.

Ask the vendor to demonstrate an unsuccessful test and a blocked action as well as a successful exploit. Those examples reveal how the system handles uncertainty, how quickly an operator can intervene, and whether the evidence trail remains coherent when the agent does not get the result it expected.

• Authorization and scope are explicit, editable records.
• The product identifies which model and tools executed each step.
• Findings separate confirmed behavior from speculative risk.
• The console exposes traffic and commands without requiring another system.
• Retesting can be assigned and completed after remediation.

Where does ARTEX fit in a security program?

ARTEX is a console for running autonomous security agents against authorized targets. Its planner and workers share an asset graph and an exploration graph, while findings, traffic, commands, and approvals stay attached to the task. The system can be self-hosted as a single binary or Docker Compose stack, and the source is available under AGPL-3.0.

Use ARTEX for recurring reconnaissance, web and API testing, lab research, and retesting known findings. Keep manual testers for judgment-heavy engagements and use deterministic scanners for broad regression coverage. The strongest program combines all three instead of claiming one method replaces the others.