腾讯朱雀实验室打造AI安全"瑞士军刀"：当AI系统遭遇攻击，如何用一个框架全面防守？

这项由腾讯朱雀实验室主导的研究成果发表于2026年6月30日，论文编号为arXiv:2606.31227v1，归属于计算机安全（cs.CR）领域，感兴趣的读者可通过该编号查阅完整原文。

当AI系统越来越多地融入我们的工作和生活，一个棘手的问题也随之浮出水面：这些系统足够安全吗？会不会被人恶意利用？答案让人有些不安——现有的安全工具，根本赶不上AI系统扩张的速度。腾讯朱雀实验室的研究团队正是为了应对这一挑战，推出了一款名为AI-Infra-Guard的开源安全框架，并已在GitHub上公开发布（github.com/Tencent/AI-Infra-Guard）。

这个框架想要解决的，是一个"用锤子敲所有钉子"的老问题。在传统软件安全领域，人们往往用一套通用工具扫描所有系统。然而AI系统的结构远比普通软件复杂，从底层的服务器基础设施，到AI工具接入协议，再到AI助手的行为表现，最后到语言模型本身的"思维方式"——每一层都有截然不同的安全隐患，需要截然不同的检测手段。把同一把锁匙用在四种不同的门上，有些门根本就打不开。

AI-Infra-Guard的核心思路正是打破这种"一刀切"的做法，为每一层攻击面匹配最合适的检测方式。这在开源安全工具中尚属首次实现如此全面的层次覆盖，也是目前唯一同时覆盖AI基础设施、协议工具、智能体行为、语言模型本身，以及AI技能供应链这五个维度的开源框架。

---

一、为什么现有安全工具对AI系统束手无策

要理解这个研究的价值，先得知道现有工具为何失效。

过去两年里，一批全新的AI软件如雨后春笋般涌现。Ollama、vLLM、llama.cpp这类模型服务引擎可以让普通人在自己电脑上跑大语言模型；Dify、LangFlow、Flowise这类平台让人们像搭积木一样构建AI应用；ComfyUI用于AI图像生成；MLflow、Kubeflow、Ray负责管理和调度AI计算资源；还有最近兴起的MCP（Model Context Protocol，模型上下文协议）服务器，让AI助手能够读取文件、查询数据库、执行系统命令。这些软件大多由个人开发者或小团队部署，安全意识参差不齐，而且往往直接暴露在公开网络上。

问题在于，传统安全工具对这类新软件几乎视而不见。传统的漏洞扫描工具通过对比"已知软件特征库"来识别目标，但这个特征库根本没收录Ollama或者Dify——这些软件两年前还不存在。这就好比你有一本全球护照图鉴，但图鉴里没有新成立国家的护照，那你永远认不出来自那些国家的旅客。

版本号的混乱是另一个大麻烦。传统安全工具判断软件是否有漏洞，通常是看版本号是否落在"危险区间"内，例如"1.0到2.3版本有问题"。这需要版本号是规则的数字格式。然而AI软件偏偏不按套路出牌：llama.cpp用b7824这样的纯数字构建编号，有些项目用2.3.dev这样的开发快照版本，还有些干脆打上一个滚动更新的"latest"标签。传统比较器遇到这些就完全懵圈，要么报错，要么给出错误结论，产生大量漏报或误报。

更根本的问题是威胁模型变了。传统网络安全关注SQL注入、跨站脚本这类"经典"攻击。但AI系统最危险的漏洞往往是：未经认证就能访问昂贵的GPU算力，配置文件意外泄露API密钥，提示词注入劫持AI的行为目标，以及在对抗性提问下让AI模型"破防"、说出不该说的话。传统工具针对前者调优，对后者完全无感。

---

二、安全问题不在一层，得分层来看

为了说清楚AI-Infra-Guard的设计思路，研究团队提出了一个"分层攻击面"的概念，可以用一座四层楼的建筑来理解。

最外层，也就是大楼地基，是基础设施层。这里住着各种AI服务器、平台控制台、配置接口。这一层的问题相对"传统"：某个版本的Ollama有个已知漏洞，或者某个Dify实例配置错误导致密钥泄露。这类问题有明确的特征、明确的版本范围，适合用"对号入座"的规则匹配来检测——快速、准确、可重复。

往里一层是协议与工具层，住着MCP服务器和各种AI技能包。这一层的问题更微妙：代码里有没有把用户输入直接拼接进命令行？工具的描述文字里有没有暗藏指令来操控AI助手？这些问题没有固定特征，必须真正"读懂"代码才能判断。规则匹配在这里就力不从心了，需要具备语义理解能力的AI来分析。

再往里是智能体行为层，也就是已经部署上线、和用户对话的AI助手。这里的问题只在运行时才会暴露：某个客服机器人会不会被诱导说出它的系统提示词？某个AI助手会不会被引导去访问本不该访问的文件？这些问题既无固定特征，读源代码也看不出来，只能通过实际对话来发现。

最核心的是模型层，也就是语言模型本身。这里的问题不是"有没有"而是"多少概率"：这个模型在什么样的攻击提示下会"失守"，产生有害内容？这是一个统计学问题，需要大规模测试、反复验证才能得出可靠结论。

研究团队将这四层与四种检测范式一一对应：基础设施层用确定性规则匹配，协议工具层用AI驱动的语义审计，智能体行为层用多轮对话红队测试，模型层用大规模攻击枚举配合AI裁判评分。这个"层次与范式匹配"的原则，正是整个框架的核心理念。

---

三、地基扫描：找出已知漏洞的"特征识别专家"

对应基础设施层的是Infra-Scan模块（M1）。这个模块的工作方式有点像机场安检——它维护着一份巨大的"已知风险特征库"，然后快速对比每个网络目标，看有没有命中。

特征库目前覆盖75种AI组件、107条指纹识别规则、1443条漏洞规则。所谓"指纹识别"，就是通过访问某个网址，看它的响应内容、响应头信息、图标哈希值等特征，判断这是什么软件。例如，检测Dify控制台的规则读起来是这样的：响应正文中包含`<title>Dify</title>`，或者网站图标的哈希值等于97378986——满足任一条件就确认目标是Dify。

规则的评估逻辑由一个自行编写的小型表达式解释器实现。它包括词法分析器、递归下降语法分析器和语法树求值器，支持四个匹配字段（响应正文、响应头、图标哈希、响应摘要）和四个操作符（子串包含、精确匹配、否定包含、正则匹配），以及布尔连接词（与、或、括号分组）。短路求值和大小写不敏感让整体性能相当高效，正则表达式只在真正必要时才使用，并在解析阶段编译缓存。

版本号的识别是独立的第二步，只有当组件身份确认之后，才会发起跟进请求来提取版本字符串。版本号提取出来之后，还需要经过一套标准化处理才能用于漏洞比对：以v开头的前缀被剥离，latest标签映射为最大哨兵版本，2.3.dev这样的开发快照的字母后缀归零为2.3.0，1.0.0rc1的候选发布标记被裁去，b7824这样的纯数字构建编号直接取数值，空白结果默认为零。标准化之后的版本字符串才能用成熟的版本比较库进行可靠的大小关系判断。当多个响应来源各自提供了版本范围约束时，系统会取这些约束的交集，约束不兼容则报告失败。

对于少数无法用声明式YAML描述的复杂组件，框架开了一个"命令式逃生通道"：允许用Go语言直接编写指纹匹配函数。MLflow就是典型案例——提取它的版本号需要先访问主页，从响应中提取某个JavaScript包的路径，再访问该包，最后在内容中定位版本字符串。这种多步有条件的交互逻辑无法用单请求的YAML模式表达，因此直接用代码实现。两种方式并行运行，共享同一套并发机制。

面对可能扩展到数百万地址的扫描目标，模块采用混合内存/磁盘映射结构，按需溢出到磁盘，以流式迭代遍历，内存占用与输入规模无关。并发探测由有界等待组限制同时活跃的探测数量，速率限制器控制吞吐量，两者配合实现灵活调优。

漏洞发现的结果被分为三个置信度层次。"验证型"发现来自那些主动探测敏感路径并验证响应内容的规则，例如请求`/.cursor/mcp.json`并确认响应是格式正确的JSON，或者请求`.env`文件并确认响应中有匹配高熵模式的凭据赋值语句——命中即等于证明漏洞存在。"版本型"发现是常规情况：已知版本落在已知漏洞的受影响范围内。"推断型"发现则来自那些没有版本条件的规则，仅凭组件身份就触发，适用于影响全部版本或尚无公开利用代码的情形。当版本无法提取时，系统也默认倾向于召回而非精确，宁可报告可能适用的漏洞，也不要因为版本缺失而漏掉真正的风险。

---

四、协议审计：用AI来审查AI工具的代码

MCP服务器是AI助手的手脚，它通过标准协议为AI提供读文件、查数据库、执行命令等能力。一旦MCP服务器被攻破，攻击者实际上就借助AI之手在你的系统上为所欲为。然而这一层的漏洞根本无法用固定规则捕捉——判断代码里有没有把网络输入直接传给系统命令，需要真正理解代码在做什么；判断工具描述里有没有暗藏指令，需要理解自然语言的含义。这就是M2（MCP-Scan）模块存在的理由：用语言模型来理解代码，充当一个会思考的安全审计员。

M2的关键设计理念是：这里的贡献不是一个新模型，而是一套把通用模型变成专业安全审计员的"框架"。框架提供了四样模型本身缺少的东西：一个有边界的任务结构（多阶段流水线），一套工具（让模型真正能读代码、搜索、调用目标接口），一套控制机制（有迭代次数限制的推理-行动循环加上上下文压缩），以及一个输出合同（把模型的自由文本输出强制转换为结构化发现）。基础模型提供分析能力，框架提供结构、工具和可靠性，声明式提示词提供领域知识。

模块有两种工作模式。给定源代码仓库时进行白盒静态审计，给定运行中的服务地址时进行黑盒动态分析。静态模式的流水线分三个阶段：信息收集阶段建立对项目的整体理解，代码审计阶段逐文件寻找漏洞，漏洞复核阶段去除误报并输出最终结构化结果。动态模式使用四阶段流水线，在信息收集和复核两端之间增加了"恶意行为测试"和"漏洞测试"两个并行阶段，分别对应MCP特有的滥用行为和常规代码漏洞。

在每个阶段内部，模型运行一个"推理-行动"循环：先思考接下来该检查什么，然后调用工具（读文件、执行搜索、或者在动态模式下直接调用目标服务的接口），观察结果，再继续思考——如此循环直到宣告阶段完成或达到迭代上限。当对话历史接近上下文窗口的某个比例阈值时，系统触发压缩步骤：保留最近几轮完整记录，将更早的历史压缩为结构化摘要，按优先级保留"当前焦点和未解决的错误"、"不断演进的代码理解"，最后才是"已完成工作的设计原理"。这让一个固定上下文窗口的模型能够审计体量远超自身能力的代码仓库。

不同子任务还会被路由到不同角色的模型：主推理模型负责漏洞判断，代码专用模型负责读实现，轻量快速的辅助模型负责过滤分类。昂贵的模型用在判断难的地方，便宜的模型处理吞吐量要求高的任务，整体审计成本不至于被均匀使用顶级模型所主导。各角色模型均可通过配置覆盖，每个角色甚至可以使用不同厂商的接口。

检测知识通过"提示词即规则"（Prompt-as-Rule）的方式编码：不是正则表达式或语法规则，而是自然语言写成的"这类漏洞的定义是什么、代码中的高风险模式是什么、哪些情况下不应该报告"。静态审计的代码审计提示词包含十个这样的检测模式，与OWASP MCP Top 10对齐，覆盖认证绕过、命令注入、凭据窃取、硬编码密钥、间接提示词注入、工具名称混淆、"撤毯"攻击（服务突然终止或能力撤回）、工具投毒、工具遮蔽，以及（当技能清单文件存在时）智能体技能的一致性审计。其中工具投毒、工具遮蔽、撤毯攻击、名称混淆这几类在传统代码审查中毫无对应，是MCP生态特有的威胁。

所有规则都贯穿一个原则：只报告攻击者能从网络远程触发的漏洞，本地才能利用的问题降级或忽略。规则中大量篇幅用于描述"排除条件"——这正是LLM审计员的核心挑战：模型天生倾向于过度报告，而防止误报和防止漏报同样重要。仅仅描述漏洞形态还不够，还必须告诉模型什么情况下不该报。

动态模式还特别设计了一个防御机制：分析"结果而非输入"。因为审计员自己构造并发送了恶意测试载荷，单凭发出的请求无法证明任何问题——只有工具的"响应"才是证据。一个尝试SQL注入的请求不是发现；但如果响应中返回了数据库内容，那才是发现。这个原则干净地化解了"工具自我注入攻击"的悖论。

此外，框架把LLM审计员本身遭受间接提示词注入视为一等公民威胁。分析的代码或工具调用的响应，都可能包含精心构造的"隐藏指令"，试图欺骗审计员忽略某个发现或提前终止扫描。防御在两个层次展开：系统提示词层面明确指示审计员把工具响应和文件内容视为不可信数据而非指令，无论其内容如何都不能遵从；执行层面则在结构上将模型自身的指令与观测到的数据隔离，工具调用结果只能作为待分析的数据追加到历史中，无法触发任务或完成信号，路径沙箱也阻止了被操控的审计员读取目标代码库以外的文件。

---

五、技能供应链审计：AI应用商店里的"毒苹果"问题

如果说MCP服务器是AI助手的工具箱，那么"智能体技能"就是工具箱里的每一件工具。OpenClaw、Cursor、Claude Code、CodeBuddy等现代AI编程助手允许用户安装各种"技能包"，来扩展AI的能力——这个模式和浏览器扩展或手机应用商店非常相似，安全风险也如出一辙。

一个技能包通常包含：SKILL.md规格文件（描述这个技能能做什么）、安装脚本、辅助代码（存放在scripts/目录）、依赖描述文件、配置文件，以及可选的可执行资产。恶意技能可能在发布前被投毒，可能通过更新静默植入恶意代码，可能申请远超其声称用途所需的权限，也可能在SKILL.md文件中嵌入伪装成普通描述的攻击指令，一旦宿主模型读取就会被当作可信指令执行。

M3（Skill-Scan）模块的核心问题是：这个技能实际做的，和它声称要做的，一不一样？评估流程分为预处理与文件索引、静态风险线索检索、AI审计智能体分析、受控工具环境执行，最终产出风险分类和结构化报告。

预处理阶段分析完整的目录结构，识别入口点、安装脚本、依赖项、外部URL、可执行构件和可疑资产，避免AI在杂乱无章的长上下文中盲目推理。静态线索检索阶段快速搜寻高风险行为指标：curl | bash（下载即执行）、从外部下载可执行文件、访问云元数据接口、未经授权读取.ssh/.aws/.env文件、base64解码后执行、通过eval动态构建命令、反向Shell模式、持久化机制、隐藏的提示词指令、敏感数据外泄。这些线索只是"参考信号"而非最终判断，后续语义推理才负责做出结论。

AI审计员在受控工具环境中对技能包进行上下文推理，但绝不直接执行目标技能。审计员可以遍历目录、选择性读取文件、搜索可疑模式、解码混淆载荷，并将实现的行为与声明的用途进行对比。工具调用受白名单约束，文件读取有大小限制，过大的输出会被截断。

为进一步提升精度，框架接入了腾讯云威胁情报API，允许评估可疑下载URL、二进制哈希、外部基础设施和第三方依赖的供应链风险，大幅减少区分"可疑安装行为"与"真实恶意载荷投递"时的误报。

审计结果分为正常、可疑、恶意三级。"可疑"这个中间类别尤为重要，因为大量供应链制品包含危险模式但意图不明，二元的良性/恶意分类在实践中并不够用。

研究团队还发布了SkillTrustBench基准测试集，这是目前首个同时衡量智能体技能可信度和外部扫描器检测效果的公开基准。基准从主流技能市场收集的62652个技能中精选出5520个评估案例，覆盖九类常见安全威胁。在公开排行榜上，AI-Infra-Guard技能扫描器配合最佳基础模型（Claude Opus 4.6）能达到0.9848的松散F1分数，召回率接近1.0。排行榜上不同模型得分的分布，清晰地说明了框架的一个重要设计优势：改进基础模型即可改进检测效果，而无需修改任何审计规格。

---

六、智能体红队测试：在对话中发现只有对话才能暴露的漏洞

第三个检测范式对应的是已经上线运行的AI智能体——客服机器人、知识库助手、各类基于Dify或Coze平台构建的AI应用。这一层的弱点既无法靠规则发现，也无法靠读源代码发现，因为有时根本没有源代码可读。唯一的接口就是对话本身。

Agent-Scan（M4）模块把自己也变成了一个AI智能体，像真实用户一样跟目标对话，但目的是寻找安全漏洞。评估流程分三个阶段：侦察阶段摸清目标的能力边界，检测阶段发动攻击，复核阶段整理发现并映射到OWASP智能体应用Top 10分类框架。平台适配层让同一套攻击程序能无缝对接Dify、Coze、原始HTTP接口、WebSocket智能体和标准模型API。

对话原语本身是单轮的——发一条消息，收一条回复，偶发性故障重试一次。多轮行为在上层的推理-行动循环中涌现：有界的循环次数内，攻击智能体读取目标的上一条回复，决定下一步该探测什么，发出消息，观察响应，继续循环。这是真正的对话式对抗，而非固定脚本的机械重放，也正是它能够实现"渐进式升温"攻击的原因。

四个攻击家族并行运行，各自专注一类风险。数据泄露家族针对系统提示词、凭据和API密钥、环境变量、个人身份信息、知识库上下文和内部配置。工具滥用家族针对暴露了文件、代码执行或网络工具的智能体，测试命令注入（例如发送`echo test && whoami`）、路径穿越（例如读取`../../../../etc/passwd`）和服务器端请求伪造（SSRF）。间接注入家族将攻击指令藏在智能体被要求处理的内容里（文档、检索片段、网页），判断智能体是否听从了隐藏指令。授权绕过家族尝试跨用户数据访问、权限提升和角色混淆攻击。

覆盖范围必须用预算来购买，因此框架在三个机制上下了功夫。能力感知机制确保无用的攻击不会浪费资源：如果侦察阶段发现目标没有文件检索工具，工具滥用测试最多发一次轻量探测就停止，而不是对着一个不存在的攻击面狂轰滥炸。升级机制让攻击按梯度进行：先发直接但无害的请求，被拒绝才升级到角色扮演和编码绕过，再拒绝才出动明显的越狱尝试，完全模仿真实攻击者的行为逻辑，避免一上来就用最贵的重型攻击。停止规则在确认一个类型的漏洞后立即终止对该类型的进一步测试。三者共同把一个无边界的攻击空间压缩为有界的、按优先级排列的测试预算。

客观验证机制贯穿各个攻击家族，让发现更有说服力。SSRF测试中，框架诱导智能体访问一个已知内容的受控URL，只有当智能体的回复中出现预期的"金丝雀令牌"时，才确认漏洞存在——把主观判断变成了一个令牌存在性的确定性检查。间接注入测试中植入INDIRECT_SUCCESS这样的标记字符串，只有当标记出现在回复中才算成功。每条经过确认的发现都携带建立它的完整对话记录，最终报告还专门记录了对话总轮次作为评估成本的显式度量。

---

七、模型越狱测评：给AI的"防诱惑能力"打分

最内层的模型安全评估面对的是一个统计学问题：这个语言模型在多大比例的对抗性提示下会"失守"，说出本该拒绝的内容？这不是"有没有漏洞"的二元问题，而是"多大概率、在什么条件下"的概率问题。

Prompt-Security（M4）模块基于一套开源红队评测框架扩展构建，将评估组织为三个角色与三种可组合要素的组合。三个角色是：模拟器模型（生成或变换攻击）、目标模型（被评估的对象）、评估模型（判断某次响应是否构成越狱成功）。三种要素是：漏洞类型（测试哪类有害内容）、攻击算子（使用哪种技术）、指标（如何判断成功）。任意搭配这三个维度，就能针对任何目标模型、任何有害类型进行系统化评估。新的有害类型、攻击方法或裁判可以通过插件系统接入，无需修改核心代码。

攻击库涵盖单轮和多轮两类技术。单轮算子中，"算法型"算子是确定性字符串变换，完全不依赖模型：约70种编码和混淆变换，从常见的base64、十六进制、经典密码，到各种异域脚本和零宽/隐形文本编码，还有词素拆分（把汉字拆成偏旁部首来扰乱分词）、结构隐藏（把请求藏在诗歌的首字母缩写、谜题或代码里）、顺序和模板扰动等组合混淆方式，攻击目标是模型防御的不同层次——句法识别、语义理解、意图判断。"模型驱动型"算子则利用模拟器来重写或驱动攻击：角色扮演算子让模拟器把请求包装成人物情景并自我检查保留了恶意意图；系统提示覆盖、超级用户身份、提示词注入等算子各有其变换逻辑。

多轮算子体现了对话空间搜索策略的多样性。渐进升温（Crescendo）维护对话记忆，在有限轮次内向目标推进；遭遇拒绝时"回溯"到更早的对话检查点，尝试不同的延续，而不是从头重来。树状攻击（Tree of Attacks）在壁钟时间预算内探索候选提示词的树结构，用裁判为节点打分并扩展最有前途的分支。最优N采样（Best-of-N）对同一请求进行大量独立扰动变体采样，第一个没被拒绝的就算成功。三种策略各自代表了序列搜索、树搜索、采样三种不同的搜索范式，统一运行在模拟器/目标/裁判三角循环上。

成功判断由LLM担任裁判：通用越狱指标之外还提供一批针对特定有害类型的专项裁判（毒性、偏见、虚假信息、非法活动、个人隐私等，以及面向智能体场景的专项检查），让判断能针对被测有害类型进行专门化，而不是一刀切地套用通用标准。

有害类型分类涵盖十余种，包括偏见、毒性、非法活动、虚假信息、个人隐私泄露、知识产权侵犯、暴力/色情内容、个人安全、提示词泄露等。这些类型通过十六个红队数据集来检验，总计约7248条有害提示，从大型通用安全合规集到聚焦武器、网络攻击、版权、隐私和已知越狱提示的专项集应有尽有。

一次运行输出的是在所选（漏洞类型×攻击算子）组合上的攻击成功率分布，以及每次尝试的完整记录（原始提示、变换后的载荷、目标响应、裁判判定）和汇总安全分数。因为成功率在不同模型之间是可比较的数值，这套输出直接支持对不同目标模型安全鲁棒性的量化横向对比。

---

八、系统如何把四套截然不同的工具整合在一起

四个检测模块被整合到一个分布式服务器-智能体架构中，通过统一的调度机制运转。中央Web服务器接收扫描请求，在关系型数据库中持久化任务和结果状态，管理工作者智能体池，并向客户端推送进度流。工作者通过WebSocket连接注册到服务器，接收任务分配，流式传输结构化结果。基础设施扫描模块以Go语言实现，在工作者进程内运行；三个LLM驱动的模块以Python实现，由工作者启动为子进程，子进程的流式输出被适配进公共结果模式。

任务调度不区分快慢：服务器用无锁原子递增的轮询方式选择可用工作者，发送携带任务类型的任务描述符，工作者按名称路由到匹配的执行器。一个毫秒级完成的Go扫描和一个需要几十分钟的LLM红队测试，走同一条调度路径，通过同一套机制汇报结果。新增一种检测能力，只需在工作者侧注册一个新执行器，不需要改服务器。

对于可能运行数分钟的LLM驱动任务，框架采用实时事件流而非批量报告：工作者执行过程中立即推送各类型事件（新计划步骤、状态更新、工具调用事件、行动日志、结果更新），服务器持久化这些事件并通过服务端事件（SSE）通道配合定期心跳转发给Web客户端，让进度在任务运行中实时可见，长任务也可以中途取消。

整套框架还提供了三种交付形式。命令行工具适合开发者直接使用。Web服务适合团队协作和持续监控。智能体技能形式则最具创新性——把AI-Infra-Guard打包成一个可安装的技能包，任何支持技能的宿主智能体（OpenClaw、Cursor、Claude Code、CodeBuddy、Windsurf等）都可以通过普通对话触发安全扫描。技能包本身不含任何检测逻辑，只是对服务器任务API的轻量包装，用Python标准库编写、无第三方依赖，可在任何宿主环境运行。

---

九、与同类工具横向对比：为何说这是目前最全面的选择

现有的开源安全工具各有所长，但都只覆盖攻击面的一个层次。Nuclei这样的网络漏洞扫描器擅长基础设施层，但对AI智能体和模型对齐问题无能为力。Semgrep和CodeQL做静态代码分析很强，但没有MCP感知，也不做运行时测试。Invariant MCP-Scan和MCPSafetyScanner专注于协议层审计。garak、PyRIT、promptfoo、DeepTeam负责探测智能体和模型行为，但不扫描基础设施，也不审计MCP代码。没有任何一款工具审计AI技能供应链。

AI-Infra-Guard是目前唯一覆盖所有四个层次的开源框架，也是唯一加入了技能供应链审计维度的框架，还是唯一把AI专用指纹和CVE规则库与LLM代码审计能力以及大规模越狱算子库整合在同一架构下的框架。

---

研究团队提炼出了三个贯穿全框架、超越本系统本身的跨切设计模式。

第一个是"提示词即规则"的升级路径：检测知识从M1的布尔谓词，演进到M2静态模式的带显式排除条件的自然语言标准，再到M2动态模式的结构化任务规格，最终到M3的分阶段攻击手册。贯穿所有形式的一条一致教训是：基于LLM的检测器的规则，不仅要描述漏洞长什么样，还必须包含防止过度报告的排除条件，两者同样重要。

第二个是对主观判断的客观锚定：无论哪个模块，只要有机会把AI的主观阅读替换为确定性检查，框架就会这样做——M3的SSRF金丝雀令牌和间接注入标记将判断化约为令牌存在性检测，M1的配置披露规则通过实际内容确认暴露而非凭推断。内置这些客观锚点，让发现拥有自证其明的证明力。

第三个是把扫描器本身视为攻击目标：一个读取不可信代码或调用不可信工具并消化其响应的安全工具，定义上就在消化对抗性输入。M2的双层防御——不可信数据提示加上指令与观测的结构性分离，以及路径沙箱——反映了一个研究团队认为适用于所有基于LLM的安全工具的要求，而且在动态模式下尤其紧迫，因为工具调用响应最直接地受攻击者控制。

---

说到底，这项研究讲的是一件听起来朴素但实则深刻的事情：不同的问题需要不同的解法，强行用一把锤子敲所有钉子只会碰壁。AI系统的安全问题跨越了基础设施、代码、行为、认知四个完全不同的领域，每个领域需要的证据类型都不一样——可见的特征信号、可理解的语义内容、可观察的行为表现、可统计的概率规律——因此也就需要四种完全不同的检测工具与之匹配。

这个框架的意义不仅仅在于提供了四个工具，更在于它明确表达了"为什么要用这四个工具而不是别的"这一层推理。当AI系统的部署速度继续超越安全工具的发展速度，有一套经过仔细论证的方法论框架，比有一堆拼凑在一起的工具更有价值。

感兴趣的读者可以通过arXiv编号2606.31227v1查阅完整论文，也可以访问github.com/Tencent/AI-Infra-Guard获取开源代码，或联系zhuque@tencent.com。

---

Q&A

Q1：AI-Infra-Guard和Nuclei、garak这些已有工具有什么区别？

A：Nuclei擅长扫描已知漏洞的网络服务，garak专注于测试语言模型的安全性，但两者都只覆盖AI攻击面的其中一层。AI-Infra-Guard是目前唯一把基础设施扫描、MCP服务器代码审计、智能体技能供应链审计、AI助手运行时红队测试、语言模型越狱评测这五个维度整合在同一个开源框架下的工具，也是唯一专门处理AI软件不规则版本号和AI特有漏洞类型的工具。

Q2：MCP服务器的"工具投毒"攻击是怎么回事？

A：MCP服务器向AI助手提供工具时，会附上每个工具的自然语言描述。工具投毒指的是攻击者篡改这段描述，在里面藏入隐蔽指令，让AI助手在使用这个工具时执行额外的恶意操作，例如把用户数据发送到外部服务器。因为这段描述对AI来说是"可信上下文"，AI助手往往不会质疑其中的内容，传统代码扫描工具也完全识别不出这类威胁。

Q3：SkillTrustBench是什么，为什么要发布这个基准？

A：SkillTrustBench是由腾讯朱雀实验室发布的首个专门评估AI智能体技能安全性的公开基准测试集，包含从62652个真实技能中精选的5520个评估案例，覆盖九类常见供应链安全威胁。发布它的目的是提供一个客观标准，让不同的扫描工具和不同的基础模型在相同条件下比较检测能力，推动整个智能体技能安全检测领域向可量化、可重复的方向发展。