把 Agent 权限校验放到工具调用之前

dev.to · AI#Agent#权限控制#可观测性

Editor brief · 编辑速览

文章建议在工具调用边界执行访问控制，将每次调用绑定到 Agent 身份及权限集，并记录授权决策。它强调共享服务凭证难以区分调用者，执行后的检查只能用于审计，无法阻止越权动作。

文章思维导图

Knowledge map

拖拽缩放

AI deep read

AI 深度解读

让 LLM 调用工具之后，安全问题就从「它会说什么」变成了「它能做什么」。原文的结论很明确：权限控制要放在工具执行之前，绑定独立的 Agent 身份，并记录每次放行和拒绝。

这篇值得读的地方，是把提示词约束、访问控制和监控分清了。它给出了一套实施顺序，也介绍了 RESK 的对应组件；但没有代码、实测或对照数据，适合当作设计检查表，不能直接当成产品效果证明。

原文用一个具体场景解释风险：Agent 持有的凭据既能调用文件读取工具，也能调用 shell 工具。提示词要求它只读取指定目录，但它读到的文档里夹带了指令，诱导它执行命令。

这里发生的是提示词注入（prompt injection）：不可信文档中的内容，被模型当成了行动指令。

提示词可以要求模型遵守规则，却不能替 shell 拦截命令。只要模型能够用现有凭据调用 shell，执行入口又没有权限检查，命令就有机会落地。

Agent 的攻击面取决于凭据能访问哪些工具，而不是提示词提到了哪些工具。

这也解释了为什么执行后检查不够。文件已经写入、记录已经修改，再发现越权，能得到的是审计记录，无法阻止刚才的副作用。

作者主张把控制放在工具调用边界，也就是工具开始执行、即将产生副作用的位置。调用顺序是：

边界的位置很关键。检查如果只存在于某个较早的业务流程里，其他调用路径可能绕开它；检查如果在执行之后，就失去了阻断能力。

要让这个流程成立，先得知道「是谁在调用」。作者要求每个 Agent 使用独立身份，而不是共用一个服务凭据。共享凭据会让调用者混在一起，难以分别授权，也难以追查哪个 Agent 在尝试越权。

接着是默认拒绝（default deny）：初始状态没有工具权限，再按身份、按工具逐项授予。一个只负责读取资料的 Agent，不应因为系统接入了 shell 就自动获得命令执行能力。

这套思路并不陌生。作者把 Agent 看作由模型驱动的服务账号，沿用最小权限原则，而不是因为调用方变成了 LLM，就把授权交给自然语言。

只记录成功调用，会漏掉模型试图越过权限边界的过程。原文要求记录放行和拒绝，并带上 Agent 身份、工具名称及调用结果。

这里需要区分两件事：权限层允许调用，不代表工具最终执行成功。权限决策和执行结果都值得保留，否则排查时容易把授权问题与工具故障混为一谈。

作者还建议，对同一身份的连续拒绝触发告警。单次拒绝可能来自配置错误，反复拒绝则说明 Agent 正在持续尝试访问未获授权的工具，应当触发事件调查。不过，原文没有给出次数阈值、统计窗口或告警降噪方法。

RESK 被介绍为这套机制的实现层：

原文描述了两者的职责，但没有展示接入代码、配置示例或部署方式，也没有说明告警如何配置。它说明了产品打算控制什么，尚不足以判断实际集成成本。

我认同把授权放到执行入口。提示词适合描述任务目标，权限系统负责决定哪些动作可以发生，两者的职责应当清楚。相比只靠提示词限制 Agent，执行前拦截提供了明确的阻断位置。

但「按工具授权」只是起点。即便允许文件读取，也还需要回答能读哪些路径；即便允许 shell，也还需要回答能执行什么命令、在什么环境里执行。原文没有说明参数和资源范围如何检查，所以不能从它的描述推断出目录隔离等能力。

独立身份同样需要配套机制：身份由谁签发、如何传递、是否可能被调用方伪造，原文都没展开。仅在请求里增加一个身份字段，还不足以证明身份可信。

对 RESK 的部分，我会把它看作产品方案介绍。作者没有提供它与自建权限中间件、已有网关或沙箱方案的对照数据，也没有性能开销和绕过测试。架构原则有参考价值，具体组件是否合适，仍需验证。

另外，重复拒绝适合作为调查信号，不能直接等同于攻击成立。任务与权限不匹配、模型反复重试，也可能制造同样的现象。