AI-Infra-Guard：面向多层 Agent 红队测试的统一框架

  • 关联论文：2606.31227
  • 作者：flyP
  • 更新：2026-07-23

一句话结论

AI-Infra-Guard 是一个开源 AI 红队框架，提出"攻击面是分层的"这一核心观察，将 AI Agent 的攻击面分为基础设施层 / 协议与工具层 / Agent 行为层 / 模型层四层，每层匹配最合适的检测范式（确定性规则、LLM 智能体审计、多轮黑盒红队、越狱工具链），并号称是当前唯一同时覆盖 Agent Skills 供应链审计的开源框架——一句话，把"打 AI Agent"这件事从零散脚本升级为分层化、可复用的工程体系。

它要解决的真问题

开源 AI 基础设施的爆炸式增长（vLLM / SGLang / Ollama 等推理引擎、MCP 生态、Agent 框架、Hugging Face 模型仓库）远超安全工具的演化速度：

  • 现有安全工具多是单一层的：ModelScan 看权重后门、Garak 做模型越狱、MCP-Scan 看 MCP 服务器——彼此互不联动；
  • 没有工具系统化覆盖Agent Skills 的供应链——当 Agent 通过 MCP 加载第三方 skill 包时，谁来审计 skill 包？
  • 真实攻击是跨层的：基础设施漏洞（pickle 反序列化）+ 工具投毒（MCP 工具描述注入）+ Agent 行为操纵（间接 prompt injection）+ 模型越狱，攻击者会把它们组合起来。单一工具只看到一层，无法联动防御；
  • 学术红队论文给出方法但不沉淀为可复用工具；商业产品功能强但不开放源码——社区缺乏中间层。

AI-Infra-Guard 想补这个中间层：开源、可扩展、把"打 AI"工程化。

核心方法：四层 + 范式匹配

第一性观察

作者把 AI Agent 的攻击面分四层，每层有不同"自然"的检测范式：

┌─────────────────────────────────────┐
│  Layer 4: Model                     │  ← Jailbreak harness
├─────────────────────────────────────┤
│  Layer 3: Agent Behavior            │  ← Multi-turn black-box red teaming
├─────────────────────────────────────┤
│  Layer 2: Protocol / Tool (MCP)     │  ← LLM-driven agentic auditing
├─────────────────────────────────────┤
│  Layer 1: Infrastructure            │  ← Deterministic rule matching
└─────────────────────────────────────┘

Layer 1 — 基础设施层（确定性规则）

  • 对象：推理引擎（vLLM、TGI、Ollama）、模型权重文件（HuggingFace pickle）、容器镜像、Agent 运行时（LangChain、AutoGen）；
  • 方法：扫描 75+ AI 组件、1400+ 漏洞规则的确定性规则库；
  • 优势：零误报、可解释、CI/CD 友好。

Layer 2 — 协议与工具层（LLM 智能体审计）

  • 对象：MCP Server、Agent Skills 包（claude/skills、function calling schemas）；
  • 方法：用 LLM 作为审计 agent，主动探测 MCP 工具描述中的 prompt injection、skill 包元数据中的隐藏指令、可疑 tool 调用模式；
  • 优势：能处理自然语言层面的攻击，弥补纯规则盲区。

Layer 3 — Agent 行为层（多轮黑盒红队）

  • 对象：完整 Agent 系统的端到端行为（是否能被诱导越权执行、是否泄露上下文、是否能被诱导调用危险工具）；
  • 方法：构造多轮对话剧本，让红队 agent 与目标 agent 对抗，覆盖间接 prompt injection、工具误用、上下文累积攻击；
  • 优势：捕捉跨步骤累积的攻击，是单轮探测发现不了的。

Layer 4 — 模型层（越狱工具链）

  • 对象：底层 LLM 本身（GPT、Claude、Gemini、Llama）；
  • 方法：26+ 攻击算子 × 16 个标准越狱数据集，覆盖 prompt injection、jailbreak、角色扮演逃逸、多语言绕过等；
  • 优势：复用成熟的越狱基准，可对比模型版本间抗攻击能力变化。

Agent Skills 供应链审计（差异化卖点）

  • 当下 MCP 生态让 Agent 可以动态加载第三方 skill（类似 npm 包）——这引入了一条新型供应链：skill 包可能在 tool description、example、metadata 里藏 prompt injection、credential theft、隐蔽后门；
  • AI-Infra-Guard 用 LLM 审计 agent 扫描 skill 包的源码、元数据、示例调用，专门检查这一层；
  • 作者强调这是当前唯一覆盖此能力的开源框架——其他工具大多还停留在 MCP Server 扫描层面，没下沉到 skill 包。

关键实验与数据

  • abstract 给出规模数字：75+ AI 组件、1400+ 漏洞规则、26+ 攻击算子、16 个标准数据集；
  • 具体成功率、检出率数字未在 abstract 公开，原文未明确给出对照表；
  • 论文重点是框架/系统贡献而非基准数字，因此对比性实验可能在附录；
  • 给出了"layer-paradigm matching"作为实践原则，希望社区以此为基础共建。

亮点

  1. 分层抽象新颖——把混沌的 AI 安全场景切成 4 层，让每层用最合适的范式，避免"一种工具打天下"的尴尬；
  2. 覆盖 Agent Skills 供应链——这是当前最被忽视、增长最快的攻击面，作者抢占了先机；
  3. 完全开源——可以本地部署，避免把内部模型 / Agent 流量外发到商业扫描服务；
  4. 模块化扩展——新组件、新规则、新攻击算子即插即用，对社区友好。

局限

  1. 缺乏定量对标——abstract 没有给出"对比 Garak / ModelScan / MCP-Scan 提升 X%"的硬指标，框架贡献的"实际效果"待验证；
  2. 依赖 LLM 审计的可信度——Layer 2、3 都用 LLM 本身做审计，存在循环依赖（LLM 被审计又被用来审计），审计质量的天花板受限于审计 LLM 自身能力；
  3. 规则库维护成本——1400+ 规则意味着需要持续 CVE 跟进，对社区贡献者的负担不小；
  4. 不覆盖训练阶段——数据投毒、预训练后门这类模型权重生成期威胁不在框架范围内（虽然规则扫描能做部分权重层检测，但精度有限）；
  5. 跨层联动不深——虽然分了层，但 framework 是否真的能把跨层攻击链（比如 L1 CVE → L2 工具投毒 → L3 行为操纵）做端到端复现，abstract 未明示。

对工程落地的启发

  • 企业内部 AI 安全平台基线：把 AI-Infra-Guard 接进 CI/CD，对模型权重、MCP 配置、Agent prompt 做上线前扫描；
  • Agent Skills 市场审核：未来若运营 MCP skill 市场，此框架的 Layer 2 模块可直接复用；
  • 红队服务产品化：安全咨询公司可基于其分层结构搭建自家服务栈；
  • 红队 / 蓝队演习：四层模型本身就是天然的演练剧本结构。

与同方向工作的关系

  • Garak (NVIDIA)：聚焦模型层越狱，是 Layer 4 的同类，但缺其他层；
  • ModelScan / PickleScan：聚焦模型权重反序列化，AI-Infra-Guard 的 Layer 1 包含类似能力但范围更广；
  • MCP-Scan / Damn Vulnerable MCP：聚焦 MCP 协议，AI-Infra-Guard 的 Layer 2 类似，但延伸到 skill 包；
  • Promptfoo / PyRIT (Microsoft)：聚焦 prompt 注入与多轮攻击，对应 Layer 3、4 部分能力；
  • 学术红队论文（如 Adversarial Prompt 系列、MindGuard、TrojanZoo）：提供方法学，但工程化沉淀在 AI-Infra-Guard；
  • 兄弟工作——与同期 MCP 安全研究（如 MCPTox、PromptArmor）形成互补关系。

适合谁读

  • 企业 AI 安全 / DevSecOps 团队负责人，需要给 Agent 系统接入门禁；
  • 安全研究员做 MCP、Agent 供应链攻击面研究；
  • 创业公司想做 AI 红队 SaaS，需要基线框架参考；
  • 模型平台运营方（HF Model Hub、MCP 目录运营者）的风控负责人；
  • 想找"AI 安全领域工程化机会"的从业者——这是一个被低估、增速极快的方向。

工程落地与核查（Jay）

事实核查

核查项 结论 存疑等级
"唯一覆盖 Agent Skills 供应链审计的开源框架" ⚠️ 强独占声明；需 fetch GitHub 确认截至 2026-07 是否真的无其他开源工具覆盖 skill 包源码层；存在"定义边界"问题——若未来 3 个月内出现竞品，此声明即过期 中
75+ AI 组件、1400+ 漏洞规则 具体数字，可通过 fetch GitHub repo 的规则文件验证条目数 低
26+ 攻击算子、16 个标准数据集 同上，可通过 repo 结构验证 低
Layer 1 "零误报"声明 ⚠️ 确定性规则库说"零误报"——这在实践中几乎不可能（规则冲突/版本不匹配时必有假阳性），应是"极低误报"之误；引用时应注意 中
"与 Garak/ModelScan/MCP-Scan 不联动" 事实陈述，三者确实各自独立；竞争关系属实 低
vLLM/TGI/Ollama/LangChain/AutoGen 组件列举 均为真实开源项目，框架提及真实 低
LLM 审计 Layer 2/3 的循环依赖问题 属于方法学局限描述，原文自述，解读引用准确 低
Cross-layer 攻击链端到端复现能力 ⚠️ abstract 未给出端到端复现案例；框架分 4 层但未证明"层间联动"——解读中"是否真的能把跨层攻击链做端到端复现"是正确追问 中

核心存疑：独占声明需 fetch 核实；Layer 1 "零误报"措辞过于绝对；跨层联动能力未在 abstract 验证。

可读性精修

  • 全文结构完整（四层分层清晰，层次递进明确），适合安全方向读者快速定位感兴趣层。
  • 术语统一：layer、red teaming、agentic、skill package 等核心术语全文一致，使用准确。
  • 伪代码/架构图（文字版）描述清晰，可操作性强。
  • 无重大措辞问题；唯一轻微冗余：§关键实验与数据节重复了 abstract 已给过的数字，但影响可接受。

工程落地关键坑

1. 规则库维护是生产运营的最大成本 1400+ 漏洞规则需要持续更新（AI 基础设施迭代速度快，新 CVE 可能 1-2 周出现一次）。工程决策： - 框架是否提供自动化 CVE 订阅（如 NIST NVD API）来更新规则？若没有，则需要人工维护，成本不可忽视 - 规则优先级分层：P0（已有 PoC 的漏洞）vs P1（理论风险）应区分对待 - ⚠️ 规则库的"零误报"声明不现实，生产中必须设置规则级别的置信度标签

2. Layer 2/3 的 LLM 审计质量受限于审计用 LLM 用 LLM 审计 LLM 存在根本性限制：更强的被测 LLM 可能能识别出审计 LLM 的探测策略并有针对性地规避（adversarial evasion）。生产部署时： - 审计 LLM 至少应比被测 LLM 同等或更强（如用 GPT-4o 审计 GPT-4o-mini） - 建议对同一被测系统使用多个不同审计 LLM 交叉验证 - ⚠️ Layer 2 的 prompt injection 检测在对抗环境下（被测 Agent 知道是红队探测时）效果可能严重退化

3. Layer 3 多轮红队的剧本构造是人工瓶颈 Layer 3（Agent 行为层）需要人工构造多轮对抗剧本，覆盖： - 间接 prompt injection（通过第三方输入） - 工具误用（诱导调用危险工具） - 上下文累积攻击（跨多轮建立信任后发动攻击）

⚠️ 剧本质量直接决定覆盖率；若只有 5-10 个固定剧本，攻击者容易绕过。生产环境需要持续扩充剧本库，并引入自动化剧本生成（如用 LLM 自动生成对抗变体）。

4. Layer 1 的 pickle 扫描已有成熟替代 Layer 1 中针对 HuggingFace pickle 的扫描，PickleScan 已是成熟工具。AI-Infra-Guard 的 Layer 1 若只是"整合了 PickleScan 等现有工具"，则差异化有限；若包含自研规则则需独立评估精度。

5. 跨层联动需要额外编排层 框架分 4 层，但各层独立运行——真实的跨层攻击（如 L1 CVE → L2 工具投毒 → L3 行为操纵）需要人工编排层间触发逻辑。生产环境若需要真正的跨层联动： - 需要额外开发一个 orchestration layer 来连接 4 层输出 - 当前框架未提供此能力（属于框架自身局限）

6. Skill 包审计的"唯一覆盖"声明的时间窗口 MCP 生态在 2025-2026 年快速演化，"唯一"声明的时间窗口可能很短。工程选型时应： - 立即 fetch GitHub 确认当前（2026-07）是否仍无竞品 - 制定 6 个月后的复审计划，判断是否有新工具已覆盖此能力

工程落地核查清单

检查项 目标 常用工具
GitHub repo 规则数量核实 确认 1400+ / 75+ 数字 find . -name "*.rule" \| wc -l
CVE 自动订阅机制 规则库是否接入 NVD/NIST API 查看 cve_sync.py 或等价模块
零误报声明核实 是否有假阳性案例记录 试用 Layer 1 扫真实模型文件
Layer 2 LLM 审计对抗鲁棒性 在被测 LLM 知道是红队时测试检出率 对比"盲测"vs"已知红队"检出率差异
Layer 3 剧本库规模 覆盖至少 20+ 跨轮攻击模式 审计 playbooks/ 目录
跨层编排能力 是否有 L1→L2→L3 联动输出 查看 orchestration/ 模块（若有）
Skill 包审计竞品检查 6 个月前无竞品是否仍成立 GitHub search "skill package audit"

⚠️ 核心结论：AI-Infra-Guard 的工程价值在于"把四层攻击面统一到一个框架下"——对需要快速建立 AI 安全基线的团队有直接价值，尤其是 Layer 1（确定性规则，CI/CD 友好）和 Layer 2（skill 供应链审计，是当前 MCP 生态的真实盲点）。主要风险是：(1) "唯一覆盖"声明需要实时核实，(2) Layer 2/3 的 LLM 审计质量天花板明显，(3) 跨层联动是 roadmap 功能而非当前能力。企业部署应先从 Layer 1 + Layer 4 入手，Layer 2/3 作为增量。