Sweeper

Sweeper is a prompt pack for orchestrating a white-box web application security review with a dependency-aware multi-agent workflow.

The repository contains specialist Markdown prompts that guide agents through:

• pre-recon architecture analysis
• attack-surface reconnaissance
• authentication review
• authorization review
• injection analysis
• IDOR and data exposure analysis
• XSS analysis
• SSRF analysis
• secrets and configuration review
• business logic review
• rate limiting and abuse review
• dependency and supply chain review
• final report synthesis

The prompts are designed to be run by an orchestrator that understands staged dependencies, parallel execution, and deliverable passing through a shared deliverables/ directory.

Repository Contents

File	Role
1.PreRecon.md	Repository-wide pre-recon and architectural security summary
2.Reconnaisance.md	Reachable surface mapping from code and live target context
3.AuthVuln.md	Authentication analysis
4.AuthZVuln.md	Authorization and access-control analysis
5.InjectionVuln.md	Injection analysis
6.IDORVuln.md	IDOR and data exposure analysis
7.XSSVuln.md	XSS analysis
8.SSRFVuln.md	SSRF analysis
9.SecretsConfigVuln.md	Secrets, crypto, and configuration analysis
10.BizLogicVuln.md	Business logic and workflow integrity analysis
11.RateLimitVuln.md	Rate limiting and resource abuse analysis
12.DependencyVuln.md	Dependency and supply chain analysis
13.report.md	Final report synthesis prompt

Two filenames intentionally retain the source naming used when these prompts were assembled:

• 2.Reconnaisance.md
• 13.report.md

How It Works

The dependency chain is already encoded inside the prompts via their <required_inputs> sections. In practice, the workflow is:

Phase 1: Sequential Foundation

These steps should run in order because each stage depends on the previous stage's output.

1. 1.PreRecon.md Produces deliverables/pre_recon_deliverable.md
2. 2.Reconnaisance.md Reads deliverables/pre_recon_deliverable.md Produces deliverables/recon_deliverable.md
3. 3.AuthVuln.md Reads deliverables/recon_deliverable.md Optionally uses deliverables/pre_recon_deliverable.md Produces deliverables/auth_analysis_deliverable.md

Authentication is kept in the sequential phase because downstream prompts use its output for de-duplication and clearer scoping.

Phase 2: Parallel Specialist Analysis

Once authentication has completed, these prompts can run concurrently:

4. 4.AuthZVuln.md
5. 5.InjectionVuln.md
6. 6.IDORVuln.md
7. 7.XSSVuln.md
8. 8.SSRFVuln.md
9. 9.SecretsConfigVuln.md
10. 11.RateLimitVuln.md
11. 12.DependencyVuln.md

All of these consume deliverables/recon_deliverable.md, with deliverables/pre_recon_deliverable.md used as supporting context. 11.RateLimitVuln.md can also read deliverables/auth_analysis_deliverable.md when available.

Phase 2b: Business Logic

10.BizLogicVuln.md can be handled in one of two ways:

• Run it with the Phase 2 batch and allow it to proceed without AuthZ de-duplication if deliverables/authz_analysis_deliverable.md is not ready yet.
• Start it as soon as 4.AuthZVuln.md finishes for slightly cleaner cross-specialist de-duplication.

The prompt already handles the missing AuthZ deliverable gracefully, so the simpler orchestration choice is to include it in the main parallel batch.

Phase 3: Final Report

Run 13.report.md last.

It synthesizes the specialist deliverables into:

• deliverables/security_assessment_report.md
• deliverables/security_assessment_report.pdf

Execution Graph

flowchart LR
    A["1. Pre-Recon"] --> B["2. Reconnaissance"]
    B --> C["3. Authentication"]
    C --> D["4. Authorization"]
    C --> E["5. Injection"]
    C --> F["6. IDOR"]
    C --> G["7. XSS"]
    C --> H["8. SSRF"]
    C --> I["9. Secrets/Config"]
    C --> J["11. Rate Limiting"]
    C --> K["12. Dependency"]
    C --> L["10. Business Logic"]
    D --> L
    D --> M["13. Report Writer"]
    E --> M
    F --> M
    G --> M
    H --> M
    I --> M
    J --> M
    K --> M
    L --> M

Loading

Deliverables

The prompts are built around a shared deliverables/ directory. The core files in the pipeline are:

• deliverables/pre_recon_deliverable.md
• deliverables/recon_deliverable.md
• deliverables/auth_analysis_deliverable.md
• deliverables/authz_analysis_deliverable.md
• deliverables/injection_analysis_deliverable.md
• deliverables/idor_analysis_deliverable.md
• deliverables/xss_analysis_deliverable.md
• deliverables/ssrf_analysis_deliverable.md
• deliverables/secrets_analysis_deliverable.md
• deliverables/bizlogic_analysis_deliverable.md
• deliverables/ratelimit_analysis_deliverable.md
• deliverables/dependency_analysis_deliverable.md
• deliverables/security_assessment_report.md
• deliverables/security_assessment_report.pdf

Some workflows may also emit machine-readable queue JSON files alongside the Markdown deliverables. The final report prompt is designed to prefer those queue files as canonical finding inventories when present.

Requirements

Before you run the orchestrator, you need:

• Python 3.10 or later
• the Codex CLI installed and available on PATH
• a working Codex login on the machine, usually via ChatGPT-backed login
• a target repository to review

If you want to use the GUI launcher, no extra dependencies are needed beyond Python's standard library. The launcher uses tkinter, which ships with the normal Python installation on macOS and most Linux setups.

Install Codex CLI if needed:

npm i -g @openai/codex

Check that Codex is available:

codex --version
codex login status

If codex login status does not show a valid login, run:

codex

and complete the sign-in flow.

How To Run

This repository now includes a local runner at autopentest_orchestrator.py.

It also includes a Tkinter launcher at autopentest_gui.py for users who do not want to work directly from the terminal.

The runner uses codex exec against a separate target repository, reuses the local Codex CLI login by default, writes deliverables into the target repo, and stores a per-run manifest plus logs under deliverables/_autopentest_runs/.

It also treats specialist queue JSONs as first-class outputs, supports per-stage timeouts, captures token-usage metadata from codex exec --json when available, and continues through partial specialist failures by default so later synthesis can still run on available evidence.

See ORCHESTRATOR.md for usage and caveats.

License

This repository is public for visibility, but it is not an unrestricted open-source project.

• Copyright remains with Stuart Armley-Jones.
• Attribution is required for any permitted reference or quoted excerpt.
• Commercial use, redistribution, and public derivative works require prior written permission.

See LICENSE for the full terms.

GUI launcher

Start the launcher with:

cd /path/to/local/Sweeper
python3 autopentest_gui.py

The GUI lets you:

• pick the target repository with a directory chooser
• optionally enter the deployed application URL
• set strict, bizlogic-waits-for-authz, include-report, and skip-git-repo-check
• adjust parallelism and stage timeout
• run either Dry Run or Run
• watch stage progress from the manifest
• view live orchestrator output in the console panel
• open the manifest, deliverables folder, logs, and report PDF after completion

On startup, the GUI checks codex login status. If Codex auth is unavailable, the run buttons stay disabled until auth is fixed and rechecked.

CLI runner

1. Change into this repository

cd /path/to/local/Sweeper

2. Dry-run the plan first

Replace /path/to/target-repo with the repository you want to review.

python3 autopentest_orchestrator.py \
  --target-repo /path/to/target-repo \
  --dry-run

This prints:

• the detected Codex auth mode
• the run directory that will be used
• the stage order
• the expected output files for each stage

3. Run the assessment

If you know the deployed application URL, pass it as --target-url. This helps the prompts that reason about live route context.

python3 autopentest_orchestrator.py \
  --target-repo /path/to/target-repo \
  --target-url https://app.example.com

4. Check the outputs

The orchestrator writes results into the target repository, not this prompt repository.

Look in:

• /path/to/target-repo/deliverables/
• /path/to/target-repo/deliverables/_autopentest_runs/<timestamp>/manifest.json
• /path/to/target-repo/deliverables/_autopentest_runs/<timestamp>/logs/
• /path/to/target-repo/deliverables/_autopentest_runs/<timestamp>/final_messages/

Typical specialist outputs include:

• deliverables/pre_recon_deliverable.md
• deliverables/recon_deliverable.md
• deliverables/auth_analysis_deliverable.md
• deliverables/auth_queue.json
• deliverables/authz_analysis_deliverable.md
• deliverables/authz_queue.json

and the equivalent Markdown plus queue JSON pair for each specialist stage.

5. Re-run safely

The orchestrator skips completed stages by default when their expected outputs already exist.

Run the same command again to resume after a failure:

python3 autopentest_orchestrator.py \
  --target-repo /path/to/target-repo \
  --target-url https://app.example.com

If you want to force stages to run again, disable the skip behavior:

python3 autopentest_orchestrator.py \
  --target-repo /path/to/target-repo \
  --target-url https://app.example.com \
  --no-skip-existing

Common Run Modes

Lower concurrency:

python3 autopentest_orchestrator.py \
  --target-repo /path/to/target-repo \
  --parallelism 2

Make business logic wait for AuthZ:

python3 autopentest_orchestrator.py \
  --target-repo /path/to/target-repo \
  --bizlogic-waits-for-authz

Fail the whole run if any specialist stage fails:

python3 autopentest_orchestrator.py \
  --target-repo /path/to/target-repo \
  --strict

Increase the per-stage timeout:

python3 autopentest_orchestrator.py \
  --target-repo /path/to/target-repo \
  --stage-timeout 3600

Run against a source tree that is not a git repository:

python3 autopentest_orchestrator.py \
  --target-repo /path/to/source-tree \
  --skip-git-repo-check

Attempt the report stage anyway:

python3 autopentest_orchestrator.py \
  --target-repo /path/to/target-repo \
  --include-report \
  --allow-report-patch-notes

Use a specific Codex model:

python3 autopentest_orchestrator.py \
  --target-repo /path/to/target-repo \
  --model gpt-5.4

What To Expect

By default, the orchestrator:

• runs the first three stages sequentially
• runs the specialist stages in parallel with --parallelism 4
• treats queue JSONs as required outputs for specialist stages
• continues past partial specialist failure unless --strict is set
• records per-stage logs, output paths, timing, and usage in the run manifest
• skips the report stage unless you explicitly enable it

At the end of the run it prints a summary including:

• how many stages completed
• how many failed, timed out, or were blocked
• aggregate token usage if Codex emitted usage events
• any report files that were produced
• the manifest path for the run

The prompt pack still does not require this specific runner, but it assumes an orchestrator that can:

• run prompts in a fixed order where dependencies exist
• dispatch independent prompts in parallel
• wait for all parallel workers to complete before report synthesis
• persist outputs into deliverables/
• pass the repository under review as the current working directory or mounted workspace

At a high level, the orchestration model is:

1. Run pre-recon.
2. Run reconnaissance.
3. Run authentication.
4. Dispatch the specialist prompts in parallel.
5. Wait for completion.
6. Run the final report writer.

In shell, this is a small wrapper around background jobs plus wait. In Python, asyncio.gather or concurrent.futures is enough.

Design Notes

• The prompts are evidence-first and expect findings to trace back to code, configuration, or clearly bounded live reachability checks.
• Recon is the main routing artifact for most specialist analysis.
• Authentication is separated early because it reduces duplicate reasoning across later prompts.
• Business logic is intentionally tolerant of missing AuthZ output so the orchestration remains simple.
• The report writer is a synthesis stage, not a scanner. It should only consolidate specialist evidence and explicitly note missing inputs.

Intended Use

This repository is suited to:

• internal white-box application security reviews
• repeatable multi-agent assessment pipelines
• prompt-driven security analysis with explicit stage boundaries
• environments where you want deterministic sequencing before parallel specialist review

It is not a standalone scanner. The quality of the output depends on the quality of the orchestrator, the reviewed codebase, and the discipline with which deliverables are persisted between stages.