Agent Product 101｜05｜Permission Model：授权不是弹窗

Permission Model 是 Agent 产品的边界系统：定义 Agent 能看什么、能做什么、何时必须请示、由谁负责、如何留下证据。

核心结论

Permission Model 不是“执行前弹一个确认框”，而是 Agent 产品的边界系统。它决定四件事：Agent 能读取哪些信息、能调用哪些能力、哪些动作必须被人类授权、以及出问题后谁能复盘和追责。

对产品经理来说，这一章的关键收益是：你会把“权限”从一个安全/合规话题，转化为可设计、可度量、可运营的产品机制。没有 Permission Model，Agent 越强，用户越不敢委托；有了 Permission Model，Agent 才能从“会说”走向“敢做、能做、做完可验收”。

一个可用的 Agent 权限模型，至少要回答这些问题：

产品问题	PM 要定义的内容	用户感知
Agent 能看什么？	数据范围、上下文来源、敏感字段、最小必要访问	“它为什么知道这些？”
Agent 能做什么？	工具、外部系统、写入动作、支付/发送/删除等副作用	“它会不会替我乱操作？”
什么时候要问我？	风险分级、自动执行阈值、确认点、审批流	“哪些事需要我拍板？”
谁来负责？	发起人、授权人、执行人、审核人、管理员	“出错后找谁处理？”
如何复盘？	日志、证据、版本、审批记录、回滚路径	“我能不能看清它做过什么？”

从真实产品看 Permission Model

ChatGPT Agent 展示了个人 Agent 的典型边界：浏览网页、操作页面、填写表单、执行敏感动作时，用户需要知道 Agent 处于什么状态，并能暂停、接管或确认。这里的权限不是一个抽象设置，而是贯穿任务过程的“可见控制”。

Claude Code、Cursor、Codex、GitHub Copilot coding agent 展示了开发者场景的权限复杂度：Agent 可能读取仓库、修改文件、运行命令、创建分支、提交 PR、触发 CI。对 PM 来说，真正的产品设计不是“允许 Agent 写代码”，而是：允许它在哪个环境写、写完如何展示 diff、谁来 review、失败如何回滚。

Copilot Studio、Agentforce 代表企业 Agent：权限通常不是个人一次性同意，而是绑定组织身份、连接器、数据对象、角色策略和审计要求。一个销售 Agent 能不能查看客户记录、更新商机阶段、触发报价流程，取决于企业已有的权限体系，而不是对话框里一句“是否允许”。

Slack 里的 Agent 则提醒我们：团队协作场景下，权限还包括“谁能看见 Agent 的工作”。Agent 在私聊、频道、thread、workflow 中行动，影响的不是一个人，而是一组人的上下文、通知和责任分配。

产品模型：把权限拆成三层

1. 数据权限：能看什么

数据权限决定 Agent 的输入边界。PM 需要区分：用户主动提供的信息、产品自动注入的上下文、第三方连接器数据、企业内部知识库、历史记忆和敏感字段。

产品判断表：

场景	建议策略	需要避免
用户上传单个文件让 Agent 总结	默认只访问该文件和当前会话	自动搜索用户全部文件
Agent 帮销售写客户跟进邮件	只读取相关客户、商机、最近沟通记录	读取整个 CRM 或跨团队客户数据
Agent 帮工程师修 issue	读取相关 repo、issue、branch、测试结果	默认读取所有组织仓库
Agent 在 Slack 总结 thread	只读取当前 thread 和被明确引用的文档	把私聊或其他频道内容混入总结

2. 行动权限：能做什么

行动权限决定 Agent 是否能产生外部副作用。写入、发送、删除、购买、部署、邀请、修改权限、触发工作流，都比“生成文本”风险更高。

PM 可以按“可撤销性”和“外部影响”分级：

风险级别	行动示例	产品处理方式
低风险	草拟回复、生成摘要、创建本地草稿	可默认自动执行，并清楚标注为草稿
中风险	修改文档、创建 ticket、生成 PR、更新内部字段	执行前展示摘要，执行后可回滚或修订
高风险	发送客户邮件、部署生产、删除数据、提交采购	必须明确确认，必要时引入审批人
极高风险	修改权限、转账付款、法律承诺、公开发布	默认不自动执行，采用强确认和审计

3. 责任权限：谁授权、谁审核、谁接管

很多 Agent 产品失败，不是因为模型答错，而是因为“责任不清”。个人用户场景里，授权人通常就是使用者；团队场景里，发起任务的人、拥有权限的人、结果审核的人可能不是同一个人。

PM 应该把责任角色显式化：

角色	负责什么	产品中应出现在哪里
发起人	定义任务目标和约束	任务卡片、workspace、thread
授权人	允许 Agent 访问数据或执行动作	权限请求、审批流、连接器设置
审核人	判断结果是否可接受	diff、preview、approval request、PR review
接管人	在失败或高风险时人工处理	暂停/接管入口、升级通知
管理员	定义组织级策略和审计	admin console、policy、audit log

反例与误区

误区一：把“确认按钮”当成权限模型

如果用户看到的只是“是否允许 Agent 执行？”，但不知道它将读取什么、改变什么、影响谁、能否撤销，这个确认没有实际意义。有效确认必须包含动作摘要、影响范围、风险提示和恢复方式。

误区二：一次授权，永久通行

很多产品为了降低摩擦，会让用户一次连接 Gmail、Drive、GitHub、CRM 后长期开放访问。对 Agent 来说，这会放大风险。更好的方式是按任务、按对象、按时间、按动作范围授权，并允许用户随时收回。

误区三：只关注安全，不关注转化

权限设计过严会让 Agent 变成“每一步都问”的助手，用户很快放弃；权限设计过松则让用户不敢交付任务。PM 的目标不是最大化限制，而是在风险可控的前提下最大化任务完成率。

设计原则

1. 最小必要权限，而不是最大可用权限

Agent 默认只应拿到完成当前任务所需的最小上下文和最小动作能力。需要更多权限时，再解释为什么需要、将用于什么、持续多久。

2. 把权限请求放在任务语境里

不要让用户在抽象设置页里理解复杂 scope。更好的体验是：当 Agent 要总结某个客户、修改某个 PR、发送某封邮件时，在那个任务节点解释具体权限。

3. 让高风险动作变成可审查对象

高风险动作不应只有“确认/取消”。它应该有预览、差异、影响对象、替代方案、回滚路径和审批记录。

4. 把权限状态持续可见

用户应随时知道 Agent 当前拥有的权限、正在使用的工具、已访问的数据和下一步可能需要的授权。权限不是一次性弹窗，而是任务运行期间的状态。

PM 检查清单

这个 Agent 的最小可用权限是什么？不授权时能完成哪些低风险任务？
用户授权时，是否能看懂 Agent 要读取的数据、执行的动作和影响范围？
权限是按账号、按任务、按对象、按时间，还是按动作粒度授予？为什么？
哪些动作可以自动执行，哪些动作必须确认，哪些动作必须多人审批？
用户是否能暂停、撤销、回滚或接管 Agent？
团队/企业场景下，发起人、授权人、审核人、管理员是否可能不同？
是否有审计日志记录：谁授权、Agent 做了什么、依据是什么、结果如何？
权限摩擦是否被纳入指标，而不是只被当成安全要求？

小结

Permission Model 的本质是把 Agent 的能力放进可理解、可控制、可恢复、可审计的边界里。PM 不需要把它设计成复杂的安全系统，但必须把“能看什么、能做什么、谁负责、如何复盘”变成产品对象。

下一篇进入 Workspace：权限边界清楚之后，Agent 还需要一个承载任务、状态、文件、预览和交付结果的工作空间。