Problem Statement
The pentester currently has to steer the harness through reconnaissance, vulnerability testing, and reporting manually, even though these activities are parts of one engagement. The current loop can focus deeply on a subset of assets while leaving other in-scope assets underexplored, and it can appear finished when the durable lead queue is empty even though recon coverage is incomplete.
Reconnaissance is the foundation of the engagement: it must continuously and recursively discover and characterize the attack surface for every initial and newly discovered in-scope asset. The current global surface-delta and no-progress model does not prove that every asset received every applicable discovery method. Newly discovered endpoints during testing also do not reliably re-enter a dedicated reconnaissance frontier.
When standard vulnerability tests fail against a defensive control, the harness can exhaust a lead without requiring a specialist bypass pass. Findings and leads of individually low severity are not systematically evaluated as building blocks of a higher-impact kill chain. Finally, the same main agent that decides the engagement is finished is not challenged by independent tester perspectives before reporting.
The pentester wants a substantially more autonomous engagement loop that maintains broad attack-surface coverage, recursively responds to discoveries, escalates resistant hypotheses to bounded bypass specialists, evaluates kill chains after every material lead or finding change, and performs an adversarial convergence challenge before declaring completion.
Solution
Introduce a deterministic campaign coordinator that owns the engagement frontier, phase transitions, coverage closure, work scheduling, bypass escalation, kill-chain review checkpoints, convergence challenges, and terminal outcome. It exposes one high-level interface, with a repository-local command adapter, so orchestration behavior is durable and testable rather than dependent on prompt prose.
Provide four user-facing commands:
/recon performs coverage-complete reconnaissance only.
/pentest tests the currently known or declared attack surface independently and can create targeted recursive recon work when testing discovers new surface.
/full-pentest runs the complete autonomous engagement: recursive recon, vulnerability testing, bypass escalation, exploitation within the rules of engagement, kill-chain analysis, convergence challenge, and report generation.
/report independently regenerates the report from durable campaign state and findings.
Reconnaissance becomes a continuous engagement responsibility rather than a one-time phase. The coordinator seeds a coverage frontier for every declared in-scope asset and every applicable authorized discovery method. Every newly discovered in-scope asset, endpoint, path, parameter, schema, role, technology, version, protocol, or trust relationship creates a surface delta and corresponding bounded discovery work. Fair scheduling prevents a high-signal asset from starving untouched assets.
When standard testing encounters a stable defensive control, the coordinator creates a bypass lead rather than marking the hypothesis exhausted. A bypass-specialist agent is dispatched with an explicit profile and the original negative evidence. Exhaustion is permitted only after both standard and applicable specialist stages are terminal.
After every durable lead or finding change, regardless of severity, the main orchestrator evaluates whether demonstrated capabilities satisfy the prerequisites of other observations. Evidence-grounded candidates become deduplicated chain leads. A validated chain becomes its own finding with references to all component findings and severity based on demonstrated combined impact.
When the campaign first appears converged, the coordinator dispatches one to three isolated lead explorers using orthogonal tester lenses. Any accepted unique lead reopens the campaign. Reporting is allowed only after the current material frontier has received a completed convergence challenge with zero accepted leads.
User Stories
- As a pentester, I want one
/full-pentest command, so that I do not have to manually invoke reconnaissance, testing, and reporting in sequence.
- As a pentester, I want
/recon to remain independently available, so that I can map an attack surface without beginning vulnerability testing.
- As a pentester, I want
/pentest to remain independently available, so that I can test a known or declared attack surface without requesting the exhaustive full campaign.
- As a pentester, I want
/report to remain independently available, so that I can regenerate a report without touching the target.
- As a pentester, I want recon, pentest, and report to be phases of one engagement run, so that transitioning between commands does not invalidate useful state.
- As a pentester, I want every declared in-scope asset seeded into the recon frontier, so that no asset is silently omitted.
- As a pentester, I want every newly discovered in-scope asset added to the recon frontier, so that recursive discoveries receive the same coverage as initial scope.
- As a pentester, I want virtual-host discovery applied where relevant, so that host-routed applications are not missed.
- As a pentester, I want subdomain and service discovery applied to every applicable scope root, so that the complete known host inventory is maintained.
- As a pentester, I want liveness, redirect, technology, CMS, version, and defensive-control characterization for each applicable asset, so that later testing has reliable context.
- As a pentester, I want historical URL collection, crawling, content discovery, and client-bundle route extraction tracked per asset, so that quiet assets cannot be mistaken for covered assets.
- As a pentester, I want API schemas, versions, protocols, operations, and endpoints recursively explored, so that undocumented or nested API surface becomes testable.
- As a pentester, I want parameters, methods, content types, headers, cookies, and path variables inventoried for discovered endpoints, so that family triage has complete input.
- As a pentester, I want authenticated recon repeated for every authorized role, so that identity-dependent attack surface is not represented by a single session.
- As a pentester, I want recon coverage represented as evidence per asset and method, so that host and endpoint counts cannot masquerade as completeness.
- As a pentester, I want a clear distinction between coverage-complete recon and budget-exhausted recon, so that incomplete work is never reported as finished.
- As a pentester, I want no-progress measured per asset and discovery method, so that two quiet global rounds cannot hide untouched assets.
- As a pentester, I want fair scheduling across assets, so that an interesting application does not consume all available depth while other assets remain at zero coverage.
- As a pentester, I want newly discovered paths and endpoints during vulnerability testing sent back into recursive recon, so that pentest discoveries expand the attack surface automatically.
- As a pentester, I want new schemas, client bundles, roles, protocols, and trust relationships to reopen applicable coverage, so that materially changed prerequisites are retested.
- As a pentester, I want every work item to have a stable fingerprint and durable status, so that retries and resumptions do not duplicate work.
- As a pentester, I want work categorized as discovery, validation, bypass, chain, or exploitation, so that the coordinator dispatches the appropriate specialist.
- As a pentester, I want positive and negative evidence retained for completed hypotheses, so that later agents do not rediscover the same controls.
- As a pentester, I want standard testing distinguished from specialist bypass testing, so that repeated variants of the same attempt do not count as meaningful escalation.
- As a pentester, I want a stable defensive signal to create a bypass lead automatically, so that resistant hypotheses receive deeper review before exhaustion.
- As a pentester, I want a bypass specialist selected by defensive class, so that WAF, parser, routing, authentication, authorization, rate-limit, and workflow defenses receive appropriate treatment.
- As a pentester, I want bypass transformations changed one class at a time, so that results are attributable and negative evidence is useful.
- As a pentester, I want bypass agents constrained by scope, required headers, rate limits, request budgets, and rules of engagement, so that autonomy does not weaken safety controls.
- As a pentester, I want failed bypass work described as “not bypassed under the tested matrix,” so that the report does not make an absolute unsupported claim.
- As a pentester, I want the main orchestrator to review kill chains after every new or changed lead, so that partial observations can change the meaning of existing work.
- As a pentester, I want the main orchestrator to review kill chains after every new or changed finding of any severity, so that several low findings can produce a higher-impact result.
- As a pentester, I want chain candidates based on demonstrated capabilities and prerequisites, so that unrelated findings are not combined merely because they share an asset.
- As a pentester, I want chain candidates to preserve ordered parent lead and finding references, so that their provenance is auditable.
- As a pentester, I want every chain edge independently scope-checked and authorized, so that a valid initial finding cannot grant permission for an unauthorized next step.
- As a pentester, I want confirmed chains recorded as separate findings, so that combined impact is visible without rewriting the component findings.
- As a pentester, I want chain severity based on demonstrated combined impact, so that severity is not mechanically inherited from one component.
- As a pentester, I want the apparent final frontier challenged by independent tester perspectives, so that the main agent does not solely validate its own conclusion.
- As a pentester, I want a Surface Archaeologist lens, so that forgotten assets, roles, versions, schemas, paths, methods, and parameters are challenged.
- As a pentester, I want an Abuse-Case Adversary lens, so that business workflows, identity transitions, lifecycle weaknesses, races, and low-severity chains are challenged.
- As a pentester, I want a Boundary Breaker lens, so that parser, protocol, normalization, routing, cache, WAF, and defensive-control assumptions are challenged.
- As a pentester, I want lead explorers isolated from one another, so that they do not anchor on the first explorer’s reasoning.
- As a pentester, I want explorers to return structured, falsifiable leads rather than findings, so that normal validation and evidence requirements remain intact.
- As a pentester, I want unsupported, duplicate, already-tested, out-of-scope, and prohibited explorer ideas rejected, so that speculative output cannot keep the campaign alive indefinitely.
- As a pentester, I want any accepted explorer lead to reopen the normal campaign loop, so that it receives recon, triage, bypass, chain, and exploitation handling as appropriate.
- As a pentester, I want the convergence challenge repeated after explorer-generated work is resolved, so that discoveries made during the challenge are themselves challenged.
- As a pentester, I want convergence tied to a digest of material campaign state, so that bookkeeping changes do not invalidate or falsely satisfy the final challenge.
- As a pentester, I want the completion guard to block when required coverage is incomplete even if no lead is queued, so that missing scheduler work cannot cause premature completion.
- As a pentester, I want the coordinator to synthesize missing work from uncovered coverage cells, so that I do not need to tell the agent what to do next.
- As a pentester, I want budget exhaustion, operator blocking, incomplete work, and true convergence represented separately, so that the final report communicates confidence accurately.
- As a pentester, I want active leases, pending bypass review, stale chain review, or an unmatched convergence digest to prevent final completion, so that no work category is silently abandoned.
- As a pentester, I want the campaign to resume from durable state after interruption, so that autonomous work is not dependent on prompt history.
- As a pentester, I want the final report generated automatically after
/full-pentest truly converges, so that no manual /report invocation is needed.
- As a pentester, I want the final report to include recon coverage, blocked work, budget-exhausted work, bypass matrices, chain findings, and challenge status, so that the engagement’s completeness is transparent.
- As a pentester, I want all target-touching explorer and specialist activity audited like existing agents, so that autonomy retains command and evidence traceability.
- As a pentester, I want the number of lead explorers scaled from one to three according to engagement complexity and budget, so that the confidence gate remains proportionate.
- As a pentester, I want all three explorer lenses used by default for a full campaign, so that reduced coverage is an explicit constrained choice rather than an accidental omission.
Implementation Decisions
- Build a deep campaign coordinator module as the authoritative owner of campaign state transitions, frontier reconciliation, fair scheduling, phase transitions, and completion decisions.
- Expose the coordinator through one repository-local command interface. Callers submit synthetic or real campaign events and receive durable state plus the next eligible work assignments.
- Retain the existing scope enforcement, finding store, audit chain, evidence rules, and rate-policy enforcement as dependencies of the coordinator rather than duplicating them.
- Remove command mode from immutable engagement identity. Track recon, pentest, exploitation, challenge, and report as resumable phases inside the same run.
- Add
/full-pentest as the exhaustive autonomous entry point. It runs recursive recon and vulnerability testing as a bidirectional loop, performs final convergence challenges, and automatically renders the report.
- Narrow
/recon to coverage-complete attack-surface discovery without vulnerability hunting.
- Narrow
/pentest to vulnerability testing over the current or declared surface. It may create targeted recon work for new surface but does not claim exhaustive recon coverage unless the coverage frontier proves it.
- Keep
/report read-only and independently runnable against durable findings and campaign state.
- Treat reconnaissance as continuous throughout the engagement. Any surface delta may reopen recon coverage and generate discovery work.
- Define the attack-surface frontier from declared and discovered in-scope assets. Each asset receives applicable discovery work for hosts, virtual hosts, services, liveness, redirects, technology and version fingerprinting, defensive controls, historical paths, crawling, content discovery, client bundles, API schemas, operations, parameters, methods, content types, and authorized roles.
- Expand coverage dimensions to represent assets, recon methods, roles, and parameter surfaces in addition to endpoints, workflows, families, and versioned scenarios.
- Seed required coverage cells as pending before work begins. Coverage cannot be inferred from the existence of one or more completed rows.
- Use normalized fingerprints for assets, surface deltas, work items, chain candidates, and coverage cells so recursive observations are idempotent.
- Measure no-progress at the relevant asset and work lane. Do not use a quiet global round as evidence that all assets are covered.
- Use fair scheduling across assets and work kinds. Baseline work for untouched assets must receive service before repeated depth work on already explored assets.
- Add durable work kinds for discovery, validation, bypass, chain, and exploitation.
- Add durable stages that distinguish standard testing, specialist testing, and terminal outcomes.
- Route newly discovered hosts, paths, endpoints, schemas, roles, bundles, protocols, and parameters into discovery work even when they originate during pentest or exploitation.
- Introduce one bypass-specialist agent with dispatch profiles for edge/WAF normalization, parser/content-type differentials, authentication/authorization routing, and rate-limit/workflow-state bypass. One parameterized specialist avoids duplicated shallow agent definitions.
- Require every bypass assignment to include the original work references, observed control, positive and negative controls, standard techniques attempted, environment facts, and safety requirements.
- Permit hypothesis exhaustion only when standard work and every applicable authorized specialist profile are terminal.
- Persist bypass negative evidence by transformation class and use “not bypassed under the tested matrix” as the terminal wording.
- Trigger main-orchestrator kill-chain review after every material lead or finding revision, regardless of severity or confirmation status.
- Model chain candidates as durable work with ordered parent references, demonstrated capability-to-prerequisite edges, expected combined impact, required evidence, scope, and safety gates.
- Bound speculative chain depth and candidate count. Deduplicate chain candidates by their ordered material inputs and intended capability.
- Record a validated chain as a separate finding while preserving its component findings unchanged.
- Base chain severity on demonstrated combined impact rather than the maximum component severity.
- Add a mandatory convergence-challenge phase before full-campaign reporting.
- Define three fixed explorer lenses: Surface Archaeologist, Abuse-Case Adversary, and Boundary Breaker.
- Isolate explorer contexts. Each explorer receives the same material campaign snapshot but not the other explorers’ reasoning or output.
- Require explorer output to contain a concrete subject, falsifiable hypothesis, supporting observations, recommended next test, provenance, priority, and safety requirements. Explorers generate leads, not findings.
- Have the coordinator reject duplicate, unsupported, already-tested, out-of-scope, and prohibited explorer candidates before they affect progress or convergence.
- Any accepted explorer lead invalidates apparent convergence and reopens the normal campaign loop.
- Repeat the convergence challenge after explorer-generated work becomes terminal.
- Store a digest of material campaign state for chain-review and convergence-challenge checkpoints. Exclude bookkeeping fields from the digest.
- Require the current material digest to have completed kill-chain review and a zero-lead convergence challenge before reporting.
- Default
/full-pentest to all three explorer lenses. Allow one or two only when engagement complexity, authorization, or budget explicitly requires a reduced challenge.
- Replace a single completion boolean with distinct outcomes for converged, budget exhausted, operator blocked, and incomplete.
- Budget exhaustion remains a valid safety stop but never counts as convergence. The coordinator must return the remaining frontier and coverage gaps.
- Completion is forbidden while required coverage is pending, actionable work or leases remain, bypass escalation is pending, chain review is stale, or the convergence challenge does not match the current material digest.
- Extend sub-agent completion contracts and hook matching to cover bypass and exploitation agents, and validate structured work handoff rather than relying only on prose headings.
- Preserve all existing scope, required-header, rate, concurrency, mutation, sensitive-data, credential-use, pivoting, availability, evidence, redaction, and audit controls across every new agent and phase.
- Provide migration or compatibility handling for existing engagement state rather than silently treating older state as coverage-complete.
Testing Decisions
- The primary behavioral test seam is the deterministic campaign coordinator command interface. Tests provide synthetic campaign events and assert observable next work, durable state, and terminal outcomes without inspecting internal helper behavior.
- Prefer black-box coordinator tests over separate unit tests for every scheduling helper. The coordinator interface is the highest seam and should remain stable while its implementation evolves.
- Use only synthetic domains, identities, roles, endpoints, findings, and evidence references. Tests must never inspect an active engagement or contact a network target.
- Reuse the existing lead-state command tests as prior art for subprocess-level state lifecycle assertions.
- Reuse the existing completion-hook tests as prior art for synthetic stop and sub-agent-stop payloads.
- Reuse the existing static loop-contract tests only for command and agent wiring that cannot be exercised through the coordinator. Do not use phrase-presence tests as the main evidence that orchestration works.
- Test that recon, pentest, full-pentest, and report transition within one immutable engagement identity without stale-context failure.
- Test that two declared assets seed independent required coverage and that completing only one cannot converge.
- Test that every applicable discovery method creates a pending coverage cell and corresponding work or an explicit terminal reason.
- Test that a newly observed in-scope asset or endpoint creates recursive discovery work exactly once.
- Test that discoveries originating from hunters, bypass specialists, exploiters, and explorers all use the same recursive discovery behavior.
- Test that a high-priority deep lead cannot indefinitely starve baseline work for an untouched asset.
- Test that no-progress on one asset does not terminate work on another asset.
- Test that incomplete coverage with an empty lead queue causes the coordinator to synthesize missing work and causes the completion hook to block.
- Test that budget exhaustion returns an incomplete or budget-exhausted outcome with remaining frontier details rather than converged.
- Test that standard test failure against a stable control creates bypass work and cannot directly exhaust the original hypothesis.
- Test each bypass profile transition with representative synthetic negative evidence.
- Test that only applicable and authorized bypass profiles are scheduled.
- Test that completing every applicable bypass profile permits the “not bypassed under the tested matrix” terminal result.
- Test that every lead or finding revision invalidates the prior chain-review digest.
- Test that unrelated findings do not produce a chain candidate.
- Test that a demonstrated capability satisfying another finding’s prerequisite produces one deduplicated chain candidate.
- Test that multiple low-severity findings can produce a separately validated higher-impact chain finding.
- Test that a chain requiring a false rules-of-engagement gate is recorded as blocked or exploitable-not-detonated rather than executed.
- Test that apparent convergence schedules the configured explorer lenses before report work.
- Test that explorer contexts are created from the same input digest and do not contain peer explorer output.
- Test that duplicate or unsupported explorer ideas do not count as progress.
- Test that one accepted explorer lead invalidates the challenge and reopens campaign work.
- Test that a later zero-lead challenge against the updated material digest permits reporting.
- Test that challenge bookkeeping does not change the material digest it is certifying.
- Test that active leases, pending bypass work, stale chain review, pending coverage, or stale challenge digest each independently prevent convergence.
- Test resumability by interrupting synthetic campaigns at recon, hunt, bypass, chain, and challenge states and asserting that the coordinator returns the correct next work after restart.
- Test that report work is emitted automatically after a fully converged
/full-pentest campaign and remains independently requestable.
- Test that the completion and sub-agent hooks fail safely without echoing engagement data while still blocking well-formed incomplete campaign states.
- Run the existing Python, shell, scope, rules-of-engagement, audit, reporting, and workflow regression suites to ensure the deeper coordinator does not weaken established safety behavior.
Out of Scope
- Proving that no undiscoverable path or asset exists. Coverage-complete recon means every known in-scope asset received every applicable authorized discovery method and every resulting surface delta was processed.
- Unbounded brute force, indiscriminate scanning, denial-of-service testing, or any activity prohibited by the engagement rules.
- Automatically expanding authorization when a new hostname, service, credential, identity, or trust boundary is observed.
- Bypassing scope, required headers, rate limits, concurrency limits, or independent rules-of-engagement gates in the name of autonomy.
- Treating speculative explorer output as a finding or reportable vulnerability.
- Replacing existing family playbooks, scope enforcement, evidence storage, finding validation, audit-chain integrity, or deterministic report rendering.
- Guaranteeing successful exploitation or bypass. The feature guarantees bounded specialist review and accurate evidence-backed terminal language.
- Introducing separate duplicated bypass-agent implementations for every vulnerability family.
- Changing the engagement’s retention and evidence-handling policy.
- Automatically deleting or archiving existing engagement state during migration.
Further Notes
- The canonical domain model treats reconnaissance as continuous and recursive, not as an initial scan. “Coverage-complete recon” is a verifiable state; a quiet round or exhausted budget is not equivalent.
- The current campaign state already contains useful primitives such as stable leads, leases, parent references, coverage entries, budgets, and convergence checks. The coordinator should deepen this existing module rather than layering another prompt-only ledger over it.
- The current run identity includes command mode, which conflicts with the intended recon-to-pentest-to-report progression. Phase must move into campaign state while engagement identity remains stable.
- The current completion hook ignores incomplete coverage when no actionable lead exists. This must be addressed at both the coordinator seam and hook integration.
- The three explorer lenses are deliberately role-based rather than cosmetic personalities. Their prompts should drive orthogonal analysis and remain isolated to reduce anchoring.
- No architectural decision records currently constrain this design.
Problem Statement
The pentester currently has to steer the harness through reconnaissance, vulnerability testing, and reporting manually, even though these activities are parts of one engagement. The current loop can focus deeply on a subset of assets while leaving other in-scope assets underexplored, and it can appear finished when the durable lead queue is empty even though recon coverage is incomplete.
Reconnaissance is the foundation of the engagement: it must continuously and recursively discover and characterize the attack surface for every initial and newly discovered in-scope asset. The current global surface-delta and no-progress model does not prove that every asset received every applicable discovery method. Newly discovered endpoints during testing also do not reliably re-enter a dedicated reconnaissance frontier.
When standard vulnerability tests fail against a defensive control, the harness can exhaust a lead without requiring a specialist bypass pass. Findings and leads of individually low severity are not systematically evaluated as building blocks of a higher-impact kill chain. Finally, the same main agent that decides the engagement is finished is not challenged by independent tester perspectives before reporting.
The pentester wants a substantially more autonomous engagement loop that maintains broad attack-surface coverage, recursively responds to discoveries, escalates resistant hypotheses to bounded bypass specialists, evaluates kill chains after every material lead or finding change, and performs an adversarial convergence challenge before declaring completion.
Solution
Introduce a deterministic campaign coordinator that owns the engagement frontier, phase transitions, coverage closure, work scheduling, bypass escalation, kill-chain review checkpoints, convergence challenges, and terminal outcome. It exposes one high-level interface, with a repository-local command adapter, so orchestration behavior is durable and testable rather than dependent on prompt prose.
Provide four user-facing commands:
/reconperforms coverage-complete reconnaissance only./pentesttests the currently known or declared attack surface independently and can create targeted recursive recon work when testing discovers new surface./full-pentestruns the complete autonomous engagement: recursive recon, vulnerability testing, bypass escalation, exploitation within the rules of engagement, kill-chain analysis, convergence challenge, and report generation./reportindependently regenerates the report from durable campaign state and findings.Reconnaissance becomes a continuous engagement responsibility rather than a one-time phase. The coordinator seeds a coverage frontier for every declared in-scope asset and every applicable authorized discovery method. Every newly discovered in-scope asset, endpoint, path, parameter, schema, role, technology, version, protocol, or trust relationship creates a surface delta and corresponding bounded discovery work. Fair scheduling prevents a high-signal asset from starving untouched assets.
When standard testing encounters a stable defensive control, the coordinator creates a bypass lead rather than marking the hypothesis exhausted. A bypass-specialist agent is dispatched with an explicit profile and the original negative evidence. Exhaustion is permitted only after both standard and applicable specialist stages are terminal.
After every durable lead or finding change, regardless of severity, the main orchestrator evaluates whether demonstrated capabilities satisfy the prerequisites of other observations. Evidence-grounded candidates become deduplicated chain leads. A validated chain becomes its own finding with references to all component findings and severity based on demonstrated combined impact.
When the campaign first appears converged, the coordinator dispatches one to three isolated lead explorers using orthogonal tester lenses. Any accepted unique lead reopens the campaign. Reporting is allowed only after the current material frontier has received a completed convergence challenge with zero accepted leads.
User Stories
/full-pentestcommand, so that I do not have to manually invoke reconnaissance, testing, and reporting in sequence./reconto remain independently available, so that I can map an attack surface without beginning vulnerability testing./pentestto remain independently available, so that I can test a known or declared attack surface without requesting the exhaustive full campaign./reportto remain independently available, so that I can regenerate a report without touching the target./full-pentesttruly converges, so that no manual/reportinvocation is needed.Implementation Decisions
/full-pentestas the exhaustive autonomous entry point. It runs recursive recon and vulnerability testing as a bidirectional loop, performs final convergence challenges, and automatically renders the report./reconto coverage-complete attack-surface discovery without vulnerability hunting./pentestto vulnerability testing over the current or declared surface. It may create targeted recon work for new surface but does not claim exhaustive recon coverage unless the coverage frontier proves it./reportread-only and independently runnable against durable findings and campaign state./full-pentestto all three explorer lenses. Allow one or two only when engagement complexity, authorization, or budget explicitly requires a reduced challenge.Testing Decisions
/full-pentestcampaign and remains independently requestable.Out of Scope
Further Notes