Autonomous penetration testing with evidence at every step

What is autonomous penetration testing?

Autonomous penetration testing is an offensive security workflow in which an AI system decides what to test next, invokes security tools, reads their output, and updates its plan. The workflow can connect observations across application pages, APIs, identities, network services, and prior findings. That connected reasoning is the capability that separates an autonomous pentest from a list of fixed scanner checks.

Autonomy is a spectrum. A tool can use AI to explain scanner results, suggest a payload, execute an approved test, or run a complete sequence of tests. The highest level of autonomy is appropriate only when the system also enforces target scope and records enough evidence for another engineer to reproduce the result. ARTEX treats the agent as one part of a control plane that also includes tools, an asset graph, an exploration graph, traffic capture, and approvals.

• The agent maintains an objective instead of producing a single response.
• Tools turn reasoning into observable actions against authorized targets.
• Shared memory prevents workers from repeating the same dead end.
• Approvals interrupt actions that can change state or exceed policy.
• Evidence connects each finding to requests, commands, and output.

How does an autonomous pentest work?

The agent starts with an authorized scope and a measurable objective. It inventories reachable assets, frames hypotheses, chooses a low-impact test, interprets the response, and stores the result in persistent state. When the first hypothesis succeeds or fails, the planner uses that result to select the next objective rather than following a static script.

A reliable workflow separates planning from execution. The planner decides why a test matters, while workers run focused checks and return structured observations. The control plane enforces the boundaries. This separation reduces context overload, makes responsibility visible, and gives a reviewer a clear path from goal to test to evidence.

1. 01
   Authorize

   Record owned domains, applications, accounts, exclusions, and testing windows.

2. 02
   Map

   Build an asset inventory and identify services, roles, endpoints, and trust boundaries.

3. 03
   Reason

   Create testable hypotheses about access control, injection, exposure, or business logic.

4. 04
   Execute

   Invoke bounded tools and save requests, responses, commands, and outputs as evidence.

5. 05
   Validate

   Reproduce impact, separate confirmed behavior from speculation, and assign an owner.

6. 06
   Retest

   Run the same path after remediation and preserve the before-and-after result.

How is autonomous pentesting different from scanners and manual testing?

An autonomous pentest adapts across a sequence of observations. A DAST scanner runs a broader set of deterministic checks and is easier to repeat, but it does not reason deeply about how one response changes the next test. A manual pentest brings human creativity, business context, and judgment, but its cost and scheduling limit how often it can run.

The right operating model combines the categories. Use deterministic scanners for baseline hygiene, autonomous agents for frequent exploration and regression, and human testers for high-impact business logic and formal assurance. A useful platform makes the handoffs visible instead of implying that one method replaces every other control.

What evidence should an autonomous pentest preserve?

A finding needs enough evidence for a reviewer to reproduce the result without trusting the model narrative. Preserve the affected asset, authentication role, request sequence, response differences, tool invocation, command output, timestamps, and policy decisions. Keep the original artifacts addressable even when the agent context is compacted or a worker session ends.

The report should distinguish a confirmed vulnerability, a failed hypothesis, and an observation worth more testing. That distinction controls triage cost. A confirmed authorization bypass with reproducible requests is a different result from an AI-written paragraph that predicts a possible bypass from application structure.

• Exact target and the scope rule that allowed the test.
• Preconditions, credentials, and roles used during execution.
• HTTP requests and responses or the relevant network transcript.
• Commands, tool versions, outputs, and evidence timestamps.
• Impact, confidence, and the reasoning that connects them.
• Remediation state and an independent retest result.

Where should human approval stop an autonomous pentest?

Human approval belongs at actions that can alter data, affect availability, expose sensitive records, move laterally, or expand the authorized scope. Read-only discovery can usually run with less friction. State-changing exploitation, bulk extraction, credential attacks, and destructive business actions need a stronger gate.

The approval model must be enforced outside the model prompt. A static deny rule should block prohibited paths even if the agent proposes a convincing reason to continue. Task-level allow lists should restrict assets and tools. Every approval and rejection should remain in the audit record with the requested action and the human decision.

1. 01
   Classify actions

   Mark tools and request types as passive, active, state-changing, or destructive.

2. 02
   Set hard limits

   Apply asset allow lists, network egress rules, timeouts, and output caps.

3. 03
   Require review

   Interrupt sensitive actions and show the exact request before approval.

4. 04
   Test the gate

   Use a harmless blocked action to confirm policy enforcement works.

5. 05
   Retain the record

   Store the request, decision, reviewer, reason, and resulting execution.

How should you evaluate an autonomous pentesting platform?

Evaluate the control plane before the model demo. Ask the vendor to show how scope is enforced, how tool permissions are assigned, where evidence is stored, how a failed action is recorded, and how an operator intervenes. Then ask for an unsuccessful test. The handling of uncertainty reveals more about production readiness than a curated successful exploit.

Compare deployment requirements as well. A self-hosted agent can keep traffic and target data inside an owned environment, but the team must operate models, databases, network access, updates, and backups. A hosted product transfers some operations to the vendor while requiring careful review of data location and access.

• Can every agent decision be traced to a tool call and artifact?
• Is scope enforced independently from the prompt?
• Can operators define deny rules and approval thresholds per task?
• Are model, tool, and credential choices inspectable or configurable?
• Does the product separate confirmed findings from hypotheses?
• Can it retest one finding without repeating the full engagement?
• Does the evidence remain useful after the model context ends?

Where does ARTEX fit in an autonomous testing program?

ARTEX is an autonomous pentesting console built around a planner, specialized workers, an asset graph, an exploration graph, and a visible execution record. Findings, traffic, commands, approvals, and retesting remain attached to the task instead of being scattered across separate tools. The public source supports inspection and self-hosting when a team needs control over execution and data.

Use ARTEX for recurring reconnaissance, web and API testing, controlled exploitation, and retesting after a fix. Keep manual testers for complex business logic and formal assurance, and keep deterministic scanners for broad baseline coverage. The strongest program assigns each method a clear job and reviews the evidence that connects their results.