pentest-ai

它不做标记。它做证明。

网站 · 安装 · 为何需要验证 · 基准测试 · 局限 · Discord

⚠️ 攻击性工具，仅限授权测试。 安装即表示你接受 AUP 和 条款。参见 负责任使用 ↓

两分钟，无需 API 密钥，无需自备目标

pip install ptai && ptai demo

ptai demo 会扫描一个内置的漏洞应用，并输出 4 findings, 3 oracle-VERIFIED。 它会从一份证明胶囊（proof capsule）中实时重放其中一条（replay 3/3），然后对 相同的路由在加固后再次运行，并输出 0 findings。

有两点值得注意。这些发现随漏洞的出现而出现、随漏洞的消失而消失，而不是因为工具 变得安静了——两次运行之间唯一改变的就是修复。而且四条中有一条始终是候选 （candidate）：SQLi 登录绕过是真实的，但没有任何 oracle 能在该路由上重新证明 它，因此它不会获得徽章。这个缺口正是产品在正常运作，而不是演示中的 bug。

这里的 VERIFIED 究竟意味着什么

大多数扫描器告诉你某个东西可能可被利用，然后把分诊工作留给你。 ptai 将一条发现视为候选（candidate），直到某个具名的机器 oracle 重新运行 该漏洞利用，并在 N 次中复现 N 次。只有到那时，它才赢得 VERIFIED。

有三个特性使这不只是一句口号：

没有任何 LLM 会产生裁决。 这条规则由代码强制执行，而非政策：一个无法指明 为其赢得裁决的 oracle 的裁决会被拒绝。LLM 负责协调运行并对结果进行推理。它 从不决定某个 bug 是否真实。

每个 oracle 都有一个必须失败的对照。 一个受信任标头绕过必须在带标头时返回 特权内容，而在不带标头时返回拒绝。一个泄露凭据检查必须对真实密钥被接受，而对 一个故意损坏的孪生体被拒绝。一个对任何请求都返回 200 的端点什么也赢不到。这正是 阻止"它返回了 200"被误认为证据的原因。

第三方扫描器的输出会被扣留。 nuclei、nikto 和 zap 的结果不会凭自身权威成为 发现。它们保持未验证状态，直到 ptai 自己的某个 oracle 独立地重新证明它们。

每条 VERIFIED 发现都以一份**可移植的证明胶囊（portable proof capsule）**形式 交付——包含该发现、重新证明它的配方，以及回执。任何人都可以 ptai replay 它 针对实时目标，并观看 oracle 重新确认，而无需信任 ptai。胶囊被故意设计为不 签名：重放才是信任机制，而不是一个你必须凭信念接受的签名。

诚实的数字

在一个故意设置漏洞的蜜罐上，23 条发现在这 14 个类别中验证通过，精确率 100%， 零误报。在一个原版 OWASP Juice Shop 上，2026-08-23 的扫描中验证了 17 条发现 ——报告的是范围内的 HTTP / 已验证 / 精确率，而不是 17/116。一次 2026-08-25 的 Path 1 MCP 会话（MCP 客户端驱动 run_probe，目标在编排器验证前就挂了）在 64 个 范围内的 HTTP 挑战中赢得了 12 个已验证证明，精确率 100%（20 个不予追查）。OSINT、 Web3 和仅 UI 的 Juice Shop 密钥按设计不在自动化计分板上。

请仔细阅读这些数字，因为缺口正是重点。 存在 64 个探针，但只有 30 个能赢得 裁决；其余 34 个报告诚实的候选。注册了 203 个包装器，但只有 18 个能将工具输出 转化为发现——其余的只是运行并交回原始文本。oracle 门控换来的是精确率，而不是 捕获率：它消除误报，但不会发现更多 bug。

蜜罐测试装置（tests/honeypot/）和一个干净应用零误报门控 （tests/cleanapp/）都随本仓库交付并在 CI 中运行，因此这些 是可复现的，而非截图。

它不做什么

直白陈述，因为一个过度吹嘘自己的安全工具比无用更糟。

• 它是一个 Web 应用扫描器。 全部 64 个探针和全部 24 种 oracle 都针对 HTTP。 AD、云、移动和无线有代理和工具包装器，但其背后没有探针库，也没有 oracle。
• 它无法进行本地权限提升。 那需要在你已经拥有的主机上执行代码。ptai 远程 测试，没有这样的通道，因此 privesc 代理报告 unsupported，而不是一个误导性 的零。
• 它不是 CVE 扫描器。 没有版本到 CVE 的数据库，也没有漏洞利用库。CVE 工作 仅限于对泄露清单进行 osv.dev 查询。
• Playbook 只做规划，不执行。 ptai playbook run 解析依赖并打印计划。针对 目标运行它尚未接通。
• 它不是自主的。 完全自主的 LLM 渗透测试代理端到端完成 21–31% 的任务；人工 辅助的设置达到 64%。ptai 是为第二种模式构建的。按两次 Ctrl+C 可在运行中途 接管。

完整的内部缺陷清单，包括上述所有内容，都是公开跟踪的，而非悄悄处理。如果这里 有什么是错的，开一个 issue，它 会被纠正。

安装

pip install ptai
ptai mcp install          # 自动检测你的 MCP 客户端并写入其配置

pip install ptai
export ANTHROPIC_API_KEY=sk-...        # 或 OPENAI_API_KEY
ptai start https://target.example.com

# 完全本地，无云：
export PENTEST_AI_LLM_PROVIDER=ollama

# 或确定性，完全不用 LLM：
ptai start https://target.example.com --no-llm

ptai tools install --tier core     # 或 recommended / full
ptai tools install nmap nuclei     # 或按名称
ptai serve                         # 用于仪表板的 HTTP REST + WebSocket
ptai menu                          # 交互式启动器，无 LLM

基准测试

可复现，在 git 中，带原始产物。没有你无法审计的"98.7% 检测率"。

n=1，单一评分者，单次运行，针对 OWASP Juice Shop。方法与原始输出见 benchmarks/；完整报告见 docs/benchmarks/juice-shop.md。

诚实的解读： ptai 在具有精选探针覆盖的 SPA Web 目标上表现强劲。 HexStrike 覆盖面更广（云、二进制、CTF），在像 WordPress 这样的传统可爬取表面上 很可能胜过 ptai。Juice Shop 也是互联网上文档最详尽的漏洞应用，因此 LLM 和探针 作者都有先发优势——这正是私有蜜罐数字更低的原因，也是两者都被公布的原因。

放入 CI

- run: pip install ptai
- run: ptai start ${{ vars.STAGING_URL }} --ci --fail-on verified --sarif pentest.sarif
- uses: github/codeql-action/upload-sarif@v3
  with: { sarif_file: pentest.sarif }

--fail-on verified 仅在 oracle 实际证明的发现上中断构建，因此该门控不会被 扫描器噪声触发。SARIF 上传到 GitHub Code Scanning，发现会作为 PR 评论发布。 GitLab 和 Jenkins 模板见 docs/ci-cd.md。

工作原理

recon ──▶ auth ──▶ web ──┬──▶ ad
                         ├──▶ cloud          ┌──────────────────┐
                         └──▶ api ──────────▶│  findings DB     │
                                             │  scope-guarded   │
                                             └────────┬─────────┘
                                                      ▼
                                          verify (oracles, N/N)
                                                      ▼
                                   chain ─▶ validate ─▶ detect ─▶ report
                                          md · html · pdf · SARIF · JUnit

18 个专家代理运行这些阶段。有 API 密钥时，每个代理使用 LLM 对结果进行推理； 没有时，它作为确定性工具循环运行。无论哪种方式，阶段顺序和检测都是相同的 ——探针发现 bug，LLM 只负责协调。

适用对象

AppSec 团队，将经过身份验证的扫描接入每个 PR，并设置仅在已证明的发现上触发 的门控。顾问，希望报告自己写出来，并提供一个客户自己的工程师可以重放的 胶囊。漏洞赏金猎人，宁愿分诊 12 条已证明的发现，而不是 600 条可能。Claude Code / Cursor / Codex 用户，希望在其助手背后有真正的工具，而不产生另一笔 API 账单。

与我合作

该工具是 MIT 且永久免费——这一点不会改变。

如果你希望交付一次渗透测试，而不是自己运行，或者想要一个带历史和团队访问权限 的托管工作区，两者都在 pentestai.xyz。 交付的交战中的每条发现都附带一份证明胶囊，你的工程师可以自己重放，这与一份 满是严重性评级的 PDF 是本质不同的产物。

问题咨询：[email protected]

负责任使用

ptai 对你指定的目标执行真实的网络和主机操作。 你对你拥有每个目标的明确书面授权负全部责任。 测试你不拥有的系统可能违反 《计算机欺诈和滥用法》、1990 年《计算机滥用法》、GDPR 第 32 条以及其他地方的 等效法律。

首次运行会提示接受 AUP 并持久化它。在 CI 中设置 PENTEST_AI_AUP_ACCEPTED=1。范围外的主机在工具调用时会被拒绝。三个护栏默认 关闭，值得开启：intensity=safe 跳过改变状态的探针，respect_rate_limits 遵守 429/Retry-After，strict_scope 拒绝主机外请求。

ptai start http://target --oast-server https://oast.example.com --oast-token <T>
ptai start http://target --no-oast          # 或完全禁用

常见问题

我需要 API 密钥吗？ 在 MCP 路径上不需要——你的 Claude Code / Cursor / Codex 订阅就是 LLM。只有独立 CLI 需要一个，而且即便在那里 Ollama 也能完全本地运行。

它是自主的吗？ 不是，它也不声称是。探针检测，LLM 协调，你决定。按两次 Ctrl+C 可在运行中途接管。

对生产环境安全吗？ 只有在获得书面授权并开启上述三个护栏的情况下。

它会回传数据吗？ 默认不会。发现留在你的磁盘上。你可以通过 ptai telemetry enable 选择加入匿名使用计数器（无目标、无发现；schema 在 engine/telemetry.py 中）。OAST 回调默认使用 ProjectDiscovery 的 oast.fun， 除非你传入 --oast-server 或 --no-oast。

这与让 Claude 去黑某个东西有何不同？ 一个精选的确定性探针库发现 bug，一个 机器 oracle 证明它们。仅靠 LLM 只能给你一个看似合理的猜测，却无法判断它是否 真实。

生态系统

社区： Discord · Discussions · Issues

Star 历史

旧的内联图表（api.star-history.com）是空的：GitHub 限制了那些 SVG 所依赖的 公共 stargazers API。实时序列在 star-history.com 上。README 不会热链接一个替代主机——否则每个访问者的浏览器都会去获取那个 SVG。

许可证

MIT。随你怎么用。