AI-Infra-Guard：为什么智能体红队测试需要分层施策

这是什么？

2026 年 6 月 30 日，腾讯朱雀实验室的研究人员发布了一份技术报告，介绍了面向 AI 系统的开源红队测试平台 AI-Infra-Guard。其核心论点值得停下来细看：现代智能体的攻击面并非一个扁平的单一目标，而是由若干不同层次堆叠而成——底层基础设施、协议与工具集成、智能体运行时行为，以及模型本身——而没有任何单一检测范式能把这些层都覆盖好。该工作的贡献是防御性和方法论层面的：它为每一层匹配一种测试方法，而不是假装单个扫描器就能捕获一切。代码在 GitHub 的腾讯组织下公开，因此这是一款配有论文的已发布工具，而非描述私有能力的论文。

工作原理

该框架的设计直接源自其分层论点。对于基础设施层——问题具体且可枚举——它使用确定性规则匹配：报告称覆盖 75 个以上 AI 组件和 1400 条以上漏洞规则，这类基于签名的检查适合已知软件缺陷和错误配置。对于协议与工具层，它对 MCP 服务器和智能体技能（skill）包进行由 LLM 驱动的智能体式审计，因为这些工件是半结构化的，其风险（过宽权限、隐藏指令、危险的工具描述）是语义性的而非纯语法性的。对于智能体行为层，它进行多轮黑盒红队测试，像对手那样在一段对话中与智能体交互，而不是只检查单条回复。对于模型层，它内置一个越狱评测框架，据称覆盖 26 个以上攻击算子、横跨十六个数据集，从而以一系列已知技术来衡量对齐鲁棒性，而不是仅凭单个提示词。

真正重要的不是其中任何单个组件，而是把它们分开的理由。签名规则精确，却对新型语义滥用视而不见；基于 LLM 的审计能捕获语义问题，但具有非确定性，可能漏掉规则本可瞬间标记的已知缺陷；多轮探测能揭示静态扫描永远看不到的行为漂移。把这一切揉进单个工具，往往会继承其中主导范式的弱点。

为何重要

大多数为智能体部署做安全的团队，只会拿起一件工具——一个提示注入分类器、一个依赖扫描器，或一套越狱测试集——并默认把它当作全面覆盖。分层视角让盲区显现出来。一个隐藏在抗越狱护栏之后的加固模型，若其 MCP 服务器暴露了一个未认证的工具，照样会失守；一套锁死的基础设施，若安装的技能包夹带了智能体会服从的嵌入式指令，照样会泄露。把攻击面框定为四个失效机理各异的层，即便对永远不会运行这款具体软件的团队也是有用的规划工具；它与 OWASP 智能体安全工作和 MITRE ATLAS 的方向一致——两者同样把智能体风险分解，而非当作一个铁板一块的问题。这也反映出生态正在成熟：AI 红队测试正从零敲碎打的提示词摆弄，走向结构化、有工具支撑的体系化项目。

防御建议

实务上的要点是：按攻击面真实的形状来测试。用适配的方法覆盖每一层，而不要假设某一项控制能通用：对基础设施和已知组件缺陷做签名与依赖扫描；对你安装的每一个 MCP 服务器和技能包做语义审计，重点关注工具描述与所申请的权限范围；对组装后的智能体做多轮行为探测，而不只是单提示词检查；并针对你所交付的具体模型与系统提示词运行一套越狱／对齐测试集，随着新算子出现而更新。把某一层的”绿灯”结果只当作关于该层的证据。若采用本文这类开源框架，请审阅它测试了什么、没测试什么，保持其规则集更新，并将自动扫描与人工复核结合——自动化审计缩小了搜索空间，但并不能证明系统安全。最后，记录每条发现所属的层次，让修复落到正确的责任方，而不是被笼统归档为”AI 风险”。

状态

这是一款配有技术报告的已发布开源工具，而非漏洞披露；它不引入任何 CVE。值得追踪的价值在于这套分层方法论，以及你自己的测试是否覆盖了全部四层。

项目	详情
发布	arXiv 技术报告，2026 年 6 月 30 日
来源	腾讯朱雀实验室（腾讯安全平台部）
层次	基础设施、协议/工具、智能体行为、模型
覆盖	75+ AI 组件、1400+ 漏洞规则；26+ 越狱算子、16 个数据集
CVE	无（防御性红队框架）