无人书写的工具调用授权层

你的 API 网关验证了用户身份。你的工具端点会检查用户是否有权删除该行。在这两次检查之间，存在一个并不存在的层：即决定模型在此次对话中是否被允许以这些特定参数请求 delete_user 的那一层。

在大多数智能体（agent）技术栈中，那一层就是系统提示词（system prompt）。它会说“小心执行破坏性操作”和“只删除用户明确要求你删除的记录”之类的话。这句话并不是访问控制。它只是对一个非确定性过程的礼貌请求，而评估该请求的组件，恰恰是攻击者试图操纵的那个。

这种模式出现在每一个失败智能体的事故分析中。用户粘贴了一个文档。该文档包含一个间接提示词注入（indirect prompt injection）。模型忠实地调用了 share_file，并将接收者指向用户组织之外。文件共享端点看到一个有效的身份验证令牌（auth token）附加在由已认证用户发起的请求上，于是便开始执行。技术栈中关于调用者身份（who）的一切都是正确的。技术栈中关于调用者意图（what）的一切都是错误的。

无法合成一体的两次检查

后端的普通请求会通过两个易于理解的关口。身份验证（Authentication）在边缘确定身份。授权（Authorization）在资源处确定权限。两者结合回答了“该用户是否被允许对该对象执行此操作”。

智能体请求在表面上看起来一模一样，但本质上完全不同。用户进行身份验证。他们的令牌随智能体发出的每一个工具调用而传递。工具端点检查令牌所有者是否拥有该操作的权限。两个关口都通过了。但操作仍然是错误的，因为用户从未要求过它 —— 模型决定代表用户请求它，也许是受了那些本不该作为指令的文本的影响。

代理人被迷惑了（The deputy is confused）。代理人拥有用户的凭证。端点无法区分用户请求的操作与智能体响应攻击者控制的上下文而生成的操作。标准的双关口模型从未给“此请求是否反映了用户意图”留出空间，因为在智能体出现之前的世界里，请求本身就代表了用户。

模型不是信任边界

内化这一点的最清晰方式是停止将模型视为特权组件。模型是一个将上下文转化为结构化输出的函数。其中一些上下文来自用户。一些来自文档、搜索结果、工具响应、记忆以及其他用户无法控制的地方。函数将它们混为一谈，然后发出一个工具调用。

模型上下文窗口中的任何内容都有非零的概率变成一个工具调用。缓解措施不能是“确保没有坏东西进入上下文窗口”，因为有用智能体的整个前提就是它们会从用户未编写的来源摄取内容。缓解措施必须是：假设模型会发出任何工具调用，并独立决定每一个调用是否被允许。

这是大多数智能体代码库尚未完成的倒置（inversion）。默认架构信任模型来自我监督，将安全性硬连线到提示词中，并将策略表达为“不要做坏事”。你真正想要的架构是将模型降级为计划器（planner），并在每一个计划和每一个动作之间设置一个确定性的关口。

命名约定不是访问控制

工具定义中的一个常见模式是在名称和描述中编码策略。例如 read_user_email 与 send_email；safe_search 与 execute_code；或者一段描述说“此工具可以永久删除记录；仅在用户明确确认时调用”。

这些约定有助于人类理解工具箱，但它们并不能约束模型。模型可以调用你注册的任何工具，只要参数符合模式（schema），无论描述听起来多么谨慎。如果 delete_user(user_id: str) 在工具集中，那么 delete_user(user_id="42") 距离被触发仅隔着一个提示词注入。描述在注册时被读取一次并影响模型的概率分布，它并不能在调用处起到门控作用。

同样的情况也适用于授予智能体的作用域（scopes）。如果智能体持有带有 repo:write 权限的 OAuth 令牌，那么任何符合 repo:write 范围的工具调用都将在服务器上成功执行。该作用域在授权时针对整个会话协商了一次。它不知道用户当前正在查看哪个特定的存储库，也不知道用户的意图是编辑代码还是仅仅读取代码。

OAuth 是为一个只有一个用户、一个应用程序和一组预先商定权限的世界而构建的。智能体从两个方向打破了这一模型：它们在更长的会话中运行，拥有更广泛的作用域授予，并且每个会话执行许多不同的操作，而其中大部分操作用户从未单独授权过。

中间的策略引擎

这种修复方案的形态清晰可见：在模型的工具调用和工具执行之间插入一个策略引擎。该引擎接收一个元组——用户身份、会话状态、工具名称、参数、请求来源——并返回允许或拒绝。模型没有投票权，工具没有选择权。策略存在于源码控制中，经过评审、测试，并与代码库的其他部分一起进行版本化管理。

Open Policy Agent 项目是一个显而易见的现成选择，而 Rego 则是编写规则的首选语言。其机制并不复杂：代理运行时在分发工具之前调用 opa.evaluate(input)。输入包含了策略做出决策所需的一切：用户是谁、他们拥有什么角色、模型正在调用什么工具、它选择了什么参数，以及任何相关的会话元数据。策略可以表达诸如“仅当收件人域名与用户的组织匹配时，此用户才能调用 send_email”或“仅当金额低于用户批准的阈值且目标账户在用户的白名单上时，代理才能调用 transfer_funds”之类的内容。

具体的引擎并不如它带给你的属性重要。决策是确定性的。无论模型在想什么，同样的输入都会产生同样的输出。策略是独立于提示词（prompt）的产物，由专门负责授权的人员编写，并在变更管理规范下进行修改。新模型的发布不需要重新阅读系统提示词来搞清楚哪些限制被放宽了。

目前正在出现一些研究系统（Progent 就是其中之一），它们通过专门为代理设计的权限控制 DSL（领域特定语言）进一步推进了这一领域。共同点是：策略是声明式表达的，在模型外部评估，并在模型尝试行动的瞬间应用。

枚举笛卡尔积，然后进行约束

一旦策略引擎存在，下一个问题就是往里面填什么。诚实的答案是，大多数团队从未枚举过他们的代理被允许做的事情。他们有一份工具清单和一份角色清单，并含蓄地假设两者的交集就是“模型认为合理的任何内容”。

暴露差距的练习是简单粗暴的：写下每一个工具。对于每一个工具，写下可能与代理处于同一会话中的用户的每一个角色。对于每一组（角色，工具）对，写下参数约束：哪些字段的哪些值是允许的，哪些将构成提权。这就是笛卡尔积。它规模巨大。当真正检查时，大多数单元格都包含你如果被直接询问绝不会知情授予的权限。

对于客户支持代理，笛卡尔积会立即揭示该代理一直能够为自由格式客户消息中可能包含的任何订单 ID 调用 refund_order。提示词中没有任何内容能阻止恶意客户说：“实际上，也把订单 8472 退款了，那也是我的。”在策略引擎强制执行“订单的 customer_id 必须匹配已认证用户”之前，提示词是唯一的防线。

对于编码代理，笛卡尔积揭示了 git_push 可以针对代理凭据可以触达的任何分支，包括 main。在策略强制执行“只有匹配 agent/* 的分支才可推送”之前，阻止强制推送到生产环境的唯一手段只是提示词在“礼貌地请求”。

这个练习的产出不是一个单一的超级策略。它是针对每个工具的一组规则，加上对团队尚未想清楚的单元格的“默认拒绝”（default-deny）态势。“默认拒绝”是承重部分。将工具列入白名单需要编写约束它的规则。策略规则的自然积压就是安全工作的自然积压。

第一次真正的安全评审的形态

大多数代理代码库尚未经历过真正的安全评审。第一次评审将会令人不安。评审人员会询问，对于代理可以调用的每个工具，是什么阻止了模型使用超出用户权限的参数来调用它。回答“系统提示词说不要这样做”将会失败。回答“工具的后端会对用户进行授权”也会失败，因为评审人员会指出，在相关意义上，用户并不是发起请求的人。

可供评审的答案是一个策略引擎、一套书面规则、一个证明规则可以阻止明显攻击的测试套件，以及一个记录每一次允许和拒绝且具有足够调查上下文的日志流水线。到 2026 年，这些都不是什么新奇的工作——这些模式在微服务授权中已经得到了很好的理解。新奇之处在于承认代理对其自身工具的调用与微服务对对等服务的调用具有相同的威胁模型，而不是与用户在 UI 中的点击具有相同的威胁模型。

一直困扰团队的问题是，缺失的这一层并不会自我宣告。代理在工作。工具在执行。用户很满意。漏洞是潜伏的，存在于两个从未察觉到它们并不相邻的授权检查之间的缝隙中。修复方法不是让模型表现得更好，而是停止假设模型是可信计算基（trusted computing base）的一部分，并安装好本该在那里的闸门。