给 agent 套一层安全壳，代价有多大

给 AI agent 配上工具，等于给它发了张银行卡。提示注入攻击干的就是骗它刷卡：藏一段指令在网页里，让它转账、删库、外发数据。一篇 10 月 22 日挂上 arXiv 的论文给了个朴素答案——与其求模型嘴上别被骗，不如让卡本身有额度、有审批。

一、发生了什么

论文研究的是大模型 agent 在提示注入下的工具执行安全问题。作者把模型和工具之间的执行层用 Petri 网建模，变成一个监督控制问题：令牌代表能力、审批和预算。一条动作只有在它需要的令牌齐了才能执行——于是一条前置条件不满足、或预算已经花光的注入请求，不管措辞多像正常指令，都会被拦下。

工具执行的结果被当作不可控部分，安全性由最大宽松的监督器保证，论文说在四个假设下这套安全性可以迁移到运行中的系统。

令牌这个设计的关键在于用完即减：预算本身就是额度。给十次调用的活只发十枚令牌，第十一枚没有就是没有，注入请求说什么都变不出来。它拦的不是「话术」，是「资格」，这就是和提示词防御的根本区别。

作者又提出「重规划闭环」：agent 被拒后可能换个说法再来，每次重试都花一次推理调用。在这种循环里，传统监督器可能比一个更严格的安全方案侵入性强得多；针对给定的提议模型，可以构造出最宽松且侵入最小的变体。在自主发布 agent 的案例上，作者用合成方法得出：安全部署必须留一个「开始执行后监督者仍能叫停」的环节。

背景补充：提示注入是把指令藏在网页、邮件或文档里诱导 agent 执行，被多家安全机构列为 agent 时代的主要风险之一。这两年 agent 接上支付、邮件、代码执行后，一次注入造成真实损失的苗头开始出现，执行层防护从论文话题变成了工程刚需。这是背景，不是论文结论。

二、跟你有什么关系

• 给 agent 接工具的开发者：安全不能靠模型自觉，执行层的闸门才是硬约束。
• 企业采购方：评估 agent 产品时，多问一句注入请求怎么拦、被拒后怎么处理。答不出权限模型的供应商，直接划掉。
• 普通用户：授权给得越细，被骗一次的损失越小。

三、怎么判断

1. 问权限模型：能力、审批、预算是不是分开管。三样挤在一个提示词里，等于没管。
2. 看被拒后的行为：agent 被拒立刻换话术重试，说明缺监督层，风险高。
3. 留人工卡点：转账、删除、发布这类不可逆动作，部署里必须有能事后叫停的位置。

四、三个别信的说法

「提示词写得够好就不会被注入」。 错。论文的出发点恰恰是嘴防不住：注入请求换个措辞就绕过模型，只有前置条件不满足这种结构性拦截才可靠。

「安全层越严越好」。 不对。论文显示，在 agent 会反复重试的场景里，宽严拿捏不当会让监督器频繁打断正常工作，侵入性反而失控。安全壳要贴身，不是越厚越好。

「拦下一次攻击就安全了」。 错。安全要在整个执行过程里持续成立，部署方案里得预设叫停点，而不是事后复盘时发现早就晚了。

五、一句话结论

Agent 的安全不在嘴上，在执行层的闸门上。

信息来源

• arXiv 摘要页：面向 agent 的可认证执行层与监督控制，2026-10-22

功能与价格以官方公告为准。本文写于 2026 年 10 月 26 日。