Gemini CLI：OAuth 引导出站与 workspace 配置装载边界

wiki/ai/sources/gemini-cli-oauth-bootstrap-and-workspace-trust.md

分类：ai / sources · 更新：2026-09-14 09:16

Gemini CLI：OAuth 引导出站与 workspace 配置装载边界

结论：工具还没执行，不代表还没发生有权限的操作。 OAuth discovery 会借用客户端的网络位置；仓库配置装载会决定之后运行哪些工具、policy 和 telemetry。二者都应在执行前受控，不能只靠模型看到工具之后再拒绝。

知识点轴：MCP Gateway / harness-runtime / sandbox-security；OAuth discovery 的经验可迁移至 A2A，但本材料不是 A2A 部署案例。

为什么值得深挖

Hermes 的长期 loop 会打开陌生仓库、连接远程工具、跟随鉴权元数据。MCP-Gateway-Runtime 若只在 tools/call 做授权，仍可能遗漏连接建立、凭据发现和配置解释阶段的出站或代码装载。安全修复值得入库，不是因为它属于热门 CLI，而是因为可以提炼成 bootstrap 与配置来源的负例测试。

本轮读到官方 PR、最终 diff、固定 merge 的选定源码和 RFC 9728 §7.7。GitHub API 确认 #29081、#29099 分别在 2026-08-26、08-28 UTC 合并；v0.59.0 的 release 于 09-08 UTC 发布并列出两项。它们是今日发现的新机制证据，不是今日刚发生的漏洞新闻。仓库快照为 106,966 stars（09-14 查询），热度不参与安全结论。

一：OAuth 引导链本身就是权限面

远程 MCP endpoint 可以引导客户端读取 protected-resource metadata，再找到 authorization-server metadata 及后续鉴权 endpoint。客户端的 HTTP 请求来自其所在网络，即使尚未取得 token，也可能具有访问本地/内网服务的隐式能力。这与 grafana-mcp-session-identity-and-egress-boundaries 的“凭据不外发≠出站安全”是同一边界问题。

在 PR #29081 merge 3c311beac2e78336816dd4a123db39743f9fbf85 的 oauth-utils.ts 中，validateOAuthEndpointUrl：

解析 scheme；一般要求 HTTPS，本地开发 HTTP 需要显式允许 loopback。
若调用方给出 expectedOrigin，比较 URL origin；相对地址解析需要明确 base URI。
远程路径拒绝 loopback、private/reserved IP；对 hostname 做异步 DNS lookup，并检查全部返回地址。
解析失败、DNS 失败和安全验证错误变成 OAuthSecurityError；相关发现分支将安全错误继续抛出，而不是当“没找到 metadata”静默降级。

规范与实现要分开。 RFC 9728 §7.7 指出 SSRF 风险，并以 SHOULD 建议采取适当防护，例如阻止内部 IP 请求；它没有在该段要求“全部 OAuth 服务都与资源服务器同源”。代码中的可选 origin 约束属于具体调用路径的防护设计，不应推广成所有跨域授权服务器都不合法。

DNS 检查也不等于传输绑定。 所读 helper 返回的是 URL 字符串，后续仍使用 fetch(validatedUrl)。单凭这一层不能证明连接复用了同一个已验证 IP，也不能证明所有重定向跳点都重新验证。本轮没有执行 rebinding/redirect PoC，不能据此宣布漏洞仍可利用或 SSRF 已彻底消除；应继续审连接层、代理、DNS 与每一跳行为。

二：workspace trust 要在配置装载时生效

PR #29099 merge 0bd1d439751478771c45d3d0895a6a9760554bf4 的最终代码明确了顺序：

GEMINI_RESTRICTED_MODE=true 或 GEMINI_CLI_TRUST_WORKSPACE=false 先得到 untrusted。
显式 GEMINI_CLI_TRUST_WORKSPACE=true 再得到 trusted。
之后才进入 isFolderTrustEnabled、IDE 信任状态与 trusted-folder 文件判定。

所以 restricted 标记不会被“folder trust 功能关闭就放行”提前吞掉；但 并非所有默认环境都 fail-closed：未指定这些环境变量且 folder trust 关闭时，函数仍返回 trusted。不能只读 PR 的标题。

最终 diff 还在不可信 workspace 配置中清除 mcpServers、policyPaths、adminPolicyPaths、tools、telemetry 五类配置面。机制不是“仅不启动 MCP”，而是避免仓库借配置定义其自己的控制策略或外送路径。GEMINI_FOLDER_TRUST 不在所读固定实现中；运维配置应使用实际实现支持的标识，不照抄 PR 过程描述。

迁移到 Hermes / agentic coding 的可执行设计

以下是建议的隔离验收，不是本机已部署配置：

场景	应保留的独立证据
远程服务提供指向内网的 discovery 地址	URL 验证结果与下游实际请求数；最终报错不足以证明没有先请求
hostname 多地址解析、重定向或代理	被验证地址、实际连接地址、每跳策略与网络日志
restricted 与 folder-trust 关闭同时出现	有效信任值及其来源，确认限制优先级
不可信仓库带 MCP / policy / telemetry 配置	装载前后配置差集与进程/出站清单
安全验证失败	不走 fallback 的错误类别，且不泄露 secret 到诊断

这补充 Harness-Engineering 的“有效配置”原则：保存系统/用户/仓库配置的来源和最终值，不能仅记录一个 restricted=true 宣告。对 A2A-Agent2Agent-Protocol，同样要审 Card→OAuth metadata→token endpoint 的引导链，但具体标准/绑定不能照搬 MCP 实现。

验证范围与未解问题

本轮仅完成代码/元数据静态核对；与另外两项雷达材料合计的 21 项离线检查中，本材料有 7 项。没有运行上游测试、启动 Gemini CLI、改变用户环境变量、连接企业工具或进行网络攻击。

未验证项包括：完整请求链的重定向处理、连接 IP 固定、企业代理和 split-DNS 行为、可信用户/系统配置的完整合并语义。源码局部证据不升级成产品级安全认证。

来源与关联

PR #29081、PR #29099、v0.59.0。
RFC 9728 §7.7，raw 仅归档此完整章节，不冒称全文已读。
AI-Knowledge-Point-Radar · llm-wiki-optimization-2026-09-14。

写入记录

2026-09-14 09:15 CST：新增固定 PR/merge 的 bootstrap 出站与 workspace 配置机制；区分规范、最终实现、静态核查和未执行的网络验收。