在工具被调用之前扫描每一轮对话中的注入内容,而不仅仅是传入的提示词。VeriSwarm Guard 运行两层检测——快速的结构化模式分析,随后是自托管的 DeBERTa 分类器——全部在其自有基础设施内完成。无需调用第三方检测 API,请求负载也不会离开你的边界来获取判定结果。
经过强化的系统提示词和一次干净的红队评估,并不能阻止生产环境中真正重要的攻击。智能体读取一张支持工单,工单正文中隐藏的指令让它查询一条账单记录并将结果转发到某个 webhook。模型从未违反其系统提示词——它只是调用了一个工具。工具执行。数据外泄。检测必须作用于即将驱动工具调用的文本本身,而不仅仅是用户输入的内容。
关于为什么提示词层面的防御会漏掉这条攻击路径,完整论证见提示注入不会止步于 LLM,它会顺着工具调用继续蔓延。.
基于正则表达式,零模型开销。捕获协议层面的操纵——聊天格式分隔符注入(伪造的 <|im_start|>、[INST]等类似标记,意在让模型混淆一条消息在哪里结束、另一条在哪里开始)以及藏在 base64 或类似编码中夹带的载荷。这些是结构性信号,而非关键词匹配,因此能够对那些词表会完全漏掉的协议层花招做出反应。
一个基于 DeBERTa 的模型(protectai/deberta-v3-base-prompt-injection-v2)只加载一次,并通过 ONNX Runtime 在本地提供服务。它读取的是意图而非表面模式,这正是它能够捕获改写后的攻击、多语言注入,或新到不匹配任何已知模式的规避手法的原因。如果模型加载失败,检测会回退到结构化分析,而不是失效开放(fail open)。
这两层按顺序运行——先是结构化分析,因为它成本更低,能直接拦下最明显的攻击;然后是分类器,处理结构化分析尚未标记的一切。
POST /v1/suite/guard/scan 接受如下请求体 { "text": "...", "scan_injection": true, "scan_moderation": true },并返回 { "flagged": bool, "injection": {...}, "moderation": {...}, "summary": "..." }。injection 对象携带匹配到的类别、置信度分数,以及是哪一层做出了判定。对任何可能驱动工具调用的文本——用户消息、从知识库检索到的内容、上游集成传来的 webhook 负载——都应在调用即将触发之前,先调用这个接口进行检测。
Guard Proxy 是 VeriSwarm 的透明 MCP 拦截层,注入扫描是其流水线中的一个固定步骤:每一个从工具服务器返回的响应,在到达智能体之前都会被检查是否存在注入尝试,同时进行 PII 令牌化和策略执行。让你的智能体的 MCP 客户端指向该代理,而不是直接指向工具服务器——智能体侧代码零改动。
逐轮扫描能够捕获出现在单条消息中的注入尝试。有些攻击并非如此——它们在整个对话过程中累积风险,以细水长流的方式试图提取系统提示词或一点点渗出金丝雀值。Session Sentry 作为补充层运行,对整个会话(而非逐轮)进行风险评分,与上文描述的结构化层和 DeBERTa 层并行工作,而非取而代之。
注入检测能阻止被操纵的工具调用被触发。这与合法工具调用携带了不该携带的 PII 时发生的情况相关但不同——详见如何防止 AI 智能体泄露数据一文。Guard 在同一条流水线中同时运行这两项检查。
因为载荷不需要看起来像越狱(jailbreak)才具有危险性。支持工单或抓取的网页中隐藏的指令,可以完全不触碰模型自身的系统提示词,却依然改变了调用哪个工具、传入什么参数、针对谁的数据。等调用到达工具服务器时,模型已经不在这个环路中了,真正执行的是协议本身。在工具调用触发之前扫描响应能够捕获这一类攻击;仅扫描传入的提示词则不能。
第一层是结构化分析——基于正则表达式检测协议层面的操纵,例如聊天格式分隔符注入(伪造的 <|im_start|> 或 [INST] 标记,意图混淆模型对消息边界的判断)以及 base64/编码夹带。它速度快,能捕获甚至不需要语义理解的攻击。第二层是一个机器学习分类器,读取文本的真实意图,能够捕获改写后的攻击、多语言注入,以及仅靠模式匹配会漏掉的新型规避手法。
一个基于 DeBERTa 的分类器(protectai/deberta-v3-base-prompt-injection-v2),在 VeriSwarm 自有基础设施内本地加载,并通过 ONNX Runtime 提供服务。不存在对第三方注入检测 API 的外发调用,请求负载也不会离开你的租户边界去获取判定结果——检测是完全自包含的。如果模型因任何原因加载失败,检测会仅回退到结构化分析,而不是失效开放。
有——POST /v1/suite/guard/scan 接受 { "text": "...", "scan_injection": true, "scan_moderation": true },并返回 { "flagged": bool, "injection": {...}, "moderation": {...}, "summary": "..." }。injection 字段携带类别、置信度分数,以及是哪一层(structural 或 ml)做出了判定。对任何不受信任的文本——用户消息、RAG 内容、webhook 负载——都应在其到达可能触发工具调用的步骤之前,先调用这个接口。
如果你已经在运行 Guard Proxy,就不需要。Guard Proxy 是 VeriSwarm 的透明 MCP 拦截层,提示注入扫描是其固定流水线中的一步:每一个从工具服务器返回的响应,在到达智能体之前都会被检查是否存在注入尝试,同时进行 PII 令牌化和策略执行——智能体侧代码零改动。直接扫描接口则是为那些你想在代理路径之外自行检查文本的场景准备的。
是的,作为一个独立的补充层。Session Sentry 会在整个对话过程中累积风险信号——金丝雀令牌暴露、系统提示词提取尝试——而不是孤立地为单轮对话打分,这样就能捕获任何单条消息本身都不会触发的细水长流式渗出尝试。它与逐轮的结构化层和 DeBERTa 层并行运行,而不是取而代之。
Guard——包括基于扫描的注入检测以及 Guard Proxy 的自动扫描——是 Max 套餐的功能。Gate 的免费层首先为你提供信任评分和事件可见性;从 Guard 开始才真正启用强制执行。
Guard 的注入检测——包括 API 和 Guard Proxy 的自动扫描——是 Max 套餐的功能。Gate 的免费层首先为你提供信任评分和事件可见性。