原创解读：Agent 凭据安全真正该优先解决的，不是'放哪里'，而是'谁在什么时候能动它'

版权声明与免责声明 本文基于《Show HN: ClawShell, Process-Level Isolation for OpenClaw Credentials》进行原创解读。原文版权归原作者与原出处所有。本文不构成官方翻译，仅用于学习、研究与观点讨论。

原文参考 Show HN: ClawShell, Process-Level Isolation for OpenClaw Credentials：https://github.com/clawshell/clawshell

开头：凭据安全最常见的错误，不是没加密，而是加密之后大家就放心了

孙伟在安全行业做了十五年，见过各种凭据管理方案，但 OpenClaw 时代给他带来的困惑是全新的。

去年，他负责评估一家公司的 Agent 系统安全状况。

那是一个普通的周三下午，会议室里阳光正好。客户的安全负责人老周是一个四十多岁的中年人，穿着整洁的衬衫，戴着一副金丝眼镜，看起来就是典型的”安全专家”形象。他面前摊开着一叠厚厚的文档，信心满满地介绍着他们的凭据保护措施。

“我们的密钥都托管在 Vault 里，“老周指着投影屏幕上的架构图，“传输过程 TLS 加密，存储时 AES-256 加密，还有定期轮换策略——每 90 天自动轮换一次。凭据安全应该是我们的强项。”

孙伟点点头，脸上带着礼貌的微笑。这种自信他见过太多次了。他等老周说完，然后问了一个让对方愣住的问题：“这些密钥在什么时候、被谁、用什么方式访问过，你们能告诉我吗？”

老周愣了一下，显然没料到这个问题。他扶了扶眼镜，想了想说：“应该能查到审计日志…我们 Vault 有完整的审计功能。”

“那最近一次访问是在什么上下文里？“孙伟追问道，身体微微前倾，“当时 Agent 正在执行什么任务？这个任务的权限范围是什么？任务完成后，凭据是被回收了还是继续驻留在内存里？”

会议室安静了。老周张了张嘴，但答不上来。他转头看向自己的团队，希望能有人帮忙回答，但其他人也都面面相觑。

孙伟靠回椅背，没有继续追问。他见过太多这样的场景了——团队把所有注意力都放在”密钥放在哪里”，却很少有人认真思考”密钥被谁使用”这个问题。

这就是我想明确反驳的流行说法：凭据安全的关键不是”放哪里”，而是”谁在什么时候能动它”。 如果这件事没被说清，存储层再安全，运行时依然会是一块巨大的、持续带电的风险面。

今天只要一谈到凭据安全，团队几乎会本能地把注意力放在三个动作上：托管、加密、轮换。它们都重要，而且在很长一段时间里也确实构成了主流安全叙事。但一旦系统进入 Agent 时代，这套叙事就开始显得不够了。因为危险不再只来自”有人把密钥拿走了”，而越来越来自另一种更隐蔽的情况：密钥本来就在系统里，被一个本不该使用它的进程、在一个本不该执行的上下文里，合规地用掉了。

这也是为什么加密之后大家就放心了，是一种危险的错觉。

这个说法为什么会这么流行

“把密钥管好”之所以流行，不只是因为它听上去对，更因为它容易变成 checklist。

你可以证明：

• 密钥不在代码仓库里
• 密钥存进了专门系统（Vault、KMS、Secrets Manager）
• 密钥有轮换策略（每 90 天自动轮换）
• 访问受到了权限控制（IAM 策略限制）

这些动作都可见、可审计、可汇报，所以它们天然适合组织传播。管理层喜欢它，因为它清晰；合规团队喜欢它，因为它可打勾；工程团队也愿意接受，因为它至少不像运行时隔离那样会直接改变执行链路。

孙伟见过太多安全评估报告，核心内容就是检查这些 checklist 项目。报告通常会说：“客户使用了行业标准的密钥管理方案，传输和存储都有加密保护，符合安全最佳实践。“但孙伟知道，这种评估漏掉了最关键的问题：当密钥被使用时，发生了什么？

问题是，流行并不等于足够。当 OpenClaw 这类系统已经具备执行能力后，真正危险的地方并不只是”秘密是否藏好了”，而是秘密在被调用那一刻，到底有没有被限制在正确的主体和动作里。

流行的凭据安全叙事有一个隐含假设：只要密钥被安全存储，访问控制被正确配置，安全就算完成了。但这个假设在 Agent 时代不再成立。因为 Agent 不是传统的”请求-响应”程序，它是一个持续运行的、有状态的、可能自动执行复杂动作的实体。它可能在任何时候、任何上下文中、以任何理由尝试使用密钥。

如果系统不能回答”谁在什么时候能动它”，那么”放哪里”的答案再完美，也只是安全故事的前半章。

但这个流行说法遗漏了什么

它遗漏了”运行时”这三个字。

一把密钥被完美存放，并不意味着它被完美使用。真正麻烦的时刻，是某个进程拿到了它，某段任务上下文接近了它，某次高风险调用试图依赖它。这时候，危险和存储位置关系已经不大，和执行边界关系极大。

换句话说，静态安全最多回答”谁有机会接近秘密”，运行时安全才回答”谁有机会拿秘密去做事”。对 Agent 系统来说，后者往往更接近事故本体。

孙伟在评估中经常发现这种gap。存储层面，密钥确实被保护得很好——Vault 有严格的访问控制，只有特定角色可以读取，读取需要审批，有完整审计日志。但运行时层面，一旦密钥被读取到内存，它就变成了进程的”财产”，进程可以在任何上下文中使用它，系统不会过问。

这意味着什么？意味着系统最脆弱的时刻，恰恰不是秘密静静躺着的时候，而是秘密开始被”合理调用”的时候。因为越是看起来合理，团队越难在当下察觉哪里不对。

孙伟讲了一个真实案例。某公司的 Agent 系统，密钥存储做得很规范，但运行时有一个问题：Agent 主进程在启动时会读取所有可能用到的密钥，把它们加载到内存里。Agent 有一个插件机制，允许动态加载新功能。某个插件被设计用来读取邮件，但在开发时，开发者为了方便，直接使用了内存里的数据库密钥来存储邮件摘要——这本不该发生，但技术上没有任何阻止机制。

结果，一个本该只能访问邮件的插件，实际上拥有了数据库的完全访问权限。这个权限从来没有被显式授予，它是”继承”来的——从 Agent 主进程继承，从主进程的密钥缓存继承。存储层面的访问控制完全失效了，因为密钥已经在内存里，任何人都可以使用。

这就是运行时隔离缺失的代价。

问题不是”密钥有没有加密”，而是”系统有没有把使用权拆到足够细”

我最想反驳的一点是：很多团队在凭据安全上花了不少力气，但真正的默认前提依然非常粗糙。密钥被安全托管了，可一旦进入任务进程，它就像一张长期有效的通行证；某个执行链只要拿到它，就能越过多个上下文本该存在的细粒度边界。

这意味着什么？意味着系统最脆弱的时刻，恰恰不是秘密静静躺着的时候，而是秘密开始被”合理调用”的时候。因为越是看起来合理，团队越难在当下察觉哪里不对。

所以我想给出一个更尖锐的说法：很多 OpenClaw 凭据事故，不是秘密保管失败，而是使用权拆分失败。

使用权拆分是什么意思？它意味着：

• 密钥的存在（被存储）不等于密钥的可用（被使用）
• 进程能访问密钥，不等于进程里的所有动作都应该能使用密钥
• 任务 A 有权使用密钥，不等于任务 B 也有权使用同样的密钥
• 正常情况下有权使用，不等于异常情况下仍然有权使用

孙伟理想中的凭据安全模型是这样的：

• 密钥被存储时，有最高的安全保护（加密、访问控制、审计）
• 密钥被读取时，有明确的上下文和时限（谁读取、为什么读取、读取后有效期多久）
• 密钥被使用时，有独立的授权检查（即使进程持有密钥，每次使用仍需验证权限）
• 密钥使用完毕后，立即失效或回收（不长期驻留内存）

这种模型把”存储-读取-使用-回收”每个环节都拆开，每个环节都有独立的控制和审计。而不是像现在这样，一旦读取，就等同于无限期授权。

一个更接近现实的判断框架

如果要判断一套 Agent 凭据体系够不够成熟，孙伟不会只问它是不是加密，而会问四件事。

第一，凭据是不是会话级、任务级、动作级逐步收窄的。 如果不是，而是长期高权限常驻，那系统迟早会在运行时把风险养大。

逐步收窄意味着：密钥的使用权限应该随着上下文的变化而变化。Agent 启动时可能只有最基本的权限，当某个具体任务被分配给 Agent 时，系统才临时授予该任务所需的特定权限，任务完成后权限立即回收。动作级更进一步：即使在一个任务内，不同动作的权限也可能不同。读取操作可能不需要密钥，写入操作可能需要特定密钥，高危操作可能需要额外确认。

第二，拿到凭据是否等于默认可以执行高风险动作。 如果两者几乎连在一起，那说明系统仍然把”身份”和”执行权”混成了一团。

理想情况下，持有密钥只是执行的必要条件之一，不是充分条件。系统应该问：你是谁（身份验证）？你想做什么（意图识别）？当前上下文是否允许（环境检查）？这个动作是否在你的权限范围内（授权检查）？只有所有检查通过，执行才被允许。

第三，异常上下文下有没有即时熔断能力。 一旦任务目标漂移、参数越界、上下文可疑，系统是继续让进程试试，还是先停？

孙伟见过太多系统，在”看起来不太对”的情况下仍然继续执行，因为”反正进程有权限”。真正的安全系统应该在异常时倾向于停止，而不是倾向于继续。熔断不是失败，而是一种保护机制。

第四，审计是不是能解释”为什么允许这次使用”。 如果审计只能告诉你用了，没有告诉你为何能用，它就只是记账，不是治理。

完整的审计应该包括：使用的密钥标识、使用时的任务上下文、授权决策的依据、执行的具体动作、执行的结果、异常标记（如果有）。这样的审计让事后分析成为可能，也让异常检测有了基础。

什么场景下旧说法仍然部分成立

当然，我并不是说存储安全不重要。对简单脚本、低执行权自动化或者极小规模内部工具来说，把密钥放对地方依然是高优先级动作。没有这一层，后面更没得谈。

孙伟举了一个例子：一个每天运行一次的定时任务，只做数据备份，不涉及复杂决策，不与其他系统交互。这种场景下，密钥存储安全可能就足够了，因为运行时风险本身就很低。

但一旦系统进入 Agent 执行时代，尤其具备工具调用、环境访问、跨任务上下文和自动操作能力后，继续把凭据安全主要理解成”存储问题”，就会变得越来越危险。因为这时真正昂贵的风险已经从”丢失”转向”误用”。

误用比丢失更难防范，因为它往往发生在”正常”的业务流程中，没有明显的攻击痕迹，也没有异常的行为模式。系统”正常”地读取了密钥，“正常”地执行了操作，只是这个”正常”在特定上下文下不应该发生。

结语：如果系统不能限制秘密被谁在什么情境下使用，那么”保管得很好”只是一个安慰词

孙伟在评估报告的最后通常会写这样一段话：

“凭据安全评估不能只关注存储层面。虽然存储安全是基础，但在 Agent 时代，真正的风险往往发生在运行时。建议客户建立运行时隔离机制，确保密钥的使用被限制在正确的上下文和权限范围内。”

这段话很少被真正采纳。因为运行时隔离比存储加密复杂得多，它要求重新设计执行链路，要求额外的权限检查，要求更复杂的审计。在短期内，它看起来像是”额外的工作”，而不是”必要的投资”。

但孙伟知道，这笔投资迟早要付。要么主动付，建立运行时隔离机制；要么被动付，在事故发生后承受损失。

我越来越觉得，很多安全讨论的问题，不在结论错，而在结论停得太早。说”密钥要加密”当然对，但只说到这里，等于在 OpenClaw 这样的系统里只讲了前半句。

后半句应该是：秘密一旦进入运行时，它就必须立刻失去大部分自由。它应该更短命、更局部、更难被横向复用、更难被不相干动作顺手带走。否则你做的就只是把一颗仍然危险的子弹，从桌面抽屉换到了保险箱；可一旦有人开箱，它照样会被打出去。

所以，如果今天还要我只给一个判断，我会选这个：Agent 凭据安全真正该优先解决的，不是”放哪里”，而是”谁在什么时候能动它”。 如果这个问题不先解决，其他所有安心感都可能只是合规版本的自我安慰。

孙伟最近开始关注像 ClawShell 这样的方案，它们试图在进程级别隔离凭据，让密钥的使用变成一种需要显式申请和授权的动作，而不是默认拥有的能力。这种方案还不够成熟，但方向是对的。

因为凭据安全的终极目标，不是让密钥难以被偷，而是让密钥难以被误用。这两者之间的差别，就是安全思维的代差。

参考与致谢

• 原文：Show HN: ClawShell, Process-Level Isolation for OpenClaw Credentials：https://github.com/clawshell/clawshell