Adversarial-Testing-Skill

一句话定位

用两个 AI 对打来测你的产品：一个读源码、一个被蒙在鼓里、只按结构化摘要和接口行为发起攻击，把任何 AI 编程助手临时变成一支安全红队。

做这个东西的人

Kieran Howard（GitHub: KieranHoward646），MIT 协议，单作者项目。README 自述 "Built with anger at insecure software, respect for real red teams, and a lot of Markdown"。

判断：单人做安全工具，作者画像像被现实咬过的开发者——README 里到处是实战过的痕迹，而不是安全咨询公司的 PPT。但单人维护与「battle-tested framework」的说法之间有张力。

它到底能做哪几件事

• 双 agent 盲测架构 → Developer AI 读源码产出结构化摘要，Adversarial AI 对源码零知识、只按摘要和接口行为攻击，模拟真实攻击者；四种调用模式（全流水线 / 先审摘要再放行 / 仅出摘要 / 仅执行测试）
• 四类攻击覆盖 → 通用软件 6 类 100+ 载荷（边界、注入、权限、并发、异常、业务逻辑）、LLM/AI 8 类 50+ 载荷（提示词注入、越狱、系统泄露、投毒、agent 攻击、多模态）、网络协议 30+、ML 模型 20+
• 企业级报告 → SARIF（一行 CI 接入 GitHub Security Tab）、JSON、Markdown、HTML，CVSS 式四维 0–10 严重度评分
• 自动修复 → 输出 unified diff 补丁
• 三层纵深防御 → Docker 沙箱（OS 级隔离、只读文件系统）→ 7 条硬编码审批规则（DROP/SYSTEM/PROD 直接 BLOCK）→ 自然语言约束兜底
• CI/CD 开箱即用 → GitHub Actions，PR 触发自动测试，结果作为 PR 评论，Critical 自动上传 SARIF
• 平台适配 → WorkBuddy 原生（一句 @ 命令）、Cursor 双会话、Claude Code 双终端、其余 AI 手动复制提示词

它在替代什么旧行为

以前测 AI 产品的安全性，两条路：一是给模型灌提示词让它自查，README 的原话是 "Traditional testing tools can't test what they can't parse"——连解析都做不到的东西没法测；二是人肉请渗透团队，按人天收费、贵且慢，而且渗透工程师的主业是 HTTP 接口，自然语言这个新攻击面恰恰不是他们的主场。

这套东西把「人肉红队」的流程——侦察、出载荷、打、写报告、出修复建议——压成两个 agent 的流水线，跑一轮的边际成本接近零。它替代的是「按人天计价的渗透测试」和「prompt 自查」，这两者一个是太贵，一个是太弱。

商业模式

未披露。 MIT 开源，没有托管服务，没有定价页，README 未提任何商业版本。

判断：README 想让这套报告格式成为事实标准——SARIF 进 Security Tab 是明显的「成为工具链输入」的意图。但现在没有任何人为它付钱的证据。

硬数字

• 41 star / 0 fork，8 次提交，2026-08-11 首次被发现
• 38 个文件：5 篇理论指南、10 个可执行模板、8 个攻击载荷库、4 个平台适配器、18 类攻击覆盖、7 条硬编码安全规则、15+ 真实案例
• README 声称「2025 年提示词注入给全球造成约 23 亿美元损失」——这是 README 的说法，未经本刊核实
• 团队规模、使用数据：未披露

四维评估

判断

设计是对的，体量是可疑的。「对抗方必须对源码盲测」这个机制是真东西，挑不出毛病；但一个 8 次提交、0 fork 的仓库自称 battle-tested framework，需要打个折。 安全工具的「battle-tested」需要别人替你打过才算数，自己说自己打过不算。

它不是 DSH 生态的东西——不依赖任何特定 harness，反而把 WorkBuddy、Cursor、Claude Code 都当宿主。所以它不是插件，是独立工具。独立的另一面是：没有生态给它背书，证明「真的有人用它」的证据目前为零。

它的命运取决于两件事：作者能否持续维护，以及有没有人真的跑起来并公开结果。

下一步看什么

① 三个月后 fork 数是否增长——安全工具被 fork 意味着真有人拿它跑，star 可以刷，fork 刷不了 ② 有没有非作者的人公开用它的报告格式（SARIF 进 GitHub Security Tab）的案例 ③ 用它的 workflow 跑一个真实项目，Critical 是否真的能自动上传——验证「CI/CD 开箱即用」是否兑现

可借鉴的做法

产品逻辑：「测试方必须盲测」可以搬到任何验证类产品上——验收方不知道答案，验证结果才可信。如果你在做 AI 产品的质量或安全验收，参考这个「知情者写摘要、不知情者执行」的双 agent 分工，它比单 agent 自查可信得多。

定价结构：无。未披露。

结论

有待观察。 机制有真东西，体量存疑。把它当「安全测试方法论」来读，不要当可依赖的工具来装。三个月后拿上面三条验证。