- AWS published a guide for running the ChatGPT desktop app through Amazon Bedrock in GovCloud (US). In that setup, ChatGPT workspace rules and user roles do not govern the app.
- Control shifts to the customer's device policy and AWS identity. This is one deployment mode, and it moves responsibility rather than adding security.
- Teams should assign owners for the two policy files, check the effective policy after restarts, and look for stray Bedrock API keys.
Who writes the rules for an AI agent
A coding agent reads source code, runs tests and edits files. In practice it holds real access. So someone must decide what it may do.
An AWS walkthrough dated October 30 offers one answer. It covers a single deployment path: the ChatGPT desktop app run through Amazon Bedrock in AWS GovCloud (US). On that path, the customer writes the rules.
What AWS describes
AWS announced that the ChatGPT desktop app can now use Amazon Bedrock in GovCloud (US) for model access. The app has two parts. Work handles larger, multi-step tasks. Codex writes, tests and reviews code.
The guide targets organisations that need model requests to stay on GovCloud identities and endpoints. Requests go to an Amazon Bedrock endpoint called Mantle, in the us-gov-west-1 region. Access can then be managed with AWS's identity service, IAM, and the network controls the customer already has in GovCloud.
AWS also covers pricing and data handling. Billing is by usage, with no per-seat licences or per-developer commitments. Processing stays in the Bedrock region the customer picks. An optional zero data retention mode keeps prompts and responses out of durable storage at AWS. AWS also says it does not pass them to model providers in that mode.
How the control moves
One sentence in the guide carries the weight. In this setup the app talks straight to AWS. AWS says that means ChatGPT workspace rules and user roles do not govern it. It names the computer's policies and the AWS identity in use as the main controls.
Two text files hold the policy. Both must be in place before the app first starts.
The first is requirements.toml. AWS describes it as an administrator-set file of limits that users cannot override. Its examples are the permission levels, tools or settings the app may use. The second is config.toml. It tells the app how to run, including the model provider, the model, permissions and context limits.
Sign-in follows a set order. The app looks first for a variable named AWS_BEARER_TOKEN_BEDROCK. If it finds one, that token wins over profile-based sign-in. Otherwise the app uses the standard AWS credential chain, which includes single sign-on through IAM Identity Center.
Because the bearer token takes precedence, a Bedrock API key placed in the app's environment file (~/.codex/.env) would override the approved profile.
Failure modes AWS expects
AWS's troubleshooting notes name four problems.
If the app asks for an OpenAI account, the policy files were probably not in place at first launch. AWS says to check the file names and locations, end all ChatGPT and Codex processes, and relaunch. Its rule is blunt: the files must precede app launch.
If the wrong AWS identity is used, check the credential source and the named profile. Also check whether a Bedrock API key overrides the profile.
If capability limits are missing, do not trust the file on disk. After a restart, look at the requirements the app actually applies. AWS adds that the API-only sign-in setting does not apply the capability policy.
If the app reports the GovCloud endpoint as unsupported, confirm the exact release, endpoint and model with OpenAI. AWS cautions that editing the web address is not enough to make an endpoint supported.
AWS also says to shield the profile configuration, credential source, single sign-on token cache and any credential helper from writes by the app's tasks. Approved authentication tools must still be able to maintain and refresh credentials.
What this does not settle
AWS states the limit plainly. Using GovCloud and following the guide does not authorise a workload. Each organisation must still test its full setup against its own system security plan and authorisation process. That covers the model and endpoint, the workstations, the code repositories and the data flows.
The setup also uses network restrictions that allow only the approved Bedrock endpoint and disable other external connections. AWS says this gives an agency security team something concrete to test and document before it approves wider use. It is a pilot recipe, not an approval.
The lesson: responsibility moves with the identity
This is the publication's view, not AWS's. In this deployment mode only, day-to-day control shifts from the vendor's workspace to controls the customer owns. Those are the identity system and the device policy.
The guide does not say workspace controls vanish everywhere. It says only that they do not govern this setup.
The shift is one of ownership, not a gain in security. The teams that already run identity and endpoint security now carry work a vendor console would otherwise hold.
Questions to put to your team
Ask who owns the two policy files and how changes to them are reviewed. Ask how the team checks the effective policy after a restart, not just the file on disk.
Ask whether Bedrock API keys could sit on managed devices, and how anyone would find them. Ask what the rollback plan is if a validation check fails. AWS's own answer is to stop the rollout and restore the approved policy. It also says to revoke temporary credentials and record what failed.
A coding agent is only as contained as the identity and device policy behind it.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: AWS.
