AI 替你干了活，日志里为什么只有你的名字？

假设你让一个 AI 助手整理 demo-notes 仓库：读一遍文档，修掉失效链接，提出一份修改。为了让它能开工，你把自己日常使用的访问令牌配给了工具。

任务很顺。第二天，你想查某个文件是谁改的，记录里却只有你的账号。你昨天手动修过一次，助手夜里也跑过一次，另一个脚本还在用同一套凭证。名字都对，事情却对不上。

这不是模型答错题。系统根本没有得到足够的信息，去区分“你亲手做的”和“一个程序受你委托做的”。

我觉得给 Agent 接工具时，最容易略过的就是这一步：我们认真选择它能调用哪些函数，却顺手把自己兜里的整串钥匙递了过去。工具能用，不代表身份已经安排妥当。

一张工牌上，至少有三件不同的事

身份回答“你是谁”，权限回答“你能做什么”，有效期回答“这张凭证能用到什么时候”。把它们分开，很多争论就清楚了。

独立账号可以拥有很大的权限；个人账号的令牌也可能被严格限制在一个仓库。短期凭证可能是管理员权限，长期凭证也可能只允许读一份公开文档。它们没有自动绑定关系。

所以，“已经给 AI 单独建了账号”只回答了第一问。“令牌一小时后失效”只回答了第三问。还得继续问：这一小时里，它能读哪些东西，能改哪些东西？

再多分清一层：身份属于运行程序，不等于模型拥有一个人的身份。模型生成调用参数，工具进程带着凭证访问外部系统。真正通过鉴权的，是后面这个调用。凭证通常没有必要出现在模型能看到的聊天记录里。

当然，不把令牌写进提示词，也不等于模型绝对碰不到它。如果助手能随意读运行目录、执行命令，它仍可能通过工具接触环境中的秘密。要检查的是实际可访问范围，不能只检查聊天窗口。

借我的身份，最省事，也最难拆账

回到整理仓库的假设任务。第一种办法，是继续使用你的个人令牌。

它方便，因为很多权限已经有了：读仓库、写文件、创建讨论，可能还包括管理其他项目。助手不用再单独申请，接上就能跑。问题也恰恰在这里：为了一个很窄的任务，它可能继承了与你日常工作有关的一大圈能力。

这里有两个不同的风险。一个是范围大，出错可能碰到不该碰的东西；另一个是身份混用，即使每次改动都合法，事后也难以只凭账号还原操作者。额外的工具日志可以补线索，但不能指望远端服务凭空知道是谁坐在模型后面。

GitHub 的凭证类型文档明确区分了关联用户账号的个人访问令牌，与关联应用安装的安装令牌。细粒度个人令牌仍然关联用户账号，不能因为名字里有“细粒度”，就把它理解成独立的机器人身份。GitHub 凭证类型说明

这不意味着个人令牌一概不能用。一次性的低风险实验，可以把范围缩到一个测试仓库，只给必要权限，设定到期时间，并保存任务记录。关键是知道自己采用了什么折中，而不是把“连通了”当成设计完成。

我会先删去一个常见念头：“它可能以后需要，先都给上。”未来要做的事，还没有形成当前授权。现在只整理文档，就不必顺带授予管理成员或删除仓库的能力。

单独发一张工牌，但别把总钥匙也挂上去

第二种办法，是为这类自动化建立可区分的服务身份。

比如把文档整理工具识别为 demo-doc-helper，让它的活动与人的活动分开。平台可能提供应用身份、服务账号、角色等机制，名字不一样，目标相近：访问记录能辨认这是哪个程序，权限与人的日常账号分别维护。

这解决的是“是谁”。它并没有自动解决“能做什么”。如果新身份拥有所有仓库的管理权，只是把风险换了个名字。

对于假设中的任务，我会先把范围写成一句能核验的话：读取 demo-notes 的内容，生成修改，提交到待审位置。至于“只能修改文档目录”“不能动主分支”，不能靠这句话就认定平台已经强制执行。有的服务把权限划分得很粗，授予内容写入后，允许的操作可能比这句话宽。

这时要继续往下拆：可否在隔离副本里修改，只把补丁交回来？能否由另一段受控程序负责提交？分支规则是否真的覆盖当前身份，是否存在绕过权限？如果工具本身只暴露“创建待审修改”，也要检查它背后的凭证有没有被其他工具直接拿去使用的通道。

最小权限是外部系统能执行的边界，不是给模型念的一句提醒。模型应当遵守任务范围，服务端也应当独立拒绝越界请求。两边都有用，但职责不同。

另一个容易混淆的词是“专用”。十个互不相关的任务共用一个叫 robot 的账号，看上去与人分开了，内部却仍然分不清。我更倾向于按职责拆身份，再用任务编号区分每次运行，而不是无限创建账号，也不是让一个机器人账号包办全部自动化。

短期凭证是在收紧时间，不是在读懂意图

第三种办法，是让工具在任务开始时取得受限、短期有效的凭证。

AWS 的 IAM 指南建议工作负载使用角色和临时凭证，避免把长期用户密钥到处分发。这给出的方向很实用：程序需要的是当下能完成任务的访问能力，并不一定需要长期保存一把钥匙。AWS IAM 最佳实践

但“临时”也有容易误读的地方。假设一张通行证只生效十分钟，如果十分钟内可以删除全部数据，它依然危险。时间缩短了，权限范围没有缩短。反过来，限制得很窄的令牌如果一直保留，泄露后的可利用时间又会很长。这两个旋钮要分别调。

GitHub App 的安装令牌就是一个具体例子：官方文档说明，它一小时后过期；生成时可以进一步指定仓库和权限，但不能超出应用安装原本获得的授权。省略这些收窄参数时，也不能想当然地认为平台会替你猜出当前任务需要什么。GitHub App 安装令牌

这也说明，“使用短期令牌”和“按任务授权”并非同义词。前者是凭证特性，后者还需要一套确定性判断：哪个运行环境来申请，为哪次任务，访问哪些资源，哪些动作已获允许。模型可以提出请求，审批或授权程序负责检查，不能让模型自己给自己扩权。

如果授权失败，合理的结果应当是停止相关动作并解释缺少哪项能力。自动换用另一套更宽的凭证，虽然可能把任务跑通，却会让原本的权限边界失去意义。失败路径也属于设计的一部分。

续签也一样：任务没有完成，不必直接延长最初那张票。先核对任务是否仍在运行、原批准范围是否有效，再取得下一段访问能力。如果任务被取消，正在等待重试的程序也应当收到取消状态，不能把网络恢复误当成继续干活的授权。

还要看签发凭证的上游。假如工具手里仍然攥着一把能够无限续签、权限很大的主密钥，那么到期的只是最外面那张票。短期令牌泄露和签发能力泄露，是两个不同层级的问题。

因此，不必执着于“令牌短到几分钟才安全”。先确认谁能签发、能签多大的范围、任务结束后还能不能继续取得新凭证。到期是最后一道时间边界，不应成为唯一的停止机制。

日志要留下委托关系，不只留下账号

把账号分开后，还缺一块拼图：谁委托的，具体是哪次任务。

同一个文档助手，上午可能替你修链接，下午替另一位使用者更新索引。只留下 demo-doc-helper，仍然无法解释一次修改对应哪条请求。反过来，只记“由用户甲授权”，也看不出是哪个工具执行的。

我会为假设任务保留几项关联信息：委托人、执行身份、任务编号、批准的资源与动作、起止时间，以及外部系统返回的操作结果。它们串起来，才有机会回答“为什么这次访问被允许”。

这些信息也有可信程度的区别。模型自己写“用户已批准”，不能代替来自授权界面的批准记录；工具说“修改成功”，不能代替外部服务的响应或最终内容。审计记录应尽量由执行程序采集，并能与服务端记录对上，而不是只保存助手最后的一段总结。

日志里也不该出现完整令牌。要追踪的是凭证的标识、关联身份与权限范围，不是把能够直接使用的秘密又复制一份。为方便排查而打印所有请求头，往往是在修一个问题时制造另一个问题。

换一个任务，权限就应当重新算

再看两个边界不同的假设例子。

一个助手负责整理公开资料。它只需要读取网页、在本地生成报告。如果报告要发给外部收件人，发送就是新增动作：读取权限不能顺手变成发送权限。更稳妥的分工，是先交付可检查的正文和收件人列表，再由已有授权的发送步骤执行。无需把邮箱全部历史和无限发送能力一起交给检索工具。

另一个助手负责修测试仓库里的拼写。它需要读文件和生成补丁，未必需要直接改共享分支。让它在独立副本中工作，最后产出待审修改，可以把模型的探索空间与真实共享状态分开。这里降低风险的主要手段是改变交付方式，未必需要复杂的身份平台。

这两种任务都叫 Agent 自动化，但合适的授权并不一样。前者关键在对外发送，后者关键在共享状态的写入。不能因为换了模型，或者给工具加上了一个“智能”的名字，就跳过原本就该存在的权限判断。

真要停下来时，停止聊天还不够

最后一个问题，我觉得应该在第一次运行前就想清楚：如果现在发现任务不对，怎么让它失去继续操作的能力？

关闭聊天窗口，可能只是停止你看到的对话。工具进程是否还活着，后台任务是否还在跑，凭证是否还能使用，要分别确认。删除本地令牌文件，也不能保证已经被复制出去的那份同时失效。

具体撤销机制随平台而异。AWS 文档说明，临时凭证的权限会在请求时进行评估，可以通过调整权限阻止访问，但策略更新可能需要一定时间生效。因此不能把“按下撤销按钮”直接当成“所有访问已经停止”的证据。AWS 临时凭证权限控制

对自己的小工具，可以先做一次受控演练：在 demo 资源上完成允许的操作，确认越界操作被拒绝，结束授权后再验证访问失败。演练的目的不是让模型保证自己听话，而是确认边界确实由系统执行。

我不会要求每个个人脚本都配齐一套复杂的身份基础设施。但至少可以从三件具体的事开始：别共用日常的万能凭证，让权限只覆盖当前任务，留下能对上外部结果的运行记录。平台支持时，再加入独立应用身份和自动到期机制。

AI 越能独立干活，越需要清楚地知道：这次究竟是谁委托它、允许它做什么，以及什么时候这份允许就结束了。