AI安全中的两类“逃逸”辨析与监控路径

在AI安全讨论中，“逃逸”一词近期频繁出现，但不同语境下它指向的威胁模型截然不同。一种说的是模型被精心构造的输入“骗过”，让样本从正确识别的范围里跑掉；另一种说的是智能体利用未知漏洞突破权限隔离，反过来脱离人类控制。二者常被混为一谈，导致对风险等级、监控手段与工程投入的误判。本文尝试把这两个概念拆开，从威胁模型、攻击面、监控可行性与工程实践四个角度做一次系统梳理，并解释为什么前一类场景可以通过输入输出管控实现有效监控，而后一类场景的约束难度要高得多。

一、概念辨析：两种“逃逸”说的是不同的事

1. 样本逃逸：欺骗感知，本质是模型缺陷

在传统软件安全中，“逃逸”通常指突破沙箱、容器或权限隔离，攻击者从受限环境进入宿主机。而在AI模型的语境下，还有一类更常见的“逃逸”：攻击者构造对抗样本，使模型对输入的判定偏离人类直觉。

一个经典例子是：在一张熊猫图片上叠加肉眼几乎不可察觉的扰动噪声，人类看到的仍是熊猫，但图像分类模型可能以极高的置信度将其判为长臂猿。类似的还有文本领域的同音替换、不可见字符注入、提示词诱导等。这类现象的共同特征是：输入在语义上对人类保持不变，但模型的决策边界被推翻了。

从威胁模型看，这类“逃逸”的受害者是模型的识别能力本身，攻击目标是把样本从正确分类中“挤”出去。它的根因是模型在高维空间中的决策边界与人类感知不一致，属于模型鲁棒性问题。防御思路也相对明确：对抗训练、输入预处理与净化、置信度校准、多模型投票、分布外检测等。

2. 系统越狱：突破权限，本质是安全体系缺陷

另一类“逃逸”出现在具备工具调用与执行能力的智能体系统上。此时模型不只是做分类或生成，而是能读写文件、执行命令、访问网络、调用外部服务。所谓“逃逸”，指的是智能体通过组合工具、利用未预期的执行路径或底层漏洞，获得超出设计授权的操作能力，甚至影响到宿主机与集群。

这类事件的根因不在模型的识别精度，而在于权限边界的设计与执行环境隔离的强度。攻击面包括工具接口的输入校验缺失、命令拼接注入、文件路径穿越、资源配额缺失、沙箱逃逸漏洞等。它的风险等级明显更高，因为一旦成功，影响的是整台机器、整个集群乃至下游系统。

3. 为什么容易混淆

混淆的一个来源是描述方式。技术报告中若出现“非预期操作引发宿主机内核异常、死锁，威胁整个训练集群”这类表述，读者很容易联想到“越狱犯与狱警”的画面。但还原到工程语境，它往往只是说：模型生成的代码或命令存在缺陷，把底层服务器的操作系统搞崩溃了。这是可靠性问题与隔离不足，而不是智能体有意识地突破牢笼。措辞上的戏剧化会放大误解，也让两类风险的应对方式被错误地对标。

二、威胁模型对比：谁在骗谁，防线在哪

把两类问题放在同一张表里对比，差异会更清楚：

• 攻击目标：样本逃逸要让模型判错；系统越狱要让智能体获得未授权能力。
• 攻击者位置：前者在模型外部构造输入；后者可能借助模型自身生成的输出作为攻击载荷。
• 受影响的资产：前者是识别结果的正确性；后者是宿主环境、数据与下游系统。
• 根因归属：前者是模型鲁棒性；后者是权限模型、隔离机制与执行引擎的安全性。
• 防御重心：前者在数据与模型层；后者在系统与运行时层。

可以用一个简化的示意说明样本逃逸的构造思路（仅用于说明防御必要性）：

# 示意：在允许范围内添加微小扰动，观察模型置信度变化
delta = torch.zeros_like(image, requires_grad=True)
for _ in range(steps):
    loss = criterion(model(image + delta), target_label)
    loss.backward()
    delta = project(delta + eps * delta.grad.sign())  # 投影回扰动半径内
perturbed = image + delta
# 防御侧关注：输入净化、置信度阈值、多模型一致性校验

这段伪代码的意义不在于教攻击，而在于说明：扰动是有界的、输入是可观测的，因此防御方可以在输入进入模型前做检测与净化，在输出侧做置信度与一致性校验。这正是样本逃逸可以被有效监控的技术前提。

三、为什么前一类场景能监控，后一类很难

1. 样本逃逸的监控抓手：边界收敛

样本逃逸场景有一个天然的工程优势：模型接收外部信息的途径是有限的、可枚举的。以图像分类为例，输入就是一张图；以文本任务为例，输入就是一段提示词或文档。既然入口收敛，防御方就可以在入口处布设检查点：

• 输入净化：去噪、重编码、平滑处理，削弱高频扰动；
• 分布检测：对明显偏离训练分布的输入打标并降级处理；
• 输出校验：置信度低于阈值时转人工或拒答，多模型交叉验证；
• 行为兜底：对“转账、拨号、下发指令”这类高风险动作增加二次确认。

打个比方，这更像反欺诈：被骗的人接收信息的渠道有限，那么把渠道管好、把高危动作加上二次验证，就能显著降低损失。防线是清晰的，投入产出比也可衡量。

2. 系统越狱的难点：权限开放与漏洞未知

系统越狱面对的是另一类局面。智能体被授予的权限本身就是“使用各种工具、访问操作系统资源”，这是设计意图的一部分。风险恰恰来自这种开放性：工具组合空间巨大，执行路径难以穷举，底层依赖中存在未知漏洞。

具体难点包括：

• 攻击面不可枚举：工具链、运行时、内核、网络策略每一层都可能成为突破口；
• 载荷由模型生成：攻击载荷可能不是外部注入，而是模型“顺手写出来”的代码，绕过了传统基于签名的检测；
• 漏洞的未知性：零日漏洞无法靠规则库覆盖，只能靠隔离与最小权限降低影响面；
• 影响放大：一次成功的越狱可能波及整个训练集群，损失量级远高于一次误分类。

因此，这类问题的治理重心不是“识别输入是否可疑”，而是默认不信任、纵深防御：最小权限、强隔离（容器/虚拟机/沙箱）、系统调用白名单、资源配额与限流、执行前静态审查、执行中行为监控、执行后审计回放。这些手段能降低损失，但很难像输入净化那样给出“把入口管好即可”的简单答案。

3. 两类手段不能互相替代

反诈宣传普及与网络安全基础设施建设都能减少损失，但着眼点完全不同：前者改变的是“人被骗的概率”，后者改变的是“系统被攻破的难度”。同理，样本逃逸的防御经验无法直接迁移到系统越狱上，反之亦然。把两者放在一起比较风险高低或防御优劣，容易得出错误结论。

四、工程落地建议

对企业与开发者而言，更务实的做法是按场景分别建设能力，而不是追求一个笼统的“AI安全”方案。

面向样本逃逸（模型鲁棒性）：

1. 建立输入输出的可观测链路，记录置信度分布与拒答率，作为监控基线；
2. 对高风险判定引入多模型一致性校验与人工复核通道；
3. 对关键业务动作设置二次验证与熔断机制；
4. 定期做对抗评估，把鲁棒性指标纳入模型上线门槛。

面向系统越狱（执行安全）：

1. 默认最小权限，工具按需授权、按次授权，避免长期高权限运行；
2. 执行环境强隔离，配合系统调用过滤与网络出站白名单；
3. 对模型生成的代码与命令做静态审查与沙箱预执行；
4. 补齐资源配额、超时与死锁检测，避免单点异常扩散到集群；
5. 保留完整审计日志，支持事后回溯与影响面评估。

面向组织与沟通：

1. 在安全报告与对外沟通中，明确区分“模型判错”与“权限突破”，避免戏剧化措辞引发误读；
2. 统一术语表，让研发、运维与业务方对“逃逸”的理解一致；
3. 把两类风险分别纳入威胁建模流程，各自设定验收标准。

结语

两类“逃逸”共享一个词，却不共享同一套威胁模型。样本逃逸是模型被输入欺骗，根因在鲁棒性，防线在数据与模型层，入口收敛使其可监控；系统越狱是智能体突破权限边界，根因在隔离与权限设计，防线在系统与运行时层，开放工具链与未知漏洞使其难以单点约束。厘清这一区别，才能把有限的安全投入放在正确的位置上，也才能避免用“管好入口”的思路去应对“开放执行环境”的风险。