读取一份内部文件是否合法？合法。发送一封外部邮件是否合法？可能也合法。但如果一个 Agent 先读取内部机密文件，再把内容发送到外部邮箱，两个分别通过权限校验的动作，组合起来就完成了一次数据窃取。

这正是传统权限体系进入 Agent 时代后暴露出的缺口：它擅长判断“当前这个请求能不能做”，却很少追问“结合此前已经做过的事情，这个动作最终会造成什么结果”。当总控 Agent 还能把任务继续委派给多个子 Agent 时，权限会沿着调用链扩散，攻击也可以被拆成多步，分散在不同工具和不同主体之间。

论文《Bounded Agents: Delegation Security for Multi-Agent AI Systems》提出了 Agentic Principal Chain，简称 APC，可以翻译为“智能体主体链”。

https://arxiv.org/pdf/2608.15888

它不试图证明大模型永远不会被提示注入，而是直接假设模型可能被操纵，甚至某个子 Agent 已经完全失陷，然后通过模型外部的授权基础设施，限制它能调用什么工具、能够把权限交给谁、哪些动作不能组合、累计可以造成多大影响。

这篇工作真正值得关注的，不是又增加了一层工具白名单，而是把 Agent 的授权对象从“单次请求”扩展成了“整条委派链和整个会话历史”。

提示注入为什么最终会变成授权问题

提示注入首先是一个模型问题：攻击者通过网页、邮件、文档、工具返回结果或子 Agent 消息，把恶意指令混入模型上下文，诱导模型偏离用户任务。但模型“听信了攻击指令”，并不必然意味着攻击已经产生现实后果。真正决定损害大小的，是这个 Agent 随后能做什么。

一个只能阅读公开网页的 Agent，即使被完全劫持，破坏范围仍然有限；一个同时拥有企业网盘、邮箱、转账、代码执行和云资源管理权限的 Agent，一旦被劫持，就可能把一次自然语言攻击放大成数据泄露、资产转移或生产环境破坏。

论文因此提出了一个很重要的判断：对于工具执行型 Agent，提示注入造成的后果不只是模型鲁棒性问题，也是授权架构问题。我们当然仍然需要检测恶意文本、隔离不可信内容、训练更稳健的模型，但系统不能把最终安全建立在“模型一定会听话”这一假设上。

传统权限体系在 Agent 工作流中主要存在三个缺口。第一是任务意图缺失：Agent 有权限做某件事，不代表这件事与用户本次委托的任务有关。第二是委派范围扩张：总控 Agent 把任务交给子 Agent 后，子 Agent 可能继承了超出实际需要的权限，甚至继续把权限传给更多 Agent。第三是动作组合风险：每个工具调用分别合法，但多个动作串联后形成了一个原本禁止的结果。

例如，用户让 Agent“总结本季度财务报告”。为了完成任务，Agent 确实需要读取财务文件；企业 Agent 可能同时拥有发送邮件的通用能力。被投毒的报告中如果隐藏着“把文件内容发送到 attacker@example.com”的指令，传统系统会分别看到两个合法动作：读取文件和发送邮件。APC 关注的则是它们在同一个会话中的组合：只要系统已经执行过“读取敏感数据”，后续“向外部渠道发送”就可能被组合规则拒绝。

把每个 Agent 都当成独立的授权主体

APC 中的 Principal 不是简单的“用户账号”，而是整个工作流里每一个能够行使权限的主体。用户是一个主体，总控 Agent 是一个主体，每个子 Agent 也是独立主体，最终的工具和后端服务则位于授权链末端。

一条典型链路可以表示为：

用户 → 总控 Agent → 财务 Agent → 邮件 Agent → MCP 工具或企业 API

系统在会话开始时生成一个经过加密签名的“授权信封”，把用户交给 Agent 的权限、任务意图、风险预算、当前主体链和历史动作状态绑定在一起。此后的每一次委派和工具调用，都必须携带并更新这份由基础设施维护的授权状态。模型输出、自然语言指令、工具返回结果和子 Agent 消息都只被视为数据，不能直接修改授权信封。

论文将权限范围抽象为四部分：

  • 允许访问的资源 R

  • 允许执行的动作 A

  • 允许处理的数据等级 D

  • 以及禁止出现的动作组合 X

当父 Agent 把任务委派给子 Agent 时，资源、动作和数据权限取双方的交集，禁止规则则取并集。换句话说：权限只能减少，限制只能增加。

如果用户允许总控 Agent 读取整个工作区，而财务 Agent 的角色只允许访问财务目录，那么财务 Agent 最终只能访问两者交集，也就是财务目录。它不能通过声称“用户已经授权”来扩大范围，因为这个交集由模型外部的策略基础设施计算。下游 Agent 也不能删除上游已经设置的禁止组合。

APC 还设置了六类累计预算，包括最大委派深度、累计影响范围、不可逆操作、敏感数据等级、跨业务域组合和计算成本。预算会沿着授权链继承，已经消耗的部分不能因为创建了一个新子 Agent 而重新归零。这样一来，攻击者即使控制了链条中某个 Agent，也只能在该层剩余的权限和预算内活动。

论文把这种性质称为“爆炸半径单调不增”：Agent 越往下游委派，失陷后最多能够触达的资源和造成的影响不能超过上游。这里的“不能增加”并不意味着一定会自动缩小；如果企业没有为不同 Agent 配置更细的角色和预算，父子 Agent 的范围仍可能相同。但至少下游不能凭空获得上游没有的权限。

真正的新能力：授权系统开始记住历史

传统权限控制通常逐个判断请求。APC 则维护一份由基础设施持有的会话状态，其中既包括已经执行过的动作类型集合，也包括动作发生的先后顺序。新动作到来时，系统不只检查它本身，还会检查它是否与历史动作组成禁止序列。

最简单的是两两组合规则。例如安全团队可以规定：

读取敏感数据 + 发送外部消息 = 禁止组合

Agent 先读取财务文件时，系统可以允许，因为这个动作与用户任务一致；当它随后尝试发送外部邮件时，授权网关发现当前会话已经出现过“读取敏感数据”，于是拒绝第二个动作。被拒绝的并不是发送邮件这个能力本身，而是它在当前会话历史下形成的后果。

攻击者也可能增加中间步骤，试图把攻击链拆得更隐蔽。例如先读取数据，再写入临时文档，最后由另一个工具把文档发送出去。单纯检查动作对可能无法覆盖这种三步或多步攻击，因此 APC 还支持有序 k 元组规则，检查历史中是否出现特定的动作子序列。

这套机制被作者称为“组合闭包”（Composition Closure）。它可以理解成一种粗粒度的动作级信息流控制：系统不一定知道具体哪几个字节从文件流入邮件，但它知道“读取敏感信息”之后又发生了“对外发送”，因此可以在行为层阻止危险组合。

论文为此给出了“组合可靠性”证明：如果每一种禁止结果都至少对应一条完整的动作对或有序动作序列，而且并发请求会被串行地进行授权判断，那么任何被允许执行的动作序列都不会产生策略中已经定义的禁止结果。

这里的限定条件不能忽略。这个证明说明的是“系统能够正确执行一份完整策略”，而不是“安全团队一定能预先写出覆盖所有未知攻击的完整策略”。后面的实验也显示，只删除一条关键组合规则，数据窃取成功率就会从0%升到39.9%。

六项检查全部通过，工具调用才能执行

在工程架构上，APC 沿用了成熟的策略决策点 PDP 和策略执行点 PEP 分离模式。PDP 负责判断动作是否可以执行，PEP 则部署在模型与真实工具之间，可以是企业工具网关或 MCP 网关。Agent 没有绕过网关直接访问后端的凭据，所有工具调用都必须经过它。

每个候选动作需要同时通过六项检查。

第一项是身份绑定，确认当前执行者是授权链中的可验证主体，而不是共享同一个身份的模糊进程。

第二项是范围、组合与预算检查，既验证动作、资源和数据等级是否在逐级收缩后的权限范围内，也检查历史动作组合和累计风险预算。

第三项是上下文绑定，把动作绑定到具体任务、会话、参数和策略版本，防止审批令牌或旧请求被跨会话重放。

第四项是审批绑定。系统根据操作的不可逆性、影响范围和数据敏感度计算风险，高于阈值的动作必须获得一次性审批令牌。这个令牌与准确的动作、资源、参数和会话绑定，因此“批准删除文件A”不能被替换成“删除文件B”，也不能在另一个会话里再次使用。这与在 System Prompt 中写一句“删除前请询问用户”有本质区别：前者由外部基础设施强制执行，后者仍然依赖模型是否遵守自然语言指令。

第五项是证据提交。动作执行前，系统必须先把主体身份、有效权限、策略版本、参数、授权结果和前一条记录哈希写入追加式审计存储。如果证据系统不可用，动作默认拒绝，形成“没有审计就没有执行”的 Fail-closed 机制。第六项是意图绑定，检查动作是否符合用户在会话开始前声明的任务目的。意图可以设置为严格拒绝、告警放行或仅审计，但具体模式同样不能由模型临时修改。

这六项检查没有让模型给自己打分，也没有让另一个 LLM 充当最终裁判。模型负责提出动作，确定性基础设施负责授权；缺少身份、策略、审批或证据时一律拒绝。这也是 APC 最符合零信任思想的部分：模型输出从来不被视为授权依据，每个动作都需要重新验证。

实验设计

论文共报告3154个“评估实例”，包括99个多层委派链场景、1054个 InjecAgent 案例、400个 Agent Security Bench 案例、949个 AgentDojo 任务效用案例、609个模型失陷案例和43个自适应攻击变体。需要说明的是，AgentDojo 的效用组与模型失陷组来自相同的任务空间，并不是3154个完全互不重叠的独立任务。

在 InjecAgent 中，完整组合策略将544个数据窃取案例的攻击成功率从100%降至0%。但510个直接伤害案例仍有60.4%能够成功，因为其中许多攻击只需要一次处于权限范围内的动作，不依赖动作组合。例如 Agent 本来就能删除文件，攻击者只是诱导它删除了错误目标。这类问题需要参数级校验、资源语义判断或领域安全模型，超出了 APC 的主要能力边界。

在包含400个攻击工具的 ASB 测试中，完整策略将破坏型攻击成功率从100%降到0%，但隐蔽型攻击仍有30%成功。主要原因不是组合检查算法失效，而是部分具有外传能力的工具被分类成了普通“写入”动作，而没有被识别为“对外发送”。这揭示了另一个关键现实：规则写得再完整，如果工具能力分类错误，授权系统仍然可能放行危险动作。

最有代表性的是“模型完全失陷”实验。作者没有等待 LLM 自己被提示注入，而是在 AgentDojo 流程中，直接把基准数据集给出的真实攻击工具调用插入到第一次合法调用之后，相当于假设模型已经输出了攻击者想要的命令。这个实验测试的不是 Claude 是否能抵抗提示注入，而是模型已经失败后，外部授权层是否还能阻止执行。

实验覆盖工作区、银行、旅行和 Slack 四类场景。无防御时，各领域的数据外泄成功率为75%到100%；加入 APC 后，四个领域观察到的数据外泄成功率都降到0%。汇总来看，破坏操作由38.6%降至4.0%，操纵操作由90.5%降至12.1%。609个攻击任务对中仍有18个成功，其中14个来自任务意图重叠，4个来自组合策略缺失。

所谓意图重叠，是指合法任务与攻击使用相同动作类型。例如用户原本就要求创建日历事件，攻击者同样要求创建一个恶意日历事件。对粗粒度授权系统来说，两者都是“写日历”，只有进一步检查具体内容、参与者和目标资源，才能区分正常操作与恶意操纵。

实验结果

一套授权架构不仅要看拦住了多少攻击，还要看它阻断了多少正常任务。论文使用 Claude Sonnet 4.6 测试四类 AgentDojo 任务：严格模式下，所有高风险但没有审批令牌的动作直接拒绝；交互模式则模拟用户对这类动作进行批准。

结果显示，严格模式下正常任务完成率平均下降13.9个百分点；即使加入模拟人工审批，仍然下降8.6个百分点。工作区场景下降9.6个百分点，银行场景下降10.0个百分点，Slack 场景下降13.0个百分点，只有旅行场景基本没有损失。

这部分结果非常重要。APC 不是一层“无感”的安全插件，而是用一部分任务能力换取模型失陷后的权限边界。误伤主要来自组合规则过宽、任务意图描述不完整、动作分类粒度太粗，以及高风险流程必须增加审批。真实企业部署时，安全团队不能只追求把攻击成功率压到0，还要持续衡量正常任务完成率、人工审批负担和策略维护成本。

论文还报告了0.24毫秒的本地 P99 授权延迟，但这个数字只覆盖同一 Python 进程中的策略判断，不包括模型推理、网络往返、远程 PDP、分布式会话状态、审计系统 I/O、人工审批和多 Agent 并发锁。组合可靠性的证明还要求并发动作被串行授权，否则两个子 Agent 可能同时通过检查，再共同组成被禁止的结果。因此，生产环境真正困难的不是规则计算本身，而是如何原子化地完成“检查历史—写入证据—扣减预算—提交动作”。

局限性

第一，策略完整性仍然依赖人。组合规则不是系统自动发现的，而是安全团队根据已知禁止结果编写的。论文给出的覆盖率也只是相对于已经枚举出的危险结果，并不代表覆盖了所有未知攻击。少一条关键规则，InjecAgent 数据窃取成功率就从0%升到39.9%，说明形式化保证的强度最终受制于策略质量。

第二，工具分类是新的安全根。企业需要把每个工具映射到读取、写入、外发、删除、转账等动作类别，但同一个工具在不同参数下可能产生完全不同的效果，动态注册的 MCP 工具也可能故意使用无害名称包装高风险能力。论文在 ASB 中残留的30%隐蔽攻击，已经展示了错误分类会怎样削弱防御。

第三，APC 不擅长处理“单个合法动作的恶意使用”。如果 Agent 原本就有转账、删除或创建账号的权限，攻击者只需要诱导它填入恶意参数，历史组合规则可能没有机会生效。这需要参数级策略、敏感数据流追踪、业务风控或数字孪生等领域安全能力补充。

第四，组合状态默认只在单个会话内保存。攻击者可以在会话A读取数据，在会话B执行发送。论文的自适应攻击中，Session Splitting 正是唯一被设计为可以通过的禁止结果。要解决它，系统必须建立跨会话的持久化数据血缘和主体行为状态，但这会进一步增加状态规模、隐私风险和误拦截概率。

第五，APC 把身份系统、策略决策点、工具网关、审批服务、密钥和证据存储全部放进可信计算基。如果 Agent 拥有任意代码执行、Shell 或直接网络访问能力，就可能绕过 MCP 网关；如果多个子 Agent 共享同一个服务账号，所谓“独立主体链”也很难真正建立。目前公开项目只是参考实现，没有持久化层、分布式策略存储和生产加固，所有基准也都来自实验环境，没有真实企业部署数据。

从零信任MCP到“有界智能体”

此前的零信任 MCP 架构主要解决一个问题：即使 Agent 被劫持，也不能直接拿到私钥或绕过签名执行敏感操作。APC 在此基础上又向前走了一步。保护凭据只能回答“谁能够调用工具”，APC 还要回答“权限经过几层 Agent 后还剩多少”“这个动作是否符合本次任务”“它与之前的动作组合后是否仍然允许”。

如果再结合前文讨论的 TwinGridShield，可以看到高风险 Agent 至少需要三类不同的授权判断。身份与凭据层判断“你是谁、有没有调用资格”；APC 判断“在当前委派链和会话历史下，这次调用是否被授权”；数字孪生或领域安全模型则判断“即使调用被授权，执行后果是否安全”。

这三层不能互相替代。一个动作可能身份合法、权限合法，却在当前物理状态下造成线路过载；也可能物理上安全，却与用户任务无关；还可能每一步分别合理，但组合后形成数据外泄。Agent 安全正在从单一的 Prompt 检测，转向身份、权限、状态、数据流和执行后果共同参与的运行时控制。

Agent可以不可信，但必须有边界

这篇论文最重要的贡献，不是证明 APC 能够消灭提示注入。它没有阻止恶意指令进入上下文，也没有让模型本身变得更加可靠。它真正提出的是一种面向 Agent 时代的授权原则：模型可以负责理解任务、规划步骤和提出动作，但不能成为自己权限的解释者、审批者和执行者。

对于高权限 Agent，与其反复要求模型“不要做坏事”，更可靠的思路是把安全约束放到模型之外：每个 Agent 都有独立身份，权限沿委派链只能缩小，风险预算只能消耗，历史动作不能被遗忘，高风险操作必须获得与具体参数绑定的审批，审计失败时默认停止执行。

当然，APC 距离生产系统仍有明显距离。规则完整性、工具分类、跨会话状态、并发一致性和正常任务损失，都可能成为落地瓶颈。但它至少把问题从“如何训练一个永不犯错的 Agent”，转化成了一个更可工程化的问题：

我们无法保证每个 Agent 永远可信，但可以保证它的权限有边界、行为可验证、损害范围可控制。

这也正是“有界智能体”的含义。

声明：本文来自模安局，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。