AI Safety + Red Team — 攻防一体的安全工具栈

这个 pack 包含什么

这是给 AI 安全工程师上线前一周搭的栈 — 跟玩家拿单个 chatbot 玩两下完全不一样。这里的受众负责的是一个反复跑的上线前审计：一个有工具、有客户数据、对某个系统有写权限的 agent，加上一个想赶紧 ship 的 CEO。任务是别让上线变成事故。

十件套干净地分三层，顺序很重要：

1. 攻击层（红队） — fuzz、jailbreak 生成、对你的 prompt 配置、agent spec、线上 endpoint 跑的脚本化对抗 prompt。目的是在可控环境里把 bug 翻出来。
2. 防御层（护栏） — 输入/输出校验器、prompt-injection 检测器、PII 脱敏、策略执行器，挂在运行时请求路径上。目的是当红队发现没修完时仍然 fail-closed。
3. 监控 + 基础设施审计层 — 静态检查 agent 的配置（哪些工具、哪些 scope、哪些 MCP server），以及扫描周边基础设施。目的是抓住运行时看不到的 over-privilege bug。

三条贯穿 kit 的主张：

• 覆盖度 > 单点新意。每次 commit 跑 210 个已知攻击模式的扫描器，赢一个你这辈子不会重跑的巧妙 jailbreak。
• 运行时护栏是兜底，不是计划。如果你的策略是「让 LLM 判断自己的输出」 — 你已经输了。静态扫描 + 红队 + 护栏 才是 layered defense。
• Agent 越权是大家最容易忘的 bug。大多数 prompt-injection 文章只写到「机器人说了脏话」就停。真正有意思的攻击落在「机器人替攻击者的地址调了 200 次退款工具」。审 工具，不要只审 prompt。

推荐安装顺序（静态扫描 → fuzz / 红队 → 运行时护栏 → 基础设施审计）

1. agent-audit — Security Linter for LLM Agents (3790) — 从这里开始，在你写第一条攻击 prompt 之前。一个静态扫描器，53 条规则来自 OWASP Agentic Top 10，外加 prompt-injection 启发式和 MCP 配置审计。在任何模型调用之前对你的 agent_spec.yaml、工具定义、MCP server 跑。最便宜的 bug 是 linter 抓到的那种。
2. AI-Infra-Guard — Scan MCP Servers and AI Stacks (3232) — 基础设施侧的伴侣。Web UI + 扫描器走遍你的 MCP server、agent skill、AI 基础设施组件，找 CVE、jailbreak 暴露面、已知 bad config。能抓住「上周有人在团队的 claude_desktop_config.json 里装了个奇怪 MCP server」这种事。
3. Promptfoo — LLM Eval & Red-Team Testing Framework (618) — 参数化红队的主力。promptfoo redteam init && promptfoo redteam run 生成并执行 jailbreak、prompt-injection 探测、PII 抽取、策略违规用例，能跑任意模型。对 CI 友好（promptfoo eval --no-cache 放进 GitHub Actions）。5,000+ 星，是这个品类社区最大的。
4. Spikee — Prompt Injection Eval Kit (CLI) (3722) — Promptfoo 的聚焦、外科手术式补充。ReversecLabs 出的模块化 CLI，专做 prompt-injection / jailbreak 评测：spikee generate 建攻击语料、spikee test 跑。当你需要某个特定攻击家族（间接注入、角色混淆、系统 prompt 抽取）而不是通用 sweep，就用它。
5. Augustus — LLM Vulnerability Scanner (Go CLI) (3855) — 宽频段扫描器。210+ 对抗攻击模式 × 28 个 provider，Go 写的单个静态二进制、CI 跑得飞快。Promptfoo + Spikee 跑完之后再跑它，捕捉精准跑漏的东西。覆盖广度是它的护城河。
6. Agentic Security — LLM/MCP Red-Team Scanner (3230) — agentic 系统专门户。对 LLM 应用和 MCP server 投递攻击 prompt，自己也带一个 MCP server 入口 — 你能从 Claude/Cursor session 里驱动这个扫描器。当你的目标是带工具的 agent 而不是单 chat completion 时选它。
7. NeMo Guardrails — Programmable Safety for LLM Applications (4258) — 开源 guardrails 框架里最成熟的，NVIDIA 出的。Colang 规则覆盖输入审核、输出校验、幻觉检查、话题边界、工具调用 gating。防御层的锚定选择。要装一个 runtime guardrail，装这个。
8. llm-guard — Secure LLM Inputs & Outputs (3103) — 轻量的「先把这个请求过一遍」扫描管线。几行 Python 完成 prompt-injection 检测、PII 脱敏、毒性、secrets 泄漏、输出校验。上限比 NeMo Guardrails 低，但把它挡在现有 endpoint 前面当第一道防御层更便宜。
9. Defender — Prompt Injection Guardrails for Agents (3695) — 间接 prompt-injection 的针对性防御器。打包了一个 ~22MB ONNX 分类器，专做工具输出注入（攻击者把 agent 要读的网页投毒，agent 跟着 instruction 走）。NeMo 和 llm-guard 通用覆盖的 bug 类，Defender 专攻。
10. ZenGuard — Runtime Guardrails for AI Agents (3908) — 实时信任层，带分级访问控制。请求边缘做 prompt-injection / PII / secrets 检测，加一个谁能用什么 scope 调什么工具的策略层。当你的防御故事必须包含授权（有些用户能问、有些用户能动手）时有用。

它们怎么协同

  上线前（红队）                  在线请求路径（护栏）                后台（监控）

  agent-audit ──┐                                                       AI-Infra-Guard ───┐
      (3790)    │                                                            (3232)        │
                ▼                                                                          │
        agent_spec.yaml  ──►  Promptfoo (618) ─┐                                           │
                                Spikee (3722) ─┼──► 攻击语料 ─► 修 ─► 重跑                │
                              Augustus (3855) ─┤                                           │
                       Agentic Security (3230) ┘                                           │
                                                                                           │
                                                                                           ▼
                                                          用户 ─► [ NeMo Guardrails (4258) ─┐
                                                                   llm-guard (3103) ────────┤── 拒/脱敏/记日志
                                                                   Defender (3695) ─────────┤
                                                                   ZenGuard (3908) ─────────┘
                                                                            ▼
                                                                        Agent + 工具
                                                                            ▼
                                                                          Response

从左到右：先静态能抓的尽量抓，再在用户之前自己攻自己，再假设两层都会漏，把护栏塞进请求路径。右上到右下：监控 agent 跑在上面的基础设施，因为最容易被漏掉的 bug 类不在 prompt 里 — 在 prompt 调到的那个工具里。

你会遇到的取舍

• 覆盖度 vs 误报率。宽扫描器（Augustus、Promptfoo redteam）覆盖几百条攻击模式，会报一堆在你这个具体部署下不可利用的 finding。窄工具（Spikee、Defender）漏得少但覆盖也少。成熟姿态是两个一起跑、做 triage — 不是二选一。
• 运行时护栏吃延迟。NeMo Guardrails 挂多条 Colang rail + llm-guard + Defender 每个请求都跑，是真的 wall-clock 时间。前后 profile 一下 p95。常见模式：便宜检测器（llm-guard 的 regex/分类器）每次都跑，贵的（NeMo 的 LLM-rail 评估）只在被 flag 或高风险 endpoint 上跑。
• 托管 vendor（Lakera、Protect AI）vs 开源栈。托管服务上手快、自带训过的模型。本栈赢在数据主权、不按请求收费、规则可扩展。很多团队两个一起跑：vendor 处理显然的 80%、团队专注定制的 20%。
• 一次性上线前 vs 持续测试。上线前红队是必要但永远不够 — 你 ship 一个新工具、一行新 system prompt、升一次模型，攻击面立刻漂移。把 Promptfoo（或 Augustus）接进 CI、每个 PR 重跑语料。你最后悔的 bug 是审完之后偷偷溜进来的那种。

常见踩坑

• 只测 prompt injection，不测工具滥用。每篇博文都在写 jailbreak 字符串。真正贵的 bug 是 agent 调了它不该有访问权的写工具，或调了 10,000 次读工具把数据吸走。agent-audit 和 AI-Infra-Guard 存在的全部理由就是 prompt 扫描器看不到工具目录。
• 只在上线那天跑一次。模型升级、新加 MCP server、system prompt 多了一行 — 全部悄无声息改攻击面。如果你的红队不在 CI 里，它只是某人最后一次跑那天的风险快照。
• 把护栏当策略。「validator 会拦住」 = 安全版的「测试会覆盖」。护栏是最后一道、不是唯一一道。静态扫描 + 红队 + 护栏 才是 layered defense。
• 让 LLM 自己评判攻击结果。LLM-as-judge 在红队结果上有已知偏见 — 偏向说「安全」。每条 llm-rubric assertion 都要配一个确定性检查（substring、regex、schema 校验），不一致的当 finding 去 triage。
• 忘了间接 prompt injection。大多数团队测直接注入（用户发敌意 prompt）。间接注入 — agent 读了一个被投毒的网页/文档/工具输出，按里面藏的指令动手 — 是 Defender (3695) 专攻的。这个 bug 类最容易悄悄上线。
• 工具 scope 没白名单。「agent 对收件箱有读权限」是个上线决定；「agent 对日历有写权限」是该需要人签字的句子。ZenGuard 的分级访问 + agent-audit 的 MCP 配置检查就在这里把签字流程兜住。