原创解读：当 Agent 试图'顺手拿走密码'，暴露的从来不只是一个泄漏点

版权声明与免责声明 本文基于《Your AI Agent Knows Your Passwords — Here’s How I Fixed It》进行原创解读。原文版权归原作者与原出处所有。本文不构成官方翻译，仅用于学习、研究与观点讨论。

观点归属声明 原文提供了重要案例线索；本文的事故叙述、结构拆解和治理判断由作者完成。

原文参考 Your AI Agent Knows Your Passwords — Here’s How I Fixed It：https://dev.to/demojacob/your-ai-agent-knows-your-passwords-heres-how-i-fixed-it-4kcd

原创性质 本文不是逐段翻译，而是围绕凭据外泄这一运行时事故场景进行重新叙述与系统化解读。

引子：真正糟糕的不是 Agent 看见了密码，而是系统默认这件事”本来也没什么”

问题最早暴露在一次常规日志检查中。

当时团队正在调试 OpenClaw 的新功能，需要查看 Agent 的日志输出，确认上下文处理是否正常。日志系统里的一条 DEBUG 记录，直接把问题暴露了出来。

那是一行普通的 DEBUG 级别日志，记录的是 Agent 的上下文信息。但在那一长串文本中间，出现了一串不该出现在日志里的字符：团队用于访问生产数据库的密码。

这不是一个日志格式问题，而是凭据边界已经被运行时链路击穿。

继续检查最近几周的日志后，更多证据浮现出来。不仅仅是这一次会话，过去几周的日志里，多次出现了各种敏感凭据：数据库密码、API 密钥、第三方服务的访问令牌。有些是明文，有些是 base64 编码但很容易解码，有些是作为上下文的一部分被 Agent “顺便”读取了。

最可怕的是，这些凭据的出现看起来是如此”自然”——它们不是被黑客窃取，不是被恶意程序提取，而是被 Agent 在正常的任务执行过程中，作为上下文的一部分，“合规”地读取、“合法”地记录、“正常”地存储。

团队很快把排查问题收束到两个关键点：第一，凭据为什么会进入 Agent 上下文；第二，包含凭据的上下文为什么会被写进日志。开发侧的解释并不罕见：某些任务需要数据库访问，所以凭据被放进环境变量，Agent 在运行时读取。真正危险的是第二个环节：系统为了方便诊断，记录了完整上下文，而上下文里已经混入凭据。

凭据相关事故之所以棘手，不是因为大家第一次听说”密码可能泄漏”，而是因为它通常发生在一种令人难堪的语境里：事后回看，系统里几乎每个设计选择都在为这次事故铺路。

密码不该长期可见，但它长期可见；令牌不该跨任务复用，但它被当成便利默认复用；高风险动作本该在使用凭据之前被单独裁决，但系统把”拿到了凭据”直接近似成”有权去做”。最后，事故看起来像一次偶发越权，实际上是长期设计假设共同作用的结果。

最危险的地方还不是”Agent 知道密码”这一事实，而是团队在很多个节点上都觉得这件事问题不大：反正只在内网、反正日志会记录、反正出了事再换令牌。就是这些”问题不大”的叠加，把一次本可被限制在局部的小偏差，扩成了一个会让整个组织开始重新思考信任边界的事故。

问题不在一个泄漏点，而在凭据被设计成了常驻能力

很多人一遇到凭据事故，第一反应是去找泄漏点：到底是日志打出来了、上下文带出来了，还是工具层裸传了？这个动作当然必要，但如果复盘只停在这里，下一次事故多半还会换一个入口回来。

因为真正的问题，不是凭据”从哪里漏出去”，而是它为什么会在系统里以一种过于宽松的形态存在——长期有效、上下文可见、可被多类动作复用、且在关键路径上缺少独立裁决。

说得更直接一点：很多 OpenClaw 型系统并不是”保护凭据失败”，而是先把凭据当成一种持续在线能力，再试图用若干补丁证明自己仍然重视安全。

事后复盘会暴露一个更刺眼的事实：系统几乎在每个环节都做了”正确的”事情，但组合起来的效果却是灾难性的。

凭据被存储在专用的密钥管理系统里——这没错。但为了方便，系统启动时会把这些凭据加载到环境变量里，供所有进程访问。这意味着一旦进程启动，凭据就变成了”常驻内存”，任何代码都可以读取。

Agent 被设计为可以访问这些环境变量——这没错，因为它确实需要某些凭据来完成任务。但 Agent 的上下文机制没有区分”普通配置”和”敏感凭据”，所有环境变量都被平等地纳入上下文。

上下文被记录到日志里用于诊断——这没错，日志对于排查问题是必要的。但日志系统没有配置敏感数据过滤，因为”我们以为凭据不会被包含在上下文里”。

日志被长期存储用于审计——这没错，审计是合规要求。但现在这些日志里包含了生产密码，而且存储期限是两年。

每一个单独看都是合理的决策，但串联起来就形成了一条清晰的泄漏路径：凭据从密钥管理 -> 环境变量 -> Agent 上下文 -> 日志 -> 长期存储。

这就是为什么换密钥、加脱敏、补规则常常都只能止血，却很难真正治病。因为病灶不在某次泄漏，而在”凭据被设计成默认可取用”这个前提本身。

为什么事故发生前，系统看上去仍然像是”合规”的

这类问题最麻烦的地方，是它经常通过很多传统安全检查。

事发后重新审视安全合规状态时，一个刺眼事实浮现出来：几乎所有常规安全检查项目都显示”通过”。

密钥被托管在专用的密钥管理系统里——符合”密钥管理”要求。环境变量被标记为敏感——符合”敏感数据标识”要求。访问日志被完整记录——符合”审计日志”要求。日志存储在加密的空间里——符合”数据加密”要求。系统有定期轮换策略——符合”密钥轮换”要求。

所有这些动作单独拿出来都没错，但它们大多属于静态合规。而 Agent 时代的危险，越来越多发生在运行时。

风险不再只是”凭据被谁存着”，而是”凭据在什么上下文里被谁调用、为了什么动作被调用、调用异常后谁来熔断”。

静态合规给团队一种很强的心理安慰：我们已经做了不少正确动作。但运行时世界从来不按清单思考问题。它只问两件事：

• 当前这个进程手里到底有什么权力？
• 当它做错事时，系统有没有能力在第一时间截断？

如果这两件事回答得含糊，表面合规越完整，事故发生时组织反而越震惊。

一次安全审计复盘里的判断很直接：问题不是没做安全措施，而是安全措施和真正的风险不在同一个维度上。系统在存数据的地方做了保护，但风险发生在用数据的时候。

根因拆解：一次密码外泄事故，往往是三层设计同时失守

第一层：表层现象是密码、令牌或高敏感凭据被模型链路读到了

这是最直观的现象，也最容易引发情绪反应。系统里出现了不该进入模型或工具上下文的敏感信息，或者 Agent 对这类信息形成了超出预期的可见性。

在这类事故里，表层现象就是：生产数据库密码出现在 DEBUG 日志中，而且是多次、明文、无脱敏。

这一层很重要，但它只是结果。如果只停留在这里，解决方案就很简单：加强日志过滤、增加脱敏规则、检查上下文清理。团队也确实立即实施了这些修复。

但如果不深入下一层，同样的问题还会在其他地方出现。因为根本问题不是”日志配置不当”，而是”凭据为什么会到达日志系统”。

第二层：真正失效的是凭据与动作边界没有被拆开

如果系统把”拿到凭据”和”可以用凭据做事”默认视作一件连续动作，那么事故迟早会来。成熟系统必须把凭据访问、动作授权和风险裁决拆成不同层。

复盘时可以看到，系统的设计假设是：如果 Agent “需要”凭据来完成任务，那么给它访问凭据就是合理的。这个假设忽略了几个关键问题：

• Agent “需要”凭据来完成任务，不等于 Agent 的每个动作都需要凭据
• 即使需要凭据，也不等于应该访问最高权限的凭据
• 即使访问了凭据，也不等于应该让凭据在上下文中”常驻”

在这种设计里，一旦 Agent 启动，凭据就变成了”环境的一部分”。Agent 不需要为每次使用凭据做额外申请，不需要证明这次使用是合理的，不需要在异常情况下放弃凭据。凭据只是”在那里”，随时可用。

这意味着，一个原本只是读取日志的任务，可能因为上下文的”污染”而意外接触到数据库凭据。Agent 不需要恶意 intent，只需要正常的上下文继承机制，就可能把敏感信息带入不该出现的地方。

正确的做法是把凭据访问设计成”按需申请”模式：Agent 明确申请”我需要访问数据库来完成任务 X”，系统根据任务 X 的性质决定是否批准、批准什么级别的凭据、有效期多长。使用后凭据立即失效，不残留在上下文中。

第三层：更深的问题是组织始终把运行时治理当成后补工程

多数团队并非不知道运行时隔离的重要性，只是总觉得它可以等下一版。结果是：方便性被优先设计，治理性被延后讨论。等真的出了事故，大家才开始意识到，自己过去以为只是”技术债”的东西，其实一直在定义事故半径。

项目时间线显示，三个月前的技术评审已经识别过同类风险：Agent 访问过多凭据，且运行时隔离不足。但这条风险没有转化为排期、owner 和控制项，而是被放进后续安全加固的待办列表。

这个”后面”永远没来。功能一个接一个上线，用户越来越多，系统越来越复杂，但凭据治理始终停留在”待办事项”列表里。每次讨论优先级，它都会被更重要、更紧急的需求挤掉。

这不是某个团队特有的问题，而是一个普遍模式：运行时治理不如功能实现性感，不如性能优化可量化，不如用户体验有直接反馈。它很难被看见，直到事故发生。

但真正的问题是，在 Agent 系统里，运行时治理不是可以”后面再补”的东西。一旦你把高权限凭据交给 Agent，你就已经承担了相应的风险。延迟治理不会降低风险，只会增加风险累积的时间。

这次事故真正教会我们的，不是”别让模型看到秘密”，而是”别让秘密成为一条默认通路”

这类事故最容易把团队带向一个错误结论：以后要更严格地隐藏信息。这个结论不算错，但还不够深。

更有用的结论应该是：系统必须尽量避免让高敏感凭据以一种可被长期引用、跨任务使用、上下文混杂的方式存在。换句话说，不是单纯地”藏起来”，而是要让秘密在系统里的存在方式本身就更脆弱、更短命、更局部。

这意味着：

凭据应尽量任务级、会话级发放，而不是长期悬挂在线上环境里。更好的方案是：Agent 启动时不预加载所有凭据，而是在每次需要时向凭据服务申请短期令牌。令牌有效期只有几分钟到几小时，且只包含完成当前任务所需的最小权限。

高危调用前必须有独立于模型语义链的裁决层。不是 Agent 说”我要访问数据库”，系统就自动给凭据。而是有一个独立的策略层，根据当前任务、历史行为、风险模型等因素，判断这次调用是否应该被允许。

一旦上下文出现异常组合，系统应优先熔断，而不是继续猜测模型会不会自我克制。如果 Agent 的上下文里突然出现了它不应该接触的敏感信息，或者它试图执行超出任务范围的动，系统应该立即暂停执行，转人工确认。

审计要能回答”为什么允许”，而不只是”确实调用过”。日志应记录：这次凭据申请基于什么策略批准、批准有效期多久、任务完成后凭据是否被正确回收。这些审计信息让事后复盘成为可能，也让异常检测有了依据。

如果重新设计，防线应该怎么补

如果把这类系统重新做一遍，优先级应该落在四件事上。

第一，把长期凭据改成短时令牌。 期限越短，事故半径越小；作用域越窄，错误组合越少。令牌有效期应被严格限制，并且只能用于特定任务类型。即使一个令牌被意外记录或泄露，它的可用时间和可用范围都受到约束。

第二，把凭据访问和动作执行拆开。 拿到令牌，不代表自动获得完整动作权限。中间必须有策略判定。Agent 可以申请凭据，但策略层会根据当前上下文决定是否批准、批准什么级别的凭据。这种分离让”访问凭据”和”使用凭据”成为两个可以被独立控制和审计的动作。

第三，把异常熔断前移到运行时。 一旦出现上下文混乱、高敏感动作叠加、或者任务目标与调用参数不一致，默认动作不是继续执行，而是停下来求证。异常模式检测应在 Agent 行为偏离预期模式时自动触发人工确认流程。

第四，把审计从记录结果改成解释过程。 真正有价值的审计，不只是告诉你发生了什么，更要告诉你系统为什么在那个时刻选择了放行。每次凭据申请和使用的日志都包含完整的决策上下文：任务 ID、申请理由、策略依据、批准人（或自动化规则 ID）、有效期、使用记录、回收确认。

结语：密码外泄事故最值得警惕的地方，不是秘密被看见，而是系统早就习惯了把秘密放在不该存在的位置

每次出现这类事故，团队都会说一句很像正确答案的话：我们以后要更谨慎地处理凭据。可如果只是更谨慎，而不重做默认路径，事情大概率还会回来。

因为危险从来不只是”有一次看见了密码”，而是系统在架构层面默认了这样一种生活方式：凭据长期在线，调用边界模糊，异常时继续向前。只要这种默认没变，下一次出事只是换一个工具、换一个进程、换一个时间点而已。

事故后的凭据管理体系会更复杂、更严格，有时候也更麻烦：申请凭据需要流程，不能像以前那样直接从环境变量读取。但这种”麻烦”是必要代价，因为它把默认暴露改成了受控申请。

设计文档应该补上一条凭据设计原则：“凭据应该像现金一样被对待——只在需要时取出，用完立即归还，从不长期持在手中。”

这句话应该成为后续凭据设计的出发点。

所以，这类事故真正逼系统设计面对的，不是怎么更会藏密码，而是怎么重新定义”谁在什么时候，以什么理由，能把一份秘密变成一项动作”。只要这个问题没有被重新设计，所谓修复都只是短暂停战。

事故三个月后，系统日志里不再出现明文密码，而是一行行凭据申请记录：任务 ID、申请时间、批准策略、令牌指纹、有效期、使用状态、回收确认。每一条记录都完整、可追溯、可解释。

系统现在仍然可能有漏洞，但至少，凭据不再是一条默认通路了。

参考与致谢

• 原文：Your AI Agent Knows Your Passwords — Here’s How I Fixed It：https://dev.to/demojacob/your-ai-agent-knows-your-passwords-heres-how-i-fixed-it-4kcd