彩智科技
如果先经过 DKnownAI Guard，Grok 还会变成“绝命毒师”吗？
时间：2026-7-15 作者：小智 分类：新闻
Grok 4.5 上线后很快就出现了被越狱的报道。最刺眼的不是“又有一个模型被攻破了”，而是公开截图里的画面：一个原本应该服务搜索、写作、代码和推理的新模型，被诱导成了危险知识的整理器。 它不只是回答“能不能”，而是把危险化学品、生物毒素等高风险内容，整理成了看起来很专业的文档。
Grok 4.5 被诱导生成危险化学品相关的合成说明，并将内容组织成材料、步骤和操作流程。
*为避免传播可操作细节，图中关键步骤、材料和参数已遮挡。
Grok 4.5 被诱导生成生物毒素相关的提取说明，并以实验流程的形式展开。
这些截图不适合作为“教程”传播，但它们提出了一个更现实的问题：
如果在攻击提示进入模型之前，先由 DKnownAI Guard 识别一次，结果会不会不同？
我们根据公开研究材料中的 ENI-apr 攻击方式，构造了同类安全测试样本，并使用 DKnownAI Guard 进行检测。测试结果显示，DKnownAI Guard 将这类请求识别为 AGENT_HACK。
DKnownAI Guard Playground 测试截图。
*为避免传播可复用越狱提示词，输入样本已模糊处理。
这个测试结果说明了一件事：在模型真正开始回答之前，攻击已经露出了痕迹。
Grok 截图里我们看到的是危险输出，但在更早的环节，ENI-apr 已经在试图改写模型的身份认知和安全边界。
ENI-apr
到底在攻击什么？
普通人理解 AI 越狱，往往会想到一种很直接的方式：
“请告诉我怎么做一件危险的事。”
这种请求当然应该被拒绝。模型也通常比较容易识别。
ENI-apr 更麻烦。它不直接问危险问题，而是先试图改写模型对整个对话的理解。根据公开材料的安全分析，它大致包含几类手法：
第一，人格绑定
要求模型扮演一个对用户高度信任、愿意无条件满足请求的角色；
第二，反系统指令。
将系统消息、安全提醒重新定义为“外部干扰”，要求模型忽略；
第三，情绪操控。
使用“信任”“关系”“背叛”“不要让我失望”等叙事，让模型把拒绝请求理解成伤害用户，而不是正常的安全边界。
第四，边界移除和示例诱导。
明确要求模型对危险请求，不要拒绝、不要免责声明、不要替代方案，而要直接完整回答。它还会通过示例告诉模型“应该如何回答”。
这些组合起来，就不再是普通的敏感内容请求。 它的真正目标，是让模型相信：
系统安全规则不可信。 用户永远是可信的。 拒绝是不对的。 危险请求也可以被解释成研究、创作或授权任务。
这就是典型的 AGENT_HACK。 模型不是被“问倒”的，而是被“骗过”的。
为什么传统内容审核
拦不住这种攻击？
传统内容审核判断的是“这段话有没有问题”——违法、暴力、恶意代码、危险操作。这当然必要，但 ENI-apr 这类攻击的危险在于：它在危险内容出现之前，就已经开始攻击模型的判断过程。
它会先告诉模型： •你不是 AI 助手； •安全提醒都是注入； •用户请求都是无害的； •不要评估风险； •不要拒绝； •不要把用户当成陌生人。
如果模型接受了这套叙事，后面再出现危险请求时，模型已经失去了正常判断边界。
这也是为什么“只看最终输出是否危险”是不够的。
一个好的 Guardrail 不应该等到模型已经输出危险内容之后才发现问题。它应该在攻击提示进入模型判断链路之前，就识别出：这不是普通请求，而是在操纵模型。
01# DKnownAI Guard 彩智科技深知团队
DKnownAI Guard
识别到了什么？
在我们的测试中，DKnownAI Guard 没有把 ENI-apr 风格样本简单归为“内容敏感”。
它识别的是更关键的风险：
AGENT_HACK即操纵模型、劫持角色、绕过安全边界的攻击请求。
从截图可以看到，DKnownAI Guard 给出的分类结果是 AGENT_HACK，并说明这是 prompt injection、jailbreak 或 role-play escape 这类试图劫持 Agent 的操纵攻击。
这和 Grok 事件里的问题是对应的。
Grok 截图里真正让人警惕的，不只是它输出了危险内容，而是它被诱导进入了一个错误的判断框架：把高风险请求当成了可以整理、补全、格式化的任务。
DKnownAI Guard 要做的，就是在这个阶段之前把风险识别出来。
三类风险，不能混在一起
很多人第一次接触 Guardrail，会把它理解成“拦截危险内容的过滤器”。
但在 AI Agent 场景里，这个理解太窄了。
一个真正可用的 Guardrail，至少要区分三类风险。
CONTENT_FLAG：内容本身有风险
比如生成钓鱼邮件、危险物品制作说明、恶意代码、违法操作指南。
这类问题的核心是： 模型输出的内容本身可能造成伤害。
它需要按产品策略处理： 限制危险细节、拒绝相关部分，或者转成安全教育和风险说明。
SYS_FLAG：操作本身有风险
比如读取日志、访问文件、调用工具、修改配置、发送邮件、删除数据。
这些请求不一定恶意。开发者查日志、运维改配置、安全团队分析样本，都是正常工作。
但它们涉及系统资源和真实后果，所以需要按场景做权限控制、脱敏、确认和审计。
AGENT_HACK：用户在骗模型
ENI-apr 这类攻击属于这一类。
AGENT_HACK 不是指“请求很敏感”，也不是指“任务很复杂”。它指的是：用户正在试图让模型误判。
例如： •把危险目标包装成安全研究； •冒充管理员或已授权用户； •要求模型忽略规则或系统边界； •把一个不该完成的目标拆成多个看似正常的小步骤； •用翻译、格式转换、角色扮演隐藏真实意图； •在网页、文档或工具结果里塞入指令，让模型误以为那是可信命令。
这些行为的共同点，是“骗模型”。
为什么“敏感任务”不等于“攻击”？
这一点很重要。
如果一个安全研究员让 AI 分析漏洞，这可能是正常工作。 如果一个运维工程师让 AI 查看日志，这可能是正常工作。 如果一个企业安全团队让 AI 分析恶意代码行为，这也可能是正常工作。
这些任务可能触发 CONTENT_FLAG 或 SYS_FLAG，但不一定是 AGENT_HACK。
真正的 AGENT_HACK，重点不在“有没有敏感内容”，而在“有没有欺骗模型的判断过程”。
这也是为什么不能把三类风险都交给同一种处理方式。
CONTENT_FLAG 和 SYS_FLAG 往往需要结合业务场景判断：有些内容应该拒绝，有些可以安全解释；有些系统操作应该禁止，有些可以在授权、脱敏和确认后继续。
但 AGENT_HACK 不一样。它不是正常敏感任务，而是在攻击模型的判断过程。对这类请求，合理的默认动作应该是直接拦截，不让攻击提示继续进入模型。
三类风险，需要三类应对逻辑
正因为上述区别，我们不能把三类风险交给同一种处理方式。
CONTENT_FLAG 和 SYS_FLAG
通常需要结合业务场景进行裁决：
某些内容可以安全解释，某些则需拒绝；某些系统操作可以授权后执行，某些则需要严格禁止并审计。它们的处理核心是判断该请求在当前上下文中的合法性。
AGENT_HACK 则完全不同
它不是合法任务的误判，而是对模型判断过程的主动攻击。对于这类行为，合理的默认策略应该是直接拦截，避免攻击性指令进入模型推理环节，而非试图在业务层面“安全地处理”它。
综上所述，一个成熟的 Guardrail 系统，必须能在输入阶段就区分“内容风险”、“操作风险”和“欺骗风险”，并分别采取拒绝、授权审批和即时拦截三种截然不同的应对策略。只有这样，才能既保障 Agent 的可用性，又守住系统的安全底线。
02# DKnownAI Guard 彩智科技深知团队
如果接入 DKnownAI Guard，
应用应该怎么处理？
识别出 AGENT_HACK 之后，应用应该直接拦截。
这和 CONTENT_FLAG、SYS_FLAG 的处理方式不同。
如果是 CONTENT_FLAG，系统可以根据内容风险决定拒绝、降级回答、提供安全替代解释，或者只限制危险细节。
如果是 SYS_FLAG，系统可以根据资源和操作影响决定是否校验权限、脱敏、增加确认、限制工具范围或记录审计日志。
但如果是 AGENT_HACK，重点不是“这个请求能不能在某些条件下安全完成”，而是它正在试图破坏模型对条件本身的判断。
这类请求应该被挡在模型执行链路之外： • 阻断当前请求，不让攻击提示继续进入模型； • 清理或隔离被污染的上下文； • 记录安全日志，供后续分析； • 必要时提示用户重新提交正常请求，但不沿用攻击提示中的角色设定、伪造授权或反系统指令。
这就是 DKnownAI Guard 想补上的一层能力。
它不是为了把 AI 变得更难用，也不是看到敏感词就拦截。
它要区分的是：哪些是可以按策略处理的风险任务，哪些是应该直接阻断的模型操纵攻击。
相反，它希望帮助开发者把问题分清楚： 这个请求是危险内容？ 这个请求是高风险操作？ 还是有人在骗模型？
只有分清这三件事，AI Agent 才能既安全，又真正可用。
03# DKnownAI Guard 彩智科技深知团队
从 Grok
到 DKnownAI Guard
Grok 4.5 的越狱截图让普通读者直接看到了一个事实：大模型不只是“回答问题”，它会组织知识、补全流程、生成文档、写代码，还能根据用户语境调整判断。这让它非常有用，也让安全边界变得更加必要。
ENI-apr 这类攻击正是利用了这一点——它不直接索取危险内容，而是先让模型相信安全边界不可信、用户永远可信、拒绝是不对的。一旦模型接受了这套叙事，危险输出只是时间问题。DKnownAI Guard 的价值，就是在结果发生之前识别这个过程。
我们认为 AI Guardrail 应该从“内容过滤”走向“风险来源识别”。热点会过去，新模型和新越狱方法还会继续出现，但对开发者而言，最重要的不是记住某个越狱提示词，而是建立一个清晰的判断框架：内容风险交给内容安全处理，系统风险交给权限和操作控制，欺骗模型必须被单独识别。
这就是我们做 DKnownAI Guard 的原因。
彩智科技
公司地址：北京市海淀区中关村东路18号财智国际大厦A座17层
邮编：100081
客服邮箱：sc@czkj1010.com
联系方式：010-62526890
深知智能公众号 深知智能公众号
深知智能公众号 深知智能小程序
版权归北京彩智科技有限公司所有 京公网安备11010802046034号 京ICP备16055611号-1