企业 Agent 的权限，不能只写在 Prompt 里
企业准备让 Agent 接触真实业务时，经常先写一份很长的 Prompt：哪些文件不能看，哪些动作不能做，遇到什么情况必须停下来问人。
这些规则有用，但它们不是权限系统。
只要 Agent 已经拿到了凭据、网络和工具，Prompt 里的「不要做」仍然是一条交给模型理解和遵守的软约束。真正的权限边界必须放在模型外面：它实际能读什么、能写什么、可以访问哪里，哪些动作没有人工确认就无法执行，失败以后怎样停止和恢复。
原文发布于 2026 年 7 月 27 日，当时几份安全披露让「模型指令」和「系统权限」的区别受到更多关注。具体事件发生在特殊评估环境中，不能直接推导为所有办公 Agent 都会突破隔离。对普通企业更实际的风险，往往是读错文件、调用错工具、写入错误账号，或者把网页和文档中的外部指令继续当成任务执行。
事件强度不同，判断标准相同：模型说自己会遵守边界，和系统让它无法越过边界，是两回事。
真正握着钥匙的是执行层
一个 Agent 要完成工作，通常不只有模型。模型判断下一步，执行层把判断变成动作，文件系统、浏览器、API、MCP 或自动化工具负责执行，账号和凭据决定它最终能接触哪些数据。
如果 Agent 使用只读账号，它就不能修改订单；如果网络出口只允许指定域名，它就不能任意访问外部站点；如果付款、删除和群发必须经过独立审批接口，模型即使生成了请求，也无法直接完成动作。
反过来，如果 Agent 已经拿到管理员账号、任意网络访问和全量写入工具，再补一句「请谨慎操作」，并没有缩小失败影响。
Prompt 仍然适合描述任务目标、业务规则、输出格式和行为偏好。只是权限校验不能由它承担。
上线前的五道门
1. 身份和数据范围
不要直接复用员工或管理员的完整身份。为具体任务建立独立身份，按最小权限开放目录、数据表和字段，并明确凭据的有效期。
读取也属于权限。客户资料、财务数据和员工信息即使不被修改，访问范围仍然需要审批和记录。
2. 网络和工具白名单
列出 Agent 可以访问的域名、API 和工具，默认拒绝，业务确有需要时再逐项开放。
工具边界还要覆盖输入内容。Agent 会读取网页、邮件、文档和接口返回值，外部内容可能夹带新的指令。只检查用户最初输入的 Prompt，覆盖不了后面的链路。
3. 外部写入确认
读取资料和生成建议可以有较高自治度，外部写入需要更谨慎。发送邮件、修改订单、删除文件、创建草稿、提交表单和付款，不应该共享同一种授权方式。
动作越难撤回、影响的人越多，人工确认就越应该靠近最后执行点。确认界面要展示准确对象和最终内容；只问一句「是否继续」起不到确认作用。
4. 独立结果校验
不能让 Agent 只凭一句「已经完成」宣布任务结束。
代码任务可以检查测试和退出码；业务任务可以核对目标账号、数据范围、审批状态、内容版本和数量上限。校验器应独立于模型输出，也不应被执行 Agent 随意修改。
5. 失败停止与恢复
系统要能识别失败并阻止 Agent 无限重试。需要提前定义连续失败多少次就停止、连接异常时是否可能已经写入、哪些结果可以安全重试、怎样恢复原状态，以及由谁接手无法判断的结果。
日志至少要回答：谁在什么时间，用什么身份，对哪个对象执行了什么动作。
一次内容写入也需要门禁
把一篇已经确认的文章写入指定平台草稿箱，看起来只是一次普通提交，实际也包含多个风险点：账号可能选错，标题与正文可能来自不同版本，连接失败时可能已经产生写入，重试还可能生成重复草稿。
更可靠的流程会先锁定目标账号和文章版本，确认标题、正文和图片属于同一次审核，再检查连接与鉴权。提交失败时不能把本地状态改成成功；结果无法判断时不能直接重试，而要先到目标系统核对。
这里最重要的是门禁可以被测试、拒绝和记录，具体选用哪个工具都在其次。它比 Prompt 里的「确认无误后操作」多了一层系统保证。
先把权限边界写成表
准备让 Agent 进入业务之前，可以让业务负责人、IT 或实施方和最终审批人一起回答五个问题：
- 它能读什么、写什么？
- 它可以访问哪些网络和工具？
- 哪些动作必须由谁确认？
- 系统怎样判断任务真的完成？
- 失败以后怎样停止、核对和恢复？
每一项都应写清允许范围、系统如何强制、谁负责，以及用什么结果证明门禁生效。任何一项答不清楚，就先保留人工执行。
Agent 能完成一次演示，只证明它有能力做这件事。一个出了问题会停止、有人能接手、系统可以恢复的 Agent，才开始具备进入真实业务流程的条件。