模型: openai/gpt-5.4
生成日期: 2026-04-01
书名: Claude Code VS OpenCode：架构、设计与未来
章节: 第17章 — 安全模型对比
Token用量: 约 4,900 input + 1,250 output

17.4 凭证隔离

Credential isolation（凭证隔离）是 agent 架构里最不吸引眼球、却最不能出错的部分之一。只要系统支持插件、MCP、远程 API、包管理、第三方集成，就必须回答一个尖锐问题：到底谁可以直接接触秘密？

最安全、也最应该被当成架构定律的一句话是：插件绝不能直接访问核心凭证。 不能直接拿宿主主模型 key，不能默认继承仓库级 secrets，不能顺手就能碰到全局 token，除非系统明确、分层、可审计地授予过。

OpenCode 的开放性让这个问题尤其重要。越开放的宿主，越容易让第三方代码靠近高权限操作。如果扩展层可以轻易继承宿主的全部凭证上下文，那么一次插件 compromise（失陷/被攻破）就可能变成整个平台 compromise。这里的 compromise 在安全领域是常见词，表示“系统或凭证已经落入不可信状态”。

OMO 则进一步放大了这个问题，因为它不仅有更多扩展类型，还有更多间接执行路径：后台 agent、skill-embedded MCP、兼容层加载组件、跨会话工作流。如果这些组件只是因为“正在参与一次任务”就自动继承宿主秘密，那么凭证传播路径会非常失控。编排越复杂，凭证边界越必须清晰。

Claude Code 的商业姿态让凭证隔离显得更基础。企业环境不能依赖“大家都别乱来”这种善意假设，它需要系统性区分：哪些是产品核心凭证，哪些是用户提供 token，哪些是扩展专属 secret，哪些只应该在某个任务窗口内临时可用。没有这层区分，所谓 enterprise readiness 基本站不住。

在这里，一个非常值得推广的设计模式是 scoped token proxy（带作用域的令牌代理）。它的核心思想是：不要把根凭证直接交给扩展，而是由宿主提供一个 broker/proxy 层。扩展请求的是“能力”，而不是“原始秘密”。宿主再根据策略决定：是否发放、发放什么范围、有效多久、是否记审计日志。

这个模式的优势非常清楚。

第一，扩展看不到最高敏感度的根凭证。

第二，权限可以按服务、仓库、操作类型、时间窗口做细粒度限制。

第三，撤销更容易，因为控制权始终在宿主代理层。

第四，可审计性更强，因为每次能力授予都可以被记录为离散事件。

第五，secret rotation（凭证轮换）更容易。这里的轮换指定期更换密钥值以降低泄漏风险；如果扩展从不直接持有长期 root token，轮换对扩展的冲击就会小很多。

凭证隔离还和沙箱化有很强的协同关系。即使某个扩展拿到了一点 scoped access（有范围限制的访问），如果它仍然被 OS 级沙箱限制在较小的环境里，它把这份访问进一步外传或横向扩大利用的难度就会更高。这也是为什么 Claude Code 的沙箱方向值得重视——它不是和凭证隔离平行，而是互相增强。

当然，凭证管理也有开发体验问题。如果做得过于死板，工程师会绕路，最后把 secret 手动写进环境变量、脚本或本地文件里，反而更危险。所以好的系统不是单纯“越麻烦越安全”，而是应该把“安全获取能力”做成最顺手的路径。

把三者放在一起看，OpenCode 说明开放扩展宿主必须重视秘密边界，OMO 说明编排复杂性会乘法式增加凭证传播路径，Claude Code 则说明商业系统必须把隔离做成基础设施，而不是约定俗成的好习惯。

未来安全扩展体系的一个核心原则应该是：扩展被授予的是 capabilities（能力），而不是 inherited trust（继承而来的原始信任）。前者可以被限制、审计、撤销；后者一旦泄漏，往往就是系统级事故。只要这一原则守住了，扩展生态就还有机会既开放又安全；一旦它被破坏，每多一个插件、一个 skill bridge、一个 MCP connector，就多一个可能泄密的洞。