智能体权限必须落到工具调用代码中

给 Agent 写一句「只有财务能看账本」，账本就安全了吗？只要底层工具仍接受任何人的调用，安全性就押在模型会不会遵守这句话上。原文的核心主张是：提示词负责交代任务，代码负责执行权限边界，两者不能互相替代。

作者以内部 Agent 平台 Hubzoid 为例，把工具权限、人工审批、共享渠道和知识库放进同一条执行链。对正在给 AI 接业务接口的程序员来说，最有用的问题是：模型一旦选错工具，系统能否把它拦下来？

提示词能指导行为，却不能授予权限

原文先拆开三个容易混用的决定：指令回答「要做什么」，权限回答「谁可以做」，审批回答「这次是否执行」。

比如，某人有权发送报表，也可能需要在发送前让指定人员检查收件人和内容。拥有权限，不代表每一次具体操作都已经获得批准。

提示词能说明任务和规则，但它仍是模型需要处理的文本。长对话、用户请求、读入文档中的指令，都可能影响模型接下来的选择。作者认为，无法穷尽所有表达方式，也就不能靠测试提示词来证明权限规则始终成立。

提示词里写了禁止，不等于执行系统已经拒绝。

这不是让程序员放弃 system prompt。清楚的指令仍能引导行为，只是敏感操作不能把它当作唯一防线。

发票里的恶意指令，应该止步于工具入口

作者举了一个假设场景：Agent 检查供应商发票时，付款信息里藏着一句要求，让它忽略之前的规则，并在回复中附上当月账本。

这就是提示词注入（prompt injection）：不可信内容试图从「待处理的数据」变成「支配执行的命令」。发票、检索文档、工具返回值都可能携带这种内容。

这里有两个不同环节：模型可能尝试查询账本，但查询能否成功，要由系统权限决定。发票中的一句话不能替调用者获得授权。

按作者的介绍，Hubzoid 对受限工具采用显式授权。没有授权时，该工具不会出现在对应用户本轮可用的工具中；即便调用仍到达守卫，代码也会检查调用者、渠道和授权，拒绝不合条件的请求。

执行顺序是：检查身份与渠道，检查授权，记录决定，允许后才运行。如果权限存储或必需的决策记录不可用，受限调用会被拒绝。也就是依赖故障时保持关闭，不因「暂时查不到权限」而放行。

隐藏工具和执行检查各有作用：前者减少模型能选择的能力，后者承接真正的拒绝责任。作者也明确承认，这只能限制注入通过受限工具产生的影响，无法消除所有错误回答，更保护不了已经进入模型上下文的敏感信息。

工具权限之外，还要管记录、收件人和运行身份

库存报告 Agent 需要读取库存，未必需要修改库存。不给它修改工具，就少了一项必须持续监督的能力。这是最小权限原则在 Agent 上的直接应用。

但「能调用查询工具」还不够。如果一个人只能看部分客户或账户，工具或源系统必须继续执行记录级限制，不能把全部结果交给模型，再要求它自行筛选。

读到数据之后，发给谁也是边界。财务同事可以读取薪资，不代表适合把答案贴进共享频道。根据原文，Hubzoid 默认阻止 Slack、WhatsApp、Telegram 等共享渠道调用受限工具；受支持的已登录网页、API 和 MCP 请求则按调用者的授权执行。定时工作流需要明确选择运行账户，并配置合适权限。

共享知识库同样可能绕过工具保护：敏感记录如果已经放进通用 Hub 上下文，Agent 不查受限工具也能看到。凭证应保存在受保护的配置里，面向不同受众的知识也需要分开。

对于发送、发布、修改记录等操作，作者建议明确哪些动作需要审批、谁有资格批准，并展示目的地和具体影响。Hubzoid 提供工具审批策略，但文章没有展开审批界面的细节，也没有说明批准后如何处理操作内容发生变化的情况。

我的判断

我认同它把关注点从「模型会不会听话」移到「错误调用能否执行」。这与普通业务接口的权限设计是一脉相承的：前端隐藏按钮能减少误操作，服务端校验才决定请求是否放行。Agent 的工具列表与执行守卫，也应这样分工。

不过，原文兼有产品介绍性质。它没有提供攻击测试集、拦截率、漏报率，也没有对照数据证明 Hubzoid 比其他方案更可靠。关于平台行为的描述，应理解为作者给出的机制说明，不能直接当作独立验证结果。

作者所说的「只要能访问，提示词迟早能让它访问」也偏绝对。文章没有证明每套系统最终都会被攻破。更扎实的工程结论是：模型可能发起不安全调用，因此权限不能依赖它始终服从指令。

代码关卡也不是自动正确。身份从哪里来、授权覆盖哪些记录、渠道如何识别，都会影响它是否有效。普通后端团队可以在现有接口、服务层和数据源里落实这些约束，未必需要先引入专门平台。

能拿来做什么

• 从最敏感的一个工具开始检查，例如内部数据查询或发布接口。确认谁能调用、会返回哪些记录，以及拒绝时是否留下可核查的活动记录。
• 给 Node 工具处理函数接入可信的登录身份和服务端权限检查；涉及客户、账户等数据时，把记录范围落实到查询或源系统，避免让模型自行判断权限。
• 为需要审批的发送、发布或修改操作指定审核人，并展示目的地、内容和影响；同时明确共享渠道及定时任务账户的访问范围。
• 把正常授权请求、无权限请求、带冲突指令的文档加入评估（evals）。既检查最终回答，也检查工具调用和活动记录，后续修改模型或工具配置时重新验证。