别把密码交给AI代理：凭证分离的安全实践

当AI代理帮你填完设置页面的大部分表单，突然停下来提示"请在此粘贴您的密码"，或者它需要调用某个服务的API密钥，而聊天框就在旁边时——很多人会顺手粘贴。这种做法感觉无害，因为对话看起来是私密的。但聊天框不是保险箱。据Tutuo公司Octuo团队发布的技术博客，这类"顺手粘贴"正在成为AI代理普及过程中最容易被忽视的安全缺口。

为什么聊天框是最糟糕的凭证存放地

任何输入到提示词中的内容都会成为模型上下文的一部分。根据具体工具的不同，它可能被保留在历史记录里、写入日志、发送给托管模型，或被摘要进后续对话读取的记忆中。你既看不见这些副本，也无法可靠地删除它们。

指令文件同样存在风险。像CLAUDE.md或AGENTS.md这样的文件，存在的意义就是让模型在每次运行时读取。这使它们成为存放项目约定的好地方，却是存放令牌的坏地方。原文给出的判断标准很直接：把这些文件视为模型可见，且往往对仓库的所有访问者可见。

Octuo团队将目标概括为一句话：代理可以使用凭证，但原始值永远不进入模型读写的文本。这并非要求代理放弃自动化能力，而是要求凭证在架构层面与对话上下文彻底隔离。

模型上下文（Model Context） 是AI代理处理任务时能够"看到"的全部文本信息集合，包括系统提示、用户输入、工具返回结果以及历史对话。一旦凭证进入这个集合，它就可能被写入服务商的日志、用于模型微调（取决于服务条款）、被摘要压缩后存入长期记忆，甚至通过提示注入攻击被诱导泄露给第三方。更棘手的是，上下文中的内容会随对话轮次在多台服务器间传输，用户既无法审计副本数量，也难以保证删除操作在所有存储位置生效。这正是"聊天框不是保险箱"的技术根源：它不是存储介质，而是一条会留下多重痕迹的数据管道。

凭证仓库：让工具替模型取用秘密

可行的模式是使用一个位于对话之外的凭证仓库或保险库。模型发起一个动作请求，比如"登录计费门户"或"用部署令牌调用API"，工具负责取出秘密并直接使用。模型看到的是引用或结果，永远看不到值本身。

操作系统的钥匙串是这个思路的最简版本；专用秘密保险库则额外提供加密、访问规则和使用历史。原文提醒了一个关键验证点：当代理使用秘密时，值会不会出现在对话记录中？如果会，那么这个仓库只是装饰品。

这一验证标准值得每个团队在部署前实际测试一遍，而不是假设工具默认安全。

操作系统钥匙串（Keychain/Credential Manager） 是macOS、Windows和Linux桌面系统内置的加密凭证存储，由系统在用户登录后解锁，应用通过受控API读取条目而不暴露明文。它适合个人开发者快速起步，但局限在于通常绑定单一用户会话，难以支持团队共享、细粒度访问控制和跨机器的审计。专用秘密保险库（如HashiCorp Vault、AWS Secrets Manager等）则在此之上增加了动态凭证签发、短期租约、策略引擎和完整审计流，代理每次请求都由保险库按策略临时发放或代理使用，事后再回收。选择哪种取决于规模与合规要求，但两者的共同底线一致：秘密值只在工具进程内可见，绝不回流到模型上下文。

最小权限：给代理的永远少于你自己拥有的

原文给出了四条具体原则：

限定令牌范围。 为单一任务创建令牌——如果读取就够了就用只读权限，限定一个仓库、一个项目。不要复用能执行一切操作的密钥。

设置过期时间。 短生命周期能把泄露变成小事故。过期时间应在创建令牌时设定，而不是事后补上。

优先使用OAuth和应用专用密码，而非主密码。 委托访问可以被限制，也可以在不改动你在其他所有地方使用的密码的情况下被撤销。主密码永远不该由代理持有。

2FA和支付留在人手里。 第二因素是确认意图的环节。让代理把你送到那个页面，验证码、购买或转账由你本人批准。

这四条原则的共同逻辑是：把"能做什么"和"能造成多大破坏"分开设计，让每一次授权都可回收、可追溯。

OAuth 是一种授权框架，允许用户在不向第三方透露主密码的前提下，授予应用对特定资源的有限访问权。其核心是"令牌"而非"密码"：令牌可以限定作用域（scope）、设定有效期，并可由用户随时在授权方一侧撤销，撤销后不影响主密码及其他已授权应用。应用专用密码则是部分服务（如邮箱、代码托管平台）提供的替代方案，为每个应用生成独立于主密码的一次性密码，泄露后只需吊销该密码即可。两者共同的价值在于"可撤销性"——主密码一旦泄露，影响面覆盖该账号的所有用途，且修改密码往往牵一发而动全身；而委托令牌的泄露可以被精准隔离和快速止血。

审计日志：每一次使用都应留下痕迹

代理可以使用的凭证，每次使用时都应留下记录：哪个秘密、何时、用于哪个任务。许多服务本身也保留登录和API活动页面。原文建议设置周期性提醒去浏览这两处记录，重点寻找你不认识的使用、你不在工作的时间点、以及你没有要求过的服务。

没有日志的凭证授权，等于放弃了事后发现异常的唯一机会。

粘贴事故之后：先轮换，再清理

如果秘密确实落入了聊天、日志或已提交的文件，请假定它已经泄露。正确顺序是：在源头轮换、撤销旧值，然后清理你能找到的副本。删除消息可以做，但它不能替代轮换。这个顺序容易被搞反——很多人第一反应是删记录，却忘了旧值依然有效。

凭证轮换（Credential Rotation） 指在源头生成新值并使旧值失效的过程，是泄露响应中唯一能真正切断攻击者访问的手段。与之相对的"清理副本"只是减少暴露面，无法收回已被读取或复制的内容。实践中轮换应遵循"先立后破"：先创建新凭证并确认依赖它的服务正常运行，再吊销旧值，避免业务中断；对于无法立即轮换的场景（如硬编码在多个系统中的密钥），应至少缩短其有效期并加急排期。自动化轮换（由保险库或密钥管理服务定时触发）能显著降低人为遗漏的风险，也是审计合规中的常见要求。

浏览器登录前的检查清单

浏览器登录是代理处理网站杂务时最有用的场景。在授权之前，原文建议逐项核对：凭证来自仓库而非聊天或模型可读的文件；账号只拥有任务所需的最小权限，站点允许时最好使用单独的受限账号；2FA保持开启且第二因素送达你而非代理；支付、账号删除和安全设置需要你确认；你能看到代理登录了哪些站点、何时登录；你知道如何一步撤销会话或令牌；任务结束时保存的浏览器会话被清除或过期。

原文强调，这一切不需要特殊工具就能开始：把下一个秘密移出提示词，缩短下一个令牌的寿命，把不可逆操作的最后一击留给自己。对正在把越来越多工作交给AI代理的团队来说，这可能是投入产出比最高的一项安全习惯。

---

本文基于Tutuo公司Octuo团队发布的技术博客编译整理。