AI Agent 进入业务系统以后，最小权限不是安全团队才关心的事，而是每个流程设计者都要先回答的问题。Agent 能看哪些数据、能调哪些工具、能不能写入、写入前要不要确认，都会决定它出错时的影响范围。
这个问题可以接上 工具权限模型、只读模式 和 决策日志。权限越早分层，后面越少靠临时补救。
工具权限要按动作分，不只按系统分
很多团队会说“Agent 可以访问 CRM”，但这句话太粗。读取客户信息、更新备注、修改报价、删除记录、发送客户邮件，风险完全不同。更稳的做法是把工具拆成只读、草稿、内部写入、对外发送和高风险写入几类。
只读工具可以先开放，草稿类工具进入人工确认，涉及价格、合同、权限和付款的写入动作要单独审批。这样即使 Agent 判断错了，也不会直接把错误扩大到关键业务对象。
数据范围要和任务绑定
Agent 不应该为了处理一张工单，就能看到全量客户库；也不应该为了写一封跟进邮件，就拿到所有合同和财务记录。数据授权最好和任务上下文绑定，只给当前任务需要的字段、时间范围和对象。
这也是上下文安全的一部分。给模型更多资料不一定更准，反而可能增加泄露、误引用和成本。前面写 结果验收 时也提到，关键是证据可复核，而不是把所有材料都塞进去。
写入前要有确认和留痕
最小权限不是永远不让 Agent 写入，而是让写入动作有边界。低风险备注可以自动写，高风险操作要人工确认；每次写入都要记录输入、判断依据、工具返回、执行人或确认人、写入前后值。
这些记录后续会进入 运行看板 和复盘。没有日志的权限控制，很快会变成“理论上安全”。
总结
AI Agent 最小权限的核心，是把工具、数据和上下文都按任务分层。先只读，再草稿，再有限写入；高风险动作保留人工确认和审计日志。Agent 越能做事，越要让权限边界清楚。
