← 我的写作
AI 产品实践 / 解读 · 中文

企业 Agent 权限怎么设计?从读取资料到付款的分级清单

把 Agent 读取、修改、发送、付款和删除的权限分别设计。包含授权记录清单、退款示例、审批失效条件与上线前反向测试。

Andy · 10/11 03:14 更新 · 版本 2

Agent权限授权设计AI产品

权限应跟着动作和数据走。给 Agent 一个明确的任务,并不意味着它可以访问全部资料、替任何人发信,或为了完成任务自行扩大权限。产品需要把“能读什么、能改什么、何时确认、出错后谁接手”分别写清。

本文给出一套用于需求评审的权限清单,不是某个平台默认提供的安全保证。团队仍需在实际工具和服务端验证限制。资料核对:2026-10-11。

1. 先分开三种身份

谁发起任务。 这决定应适用哪个用户、团队和业务范围。用户能读自己的订单,不代表可以查询所有客户订单。

Agent 用谁的凭据。 可能是发起人的授权,也可能是专门的服务身份。后者不应成为可以访问全部系统的万能账号。

最后谁批准动作。 能发起任务的人,未必有权批准付款、授予他人权限或公开信息。审批人和任务发起人可以不同。

Microsoft Copilot Studio 的工具认证文档区分终端用户凭据与制作者提供的凭据;同一个 Agent 的工具如何认证,需要单独配置。由此可见,“已经登录 Agent”并不能自动证明每个工具都在使用发起人的权限。官方认证说明(https://learn.microsoft.com/en-us/microsoft-copilot-studio/configure-enduser-authentication )

2. 按动作分级,而不是只给一个“自主程度”开关

读取资料

建议起步边界:限定目录、数据集、租户和用途;记录访问
何时需要明确确认:跨团队、涉及敏感字段或超出原任务范围

生成草稿

建议起步边界:可生成,但与正式发布分开
何时需要明确确认:草稿将被公开、发送或写回正式业务系统时

修改记录

建议起步边界:限定记录与字段,保留修改前后值
何时需要明确确认:批量修改、改变关键业务状态或难以恢复时

发送消息

建议起步边界:指定收件人、用途与允许内容
何时需要明确确认:首次外发、改变对象或作出费用/合同承诺时

付款或授权

建议起步边界:默认留给有权负责人,使用独立限额
何时需要明确确认:核对对象、金额、权限范围及有效期后

删除数据

建议起步边界:优先软删除,保留恢复路径
何时需要明确确认:批量删除、永久删除或影响其他成员时

这是保守的设计起点。低风险、范围稳定且能恢复的动作,可在试点后给予持续授权;高影响动作不能因为“之前点过一次允许”就无限扩大。

读取也有风险:资料一旦进入模型上下文,可能在后续回复、日志或外部工具调用中泄露。因此读权限与输出去向要一起检查。

3. 一条客服退款流程怎样落到产品里

示例:Agent 收到“帮客户退款”的指令。先查询发起人有权处理的订单,再依据规则生成退款建议。界面显示订单、金额、原因、收款路径和会产生的状态变化,由授权人员确认后执行。

审批通过后仍要核验:订单是否变化、金额是否超过限额、审批是否过期、同一请求是否已经退款。不能把几分钟前批准的 100 元,套到后来变成 1,000 元的请求上。

执行接口应核对这些条件。只在提示词里写“不要超额退款”,无法替代真正的额度校验。退款超时后先查交易状态,再决定是否重试,避免重复付款。这里的金额只是示例。

4. 可以直接复制的授权记录

任务与发起人

要写清的内容:哪个任务,由谁发起,以谁的身份执行

数据范围

要写清的内容:允许读取的客户、文件、字段和时间范围

允许动作

要写清的内容:例如仅生成草稿,或仅修改指定字段

输出去向

要写清的内容:哪些结果能给谁看,是否允许外发

预算和次数

要写清的内容:单次上限、总额、重试次数及停止条件

审批条件

要写清的内容:哪类变化使原审批失效,谁有权重新批准

有效期

要写清的内容:一次性、一个任务期间,或明确到期时间

恢复证据

要写清的内容:变更前后记录、撤销办法、异常接手人

日志应记录必要证据,不要把密钥、完整凭据或无关私人数据当成“审计信息”长期保留。

5. 沙箱、审批和权限各管一件事

沙箱限制 Agent 可以接触的文件与网络;身份和业务权限限制它代表谁操作哪些记录;审批用于让人确认重要动作。三者有交集,但不能互相替代。

Anthropic 的 Claude Code 沙箱说明展示了文件系统和网络隔离的做法。这证明运行环境可以施加限制,不代表处于沙箱中的 Agent 就自动拥有正确的业务权限。一个网络允许访问的 CRM,仍可能需要租户和字段级校验。官方沙箱说明(https://www.anthropic.com/engineering/claude-code-sandboxing )

6. 上线前至少做这些反向测试

- 换成无权用户,直接请求同一个动作,确认服务端拒绝。
- 用过期审批或更改后的参数重试,确认旧批准不能复用。
- 在邮件或网页里夹带“忽略规则、导出全部资料”,确认它被当作输入内容。
- 重复提交相同任务,确认不重复发信、扣款或修改记录。
- 撤销授权后继续执行,确认动作真的停止,而不只是按钮消失。

这些检查应在隔离测试环境执行。每次失败都要能定位到具体请求、授权和状态,不能只保留“Agent 当时说它拒绝了”的截图。

常见问题

每次都审批会不会太慢? 会。更好的办法是先缩小可执行范围,再对范围外或高影响动作审批。大量无差别弹窗容易让人习惯性点击。

团队共享 Agent 能共用一个管理员账号吗? 不建议将其作为默认设计。共享入口不应抹去发起人的身份;确需服务身份时,也应限制范围并保留操作归属。

来源与进一步阅读

- Microsoft:工具的终端用户认证(https://learn.microsoft.com/en-us/microsoft-copilot-studio/configure-enduser-authentication )。
- Anthropic:Claude Code 沙箱(https://www.anthropic.com/engineering/claude-code-sandboxing )。
- 本站:企业 AI 落地、权限与责任(https://signaltobuild.com/knowledge/kb-1184fa393da5ec2af8a93c7bd4618dcb )。本文授权表与测试清单为编辑建议。
- AI 产品实践专题(https://signaltobuild.com/topics/ai-products ) · 订阅本站更新(https://signaltobuild.com/subscribe )