在 AWS 政府云受控部署 ChatGPT 桌面端

把 Codex 的模型请求接入 AWS GovCloud (US)，难点不只是改一个 API 地址。这篇 AWS ML Blog 给出了一套受控部署方案：用 AWS 身份调用 Amazon Bedrock，再通过设备策略限制登录方式、网络出口和可用能力，验证后才扩大使用范围。

对国内前端和全栈开发者，它更适合作为企业 AI 编程工具的治理案例来读。最有价值的是分清三件事：请求发给谁、工具能做什么，以及如何证明配置确实生效。

接入 Bedrock 后，谁来管 Codex

原文介绍了 ChatGPT desktop app 的两类用途：Work 处理需要规划、研究、文件和成品交付的任务；Codex 负责编辑代码、运行测试和审查 pull request。具体配置重点是让 Codex 经由 Amazon Bedrock Mantle，在 us-gov-west-1 调用模型，推理接口使用 Responses API。

这条路径使用 AWS 凭证，主要控制点变成设备策略、AWS 身份和 IAM 权限。ChatGPT workspace 的规则与用户角色不控制这套部署。团队不能把原有工作区管理设置，直接当成新接入方式的安全边界。

作者给出的服务条件包括：按 token 付费，没有席位许可证和每开发者承诺；有数据驻留要求时，处理留在所选 Amazon Bedrock AWS Region；同时支持零数据保留（ZDR）。按原文描述，在这一可配置模式下，提示词和响应不会被 AWS 写入持久存储，也不会共享给模型提供商。

这些陈述限定的是模型服务及相应模式，不能据此推断本地文件、仓库和整个工具链都没有数据留存。原文也明确说明，使用 GovCloud 并照着配置，不会自动获得组织的工作负载授权。

为什么要先写策略，再启动应用

作者把配置拆成两个文件：requirements.toml 是管理员控制的限制，用户不能覆盖；config.toml 决定当前怎么运行，包括 provider、模型、权限和上下文等设置。

配置文件存在，不等于策略已经生效；它们必须在应用启动前就位。

原文用下面这段策略约束登录、沙箱和审批方式：

allowed_login_methods = ["api"]
allowed_sandbox_modes = ["read-only", "workspace-write"]
allowed_approvals_reviewers = ["user"]
allowed_approval_policies = [
{ granular = { sandbox_approval = false, rules = true,
mcp_elicitations = false, request_permissions = false,
skill_approval = true } },
]
allowed_web_search_modes = ["disabled", "cached"]
allow_browser_and_computer_use = false
allow_appshots = false
allow_remote_control = false
allow_login_shell = false
allow_managed_hooks_only = true
check_for_update_on_startup = false
mcp_servers = {}

重点看 allowed_login_methods = ["api"]：它只限制登录方式。浏览器、远程控制、MCP 和其他能力，还需要各自的策略，不能靠 API 登录一并解决。

完整基线进一步关闭应用内聊天、语音输入、浏览器和电脑操作、图片生成、记忆、Apps、插件、技能搜索、工作区依赖及 hooks 等功能，并禁用反馈和应用内更新。Windows 还要求 allowed_sandbox_implementations = ["elevated"]、sandbox_private_desktop = true，其中私有桌面必须得到获批运行时支持。

网络限制也有两层：应用层只允许 bedrock-mantle.us-gov-west-1.api.aws，显式拒绝 OpenAI 登录、聊天、遥测及更新等出口；工作区沙箱则用 network_access = false 禁止任务联网。应用发送推理请求，与任务运行时发起网络访问，是两件分别受控的事。

原文粘贴内容没有保留所引用的位置表，因此无法从这份材料确认两个 TOML 文件的准确部署路径。生产部署时，这个缺口必须补齐。

身份、端点和验证，哪一步最容易踩坑

认证有两条路径：Amazon Bedrock API key，以及 AWS SDK credential chain。后者支持通过 AWS IAM Identity Center 使用 AWS SSO。

应用先检查环境变量 AWS_BEARER_TOKEN_BEDROCK。桌面环境可以通过 Windows 的 %USERPROFILE%\.codex\.env，或 Linux、macOS 的 ~/.codex/.env 提供它。只要 bearer token 存在，它就优先于 profile 认证。

没有 bearer token 时，才走标准凭证链，读取 ~/.aws/credentials 和 ~/.aws/config；Windows 对应 %USERPROFILE%\.aws\credentials 和 %USERPROFILE%\.aws\config。SSO 使用 profile 设置与缓存会话取得临时角色凭证，不需要手动写入 credentials 文件。

因此，配置了 codex-il5，不代表实际一定使用它。还要检查环境中有没有优先级更高的 token，并保护 profile、凭证来源、SSO 缓存及 credential helper，避免被任务写入；获批认证工具仍需能够刷新凭证。秘密也不能塞进 TOML。

下面这段把推理接口、Region 和 profile 关联起来：

[model_providers.amazon-bedrock]
base_url = "https://bedrock-mantle.us-gov-west-1.api.aws/openai/v1"
wire_api = "responses"
requires_openai_auth = false
supports_websockets = false
supports_standalone_web_search = false

[model_providers.amazon-bedrock.aws]
region = "us-gov-west-1"
profile = "codex-il5"

[sandbox_workspace_write]
network_access = false

要重点核对 base_url 和 profile。顶层还需设置 model_provider = "amazon-bedrock"、forced_login_method = "api"，并把 REPLACE_WITH_APPROVED_MODEL_ID 换成获批模型。原文没有给出具体模型 ID，也没有列出支持这套部署的最低版本。

运行配置同时采用 sandbox_mode = "workspace-write"、web_search = "cached"，关闭 analytics、feedback 和 memories，并把 OpenTelemetry 的 exporter、trace_exporter、metrics_exporter 设为 "none"，log_user_prompt 设为 false。cached 不能当作允许实时联网搜索来理解。

安装后要保持应用关闭；如果已经启动过，需退出并结束残留的 ChatGPT、Codex 进程，再加载配置。CLI 用 /status 检查 provider，桌面应用也要确认显示 amazon-bedrock。

如果仍提示登录 OpenAI 账号，先查文件名、位置和残留进程；如果端点不受支持，要向 OpenAI 确认确切的 desktop 或 app-server release、端点和模型，改 URL 本身不能建立兼容性；如果限制缺失，则检查重启后的完整有效策略。

验证失败后，原文要求停止推广、恢复已批准配置、撤销临时凭证或 API key，并确认设备无法继续连接 Bedrock，留下失败记录。

我的判断

我认同它把身份、设备能力和网络出口分开管理。单改 provider 只能回答「模型请求去哪儿」，完整部署还必须回答「代理能接触什么」和「谁能改变这些限制」。

但这是一份配置 walkthrough，作者没有提供性能、开发效率、成本或与其他接入方案的对照数据。按 token 计费是否更划算，也不能仅凭没有席位费下结论。

它还有很强的适用前提：组织已经要求使用 AWS GovCloud (US) 的身份、端点和 Region 控制，并拥有受管设备与审批流程。对一般团队，直接照搬会同时失去插件、联网研究、自动更新等能力。禁用更新之后如何分发获批版本，原文也没展开。

相比只限制 API 出口，这套方案覆盖更完整；相比保留联网能力、对依赖源逐项放行，它选择了更严格的能力收缩。哪种合适，取决于允许工具完成什么任务，而不是限制越多越好。

能拿来做什么

• 给团队接入 Codex 时，分别记录实际 AWS 身份、模型端点、管理员限制和运行配置，并检查 AWS_BEARER_TOKEN_BEDROCK 是否覆盖了预期 profile。
• 在前端或 Node 项目中试用受限配置前，先检查任务是否依赖安装包、下载浏览器或外部 API；network_access = false 下，这些步骤需要另行安排获批流程。
• 把 /status、实际凭证来源、有效策略和失败回退步骤纳入验收记录。provider 显示正确，只能证明其中一项配置。
• 将密钥、SSO 缓存和认证辅助程序放在任务写入边界之外，同时保留认证工具正常刷新临时凭证的能力。