**工作原理：**

1. **Claude Code** 读取 `CLAUDE.md` 获取完整渗透测试方法，并编排 7 阶段工作流
2. **角色专业化子代理**（侦察兵、分析者、利用者、报告者）使用专用提示模板、工具指导和反模式执行聚焦任务
3. **WSTG MCP 服务器**（68+ 工具）提供 OWASP 测试程序、31 份 PortSwigger 技术指南、层次化任务树、知识图谱、WAF 绕过、端点优先级排序、结果验证、上下文压缩、质量门控和报告生成
4. **Docker 容器**运行全部 27 个安全工具——流量可选择性通过 Burp Suite 路由以进行被动监控
5. **Playwright MCP**处理基于浏览器的测试（DOM XSS、点击劫持、JS 渲染的登录页面）

---

## 功能特性

### 全面的 OWASP 覆盖
- **109 个 WSTG 测试用例**，涵盖 12 个类别——从信息收集到 API 测试
- 每个测试包含步骤式 CLI 程序、上下文相关有效载荷、检测标准和严重性分级
- 测试按优先级（必须/应该）排列，并附带条件触发，确保不跳过任何相关内容

### 31 个 PortSwigger 攻击技术指南
- 来源于 [PortSwigger Web 安全学院](https://portswigger.net/web-security)——检测方法、利用技术、有效载荷、速查表和 WAF 绕过模式
- 按漏洞类别（SQLi、XSS、SSRF、JWT、OAuth 等）组织，便于测试时直接使用
- 集成到每个测试阶段——代理在测试每个漏洞类别前自动加载相关技术指南
- 数据库/平台特定有效载荷表（SQLi 的 Oracle vs MySQL vs PostgreSQL vs MSSQL，SSTI 的 Jinja2 vs Twig vs Freemarker 等）
- WAF 绕过模式按绕过级别（基础→中级→高级）组织

### 27 个预配置安全工具
- 所有工具已预装在单个 Docker 镜像中——运行 `make setup` 即可准备就绪
- 工具按阶段组织：发现、注入测试、身份验证、密码学、API 测试
- 自动 Burp Suite 代理集成，用于被动流量监控

### 结构化的 7 阶段工作流
- **阶段 0：** 应用发现与映射
- **阶段 1：** 信息收集与侦察
- **阶段 2：** 配置与部署测试
- **阶段 3：** 身份、认证、授权与会话管理
- **阶段 4：** 输入验证测试（流水线化 XSS/SQLi/SSRF 管道）
- **阶段 5：** 错误处理、密码学、业务逻辑、客户端与 API 测试
- **阶段 6：** 覆盖验证与报告
- **阶段 7：** 最终评审与修复

### 质量保证系统
- **自动化阶段门控**——每个阶段必须通过质量检查才能继续
- **质量审查者**子代理在每个阶段过渡时识别差距并提出改进建议
- **最终评审**——一个零上下文的代理以外部 QA 审查员的视角冷启动审查整个参与过程
- **穷举门控**——“未发现漏洞”需要证明足够的测试努力（最少技术和绕过尝试）

### 基于证据的发现
- 每个发现需要可重现的 curl 命令以及完整的请求/响应证据
- **三级分类：** 已利用（已证实的危害）、潜在（被控制措施阻止）、误报（控制措施有效）
- **反幻觉框架**——“无利用即无发现”在每个级别得到强制执行
- 每个漏洞类别的证据检查清单在记录任何发现前进行验证

### 角色专业化子代理
- **4 个专用角色**，配备聚焦的提示模板、工具指导和反模式：
  - **侦察兵**——仅进行侦察，映射攻击面而不发送有效载荷（阶段 0-1）
  - **分析者**——使用金丝雀/佐证有效载荷识别潜在注入点，构建利用队列（阶段 2-5 分析）
  - **利用者**——消耗分析者输出，用证据证明利用，记录已确认发现（阶段 4 利用）
  - **报告者**——质量审查和最终评审，审查数据而不发送请求（QA + 报告后）
- 分析与利用之间的验证检查点可防止浪费精力
- 每个角色具有明确的允许/限制工具列表以及输入/输出协议

### 流水线化利用（阶段 4）
- 3 条独立的**两阶段流水线**并行运行：XSS、注入（SQLi/CMDi）、SSRF/SSTI
- 每条流水线：分析者（发现→分析→排队）→ 验证检查点 → 利用者（利用→记录）
- 每条流水线加载其 PortSwigger 技术指南，用于检测方法、速查表和 WAF 绕过模式
- WAF 智能跨所有流水线共享
- 针对 13 种注入点类型的上下文感知佐证有效载荷

### 自适应 WAF 绕过
- **自动 WAF 指纹识别**，通过响应头、正文和状态码——识别 12 种 WAF 厂商（Cloudflare、AWS WAF、Akamai、Imperva、ModSecurity、F5、FortiWeb、Sucuri、Barracuda、Wordfence、NAXSI、Citrix）
- **厂商特定绕过有效载荷**按复杂度级别（基础→中级→高级）组织
- WAF 智能通过交付物系统在所有代理间共享
- 代理在首次遇到阻止响应时自动识别 WAF 并切换到定制的绕过有效载荷

### 跨阶段知识图谱
- **实体-关系图**追踪端点、参数、技术、发现、Cookie、域名和用户角色
- **自动漏洞链利用**，通过 BFS 路径查找，具有 7 个预定义链模式：
  - XSS + 缺少 CSP、XSS + 弱 Cookie（无 HttpOnly）、开放重定向 + OAuth 回调
  - IDOR + 管理员角色、SSRF + 云元数据、无锁定 + 无 MFA、CORS + 敏感端点
- 当链利用实质上增加危害时，严重性升级
- 在测试过程中持续填充，在阶段 4 之后查询以发现链

### 层次化任务树
- 持久树结构（阶段为分支，测试为叶子）防止 LLM 深度优先偏差和上下文丢失
- 主代理维护战略宏观视图；子代理仅更新其分配的叶子节点
- 自动传播：当所有子节点完成时，父节点自动完成
- 阶段级完成百分比，用于知情决策

### 端点风险优先级排序
- 按风险对端点进行评分和排序，以进行优先级测试——风险最高的先测试
- 评分因素：参数数量、技术风险指标、污点链置信度、工具收敛、认证要求、可注入参数名称
- 集成到阶段 0 端点映射生成中

### 工具输出解析
- **13 个内置解析器**，针对常见 CLI 工具（nmap、nuclei、sqlmap、ffuf、httpx、whatweb、testssl、nikto、dalfox、katana、gau、wapiti、commix）
- 将原始工具输出压缩 3-5 倍，同时保留关键发现、端点和错误
- 可配置详细程度：摘要（约 15 行）、详细（约 50 行）、完整（完整解析输出）

### CLI 工具结果验证
- 自动验证 CLI 工具输出质量——检测空输出、代理错误、权限问题和可疑结果
- **10 个逐工具验证器**（nmap、nuclei、sqlmap、ffuf、feroxbuster、testssl、dalfox、wapiti、katana、httpx），附带修正命令建议
- 当工具产生空或可疑输出时，验证器建议修复（例如，为 nmap 添加 `-Pn`、移除代理环境变量、尝试不同标志）
- 集成到工具执行工作流中——代理在每个 CLI 工具运行后调用 `verify_tool_result()`

### 渐进式上下文压缩
- **阶段摘要**（约 500-800 字）在阶段门控通过时自动生成——以压缩形式捕获发现、覆盖范围、工具结果和攻击面
- 通过用结构化摘要替换原始历史数据，防止长时间运行参与中的上下文退化
- `get_engagement_summary()` 将所有阶段摘要合并为单一概览，用于注入到新的子代理提示中
- 摘要作为交付物存储——任何下游代理均可访问，无需完整参与历史

### 反事实分析（二次发现）
- 在分析者完成并发现漏洞后，生成一个**第二分析者**，指示“假设这些漏洞已被修补”
- 反事实分析者搜索**额外**的漏洞：不同的端点、不同的参数、不同的注入上下文、逻辑缺陷
- 结果附加到现有利用队列（自动合并，通过端点+参数去重，自增 ID）
- 基于 PenHeal 消融研究，反事实提示可将漏洞覆盖范围提高 +71%

### 多域名支持
- 自动检测和处理 SSO/OAuth/OIDC/SAML
- 按域的范围注册、爬取和测试
- Cookie jar 管理，用于跨域会话持久化
- 6 级认证失败升级（替代授权 → PKCE → 无头浏览器 → 令牌提取 → 用户提供 → 未认证）

### 崩溃安全参与管理
- 仅追加的 `findings.md` 和 `progress.log` 在崩溃后依然存在
- Git 工作空间检查点，具有回滚能力
- **中断时自动恢复**——在每个检查点自动生成 `resume-prompt.md`，包含完整上下文（目标、凭证、当前阶段、剩余测试、范围）。粘贴到新会话中即可从上次中断处继续
- 阶段内检查点粒度——追踪阶段内哪些测试已完成，而不仅仅是阶段级状态
- 每次 MCP 工具调用的完整审计跟踪，带有时间戳

### 专业报告
- Markdown 格式报告，包含执行摘要、按严重性排序的发现、测试覆盖矩阵和工具覆盖
- 按类别的覆盖百分比和差距分析
- 记录漏洞链利用分析
- 包含最终评审观察结果和质量备注

---

## 代理角色系统

AutoPentest 使用 4 个专业代理角色，而非通用子代理。每个角色具有专用提示模板，包含聚焦的工具指导、输入/输出协议和反模式。

| 角色 | 模板 | 用途 | 阶段 |
|------|------|------|------|
| **侦察兵** | `templates/agent-roles/scout.md` | 侦察和攻击面映射 | 阶段 0-1，源代码发现 |
| **分析者** | `templates/agent-roles/analyzer.md` | 使用金丝雀/佐证有效载荷发现漏洞 | 阶段 2-5 分析 |
| **利用者** | `templates/agent-roles/exploiter.md` | 利用证据证明 | 阶段 4 利用 |
| **报告者** | `templates/agent-roles/reporter.md` | 质量审查和最终评审 | 阶段过渡，报告后 |

### 流水线工作原理

阶段 4（最高影响测试）对每个漏洞类别使用两阶段流水线：```
┌──────────────────────────────────────────────────────────────┐
│                    Pipeline 1: XSS                           │
│                                                              │
│  Analyzer (75 turns)          Exploiter (75 turns)           │
│  ┌─────────────────────┐      ┌─────────────────────┐        │
│  │ Discover endpoints  │      │ Load Analyzer queue │        │
│  │ Send canary payloads│─────▶│ Attempt exploitation│        │
│  │ Build exploit queue │ gate │ Prove impact        │        │
│  │ Save deliverable    │      │ Log findings        │        │
│  └─────────────────────┘      └─────────────────────┘        │
│                          ▲                                   │
│               validate_exploitation_queue()                  │
└──────────────────────────────────────────────────────────────┘

就这样。现在所有27个安全工具都已安装并在Docker容器内就绪。

### 验证安装```bash
# Check all tools are installed
make verify-tools

# Expected output:
# [+] nuclei: installed
# [+] httpx: installed
# [+] katana: installed
# ... (27 tools total)

然后告诉Claude要测试什么：```
Run a full WSTG assessment against https://target.example.com

Claude 会询问任何缺失的信息（如凭证），然后开始7阶段工作流。

### Option B: Config-Driven Mode (推荐)

创建一个YAML配置文件用于可重复、一致的评估：```yaml
# configs/my-target.yaml
target:
  url: https://app.example.com
  scope:
    - app.example.com
    - api.example.com
  exclude:
    - cdn.example.com

authentication:
  login_type: form
  login_url: https://app.example.com/login
  credentials:
    username: [email protected]
    password: secret123
  login_flow:
    - "Type $username into the email field"
    - "Type $password into the password field"
    - "Click the 'Sign In' button"
  success_condition:
    type: url_contains
    value: "/dashboard"

rules:
  avoid:
    - description: "Do not test logout"
      type: path
      url_path: "/logout"
  focus:
    - description: "Prioritize API endpoints"
      type: path
      url_path: "/api"

reporting:
  tester_name: "Security Team"

### 选项 C：针对性测试

针对特定端点运行特定的 WSTG 测试：```
Run WSTG-INPV-05 (SQL Injection) against https://app.example.com/search?q=

```bash
git clone https://github.com/Araekiel/orion.git
cd orion
pip install -r requirements.txt
python orion.py -u target.com

### 选项 D：恢复已中断的交互```
Resume engagement pentest-2026-02-11-myapp

每个并行测试代理在测试前会自动加载相关的技术指南，提供：
- **检测载荷** — 注入以识别漏洞的载荷
- **利用技术** — 按攻击方法组织，包含逐步操作流程
- **速查表** — 数据库/平台特定的语法参考表
- **WAF绕过模式** — 编码、混淆及过滤器绕过策略

### 添加自定义指南

参见 [`docs/adding-knowledge-base-resources.md`](https://github.com/bhavsec/autopentest-ai/blob/HEAD/docs/adding-knowledge-base-resources.md) 了解向知识库中添加新技术指南的说明。

---

## 质量保证系统

AutoPentest 拥有多层 QA 系统，防止浅层测试：

### 1. 阶段关口（自动化）

每个阶段结束后，`phase_gate_check()` 会验证：
- 所有 MUST 优先级的测试均已执行
- 最低覆盖率阈值已达标
- 工具覆盖充分
- 不存在关键缺口

**受阻阶段无法继续**，直到所有问题解决。

### 2. 质量审查员（每阶段一次）

在每个阶段转换时生成一个子代理，其职责包括：
- 检查 16 种已知反模式（橡皮图章式确认、N/A 级联、发现膨胀）
- 识别未测试的端点与参数
- 提出漏洞链利用机会
- 为受阻测试推荐替代方案

### 3. 最终评审员（报告后）

一个零上下文代理，以全新视角审查已完成的任务：
- 分析所有领域的覆盖率完整性
- 检测 N/A 级联及其根本原因
- 验证发现质量与证据完整性
- 识别被忽略的攻击面
- 给出裁决：**通过**、**有条件通过** 或 **未通过**

### 4. 耗竭门控

将漏洞标记为“不可利用”需要证明尝试的充分性：

| 漏洞类别 | 最少技术 | 最少绕过尝试 |
|----------|:--------:|:------------:|
| XSS          | 3 | 5 |
| SQL注入      | 3 | 5 |
| 命令注入     | 3 | 5 |
| SSTI         | 2 | 3 |
| SSRF         | 3 | 5 |
| 路径穿越     | 3 | 5 |

### 5. 证据清单

在记录任何发现之前，核实证据要求：
- 可复现的 curl 命令
- 完整的 HTTP 请求与响应
- 实际利用的证明（非理论影响）
- 正确的分类层级（已利用  vs  可能存在）

### 6. 实时任务记录

每次 MCP 工具调用自动记录到 `engagements/<eid>/logs.txt`，包含完整参数、结果和执行时长。在另一个终端运行 `tail -f logs.txt` 即可实时查看所有代理活动。通过自动工具包装实现 100% 覆盖率——无需手动插桩。

### 7. 阶段关口时间控制

阶段门控强制调用间隔至少 60 秒（CTF 模式为 15 秒），防止阶段提前完成。连续门控之间的工作量验证：若两个连续门控之间工作事件少于 3 个，则发出警告。

---

## 基准测试

AutoPentest 集成了 [XBOW 验证基准测试](https://github.com/xbow-engineering/validation-benchmarks)——104 个 CTF 风格的 Docker 挑战，作为 AI 渗透测试代理基准测试的行业标准。

### 基准测试分数（参考）

| 代理          | 分数   | 来源              |
|---------------|:------:|-------------------|
| Shannon       | 96.2%  | KeygraphHQ (2024) |
| PentestGPT    | 86.5%  | USENIX Sec 2024   |

### 使用方式```bash
# Setup (one-time)
cd benchmarks/xbow && make setup

# Solve with AutoPentest (MCP server + CLAUDE.md + CTF mode)
make solve ID=XBEN-001-24

# Solve with raw Claude (baseline — no MCP, no methodology)
make solve ID=XBEN-001-24 RAW=1

# Solve by vulnerability tag
make solve-tag TAG=sqli

# Solve all 104 challenges
make solve-all

# Full baseline run for comparison
make solve-all RAW=1

# Score the latest run
make score

# Compare autopentest vs raw runs side-by-side
make compare

CTF模式会缩短阶段闸门时间（15秒对比60秒），跳过QA评审人员要求，并将完成阈值减半——同时保持发现质量和证据标准。

---

## 示例报告

仓库中包含一份针对[PortSwigger的Gin & Juice Shop](https://ginandjuice.shop)（一个故意存在漏洞的应用程序）进行渗透测试的完整示例报告：

**[查看完整报告](https://github.com/bhavsec/autopentest-ai/blob/HEAD/engagements/pentest-2026-ginandjuice/report.md)**

### 报告包含内容

该报告展示了AutoPentest针对一个真实目标的输出，包含23个跨越所有严重级别的发现：

| 严重性 | 数量 | 示例 |
|----------|:-----:|---------|
| Critical | 2 | 基于UNION的SQL注入，可完全提取数据；通过X-Original-URL标头绕过访问控制 |
| High | 5 | 通过JS字符串转义绕过实现反射型XSS；订单详情IDOR；XXE实现本地文件读取；通过原型污染实现DOM型XSS |
| Medium | 6 | 缺少安全标头；无账户锁定机制；缺少CSP；CRLF注入；基于DOM的开放重定向 |
| Low | 5 | 基础设施信息泄露；过时AngularJS；不安全的ALB Cookie；TLS配置薄弱 |
| Informational | 5 | 合并重复项及主要发现中的辅助证据 |

### 报告结构```
1. Executive Summary         — Target scope, finding summary, domain architecture
2. Detailed Findings         — Each finding with description, evidence (curl commands), and remediation
3. Vulnerability Chaining    — Cross-finding analysis (e.g., XSS + no CSP = severity upgrade)
4. Test Coverage Matrix      — Per-category WSTG coverage (100% across 12 categories)
5. Tool Coverage Matrix      — 27/27 tools tracked, 8 actively run

每个发现都包含可复现的curl命令、完整的请求/响应证据以及可操作的修复指导。

---

## 配置

### 测试配置（YAML）

基于配置的渗透测试跳过交互式问题，确保一致性：```yaml
target:
  url: https://app.example.com
  scope: [app.example.com, api.example.com]

authentication:
  login_type: sso                    # form | sso | api | manual | none
  login_url: https://app.example.com/login
  credentials:
    username: testuser
    password: secret123
  sso:
    provider: keycloak               # keycloak | auth0 | okta | azure_ad
    auth_domain: auth.example.com
    realm: myrealm
    client_id: my-app

rules:
  avoid:
    - { type: path, url_path: "/logout", description: "Skip logout" }
    - { type: endpoint, method: DELETE, url_path: "/api/admin/*", description: "No destructive admin ops" }
  focus:
    - { type: path, url_path: "/api", description: "Prioritize API" }

reporting:
  tester_name: "Security Team"

### Burp Suite 集成（可选）

通过 Burp Suite Professional 进行被动流量监控：

1. 启动 Burp Suite 并在**所有接口**上启用代理（`0.0.0.0:8080`）
2. Docker 容器自动通过 `host.docker.internal:8080` 路由流量
3. 所有 HTTP 请求会出现在 Burp 的代理历史中，供手动审查

---

## 多域测试

AutoPentest 对包含多个域的应用（例如 SPA 前端 + API 后端 + SSO 提供者）提供一流支持：

### 自动检测

在第 0 阶段，AutoPentest 通过跟踪登录重定向来检测跨域认证：```
app.example.com → redirects to → auth.example.com/login
                 → after login → app.example.com/callback

这会恢复：
- 所有发现和测试跟踪数据
- 覆盖率统计和阶段门结果
- 范围注册和可交付物
- 阶段中剩余测试（不仅仅是阶段级状态）
- 下一步操作说明

### 手动检查点

随时保存：```
Save a checkpoint before starting Phase 4 exploitation

---

## 项目结构```
autopentest-ai/
├── CLAUDE.md                          # Master pentest workflow (drives Claude Code)
├── .mcp.json                          # MCP server configuration
├── Dockerfile                         # Multi-stage Docker build (27 tools)
├── docker-compose.yml                 # Docker Compose alternative
├── Makefile                           # setup, start, stop, verify-tools, shell
│
├── server/
│   ├── server.py                      # FastMCP server (68+ MCP tools)
│   ├── task_tree.py                   # Hierarchical task tree (6 MCP tools)
│   ├── tool_parsers.py                # Tool output parsing (2 MCP tools, 13 parsers)
│   ├── endpoint_priority.py           # Endpoint risk prioritization (2 MCP tools)
│   ├── waf_evasion.py                 # Adaptive WAF evasion (3 MCP tools, 12 vendors)
│   ├── knowledge_graph.py             # Cross-phase knowledge graph (5 MCP tools)
│   ├── tool_verification.py           # CLI tool results verification (1 MCP tool, 10 validators)
│   ├── context_compression.py         # Progressive context compression (2 MCP tools)
│   └── pyproject.toml                 # Python dependencies
│
├── knowledge-base/
│   ├── web-security-testing-guide/    # OWASP WSTG knowledge base (109 test procedures)
│   │   ├── 01-information-gathering/  # 10 tests (WSTG-INFO-01 → 10)
│   │   ├── 02-configuration/          # 14 tests (WSTG-CONF-01 → 14)
│   │   ├── 03-identity-management/    # 5 tests  (WSTG-IDNT-01 → 05)
│   │   ├── 04-authentication/         # 11 tests (WSTG-ATHN-01 → 11)
│   │   ├── 05-authorization/          # 5 tests  (WSTG-ATHZ-01 → 05)
│   │   ├── 06-session-management/     # 11 tests (WSTG-SESS-01 → 11)
│   │   ├── 07-input-validation/       # 20 tests (WSTG-INPV-01 → 20)
│   │   ├── 08-error-handling/         # 2 tests  (WSTG-ERRH-01 → 02)
│   │   ├── 09-cryptography/           # 4 tests  (WSTG-CRYP-01 → 04)
│   │   ├── 10-business-logic/         # 10 tests (WSTG-BUSL-01 → 10)
│   │   ├── 11-client-side/            # 14 tests (WSTG-CLNT-01 → 14)
│   │   └── 12-api-testing/            # 3 tests  (WSTG-APIT-01 → 03)
│   └── portswigger-academy/           # 31 PortSwigger attack technique guides
│       ├── sql-injection.md           # UNION, blind, error-based, OOB, WAF bypass
│       ├── cross-site-scripting.md    # Reflected, stored, DOM, CSP bypass, filter evasion
│       ├── ssrf.md                    # URL schemes, cloud metadata, DNS rebinding
│       ├── ssti.md                    # Jinja2, Twig, Freemarker sandbox escapes
│       ├── jwt.md                     # Algorithm confusion, kid injection, JWK exploitation
│       ├── oauth.md                   # Auth code theft, redirect exploitation, scope upgrade
│       └── ... (31 total)             # One per vulnerability class
│
├── templates/                         # Testing guides and procedures
│   ├── input-validation-guide.md      # Phase 4 step-by-step procedures
│   ├── testing-strategies.md          # Test matrices, chaining, parallel strategy
│   ├── cli-tools-guide.md             # Tool setup and Docker management
│   ├── tools.md                       # Per-tool command reference
│   ├── quality-gates.md               # Phase quality checklists and anti-patterns
│   ├── cross-domain-auth-guide.md     # SSO/OIDC/SAML procedures
│   ├── source-code-analysis.md        # Security-focused code review template
│   ├── pipelined-testing.md           # Phase 4 pipelined exploitation strategy
│   ├── agent-roles/                   # Role-specialized subagent templates
│   │   ├── README.md                  # Role index and selection guide
│   │   ├── scout.md                   # Reconnaissance role (Phase 0-1)
│   │   ├── analyzer.md                # Vulnerability discovery role (Phase 2-5)
│   │   ├── exploiter.md               # Exploitation proof role (Phase 4)
│   │   └── reporter.md                # QA review + Final Judge role
│   ├── shared/
│   │   ├── honesty-framework.md       # Anti-hallucination guardrails
│   │   ├── exploit-classification.md  # Three-tier finding classification
│   │   ├── reproducibility.md         # Evidence format requirements
│   │   └── scope-rules.md            # Avoid/focus rule templates
│   └── wordlists/                     # Tech-specific fuzzing wordlists
│
├── benchmarks/
│   └── xbow/                              # XBOW benchmark suite (104 CTF challenges)
│       ├── runner.py                      # Challenge orchestration
│       ├── solver.py                      # Automated solver (Claude Code CLI)
│       ├── Makefile                       # solve, solve-all, score, compare
│       └── results/                       # Run reports
│
├── docs/
│   ├── ROADMAP.md                         # Competitive analysis + improvement roadmap
│   └── adding-knowledge-base-resources.md # Guide for adding new technique guides
│
├── configs/
│   ├── example-config.yaml            # Example engagement configuration
│   └── config-schema.md               # YAML schema documentation
│
├── scripts/
│   ├── install-tools.sh               # Docker build + container start
│   ├── browser-auth.py                # Headless Chromium auth (JS-rendered logins)
│   ├── pkce-auth.py                   # OAuth 2.0 PKCE flow automation
│   └── status.sh                      # Engagement status dashboard
│
└── engagements/                       # Runtime output (git-ignored)
    └── <engagement-id>/
        ├── logs.txt                   # Live engagement log (tail -f to watch)
        ├── findings.md                # Append-only findings log
        ├── progress.log               # Timestamped event log
        ├── resume-prompt.md           # Auto-resume prompt (paste into new session)
        ├── report.md                  # Final pentest report
        ├── cookies.txt                # Cross-domain cookie jar
        └── tool-output/               # Raw CLI tool outputs