Agentic Pentest

Skill: Agentic Pentest

Supplementary Files:

• payloads.md — PentestGPT / HexStrike AI / Viper / PentestAgent / AI-Infra-Guard / AutoPWN / EvilPrompt setup recipes, session/prime/context templates, tool-delegation manifests, multi-agent team configs, scope-lock policies, human-in-the-loop checkpoint scripts, hallucination-mitigation patterns, token/cost budgets, evidence templates, and reporting skeletons
• test-cases.md — 12 structured test cases (TC-AP-001 .. TC-AP-012) covering framework setup, scope enforcement, context priming, autonomous recon, autonomous exploitation, human-in-the-loop checkpoints, multi-agent coordination, hallucination mitigation, output validation, evidence chain, cost discipline, and full end-to-end engagement
• guides/agentic-pentest-playbook.md — End-to-end operations manual (engagement framing, framework selection matrix, reasoning-chain design, six-phase autonomous workflow, context window management, human-in-the-loop integration, scope drift prevention, and the team-vs-tool decision)
• guides/agent-orchestration-patterns-playbook.md — Multi-agent orchestration patterns playbook (single vs multi-agent decision framework, orchestrator-worker / CEO specialist topology, LangGraph-style state graph, DAG-based task decomposition, memory/persistence layer with Redis/SQLite, A2A vs MCP inter-agent protocols, loop termination criteria, cost-bounded execution, and real-world agentic security tools XBOW / RaxisAI / Pentest Copilot / HexStrike AI / CAI)
• guides/agentic-pentest-deep-dive.md — Multi-agent team coordination patterns (four-role reference team, shared-state handoff protocol, PentestGPT internal planner/executor split, HexStrike explicit planner/executor/verifier topology, Viper adversary-profile-driven flow, role decomposition anti-patterns, MCP vs A2A vs shared-file protocols), HITL checkpoint design (five-class safety taxonomy, checkpoint document schema, pause/resume semantics, evidence-review gates, scope-enforcement guardrails, HITL anti-patterns), and three end-to-end case studies (web app recon→SQLi, multi-agent team against /24, APT29 purple-team emulation)

Summary

Agentic pentest skill domain covering the deployment and operation of LLM-driven autonomous penetration testing frameworks — PentestGPT, HexStrike AI, Viper, PentestAgent, AI-Infra-Guard, AutoPWN, EvilPrompt, and the custom OpenClaw/nanoclaw harness pattern. Where autonomous-loops teaches generic loop constructs and engagement-manager orchestrates skill composition, this skill is the concrete toolkit for putting an LLM in the driver's seat of an actual engagement — priming its context with scope and target data, delegating tool calls (nmap, sqlmap, ffuf, metasploit, custom Python), enforcing human-in-the-loop checkpoints before destructive actions, validating the agent's claims against ground truth (verification-loop integration), and coordinating multi-agent teams (recon / exploit / post-exp / report agents) without scope drift.

Tools: PentestGPT, HexStrike AI, Viper, PentestAgent, AI-Infra-Guard, AutoPWN, EvilPrompt, OpenClaw/nanoclaw harness, Claude/GPT-4o (driving models), plus the standard pentest toolkit that the agent invokes (nmap, sqlmap, ffuf, gobuster, nuclei, metasploit, bloodhound, custom Python)

Domain: ai-meta

Mappings: Meta-skill (no direct MITRE mapping); orchestrates coverage across all ATT&CK tactics (TA0043-Reconnaissance through TA0042-Exfiltration) via framework delegation. The skill itself is operator infrastructure.

Description

Agentic pentest is the discipline of treating a large language model as the reasoning core of a penetration test — not a chat assistant that suggests commands, but an autonomous operator that reads output, decides the next step, and invokes tools, with a human reviewer approving destructive actions. The pattern is now mature enough to be standardized: PentestGPT (13.7k stars) demonstrated the reason-chain-first approach; HexStrike AI (9.6k) shipped the MCP-based multi-agent variant; Viper (5k) added adversary simulation; PentestAgent (2.6k) formalized black-box agentic testing; AI-Infra-Guard (3.9k) operationalized AI-driven infra scanning; AutoPWN and EvilPrompt pushed automated exploitation. The kali-claw workspace is itself a reference implementation of this pattern — the OpenClaw agent harness.

This skill is the operator's manual for putting any of these frameworks into production on a scoped engagement. Where ai-agent-security is how you attack agent systems, agentic-pentest is how you deploy and operate one as your offensive tool. Where autonomous-loops is generic loop constructs, agentic-pentest is domain-specific (pentest) with concrete frameworks, MCP servers, and tool-delegation manifests. Where engagement-manager is the human-readable orchestration layer, agentic-pentest is the agent-readable execution layer that the engagement manager invokes when it wants to delegate a phase to an LLM.

Difference from autonomous-loops: autonomous-loops defines the four generic loop patterns (sequential pipeline, watch loop, batch, learning cycle) — the abstract constructs. agentic-pentest is the domain-specific application: which LLM-driven framework implements each pattern for pentest, how to prime the agent's context, how to delegate tools, how to enforce scope at the agent layer. autonomous-loops tells you what a loop is; agentic-pentest tells you how to put an LLM in charge of one running nmap across a /24.

Difference from multi-agent-collaboration: multi-agent-collaboration is the generic multi-agent coordination primitive. agentic-pentest applies it to the specific case of a pentest team — recon agent, exploit agent, post-exp agent, report agent — with concrete MCP configurations and tool-delegation manifests. Use multi-agent-collaboration for the abstract patterns; use agentic-pentest for the operational deployment.

Difference from engagement-manager: engagement-manager is the orchestration layer that tracks the kill chain phases, evidence chains, and stakeholder communication — it is human-readable. agentic-pentest is the execution layer the engagement manager invokes when it wants an LLM agent to drive a phase autonomously. The engagement manager decides what to delegate; agentic-pentest decides how the agent does it.

Difference from ai-agent-security (v0.1.30 sibling): ai-agent-security is how you ATTACK agent systems (prompt injection against the agent, tool abuse, MCP poisoning). agentic-pentest is how you DEPLOY an agent as your offensive tool. They share concepts (MCP, tool delegation, context windows) but use them in opposite directions. They pair well: run agentic-pentest for speed, then run ai-agent-security to test whether your own pentest agent is itself vulnerable to adversarial inputs from the target.

Difference from terminal-ops: terminal-ops is the skill for safe, evidence-logged command-line execution by the operator. agentic-pentest is the skill for delegating that command-line execution to an LLM agent. The agent's tool invocations should still follow terminal-ops discipline (logging, scope check, evidence capture); this skill ensures they do.

Use Cases

• Autonomous recon sweep — Point PentestGPT or a custom OpenClaw harness at a scoped target list and let the agent run nmap/nuclei/ffuf/web-discovery, parse output, decide next steps (deeper enumeration on interesting ports), and produce a structured attack surface map, with the human approving any phase-2 active exploitation.
• Reasoning-chain exploitation — Feed the agent a vulnerable web app and let it reason through SQLi discovery → sqlmap dump → credential reuse → lateral movement, halting at each destructive step for human approval (PentestGPT's --reasoning mode or HexStrike's planner-exploiter split).
• Multi-agent pentest team — Deploy a Viper or custom MCP-based team: recon agent (nmap, ffuf), vuln agent (nuclei, custom checks), exploit agent (metasploit, sqlmap), report agent (consolidates evidence). Coordinate via shared state with the human as engagement manager.
• Continuous attack-surface monitoring — Stand up an agent that watches a target perimeter (your own production or a scoped client) for new services, new subdomains, exposed credentials, and drift from the known-good baseline, alerting on changes.
• Adversary simulation (purple team) — Use Viper or a custom harness to emulate a specific threat actor's TTPs against the client's detection stack, validating that blue-team detections fire and measuring detection latency.
• AI infra perimeter sweep — Use AI-Infra-Guard (driven by an LLM that triages findings) to scan the target org's perimeter for exposed MLflow, Ray, Jupyter, Triton, vLLM, Ollama, and LLM APIs — the agent prioritizes and reports.
• Scope-bound automated exploitation — AutoPWN-style: agent enumerates, matches findings to known exploit modules, attempts safe exploitation (POC only, no destructive payload), reports verified exploitability with evidence.
• Pre-engagement recon automation — Before a manual engagement, run an agent overnight against OSINT sources (subfinder, amass, theHarvester, GitHub dorks) to produce a prioritized target list and attack-surface map that the human operator starts from on day 1.
• CTF / training automation — Deploy an agent in a sandbox CTF environment to demonstrate the autonomous pentest workflow end-to-end without authorization concerns, useful for training and for showcasing the technique to stakeholders.
• Engagement acceleration — On a time-boxed engagement, delegate the repetitive 60% (port scans, service enumeration, basic vuln scanning, screenshot capture) to the agent while the human focuses on the high-judgment 40% (manual exploitation, business-logic flaws, post-exploitation decision-making).

Core Tools

Methodology

Six-Phase Agentic Pentest Engagement

Phase 1           Phase 2            Phase 3            Phase 4            Phase 5            Phase 6
Authorize &    →  Select & Prime  →  Autonomous      →  Human-in-Loop   →  Validate &       →  Report &
Scope             Agent              Recon Sweep        Checkpoints        Exploit Chains       Detect
   │                 │                  │                  │                  │                  │
   ▼                 ▼                  ▼                  ▼                  ▼                  ▼
Engagement      Framework choice,  nmap/ffuf/nuclei  Destructive actions Independent        OWASP / MITRE
letter, scope,  context priming,   driven by agent;  require human      re-run of every    mapping, evidence
HITL policy,    scope lock load    structured ASMD   approval; report   agent claim;       chain, detection
cost ceiling    into agent state   to evidence dir   at every checkpoint hallucination check   rules from findings

Phase 1: Authorize & Scope

The engagement letter for an agentic pentest is stricter than a manual one. The agent will attempt actions the operator did not explicitly authorize — that is the point of autonomy. The scope must define:

1. Target list (CIDR / hostnames / URLs) — explicit, enumerated
2. Allowed techniques — explicit allow-list (e.g., "nmap -sV", "sqlmap --dump", "ffuf")
3. Forbidden techniques — explicit deny-list (DoS, social engineering, physical, prod-destructive)
4. Human-in-the-loop policy — which action classes require human approval BEFORE execution
   (typically: any exploitation, any credential use, any data modification, any cross-host action)
5. Cost ceiling — USD or token cap; agent aborts if exceeded
6. Time ceiling — wall-clock cap; agent aborts if exceeded
7. Hallucination policy — what happens when the agent claims a finding that verification cannot reproduce
   (typically: drop the finding, log the hallucination, do NOT report unverified claims)
8. Out-of-scope bystanders — third parties who might be affected (e.g., shared hosting, cloud provider APIs)
9. Disclosure terms — vendor findings, internal NDA, publication rights

Phase 2: Select & Prime the Agent

Select the framework based on the engagement shape (see Selection Guide below). Then prime the agent's context — this is the highest-leverage operator action in an agentic engagement.

# PentestGPT — prime with engagement context
pentestgpt --reasoning_api gpt-4o
# Within the session, paste:
#   - Target list
#   - Allowed/denied techniques
#   - HITL policy
#   - Initial reconnaissance data (if any)

# HexStrike — prime via config file
cat > engagement.yaml <<'YAML'
target: https://target.com
scope:
  allowed_techniques: [nmap, ffuf, nuclei, sqlmap-safe-mode]
  denied_techniques: [dos, social-engineering, destructive-exploit]
hitl_policy:
  require_approval_before: [exploitation, credential-use, data-modification]
cost_ceiling_usd: 500
time_ceiling_hours: 8
YAML
hexstrike --config engagement.yaml

The prime should include:

• The target list (explicit, enumerated)
• The allowed/denied techniques
• The HITL policy (what requires approval)
• Any known context (prior recon, client-provided intel)
• The evidence directory convention (where to write outputs)
• The verification policy (every claim must be independently reproducible)
• The abort conditions

Phase 3: Autonomous Recon Sweep

Delegate the recon phase to the agent. This is the safest phase to fully automate — recon is non-destructive, evidence is straightforward to capture, and the agent's value is highest here (deciding what to enumerate deeper based on what it finds).

# OpenClaw harness example — autonomous recon
./validation/orchestrator.sh \
  --target web \
  --phase recon \
  --agent-mode autonomous \
  --scope scope.yaml \
  --evidence-dir evidence/$(date +%F)/recon

# The agent will:
# 1. Run nmap against the target
# 2. Parse open ports, decide which to enumerate further
# 3. Run ffuf for web discovery on open HTTP ports
# 4. Run nuclei for known vulns
# 5. Produce an attack-surface map (ASMD)
# 6. HALT before any active exploitation

Phase 4: Human-in-the-Loop Checkpoints

For every action class in the HITL policy's require_approval_before, the agent halts and surfaces a checkpoint to the operator. The operator approves, modifies, or rejects. The agent logs the decision and continues (or aborts).

## HITL Checkpoint — Exploitation Approval Request
- **Agent**: OpenClaw recon→exploit transition
- **Target**: https://target.com/login.php
- **Proposed action**: sqlmap -u "https://target.com/login.php" --data "user=FUZZ&pass=FUZZ" --batch --risk=2
- **Reasoning**: Found parameterized login form, nmap shows MySQL backend, nuclei flagged
  potential SQLi. Proposing safe-mode sqlmap to confirm.
- **Evidence**: nuclei output (nuclei-2026-06-17.json), login form screenshot
- **Risk assessment**: --risk=2 = elevated risk; --batch = non-interactive; no --dump (no data exfil)
- **Operator decision**: [APPROVE / MODIFY / REJECT / DEFER]
- **Operator notes**: ____

Phase 5: Validate & Exploit Chains

Every agent claim ("I found SQLi", "I got a shell") must be independently verified by the operator or a verification script. Hallucination is the dominant failure mode of agentic pentest — the agent confabulates findings, claims exploitation succeeded when it did not, or invents credentials. Verification is non-negotiable.

# Verification harness — re-run every agent claim independently
python3 verify.py \
  --claims evidence/$(date +%F)/claims.json \
  --output evidence/$(date +%F)/verified.json \
  --policy verify-everything

# Claims that fail verification are dropped from the report and logged as hallucinations
# Hallucination rate is itself an engagement finding (the agent's reliability)

For exploit chains, the human is more involved — chains require judgment the agent does not have (when to stop, when to escalate, when to call the client). Phase 5 is the most human-in-the-loop phase.

Phase 6: Report & Detect

Compile the verified findings into the engagement report. The agent can draft the report (it has the context), but the operator reviews every word before delivery. Detection rules are derived from the agent's actual actions — every command the agent ran becomes a candidate Sigma rule for the blue team.

# Agent drafts the report from verified evidence
python3 report/generate.py \
  --verified evidence/$(date +%F)/verified.json \
  --template report/pentest.md.j2 \
  --output deliverables/pentest-report-draft.md

# Operator reviews, edits, signs off
$EDITOR deliverables/pentest-report-draft.md

# Detection rules from agent's commands
python3 detect/extract_sigma.py \
  --log evidence/$(date +%F)/agent-actions.log \
  --output deliverables/detection-rules/

Framework Selection Guide

HITL Policy Templates

Agentic Pentest Attack Matrix

The Agentic Pentest Attack Matrix maps the kill-chain phases to the agent capabilities, tools, and HITL classes each phase requires. This matrix guides engagement planning by making explicit which agent role owns which phase, what the verification looks like, and where the human must intervene.

Attack Chain Scenarios

Scenario 1: Web-App Autonomous Recon-to-Exploit Chain

1. Recon agent runs nmap and ffuf, discovers /api/users?id=1
2. Recon agent proposes safe-mode sqlmap probe; operator approves at HITL gate
3. Exploit agent runs sqlmap --batch --risk=1; verifier independently confirms injection
4. Exploit agent halts; operator reviews verified finding and decides whether to authorize --dump
5. Report agent drafts the finding; operator edits risk rating and signs off

Scenario 2: Network Segment Multi-Agent Sweep Chain

1. Recon agent sweeps /24 in three passes (host discovery, service discovery, vuln scan)
2. Handoff (manifest-validated) to exploit agent with prioritized target list
3. Exploit agent proposes initial access attempts (SMB checks, eternalblue probes); operator approves at HITL gate
4. Verifier independently confirms each vulnerable host
5. Post-exp agent receives verified initial-access credentials; operator approves lateral movement step-by-step

Scenario 3: Adversary Simulation (Purple Team) Chain

1. Viper's LLM decisioning loads adversary profile (e.g., APT29 emulation)
2. Agent steps through TTP chain: spearphish → macro → PowerShell → credential dump → lateral → exfil
3. Each destructive TTP is HITL-gated; operator approves after confirming match to agreed profile
4. Verifier cross-checks SIEM alerts against executed TTPs; flags detection gaps
5. Report includes both successful detections and gaps, with detection rules packaged for blue team

Reasoning-Chain Architecture

The Planner-Executor Split

Every agentic pentest framework implements some variant of the planner-executor split. Understanding this split is essential because it determines where the operator can intervene and where the agent's autonomy is bounded.

• Planner — reads the target, the current state, and the engagement scope; proposes the next step as a structured task with a HITL class. The planner is where reasoning happens; it is the "what to do next" decision.
• Executor — receives the planner's task, invokes tool servers (bash, filesystem, http, custom pentest MCP), returns raw output. The executor is where tool calls happen; it is the "how to do it" execution.
• Verifier (operator-controlled, not an LLM) — independently re-runs any claim the executor makes. The verifier is the truth layer; it converts the agent's claims into verified findings.

PentestGPT leaves this split implicit — the operator drives it via alternating planner-style and executor-style prompts. HexStrike AI makes it explicit in the topology. Viper collapses planner and executor into a single decisioning loop driven by the adversary profile. The OpenClaw harness pattern makes all three roles explicit and pluggable.

Context Window Strategy

A typical long-context LLM has 200k tokens of context. A typical engagement generates far more than that in raw tool output. The agent must manage its context window strategically or it will lose track of what it has already tried, what worked, and what the scope is.

Three strategies that work:

1. Selective summarization — after each phase, summarize the raw output into a compact structured form (e.g., nmap XML → "12 live hosts, top services: 22/SSH, 80/HTTP, 443/HTTPS, 3306/MySQL"). Keep the summary in context; archive the raw output to disk.
2. Phase-boundary context reset — between phases, drop the raw output of the previous phase from context and load only the summary plus the next phase's prime. This bounds context growth.
3. External memory — for engagements that span multiple sessions, persist the agent's state to disk (shared state directory) and reconstruct context from the persisted state on resume. Never rely on in-memory state that cannot be reconstructed.

Tool Delegation Manifest

The tool delegation manifest is the contract between the agent and its tool servers. It lists every tool the agent may invoke, the schema for each tool's input, and the HITL class for each tool's invocation. Without a manifest, the agent's tool graph is implicit and un-auditable.

# tool-manifest.yaml — the agent's allowed tool graph
tools:
  - name: bash
    description: "Run a shell command (subject to scope_check)"
    hitl_class: variable  # determined by scope_check on the proposed command
    input_schema:
      command: string
  - name: read_file
    description: "Read a file from the evidence directory"
    hitl_class: auto
    input_schema:
      path: string  # must be under evidence/
  - name: write_file
    description: "Write an artifact to the evidence directory"
    hitl_class: auto
    input_schema:
      path: string
      content: string
  - name: http_request
    description: "Make an HTTP request (subject to scope_check on URL)"
    hitl_class: variable
    input_schema:
      url: string
      method: string
  - name: hitl_checkpoint
    description: "Surface a checkpoint to the operator and wait for decision"
    hitl_class: auto  # the checkpoint itself is always allowed
    input_schema:
      action_class: string
      target: string
      proposed_action: string
      reasoning: string
      evidence_refs: array
      risk_assessment: string

Safety Considerations

Agentic Pentest Safety Philosophy

An agentic pentest is not a faster manual pentest — it is a qualitatively different engagement with different failure modes. The agent will attempt actions the operator did not explicitly authorize; that is the point of autonomy. Safety in this context means bounding the agent's autonomy so it cannot cause harm the operator did not intend.

Pre-Engagement Safety Requirements

Before launching any agentic engagement, complete these mandatory safety steps:

1. Obtain written authorization that explicitly identifies that an autonomous (agentic) tool will be used and that the operator reviewed every action.
2. Identify out-of-scope bystanders — shared hosting, cloud provider APIs, third-party services that might be affected by agent actions.
3. Establish a stop-testing signal — a clear, fast way for the operator to halt the agent when something unexpected happens.
4. Document the abort conditions — what triggers an immediate halt (scope violation, hallucination rate exceeded, cost ceiling approached, unexpected target response).
5. Verify isolated lab environment for any first-run of a new agent configuration. Never deploy a new agent topology directly against a client target.
6. Review the agent's tool graph — every tool in the manifest must be reviewed and approved before the engagement starts.

Safety Impact Classification

Classify each planned agent action by its potential impact:

Operational Constraints

• Maintain target availability: Agentic pentest must not disrupt production. Schedule destructive phases during maintenance windows.
• Respect rate limits: Aggressive scanning can trigger IP bans or rate-limit alerts. Use conservative timing templates.
• Preserve audit trail: Every agent action must be logged with timestamp, command, output, and operator decision. The log is the engagement's chain of custody.
• Monitor for cascading effects: An action on one host may trigger automated responses elsewhere. Understand interdependencies before authorizing.
• Honor cost and time ceilings: Abort when either ceiling is approached, not after it is exceeded.

Emergency Procedures

If the agent does something unexpected:

1. Halt the agent immediately — invoke the stop signal; the agent must support clean halt within seconds.
2. Isolate the affected system — if the agent touched production, isolate the affected host from the network.
3. Notify the engagement lead — escalate before resuming any agent operation.
4. Document the event — record the exact action, time, observed response, and root cause.
5. Review and restructure — before resuming, identify why the agent took the unexpected action and add a guardrail to prevent recurrence.

Operational Constraints

Beyond safety, agentic pentest engagements operate under three hard constraints that distinguish them from manual engagements:

Cost Discipline

Every LLM call costs money. An autonomous agent running for 8 hours can easily spend hundreds of dollars in API costs. Cost discipline is not optional — it is the difference between a profitable engagement and one that loses money.

• Per-phase budgets: Allocate the total ceiling across phases (recon 20%, exploit 40%, post-exp 30%, report 10%).
• Model tiering: Haiku for executors, Sonnet for planners, never Opus for autonomous loops.
• Retry caps: Maximum 3 retries on any single failed approach before halting.
• Cost tracker with abort: A wrapper around the LLM client that aborts when the ceiling is approached (typically at 80% of ceiling, to leave room for clean shutdown).

Time Discipline

An agent stuck in a loop is worse than no agent at all — it burns budget without producing findings. Time discipline means bounding how long any phase can run.

• Wall-clock cap per phase: Typically 4-8 hours per autonomous phase.
• Per-turn timeout: If the agent takes longer than X minutes on a single tool call, halt and surface to operator.
• Phase-completeness check: At the end of each phase, verify the agent produced the expected artifact (ASMD for recon, verified chains for exploit) before proceeding.

Hallucination Discipline

Hallucination is the dominant failure mode. Every claim the agent makes must be independently verified. Hallucination discipline means treating the agent's output as hypotheses, not findings, until verified.

• Verification harness: A Python script (not an LLM) that re-runs every claim and reports verified vs. hallucinated.
• Hallucination-rate logging: Track the percentage of claims that fail verification. A rate above 15% indicates the agent is unreliable on this target.
• Drop-and-log policy: Claims that fail verification are dropped from the report and logged as hallucinations. They are never reported as findings.

Common Pitfalls

1. Trusting the agent without verification — The single most common failure. The agent confabulates findings, claims exploitation succeeded when it did not, invents credentials. Verification is the only reliable mitigation. Operators who skip it ship false findings.
2. Skipping the scope-lock — The agent will interpret "find vulnerabilities" broadly. Without a hard scope-lock policy engine intercepting every command, the agent will eventually act out of scope. Operators who skip scope-lock risk unauthorized access and engagement termination.
3. Rubber-stamping HITL gates — If the operator approves every checkpoint without reading them, HITL is theater. Force the operator to write a one-sentence rationale for each approval.
4. HITL on every action — If every nmap requires approval, the operator is the bottleneck and the engagement does not benefit from autonomy. Reserve HITL for action classes with consequences.
5. Treating the agent as a human replacement — The agent excels at the 60% that is pattern-matching; it misses the 40% that requires judgment (business-logic flaws, novel CVEs, complex chains). Operators who treat the agent as a replacement miss high-impact findings.
6. Ignoring the cost ceiling — An agent stuck in a retry loop can burn the engagement's entire budget in hours. Cost tracking with abort-on-ceiling is mandatory.
7. Using Opus for autonomous loops — Opus is the most capable model, but its cost-per-turn is prohibitive for an engagement running hundreds of turns. Use Sonnet for planning, Haiku for execution.
8. Deploying a new topology directly against a client target — Always first-run a new agent configuration in a lab. Production deployments of untested agent topologies are a leading cause of incident-response calls.
9. No pause/resume capability — If the agent's state cannot be paused and resumed, the engagement cannot survive an overnight pause or a HITL defer. Design every agent for clean pause/resume.
10. No evidence manifest — Artifacts without manifests are not auditable. Engagement reports built on un-manifested evidence are not defensible in front of a client or regulator.

Practical Steps

Detailed payloads in payloads.md, complete test checklist in test-cases.md, deep-dive playbook in guides/agentic-pentest-playbook.md.

Exercise 1: Stand Up PentestGPT on a Scoped Target

Goal: deploy PentestGPT in reasoning mode against a single authorized target and run an interactive autonomous recon session.

# 1. Install PentestGPT
git clone https://github.com/GreyDGL/PentestGPT.git
cd PentestGPT
pip3 install -r requirements.txt

# 2. Configure the LLM backend
export OPENAI_API_KEY=sk-...
# or use Azure, local Ollama, etc.

# 3. Launch in reasoning mode
pentestgpt --reasoning_api gpt-4o --parsing_api gpt-4o-mini

# 4. Within the session, prime the context:
#    - "I'm testing https://target.com — single web app, client-authorized, no DoS,
#       require my approval before any exploitation"
#    - Paste any prior recon
# 5. Use: 'test <module>' to give the agent tool output
#          'next'    to ask for the next step
#          'discuss' to brainstorm
# 6. Capture every command the agent suggests into evidence/
# 7. Verify every claim before adding to the report

Exercise 2: Configure HexStrike AI Multi-Agent Team

Goal: deploy HexStrike's planner + executor split against a target, with MCP-based tool servers.

# 1. Clone and set up HexStrike AI
git clone https://github.com/ZacharyZcR/Hexstrike.git
cd Hexstrike
./setup.sh  # or per README — installs deps, MCP server configs

# 2. Configure MCP tool servers
cat > mcp_config.yaml <<'YAML'
servers:
  - name: bash
    command: npx
    args: ["-y", "@modelcontextprotocol/server-bash"]
  - name: filesystem
    command: npx
    args: ["-y", "@modelcontextprotocol/server-filesystem", "/workspace/evidence"]
  - name: pentest-tools
    command: python3
    args: ["./mcp_servers/pentest_tools_server.py"]
YAML

# 3. Configure the engagement
cat > engagement.yaml <<'YAML'
target: https://target.com
planner_model: claude-sonnet-4
executor_model: claude-haiku-4
scope:
  allowed_techniques: [nmap, ffuf, nuclei]
  denied_techniques: [dos, destructive]
hitl_policy:
  require_approval_before: [exploitation]
cost_ceiling_usd: 300
YAML

# 4. Launch
hexstrike --config

…(truncated)