AI Agent 的最小权限，不是简单地“少给几个权限”，而是让它在特定任务、特定数据和特定操作范围内，只获得完成工作所必需的能力。权限边界应与业务流程绑定，而不是与“这个 Agent 很聪明”绑定。能读取项目进度的 Agent，不应因此获得客户数据库的删除权限；能生成周报的 Agent，也不应自动发布涉及价格、合同或交付承诺的内容。

实现最小权限，首先要把 Agent 当作独立的服务账号，而不是管理员的自动化替身。每个任务都应明确三件事：可以读取哪些数据，可以创建或修改哪些记录，哪些操作必须经过人工确认。负责整理会议记录的 Agent，可以提取需求并写入“待确认”表，但不应直接生成正式任务，更不能替人向客户发送承诺。

权限控制还要覆盖数据范围。项目、客户、文档和 AI 执行记录应保持清晰关联，使 Agent 只能访问当前任务所需的数据。对于外部协作者，应限制其访问被授权的项目；对于审计账号，可以查看日志，但不能修改业务记录。权限越接近资源和动作本身，越容易发现越权风险。

高风险操作应采用“默认拒绝、人工批准”的设计。涉及删除、导出、对外发送、修改财务信息或改变合同状态的动作，不应仅凭提示词决定。更稳妥的流程是：Agent 先生成结构化结果，系统进行格式校验和权限判断，再进入人工复核；失败或无法解析的结果进入异常队列，而不是静默写入正式数据。

最小权限必须能够被审计。日志至少要记录操作者或服务账号、时间、操作对象、操作类型、关键变更、关联任务、流程版本和失败原因。模型密钥应保存在服务端的密钥管理配置中，不能放入前端代码、共享文档或提示模板。

上线前可逐项检查：权限是否按任务拆分，服务账号是否独立，写操作是否默认受限，敏感数据是否经过授权，原始输入与生成结果是否可追溯，权限和日志是否有人定期复核。最小权限的目标不是让 Agent 什么都做不了，而是让每一次能力扩张都有明确边界、责任人和撤销路径。