Mantishack（Mantis AI）
基于 OpenAI Codex CLI 改造的自主漏洞发现代理，用「先宽检测、后严验证」的流水线，把误报过滤成可证明可达的真实漏洞。
README声明了双重门控的利用开关（默认关闭）、canary注入诱饵工具、findings服务在代码层面强制'无证明不确认'，并要求先确立授权范围；但实际MCP服务器代码、agent TOML与系统提示词未在本次证据中出现，最小权限与确认机制仅是文档断言，故各扣1分。敏感数据处理仅有'有界、脱敏的证据包'一句，未展示脱敏实现，得1分。依赖固定较严格（package. resolutions/overrides），外部工具缺失时降级为available:false而非伪造结果。回滚路径完全没有提及——fixer会修改代码但无恢复/撤销说明，扣至1分。归属处理出色：上游Codex、已退役的RAPTOR历史、双版权与NOTICE齐全。
架构自洽：README与MANTIS.md声明的分层（tool=code/agent=prompt/skill=knowledge）内部一致；扫描器缺失时明确报告而非编造发现，这是可信的失败语义。但findings服务的拒绝/roadblock实现代码未见，只能按文档采信，未给满分。SECURITY.md是上游OpenAI/Codex原文，未针对本项目改写，对本仓的故障处理无增量信息。
明确目标受众（授权的攻击性AppSec从业者）与场景（自有或授权目标），并给出授权不明时降级为只读静态分析的规则，边界意识较好。但触发精度无从评估：agent/skill触发条件与slash命令的实际定义文件未提供，仅得1分。多平台依赖（pip/brew/go/CodeQL CLI）对环境有一定要求，但'报告直至安装'模式缓解了这一点。
信息架构清晰（仓库结构图、What's wired表格、流水线生命周期图）；安装说明具体可执行（构建命令+各扫描器安装）；对已知缺口的坦率说明（'not polished software'、roadmap）是亮点；双许可文件加NOTICE与CITATION.cff完备，且明确警示CodeQL不可商用。扣分项：无版本号、无CHANGELOG，版本管理为零分；无示例输出、无FAQ；维护责任仅有issue链接，发布者身份未经验证，得1分。
产出形态明确（工具拥有的findings、带引用roadblock的拒绝、HTTP证据包与稳定哈希），比纯文字报告可审计。'检测是商品，验证精度是产品'的定位有一定边际价值，且零依赖组件（findings/canary/http-audit）开箱可用。但所有有效性声明均无执行证据或基准数据支撑，成本（需构建Rust+安装8+个外部工具+LLM API）与收益对比未量化，均不给满分。
声明可追溯到具体文件路径（.codex/mcp-servers/、codex-rs/等），事实与愿景（'The core bet'）区分清楚。但本次提供的源文件集未能交叉证实关键声明——核心能力层代码均未出现，交叉印证只得1分；同时评分整体维持低置信度，未将文档声明当作已验证事实。
- 所有安全机制（利用门控、canary、findings强制转换）均为文档声明，未见实现代码；使用前应自行审计 .codex/mcp-servers/ 与 agent 提示词。
- fixer组件会修改目标代码且未提供任何回滚/恢复机制，生产环境使用前务必在版本控制下运行。
- 证据包的'脱敏'仅为一句断言，捕获的HTTP交换可能含凭据或令牌，需自行核验脱敏逻辑。
- CodeQL CLI不允许商用，商业用途前核查所有被调用组件的许可。
- 发布者身份未经验证；敏感数据（API密钥、目标系统信息）会流经模型提供商，评估数据外流风险。
- 本仓库无版本号与变更日志，升级无法追踪变更内容。
这个 Agent 能做什么，适合哪些场景？
Mantishack 是将 OpenAI Codex CLI（Rust，Apache-2.0）整体改造为 Mantis AI 的攻击性 AppSec 框架，主打自主漏洞发现。它的核心是 MCP 工具层（.codex/mcp-servers/，含 semgrep、CodeQL、osv-scanner、trufflehog、bandit、trivy、ast-grep、z3 包装器）加上 findings 服务，所有发现由工具状态机管理：candidate → confirmed/rejected → exploited → fixed → verified。验证阶段要求以攻击者模拟和可达性证据（如 z3 的 smt_check_reachability）确认候选漏洞，无法附证据的候选会被拒绝并须引用具体路障。检测能力遵循「报告直至安装」原则：缺少底层扫描器二进制时如实降级为 available: false，绝不伪造结果。项目自称是有真实缺口的可用框架，非成品软件，且明确要求仅在授权范围内使用，攻击利用默认双重门控关闭。
构建 codex-rs 中的 Codex CLI 后，代理运行一个多阶段流水线：recon、context-enrich、detector、reachability、validator、chain-builder、exploiter（门控）、fixer、reporter 等角色代理（.codex/agents/*.toml）。读取目标代码库，调用 MCP 能力服务器执行 SAST/SCA/密钥扫描（semgrep_scan、codeql_analyze、osv_scan、trufflehog_scan、bandit_scan、trivy_scan）、结构化搜索（ast_grep_scan）、可达性证明（smt_check_reachability，基于 z3 的 SMT-LIB2 路径条件求解，返回 sat/unsat/unknown）。所有发现通过 findings 服务的 finding_create/update/get/list 管理，强制「无证据不得确认、拒绝必须引用路障」；http-audit 服务器将捕获的 HTTP 交互转为带请求引用哈希的脱敏证据包；canary 服务器部署诱饵工具检测提示注入。输出为经修复与验证的漏洞报告；技能层（.codex/skills/*/SKILL.md）提供 mantis-pipeline 等操作手册。
- AppSec 工程师对自己拥有或获书面授权的目标代码库做高召回漏洞检测，再用攻击者模拟自动剔除误报
- 安全团队需要每个确认漏洞都附带可达性证据（z3 求解结果或 HTTP 证据包），而非扫描器原始输出
- 渗透测试人员在授权范围内做静态侦察与漏洞链构建，利用阶段保持默认关闭直至明确授权
- 研究员在多模型环境下复用 Codex CLI 的供应商无关路由，切换底层模型而不改框架
- 工具开发者按现成的 MCP server 模式扩展能力（如 DAST、OOB、fuzzing），沿用 findings 生命周期与 canary 防注入机制
这个 Agent 有哪些优点和局限？
- 验证精度优先：findings 服务在代码层面强制「无证据不得确认」，拒绝必须引用具体路障（认证门、sanitizer、不可达路径），显著降低扫描器误报噪音
- z3 SMT 可达性集成：smt_check_reachability 用可证明的 sat/unsat/unknown 结论驱动检测到验证的流转，而非 LLM 自由裁量
- 反注入内建：canary 诱饵工具在提示注入或幻觉工具调用触发时告警
- 无二进制即如实降级：每个能力服务器在扫描器未安装时报告 available: false，不伪造发现
- 供应商无关模型路由：继承 Codex CLI 的多提供商配置，可换底层模型
- 重度依赖外部工具链：Rust 构建、Node.js、Python、z3 及多个扫描器二进制缺一即降级，完整能力需要逐个安装
- CodeQL 不允许商业使用，商用前需审查所有被调用组件的许可
- 项目自述「非成品软件」：README 与 MANTIS.md 列明有真实缺口，部分流程仍需外部二进制或运行中的目标
- 仅为 Codex CLI 框架的品牌化改造，上游更新与本项目维护之间的同步成本由使用者承担
- 自主攻击性安全代理的运行边界要求严格的授权管理，误用于未授权目标的合规风险在用户侧
如何安装或部署这个 Agent？
需要 Rust 工具链（版本见 codex-rs/rust-toolchain.toml）、Node.js（MCP 服务器为纯 Node.js）、Python，以及可选扫描器二进制。步骤：
bash
git clone https://github.com/deonmenezes/mantishack.git
cd mantishack/codex-rs
cargo build --release -p codex-clicd ..
# 安装能力目录的底层扫描器（缺了会如实降级，不伪造结果）
pip install semgrep bandit
brew install trufflehog trivy z3 ast-grep
go install github.com/google/osv-scanner/v2/cmd/osv-scanner@latest# CodeQL CLI 另行安装：https://github.com/github/codeql-cli-binaries
模型供应商、API key 与按模型设置按上游 Codex CLI 方式配置（见 codex-rs/config.md 与 codex-rs/model-provider/）。
如何使用这个 Agent？
在仓库根目录运行（以便解析项目级 .codex/config.toml）：
bash
./codex-rs/target/release/codexTUI 会播放 Mantis 吉祥物启动动画。代理按 .codex/skills/ 中的 mantis-pipeline 主手册执行流水线；先用目标文件确立范围与授权，授权不明确时仅限只读静态分析。可通过 spawn_agent 角色代理（recon、detector、validator 等）分阶段运行；确认漏洞后才可进入 chain/exploit/fix/verify 阶段，exploiter 默认双重门控关闭。
这个 Agent 与同类方案有什么区别？
与上游 OpenAI Codex CLI 相比，Mantishack 保留其全部框架能力（会话、沙箱、TUI、MCP 客户端），但叠加了漏洞发现专用的 MCP 能力层、角色代理目录、findings 生命周期和授权安全契约；它历史上也改造过基于 Claude Code 的 RAPTOR 框架，但该架构已退役，当前代码树不含 RAPTOR 代码。