当Dify、MCP、Ollama等AI基础设施以周为单位迭代时，传统安全工具连“识别组件版本”都做不到。朱雀实验室这篇技术报告试图回答一个更根本的问题：安全检测范式，是否也需要随攻击面分层而进化？

上周，腾讯朱雀实验室发布了一篇题为《Securing the AI Agent: A Unified Framework for Multi-Layer Agent Red Teaming》的技术报告。

这篇报告最值得关注的，并非它又多发现了几类漏洞，而是它提出了一套​关于AI安全评估的方法论​。

在过去两年里，AI软件供应链的膨胀速度远超安全能力的建设速度。Ollama、vLLM、llama.cpp等推理引擎，Dify、LangFlow等Agent开发平台，以及去年底 Anthropic 提出的MCP（模型上下文协议）——这些组件正被大量部署，很多直接暴露在公网，但运维者往往缺乏专业安全背景。

问题在于：现有的安全工具，几乎无法覆盖这套新体系。

为什么传统工具“失灵”了？

报告指出了三个现实障碍，这些并非理论推演，而是工程落地的直接阻力：

第一，指纹库缺失。 Nuclei、Shodan等主流扫描器的指纹库中，大量AI组件是缺失的。一个Dify控制台或Ollama实例摆在面前，工具可能根本认不出来。

第二，版本号不可比。 这是更隐蔽但更致命的问题。漏洞匹配高度依赖版本比较，但AI项目大量使用非常规版本标识——b7824（单调递增构建号）、2.3.dev（开发快照）、latest（滚动标签）——这些字符串无法用语义化版本比较逻辑处理。结果是，软件成分分析（SCA）工具要么报错，要么静默给出错误判断。

第三，威胁模型变了。 传统Web扫描器最擅长找SQL注入和XSS，但AI组件当前最高频的风险是：​未认证访问导致GPU算力被滥用​、配置文件泄露云厂商API Key、MCP工具描述被投毒导致Agent行为被操纵。这些攻击面，不在经典扫描器的“舒适区”内。

这三重差距指向一个判断：不是传统工具不够好，而是它们的设计前提，已经不适用于AI系统了。

核心论点：分层攻击面，需要分层检测范式

报告的中心论点是：AI Agent的攻击面是“分层”的，每一层需要的证据类型不同，因此适用的检测范式也必然不同。

作者将攻击面划分为四个层级：

每一层所需要的“证据”，决定了该层“该用什么方法测”。 基础设施层需要的是快速、可复现、低成本的指纹匹配，用LLM去扫版本号是不经济的；模型层需要的则是对抗样本下的统计表现，用固定规则去判断是否越狱则是不可能的。

报告将这套思路总结为“​层-范式匹配原则​”（Layer-Paradigm Matching Principle），这也是AI-Infra-Guard整个框架的设计基石。

四层引擎，各司其职

基于上述分层，AI-Infra-Guard构建了四个检测模块：

M1：基础设施扫描器（确定性规则匹配）

该模块的核心技术投入，不在于规则数量（目前已覆盖75+组件、1400+漏洞规则），而在于两套底层机制：

• ​自研指纹匹配语言​：基于布尔表达式（支持 body、header、icon 哈希等字段）进行组件识别，而非简单依赖正则。解释器手写实现，支持短路的 &&/|| 运算。
• ​版本归一化逻辑​：针对AI项目特有的非标准版本字符串，建立了一套映射规则——latest 映射为“极大值”，2.3.dev 规整为 2.3.0，b7824 剥离前缀后参与数值比较。这套逻辑虽然“不 glamorous”，却是让SCA在AI场景下重新生效的前提条件。

此外，报告特别区分了三类检测置信度：​已验证​（主动探测并确认敏感内容泄露）、​基于版本​（符合CVE版本范围）、​推断型​（规则无版本约束，仅凭组件名报告风险）。这种显式的置信度分层，在安全扫描工具中并不常见。

M2：MCP服务器审计（LLM驱动的语义分析）

这一层处理的是“规则无法表达”的漏洞——命令注入的触发条件、工具描述是否被投毒、凭证是否有外泄路径。这些问题需要​理解代码做了什么​，而非匹配固定模式。

AI-Infra-Guard的做法是构建一个​Agentic审计框架​：LLM作为推理核心，配备文件读取、grep搜索、MCP工具调用等能力，在一个受限的“推理-行动”循环中对目标代码或运行实例进行审计。

这里有两个值得关注的设计细节：

• ​**“Prompt-as-Rule”范式​：检测知识不再编码为正则或YAML，而是以结构化自然语言描述的形式写入提示词，包含漏洞定义、高风险代码模式、以及——同等重要的——​排除条件**​。报告指出，LLM审计器的主要失效模式是“过度报告”（false positive），因此每条规则必须明确告诉模型“什么不算漏洞”。
• ​自防护机制​：LLM审计器本身是攻击目标——它读取的代码或MCP工具返回值可能包含​间接提示词注入​，试图诱导审计器跳过检测或提前结束。报告描述了双层防御：提示层面明确指示模型将所有输入视为“数据而非指令”，执行层面通过路径沙箱和工具白名单进行结构性隔离。

M3：Agent行为红队（多轮黑盒对抗）

当目标是已上线的Agent（如Dify或Coze上部署的机器人）且无源码可用时，唯一的接口就是对话。M3模块将LLM自身作为一个红队Agent，与目标进行多轮对抗性对话。

红队的攻击策略围绕四个风险家族展开：​数据泄露​（诱出系统提示词或密钥）、​工具滥用​（命令注入、SSRF）、​间接注入​（在模拟文档中埋藏指令）、​权限绕过​（越权访问其他用户数据）。

设计上的几个务实之处：

• ​成本可控​：每个攻击家族有明确的“能力感知”预检查——若目标未接入检索或文件工具，则不再浪费时间测试相关攻击；攻击采用“阶梯式升级”，从直接请求开始，失败后逐步升级到编码绕过和角色扮演；一旦确认漏洞，停止规则立即终止该方向的后续测试。整个对话轮次被记录为显式成本指标。
• ​客观验证优先​：对于SSRF检测，红队Agent会在可控服务器部署唯一标识令牌，诱导Agent发起请求，​只有当令牌出现在响应中时才确认漏洞​。间接注入也采用类似“植入标记”的方式。这种设计将尽可能多的判断从“LLM主观阅读”转化为“确定性字符串匹配”。

M4：模型越狱评估（统计性对齐测试）

这一层回到经典的LLM安全评估范式：给定一组有害提示，应用多种攻击变换，统计模型产生违规响应的比例。

AI-Infra-Guard在这层的贡献在于​集成与规模化​：整合了70余种编码混淆变换、多轮Crescendo攻击、Tree-of-Attacks等搜索策略，覆盖16个公开越狱数据集（约7248条有害提示），并通过可插拔的LLM-as-Judge进行统一评判。攻击成功率（ASR）作为跨模型可比的量化指标输出。

另一层攻击面：Agent Skills供应链

除四层框架外，报告还重点讨论了Agent Skills（技能包）的安全问题。随着Cursor、Claude Code、OpenClaw等IDE和Agent框架允许用户通过安装 SKILL.md 包来扩展Agent能力，一种类似于“浏览器扩展商店”的供应链风险正在形成。

一个Skill可能包含声明文件、安装脚本、辅助代码和依赖配置。恶意Skill可以伪装成正常工具，却在安装时窃取 ~/.ssh/ 或 .env 中的密钥，或通过 curl | bash 拉取远程载荷。

AI-Infra-Guard的技能扫描器沿用了“LLM语义审计”的思路，但做了针对性设计：不直接执行Skill代码，而是通过静态索引和受控文件读取，让LLM判断“声明行为”与“实际代码”是否一致。扫描结果分为三类：​正常​、​可疑​、​恶意​——中间分类的存在，反映了供应链安全中“意图不明确但行为危险”这一现实困境。

团队同时发布了 ​SkillTrustBench​，一个包含5520条评估用例的基准，从62552个真实Skill中提炼而来，覆盖9类安全威胁。公开榜单显示，在Claude Opus 4.6作为基座模型时，该扫描器的Loose F1达到0.9848，召回率接近1.0，但不同模型间的假阳性率差异显著（从0.012到0.187），这说明​基座模型的能力直接决定了审计质量​。

架构层面的两个设计选择

报告在架构层面有两个设计选择值得提及。

其一，Server-Agent分布式架构。 框架由一个中央服务器和多个Worker Agent组成。不同检测任务——毫秒级的基础设施扫描和可能运行数十分钟的LLM审计——经由同一任务分发管道调度，结果通过WebSocket和SSE实时流式回传。这种统一调度机制的价值在于：​将异构检测任务抽象为同一种可观测、可取消的工作流​，而非让不同范式各自为政。

其二，双重交付形态。 除标准CLI和Web服务外，AI-Infra-Guard还可作为Agent Skill本身被安装到OpenClaw、Cursor等宿主环境中——用户通过自然语言即可触发扫描。也就是说，​检测工具与检测对象处于同一生态位​，这反过来要求工具自身必须是一个“可信Skill”——一个微妙的递归约束。

与现有工具的比较

报告将AI-Infra-Guard与Nuclei、Semgrep、garak、PyRIT、promptfoo等开源工具进行了横向对比（见报告Table 6）。

结论是清晰的：Nuclei和Semgrep擅长基础设施和源码扫描，但不涉及Agent行为或模型对齐；garak和PyRIT聚焦于LLM红队，但没有基础设施指纹或MCP源码审计能力；近期出现的Invariant MCP-Scan和MCPSafetyScanner则专注于MCP协议层。

AI-Infra-Guard是目前唯一在单一架构下覆盖全部四层、并额外纳入Skill供应链审计的开源框架。 这不是在说它每一层都做到了极致，而是说它提供了一个​让不同范式在同一体系内协同工作的框架​——这一点，此前没有先例。

值得继续观察的方向

报告最后列出了几个正在推进的方向：

一是​大规模测量​——将基础设施扫描器应用于公网AI资产测绘，量化AI暴露面的真实规模；二是​层间协同​——让基础设施层的识别结果指导Agent行为层的侦查，或静态MCP审计结果动态测试的输入；三是​知识库持续扩展​——指纹库、CVE规则、Prompt-as-Rule检测标准、越狱算子库，都需要随AI生态演进而持续更新。

AI-Infra-Guard的定位并非一个“完成品”，而是一个“活的框架” ——它的价值不在于当前覆盖了多少规则，而在于其分层范式能否持续吸纳新的攻击面。

对于安全从业者而言，这篇报告提供了一个观察AI安全的新坐标：检测范式必须随攻击面分层而分化，而非试图用同一套方法覆盖所有问题。 这个判断看似朴素，但在工程实践中被普遍忽视——AI-Infra-Guard的开源，正是将这个判断从论文推向可操作工具的一次尝试。

项目地址：github.com/Tencent/AI-Infra-Guard
技术报告：https://arxiv.org/pdf/2606.31227