AI pentest agents that plan, execute, and leave evidence

What is an AI pentest agent?

An AI pentest agent is a software agent that can interpret a security objective, select tools, run tests, inspect results, and decide what to do next. The useful unit is not a single prompt response. It is a bounded run with a target, a policy, a transcript, and evidence.

The agent needs a model that can reason over tool output, but reasoning alone is insufficient. It also needs an execution environment, an asset model, memory across turns, an approval mechanism, and a reliable way to link an action to the vulnerability it supports.

ARTEX separates the planner from execution workers. The planner owns the task intent and sequence; workers investigate specific assets or hypotheses. A main agent can accept human guidance, while system records preserve the commands, traffic, and findings produced along the way.

What roles belong in a multi-agent pentest system?

A multi-agent architecture helps only when each role has a clear contract. If every agent receives the same prompt and unlimited tools, parallelism increases noise rather than coverage. ARTEX assigns different responsibilities to planning, execution, human interaction, and review.

How do planner and workers share context?

The planner turns the engagement objective into a shared todo list and assigns useful work. Workers write observations back into the exploration graph instead of keeping discoveries hidden in isolated chat histories. That lets later workers build on confirmed facts without inheriting every irrelevant detail from earlier turns.

ARTEX describes this as a dual-graph model: an asset graph records what exists and how it relates, while an exploration graph records what the agents tried, learned, and proved. The two graphs keep inventory knowledge separate from task progress.

• The asset graph stores companies, domains, hosts, services, endpoints, and scope.
• The exploration graph stores goals, intentions, facts, findings, and transitions.
• Worker observations become shared facts rather than private completion messages.
• The planner can revisit an unexplored branch without replaying the whole task.

Which tools does an AI pentest agent need?

The minimum toolset includes HTTP requests, DNS and service discovery, command execution, file inspection, and structured access to the asset graph. Real engagements also benefit from extensible skills, MCP servers, custom tools, and a controlled way to add tool output to the agent context.

Tool access should be explicit. The agent needs enough capability to test the target, but not unlimited access to the host, the internet, or secrets unrelated to the engagement. A visible tool registry and execution transcript make that boundary reviewable.

• HTTP and browser tooling for application behavior.
• Command execution inside a constrained test environment.
• Skills for repeatable methodology and task-specific procedures.
• MCP integrations for external systems and data sources.
• Traffic capture so commands can be connected to network evidence.
• Notification and report hooks for findings that need a human response.

Where should human approval interrupt an agent?

Approval should interrupt actions that can change state, exceed the agreed scope, expose sensitive data, or create meaningful business impact. Read-only reconnaissance usually needs less friction than account takeover, destructive endpoint calls, or lateral movement.

ARTEX supports interception rules, asset deny lists, task-level allow lists, approval records, and a main-agent conversation path. These controls should be configured before the run and tested with harmless commands. A guardrail that has never been exercised is only an assumption.

1. 01
   Define sensitive actions

   Classify destructive HTTP paths, credential access, lateral movement, and bulk extraction.

2. 02
   Add static deny rules

   Block broad categories before the model can request them.

3. 03
   Create task scope

   Allow only the assets and host patterns covered by authorization.

4. 04
   Test the guardrail

   Use a safe command or path to confirm the approval flow actually fires.

5. 05
   Review approvals

   Keep the requester, decision, reason, and resulting action in the audit record.

What are the most common AI pentest agent failure modes?

The first failure mode is confident reasoning without evidence. A model may connect several plausible observations and describe an exploit path that was never executed. The second is context drift: a worker discovers a useful fact, but the planner cannot see it or later agents forget an important exclusion. The third is tool misuse, where the model chooses an action that is technically capable of testing the target but outside the approved scope.

Other failures are operational. An agent can loop on a dead end, consume its context on irrelevant tool output, or interpret a transient server error as a security result. Parallel workers can duplicate work or overwrite each other’s state if ownership is unclear. These are engineering problems, so evaluate the state model, logging, retries, and approval path rather than treating model quality as the only variable.

• Require a concrete artifact before promoting a hypothesis to a finding.
• Persist discovered facts in shared state instead of relying on chat history.
• Bound tool output and keep full artifacts addressable outside the prompt.
• Add loop detection, task budgets, and explicit stop conditions.
• Test scope enforcement with a deliberately out-of-scope target.
• Keep a human path for uncertain or impact-bearing actions.

How should you design the agent tool loop?

Give every tool a narrow contract: inputs, outputs, timeout, side effects, and evidence expectations. The planner should know whether a tool is read-only, changes state, or requires approval before it can even schedule the call. This makes policy enforcement independent of whether the model remembers the instruction.

Keep outputs structured where possible so the agent does not need to parse a giant terminal transcript. Store the full output as an artifact, return a bounded summary, and preserve a pointer to the complete record for a reviewer. That pattern controls context growth while keeping the proof available.

1. 01
   Classify

   Mark each tool as passive, active, destructive, or credential-sensitive.

2. 02
   Constrain

   Set target allow lists, timeouts, output limits, and network rules.

3. 03
   Observe

   Record the invocation, result, duration, and related traffic sample.

4. 04
   Summarize

   Return only the information the planner needs to choose the next step.

5. 05
   Review

   Escalate uncertain effects and keep the full artifact for evidence.

How should an agent document a finding?

A finding should be linked to the task, asset, supporting traffic, command transcript, and the agent session that produced it. The summary can be model-generated, but the underlying evidence must remain available even if the model context is compacted or the run ends.

ARTEX keeps findings, traffic, command logs, and conversation records attached to the engagement. A separate retester agent can later request the same vulnerability and record whether it still reproduces. That separation reduces the chance of accepting a confident narrative as proof.