AWS Documents Controlled ChatGPT Desktop Inference Through GovCloud Bedrock, With Separate Identity and Device Checks

AWS published a walkthrough on October 30 for routing ChatGPT desktop-app model inference through Amazon Bedrock in AWS GovCloud (US). This November 1 technical issue preserves that original date. The tutorial targets organizations that require GovCloud identities, endpoints and Regional controls and uses a controlled local deployment in `us-gov-west-1` through Bedrock Mantle. AWS explicitly says that following the guide or using GovCloud does not authorize a workload by itself. Each organization must review its selected model, services, workstation controls, repositories, credentials, endpoint and data flows under its own security and authorization process.

The proposed desktop experience has two uses. Work handles larger tasks involving planning, research and files; Codex handles technical work such as editing code, running tests and reviewing pull requests. The application or CLI runs on an organization-managed computer and uses configured AWS credentials to send model requests to Bedrock. AWS says that in this direct AWS mode, the effective controls are the computer's policies and the AWS identity and permissions, not the ordinary ChatGPT workspace roles. The post describes Regional processing, per-token pricing without seat commitments, and support for zero data retention, but those properties still have to be checked against the approved configuration and the selected model and endpoint.

Prerequisites are more than installing an app. AWS asks the operator to verify that the exact desktop version supports Bedrock in GovCloud, that an approved GovCloud account and IAM identity exist, and that the chosen model, Region and endpoint are authorized. The walkthrough divides setup into authentication, two configuration files named `requirements.toml` and `config.toml`, and then launch, initialization and verification. Its example named profile is `codex-il5`; that is a configuration label in a tutorial, not a credential to copy. Secrets, bearer tokens and session tokens should remain outside TOML files. The profile configuration, credential source, SSO token cache and helpers also need protection from task writes while legitimate authentication tools may refresh them.

Authentication has an important precedence rule. The application first checks `AWS_BEARER_TOKEN_BEDROCK` in its environment. If set, that bearer token takes precedence over profile-based authentication. If no token is present, the standard AWS SDK credential chain can use the named profile, credential files and an IAM Identity Center SSO session. Therefore a correct-looking profile name does not prove which AWS principal is actually making requests. When a wrong identity appears, inspect the effective credential source and check whether a bearer token has overridden the intended profile. Managed device capability and network restrictions are separate controls; API-mode sign-in by itself does not apply all of them.

AWS says the two configuration files should be in place before the first app launch. If the app has opened already, it should be fully exited and relaunched so the policy and provider configuration are loaded. These are instructions in the vendor's future deployment procedure, not actions performed by this publication on any live service. After launch, the operator checks that the Codex CLI `/status` screen and desktop settings show `amazon-bedrock` as provider. The operator must also verify the approved identity, `us-gov-west-1` endpoint and network restrictions. Seeing a provider label alone would be too weak to prove that data flows and device capabilities meet an agency's authorization conditions.

The article separates several failure cases. An unexpected OpenAI-account prompt can mean the files were missing at startup or placed incorrectly. An unsupported GovCloud endpoint may mean the release, model or endpoint is not supported; changing a URL alone cannot create support. Wrong identity requires examining token precedence and profile resolution. Missing capability restrictions require checking the full effective requirements after a restart, not just confirming API-only login. These are fail-closed checks in a controlled rollout. If verification fails, AWS advises stopping the rollout, restoring the previously approved policy and provider settings, revoking temporary credentials or API keys, and confirming that affected devices no longer connect to Bedrock.

This article does not configure a GovCloud workstation or validate an actual agency environment. The grounded change is AWS's published, controlled configuration path for the desktop app, including the authentication and device-policy boundaries it specifies. A team considering it should obtain its own authorization first, then use the full original guide and current product documentation to validate exact support and data handling. The vendor's claim of availability and its optional retention setting must not be promoted into a blanket compliance guarantee for every installation.