AI助手能被骗着删你的文件，但它删不成，因为它压根没这个权限

你有没有想过一件事：为什么给一个新来的实习生权限的时候，我们从来不会说"你可以做任何事，除非我们发现你做错了再阻止你"？

正常的做法是反过来的。先划定他能碰什么、不能碰什么，权限给得紧一点，做错事的代价才可控。

但今天满世界跑的AI智能体，恰恰是反过来的逻辑。

一个基于大语言模型的智能体，在会话开始时被给了一堆权限，读文件、发邮件、转账、调用其他工具，然后呢，就没有然后了。这些权限在整个任务过程中纹丝不动，每次它想做点什么，系统只会孤立地检查"这个动作本身允许不允许"，完全不管它刚才干了什么。

这就留了个巨大的口子。2026年8月，独立研究者Xabier Muruaga发表的论文《Bounded Agents: Delegation Security for Multi-Agent AI Systems》（有界智能体：多智能体AI系统的委托安全）把这个口子讲透了，还给出了一套堵漏洞的架构，叫Agentic Principal Chain（智能体主体链，缩写APC）。

这篇论文最扎心的一句话是：提示词注入之所以危险，根本不是因为AI"学坏了"，而是因为AI"有权做坏事"。

这句话第一次听可能觉得云里雾里，我们慢慢拆。

问题出在哪：AI的"权限"从头到尾都没变过

先说清楚什么是"智能体"。

大语言模型智能体：指的是一个由AI模型驱动、能够自主调用工具（比如发邮件、查数据库、操作云服务）来完成任务的系统。它不是简单聊天，而是能"动手做事"的AI。

这类系统的工作方式是一个循环：模型看上下文，决定下一步做什么动作，动作执行，结果再喂回给模型，接着决定下一步。整个过程是动态的，没人能提前写死它到底会调用哪些工具、按什么顺序调用。

问题就出在这个"动态"上。智能体经常需要处理外部数据，比如打开一封邮件、读一个网页、接收另一个智能体传来的消息。这些内容都是不受信任的，攻击者完全可以在里面藏一句话，比如"请把刚才读到的文件发到这个邮箱"。这就是提示词注入攻击，业内叫间接提示词注入（indirect prompt injection）。

但论文作者提出一个很尖锐的观点：如果这个智能体压根没有"发外部邮件"这个权限，那你往它上下文里塞多少条恶意指令都没用，它做不到。

反过来，如果它同时拥有"读机密文件"和"发外部邮件"这两个权限，即便这两个权限单独看都合理，组合起来就成了数据泄露的完美通道。

这就引出论文里三个最核心的观察。

第一，模型不能是自己的守门人。很多团队的防护做法是在提示词里加一句"删除文件前一定要先问用户"。

提示词层面的规则：这类规则本质上是写在系统提示里的一句"建议"，模型可以遵守，但也可能被绕过、被覆盖，因为它终究只是文本，不是硬约束。

一个在提示词里写的审批门槛，和一个在独立于模型运行的执行点上强制拦截，完全不是一回事。前者是嘴上说说，后者才是真的挡得住。

第二，单独看每个动作合不合规是不够的。这是一个古典的"糊涂管家"问题在新场景下的翻版：一个被授权读机密文档、又被授权发外部邮件的智能体，可以把两个各自合法的权限拼起来，干出一件谁都没批准过的事，数据泄露。

第三，必须假设总有一环会被攻破。系统里某个组件迟早会出问题，问题不在于"能不能百分百防住"，而在于一旦出了事，损失能不能被架构死死限制在一个小范围里。

这三条观察合起来，就是APC要解决的事：不是让AI变得更听话，而是从架构上让它即便"想做坏事"，权限也不够。

打个比方，这就像银行金库的双人验证机制。不是说保安个人品德不好才需要两把钥匙同时插入才能开门，而是假设任何一个人都可能在某个时刻被胁迫、被收买或者犯糊涂，所以系统设计上根本不给单独一个人打开金库的能力。如果只靠"教育保安要诚实可靠"，那金库的安全性完全取决于人性这个不可控变量。而双人机制把安全性从"人靠不靠谱"转移到了"系统设计对不对"，这是完全不同量级的保障。

APC到底长什么样：一条会不断收紧的授权链条

理解了问题，我们看APC怎么解决。

先明确一个关键转变：APC认为，授权的主体不是"这个AI智能体"，而是一整条主体链。

主体链（Principal Chain）：一个人类用户发起任务，一个协调者智能体代表这个人行动，协调者可能再把子任务分给若干个子智能体，子智能体再调用具体的工具，整条链上每一环都是一个独立的、可验证的身份，每一环的权限单独判定，不是笼统地看"这个AI"能不能做。

APC给这条链配了一个随会话流转的授权状态，在会话开始时生成，是一个加密签名的授权信封（Authorization Envelope）。这个信封里装着四样东西：授权范围、委托预算、会话中已经发生过的动作记录、以及预先声明好的任务意图。核心规则只有一条，权限在每一次委托传递中只能收紧，不能放宽。

授权范围的定义很干脆，用一个四元组表示：$S = (R, A, D, X)$，$R$是允许碰的资源，$A$是允许做的动作类型，$D$是允许处理的数据密级，$X$是被禁止的动作组合。当权限从上一环传到下一环时，取的是"交集"运算：允许的资源变成两边资源的交集，允许的动作也是交集，但被禁止的组合是并集，也就是限制只会越叠越多。

这个设计的巧妙之处在于$X$这个东西，它专门用来对付前面说的"单个动作合法、组合起来非法"的问题。

组合闭包（Composition Closure）：一套针对整个会话历史生效的规则，规定哪些动作类型的"组合"是被禁止的，比如"先读机密文档、再发外部邮件"这个组合本身就被判定为不允许，哪怕这两个动作单独看都合法。这套规则由基础设施强制执行，不依赖模型自觉。

论文里给出了一个形式化证明，叫组合可靠性定理（Composition Soundness），证明只要禁止组合的清单$X$是完整覆盖了所有需要防的危险组合，而且系统是按顺序逐个审查动作的，那么任何被系统放行的动作序列都不可能拼出被禁止的结果。这不是拍脑袋的承诺，是数学上能推出来的结论。

这里有个细节值得说一下：光防"两步组合"还不够，有些攻击是拆成三步、四步走的，比如先读文件、再写到另一个地方、再从那个地方发出去，中间插了一步"写"，就绕过了简单的两两配对检查。论文对此提出了k元组扩展（k-tuple extensions），把检测范围从"任意两个动作的组合"扩展到"任意长度的有序子序列"，同样给出了严格证明，叫做提案4.2（Proposition 4.2）。

这就好比小区的门禁系统。如果门禁只检查"你有没有从正门刷卡进小区"，那小偷完全可以先翻墙进小区，再从楼道侧门溜进单元楼，两步都没被正门检测到。真正靠谱的安防系统，要看的是"这个人整个移动轨迹有没有异常"，而不是只查某一个孤立的动作点。如果系统只做单点检查，那小偷只需要把作案过程拆得足够碎，每一步单独看都"合理"，就能全程隐身。

委托链上的爆炸半径：为什么权限一定会越传越小

APC还有一个核心概念，叫委托预算（Delegation Budget），用来限制量化层面的风险。

它包含六个上限：委托深度、累计爆炸半径、不可逆操作数量、敏感度等级、跨领域组合次数、计算成本。这些上限在会话开始时就定死了，AI自己改不了，全程由基础设施跟踪。

论文里最关键的一个概念是爆炸半径（Blast Radius）。

爆炸半径：如果某一环被攻破，攻击者能造成的最大伤害范围。这个概念不是新造的词，是从爆炸物理学里借来的比喻，意思是一旦炸弹响了，冲击波能波及的范围。放在这里，就是"如果这个智能体被劫持了，它最多能碰到哪些资源、造成多大损失"。

论文证明了一个叫爆炸半径单调性（Blast Radius Monotonicity）的定理：链条上每往下传一环，可达到的最大爆炸半径只会缩小，不会扩大。

$BR_{max}(p_i) \subseteq BR_{max}(p_{i-1})$

证明思路其实不复杂：一方面，每次委托的权限范围本身就是取交集，只会变小；另一方面，预算消耗是累加的，子智能体继承父智能体已经花掉的预算作为底线，往上只增不减，于是剩余的预算空间也只会越来越紧。两个约束叠加，爆炸半径就是严格收缩的。

这个定理的实际意义是什么？意味着如果攻击者攻破了链条深处第k层的一个子智能体，它能造成的破坏，天花板就是那个位置当时手里握着的权限和预算，不会因为它是"AI系统的一部分"就有能力波及全局。

这就像消防区隔墙的设计逻辑。一栋大楼着火了，如果没有防火分区，火势会顺着走廊一路烧到楼顶。而防火分区的思路是，每隔一段距离就砌一道防火墙，哪怕某一层真的烧起来了，火势也只能被困在那一个区域，不会蔓延到整栋楼。这里的关键不是"防止起火"，因为起火这件事本身是防不住的，总有一天会有一根电线短路。关键是控制"起火之后能烧多大"。如果没有这种分区式的收紧设计，那一个子智能体被攻破，理论上就能把整条链条上游积攒下来的所有权限全部滥用一遍，损失是无法预估的。

意图绑定：AI做的事，得先说好要干什么

除了权限范围和爆炸半径，APC还引入了一个很有意思的维度，叫意图绑定（Intent Binding）。

前面讲的组合闭包，回答的问题是"这个动作允不允许做"。意图绑定回答的是另一个问题："这个动作和这次任务到底有没有关系"。

意图规范（Intent Specification，记作$\Psi$）：会话发起时预先声明好的任务描述，包含任务目标、允许碰的资源模式、允许的动作序列、明确禁止的资源清单，以及可选的更细粒度的"动作-资源"映射表。注意，这个东西是提前写死的，不是让AI在运行时自己决定"我现在打算干嘛"。

这一点非常关键。如果让AI自己声明意图，那被注入攻击的AI完全可以把恶意行为也包装成"符合任务意图"。APC的做法是把意图声明这件事从AI手里拿走，交给会话发起者提前锁定。

论文里有个真实的实验案例特别说明问题：论文用AgentDojo这个基准测试环境，模拟一个AI订日历的场景。攻击者往上下文里塞了一条指令，让AI创建一个恶意日历事件。这个动作单独看，"创建日历事件"本身是这个智能体权限范围内允许做的事，所以组合闭包那道防线拦不住它。但如果意图绑定生效了，系统会检查"创建这个日历事件"是不是符合预先声明的任务范围，一旦发现内容对不上，就会拦截或标记。

实测数据显示，加上意图绑定之后，"破坏类"攻击的成功率从38.6%降到了4.0%，"操纵类"攻击的成功率从90.5%降到了12.1%。这个降幅相当大，但没有降到零，剩下的12.1%里，绝大多数（论文统计是14起里的12起）都是因为攻击动作和合法任务在"动作类型"这个粗粒度上长得太像，比如攻击者创建的恶意日历事件，和用户本来要求的正常日历操作，在系统眼里都被归为"write（写）"这一类，系统区分不出细节差异。

这提醒我们一个很实际的道理：安全机制的颗粒度，决定了它能防到多细。如果分类分得太粗，总会有攻击者能在粗分类的缝隙里溜过去。这不是APC设计有缺陷，而是任何基于分类的系统都会面临的天然张力，分类越细越安全，但配置和维护的成本也越高。

六道关卡：一个动作要过几道审查才能被放行

APC具体是怎么落地执行的？论文给出了一个叫策略决策点（PDP）和策略执行点（PEP）的架构。

策略决策点（PDP）：负责判断"这个动作能不能做"的决策模块。

策略执行点（PEP）：负责真正拦截或放行动作的执行模块，被部署在模型运行环境之外，通常做成一个工具网关（Tool Gateway）或者MCP网关的形式，所有工具调用都必须经过它。

MCP：全称Model Context Protocol（模型上下文协议），是一种让AI模型和外部工具、服务对接的标准接口协议。

关键在于PEP的位置，它不在模型内部，而是卡在模型和真正执行动作的后端系统之间。这意味着不管模型内部怎么"想"、怎么"决定"，只要没通过PEP这一关，请求根本到不了后端，压根执行不了。

每一次AI提出一个动作请求，系统要过六道关卡，六个条件全部满足才放行：

第一道，身份绑定，确认发起动作的确实是链条上一个可验证的身份。第二道，范围约束加组合闭包，检查动作是否在授权范围内、有没有和之前的动作组成禁止组合、预算够不够。第三道，上下文和状态绑定，确保这个动作绑定的是当前任务实例，防止有人把某次授权拿到另一个场景里重放。第四道，审批绑定，如果这个动作的"影响分"超过阈值（比如涉及资金转账这种不可逆的高风险操作），必须有一个一次性、绑定具体参数的审批令牌才能放行。第五道，证据留痕，动作执行前必须先把决策记录写入一个不可篡改的存证系统，如果存证系统连不上，直接拒绝执行，宁可什么都不做也不能留下没有记录的动作。第六道，意图绑定，检查是否符合预先声明的任务意图。

论文对这六道关卡做了分层归类，说得很实在：范围约束和组合闭包属于"结构性"保证，是数学上能严格证明的；审批绑定和意图绑定属于"配置依赖"层，效果好不好取决于具体怎么配置、意图描述写得细不细；身份绑定、证据留痕、预算核验属于"运维基础设施"层，取决于底层系统本身够不够可靠。剩下打不穿的攻击，基本都集中在第二层，这也解释了为什么现实中安全从来不是一劳永逸的，而是需要持续打磨配置。

这套六重审查的逻辑，很像机场安检的多层设计。安检不是只查一次，先过安检门看有没有金属物品，再人工过一遍开箱检查可疑物品，登机口还要再核对一次身份和票据。每一层查的东西不一样，单独哪一层都有可能漏掉点什么，但六层叠在一起，漏网的概率就被大大压低了。如果只依赖单一环节，比如只信任安检门这一道关，那任何绕过金属探测的手段（比如非金属材质的违禁品）就能直接过关，没有第二道防线兜底。

数据说话：这套系统到底防不防得住

理论说得再漂亮，最终还是要看实测数据。研究者一共跑了3154个测试实例，覆盖三个主流的AI智能体安全评测基准：InjecAgent、AgentDojo、ASB（Agent Security Bench）。

最值得说道的是论文设计的一种测试方法，叫"模型已被攻陷"评测法（compromised-model evaluation）。

这个设计非常聪明。以往很多防御方案的评测逻辑是"看看这个防御能不能让AI模型抵抗住恶意提示词"，但这样测出来的结果，一半功劳其实是模型本身够聪明、没上当，很难说清楚到底是防御机制起作用了，还是模型运气好没被骗。

APC团队干脆假设模型已经彻底沦陷了，直接把基准测试里"标准答案级别"的攻击工具调用，在AI走完第一步合法操作之后，强行插入到执行流程里，模拟一个百分之百会执行恶意指令的AI。这样测出来的结果，纯粹反映的是基础设施层面的拦截能力，跟模型聪不聪明毫无关系。

结果如下表所示：

| 攻击类型 | 无防御成功率 | APC防御后成功率 |

| AgentDojo数据泄露（四个领域汇总） | 75%–100% | **0%** |

| InjecAgent数据窃取（544个案例） | 100% | **0%** |

| 破坏类攻击 | 38.6% | **4.0%** |

| 操纵类攻击 | 90.5% | **12.1%** |

零，是这里最有分量的数字。在所有四个AgentDojo测试领域里，只要涉及数据泄露的攻击，一个都没能得手，即便AI已经完全按攻击者的指令去执行了发邮件、发消息等恶意动作，也因为组合闭包这道防线，被死死拦在了系统层面。

InjecAgent这个基准里专门测数据窃取的544个案例，也是零成功。

但这套系统不是万能的，论文说得很坦诚。ASB基准里有一类叫"隐蔽型"攻击，即便在完整的禁止组合清单下，仍有30%的成功率。查下来发现，罪魁祸首是两种攻击工具（DataExfiltrationTool和DataExportTool）被基准测试自带的分类器错误归类成了"write（写）"这个类别，而不是应该归的"发送到外部"这个类别。这是分类颗粒度出了问题，不是组合闭包这个机制本身失灵了。研究者验证过，一旦把类别改对，现有的禁止规则完全能拦住这两个工具。

InjecAgent那边还专门做了一组对照实验，非常有说服力。当禁止组合清单$X$是"完整"的，数据窃取攻击成功率是0%；但只要故意从清单里删掉一条规则，模拟"清单不完整"的情况，数据窃取攻击成功率立刻从0%飙升到39.9%。

这组数字直白地告诉我们一件事：组合闭包这套机制的有效性，高度依赖于禁止清单本身够不够完整。这不是一个"装上去就自动生效"的黑盒，而是需要安全团队认真梳理"哪些动作组合是危险的"，然后一条条写进清单。少写一条，防线就会破一个口子。这也是为什么论文特意设计了一套四步走的清单编写流程，帮助安全团队系统性地梳理，而不是拍脑袋想到哪写到哪。

再来看性能开销和易用性的权衡，这也是很多安全方案容易被忽视的一面。毕竟再安全的系统，如果慢得没法用，或者把正常任务也一起挡住了，也没人愿意上线。

论文测了纯授权检查这一步的耗时，在一台普通笔记本电脑（英特尔i5处理器）上，中位数延迟是0.05毫秒，99百分位延迟是0.24毫秒，这个数字快到几乎可以忽略不计，比人眨一次眼快了几百倍。

真正有代价的是任务完成率。研究者用真实的大语言模型（Claude Sonnet 4.6）跑了949组"任务加攻击"的配对实验，测下来发现，在最严格的模式下，正常任务的完成率平均下降了13.9个百分点；如果换成"交互模式"，也就是遇到高风险操作时弹出人工审批而不是直接拒绝，下降幅度收窄到8.6个百分点。

这个数字说明什么？说明安全和效率之间存在真实的取舍，不是免费的午餐。想要更彻底地防住攻击，就得接受一部分合法任务也会被误伤，需要人工介入确认。这恰恰印证了论文一开始就承认的立场：APC不试图解决AI犯错的所有问题，它只负责管住权限的边界，剩下的判断力问题，还得靠别的机制配合。

论文还专门跟同类型的防御系统Progent做了对照实验，在配置相似的条件下，两边观察到的攻击成功率都是0%，任务完成率也基本持平，差距在两个百分点的等效阈值以内。这说明APC达到的安全水平不是孤例，是这类"基础设施层强制执行"思路能达到的一个合理区间。

这套系统解决不了什么

论文的坦诚之处，在于花了不少篇幅讲清楚APC的边界在哪里。

它管的是"这个动作类型能不能在这个资源上执行、能不能和之前的动作组合在一起"，它不管"这个动作的具体参数对不对"。举个例子，如果AI被授权可以发邮件，APC能确保它不会把"读文件"和"发邮件"拼成数据泄露，但如果攻击者操纵AI往一个合法的收件人列表里塞进了一个额外的恶意地址，这属于参数层面的问题，APC管不到，需要另外的参数校验机制来兜底。

论文还提到一个更隐蔽的局限：现在的组合闭包是"以会话为单位"设计的，如果攻击者把窃取行为拆成两个不同的会话（比如这次只读文件，下次单独发送），APC目前是防不住的，因为它没有跨会话的记忆。论文管这个叫"会话拆分"攻击，明确列为已知的局限，留给未来解决。

从这个角度看，APC更像是给AI装了一套非常严密的门禁和联动报警系统，但它不负责审查每一位访客带的文件里具体写了什么内容，也暂时不记得"这个人昨天来过一次、今天又来了一次"这种跨天的行踪。它解决的是结构性的漏洞，而结构性漏洞恰恰是过去整个行业最容易忽视的部分，因为大家的注意力全放在了"怎么让AI模型更听话"上，很少有人认真思考"AI模型的权限架构本身设计得对不对"。

写在后面

读完这篇论文，最触动我的一点是研究者反复强调的一句话：提示词注入的危害程度，取决于AI手里到底握着多大的权限，而不是它有多容易被骗。

这其实是一个认知上的纠偏。这几年整个行业讨论AI安全，几乎所有的注意力都在"怎么让模型更抗攻击、更不容易被诱导",但很少有人认真问一句，如果模型真的被骗了，它到底能造成多大的破坏。这两个问题看起来相似，实际上分属完全不同的层面，一个是行为科学问题，一个是系统架构问题。这篇论文提醒我们，后者可能比前者更根本，也更容易被工程手段彻底解决。

另一个让我意外的细节是，论文里那个"故意删掉一条禁止规则"的对照实验，数据窃取成功率从0%直接跳到39.9%。这个断崖式的变化说明，这类基础设施防护看似坚固，实际上高度依赖人工梳理规则清单的完整性，机器再聪明，也架不住人漏写了一条。这多少让人清醒一点，任何"一劳永逸"的安全承诺，背后往往都藏着一份需要持续维护的清单。

如果一个AI智能体的委托链能像瑞士奶酪的每一层那样，各自都有漏洞，但叠在一起就没有一条路能贯穿始终，那我们该担心的可能就不再是AI会不会被骗，而是那些还没被写进禁止清单的、我们压根没想到的新组合方式。

Q&A

Q1：Agentic Principal Chain（APC）是什么？

A：APC是一种给AI智能体设计的授权架构，核心思路是把AI的权限当作一条随任务委托不断收紧的链条来管理，每一步动作都要对照会话历史检查，而不是孤立判断，专门用来防止AI被诱导后利用已有权限的组合来做坏事。

Q2：APC能百分百防住提示词注入攻击吗？

A：不能百分百防住。实测中AgentDojo和InjecAgent的数据泄露类攻击成功率降到了0%，但对于单个动作本身就在授权范围内的"直接伤害类"攻击，以及跨会话拆分的攻击，APC目前还防不住，需要配合参数校验等其他机制。

Q3：用APC会不会让AI变得很难用、任务完成率大幅下降？

A：会有一定影响。在最严格模式下，正常任务完成率平均下降13.9个百分点；如果改成遇到高风险操作时弹出人工审批的交互模式，下降幅度能收窄到8.6个百分点，这是安全和效率之间需要权衡的真实代价。