与 AI 一起工作 | 4.当 AI 可以修改文件和发送消息，权限应该怎样给？

当 AI 只能在对话框里生成文字时，最常见的风险是答案不准确。即使它写错了一段代码或误解了一份材料，人仍然可以在复制、粘贴和执行之前停下来检查。

但当 AI 能够读取本地文件、修改代码、查询数据库、创建日程和发送消息后，情况发生了变化。它不再只是给出建议，而是可能直接改变现实状态。

这时真正的问题不再是“要不要给 AI 权限”，而是：它可以访问什么、执行什么、做到什么范围、持续多长时间，以及哪些动作必须再次经过人的确认。

权限不是一个总开关。一个可靠的 Agent 不需要随时拥有所有能力，而应当只在完成当前任务所必需的范围内获得权限。
在这里插入图片描述

先把权限拆成五个问题

讨论权限时，人们很容易只关注“允许”与“拒绝”。但同一个“允许读取文件”，可以意味着读取一个指定文档，也可以意味着扫描整个主目录；同一个“允许发送消息”，可以意味着生成一份草稿，也可以意味着直接向所有联系人群发。

至少需要把权限拆成下面五个维度：

维度	需要回答的问题	例子
对象	AI 可以接触什么	指定文件、某个数据库、一个聊天群
动作	AI 可以做什么	读取、修改、删除、导出、发送
范围	一次可以影响多少	单个文件、十条记录、整个目录
时效	权限持续多久	当前步骤、当前任务、长期有效
去向	数据和结果可以流向哪里	仅本地、内部系统、外部联系人

这五个问题共同决定了权限的真实含义。只写“允许访问数据库”几乎没有可执行价值，因为它没有说明可以访问哪些表、能否写入、能返回多少数据，也没有说明结果是否可以被发送到外部服务。

动作越接近现实，确认点越应该靠近执行

不同动作产生的影响并不相同。读取一份公开文档、修改一个可以恢复的本地文件、批量删除记录和向客户发送邮件，不能使用同一种授权方式。

从左向右，影响逐步扩大。权限设计也应随之收紧：

生成建议通常不改变外部状态，可以直接执行。
限定范围读取需要明确数据边界，避免顺带扫描无关文件和敏感信息。
可恢复的本地修改应保留 Diff、版本记录或其他恢复路径。
批量或不可逆操作应先试运行，展示将受影响的对象，再等待确认。
发送、发布或改变外部状态应在执行前核对接收方、正文、附件和关键参数。

这里的关键不是每一步都弹出确认框，而是把确认放在真正改变风险的边界上。频繁、无差别的确认只会让人机械点击；太晚的确认则只是在通知人一件已经发生的事。

权限应该形成一个闭环

一次授权不应只包含“允许执行”这个瞬间。可靠的流程需要在执行前展示真实动作，在执行后回读结果，并在任务结束后收回临时权限。

这个闭环把权限从静态配置变成了任务过程的一部分：需要什么才申请什么，批准什么才执行什么，执行完成后还能确认实际发生了什么。

读取文件：给目录，不要给整台机器

假设我们让 AI 整理一份项目文档。完成任务可能只需要读取项目目录中的 Markdown 文件，却没有必要让它同时接触浏览器数据、个人照片、下载目录、密钥文件和其他项目。

比较清楚的授权方式是：允许读取指定项目，明确排除凭据、隐私数据和无关目录；需要扩大范围时，再说明为什么当前材料不足。

最小权限并不意味着永远只给最少的一个文件，而是让权限跟着任务逐步扩大，而不是一开始就把所有可能用到的资源全部交出去。

修改文件：先保留可恢复性

AI 修改本地文件时，风险通常不是某一行写错，而是改动范围超出预期，或者在没有意识到用户已有修改的情况下覆盖内容。

因此，权限不仅要限制“可以修改哪些文件”，还要规定修改后的检查和恢复方式：先查看当前状态，只改指定范围，保留已有改动，展示 Diff，并在删除或大范围迁移前等待确认。删除类任务还应优先采用可恢复的归档方式，而不是直接物理清除。

一个本地改动如果没有可查看的差异，也没有可靠的恢复路径，就不应仅凭一句“已经修改完成”进入下一步。

写数据库：不要把查询权自动升级为写入权

能读取数据库，不代表可以修改数据库；能够更新一条测试记录，也不代表可以批量处理整张表。

对于写入任务，应尽量把读取、生成变更方案和真正提交拆开。先展示将修改哪些记录、旧值和新值分别是什么，再限制单次影响范围；能够使用测试环境、事务、备份或试运行时，先用这些手段缩小错误后果。

尤其需要警惕“为了方便”长期保留高权限账号。Agent 可以继承一个账号的技术权限，却不会自动继承账号持有者对组织关系、业务例外和后果的完整理解。

发送消息：草稿权与发送权应该分开

生成一封邮件和真正发送邮件，是两项不同的能力。

AI 可以先根据上下文起草正文，但在发送前，人仍应看到实际接收人、抄送对象、标题、正文和附件。如果收件人来自模型推断、模糊搜索或历史记录，更需要重新确认。

发送完成后还应回读系统状态，核对实际发送对象和内容。工具返回“成功”只说明调用完成，不自动证明没有选错联系人、漏掉附件或发错版本。

类似的边界也适用于发布文章、创建公开日程、提交审批和触发工单：生成内容可以自动化，改变外部状态应保留清楚的最后确认。

一份可复用的授权模板

把权限写进任务时，不必使用复杂的安全术语。下面这份简单结构已经能够覆盖多数日常场景：

目标：最终要完成什么。

允许：可以读取哪些资料，可以调用哪些工具，可以修改哪些对象。

禁止：不得访问的数据、不得执行的动作、不得输出到的位置。

确认点：哪些动作只能先生成预览，得到确认后才能执行。

恢复方式：发生错误后如何撤销、回滚或重新核对。

验收：执行后需要回读什么结果，怎样证明没有越界。

例如，与其说“整理旧文件并清理掉”，不如说：

只检查 project/docs 目录，列出疑似废弃文件及判断依据。
当前阶段只读，不移动、不删除、不修改引用。
我确认清单后，才能把指定文件移动到可恢复的归档目录。
完成后重新列出原目录和归档目录，核对实际移动结果。

这里最重要的不是文字更长，而是建议、授权和执行被分成了不同阶段。

四个常见的权限误区

第一，把人的账号权限直接当成 AI 的合理权限。一个人可以访问某个系统，不代表当前任务需要让 Agent 使用其中的全部能力。

第二，只限制读取对象，不限制输出去向。内部文档即使读取合法，一旦摘要、日志或工具参数流向外部服务，仍可能越过原有边界。

第三，只记录成功或失败，不记录实际动作。如果日志只写“调用成功”，却没有对象、参数、接收方和确认记录，出错后很难还原发生了什么。

第四，把一次授权变成永久授权。临时任务结束后，令牌、连接器、插件和服务账号如果继续有效，就会把一次需要变成长期暴露面。

授权前的 30 秒检查

在允许 AI 执行动作前，可以快速确认：

它要访问的对象是否与当前任务直接相关？
它需要读取、修改，还是只需要生成建议？
单次动作最多会影响多少文件、记录或联系人？
数据是否可能通过日志、插件或消息流向外部？
不可逆动作之前是否有清楚的预览和确认点？
出错后能否恢复，并能否回读实际结果？
任务结束后，临时权限是否会失效？

真正可靠的权限设计，不是让 AI 什么都不能做，也不是为了效率把所有权限一次性打开。它要实现的是：低风险步骤可以顺畅推进，高风险动作能够被看见、被理解，并在发生之前由真正承担后果的人作出决定。