OpenAI Codex on Amazon Bedrock

Developers increasingly use Codex with Amazon Bedrock to explore unfamiliar code, make changes, and handle repetitive engineering work. For platform teams, the challenge is to make those tools available without creating a second model-access, identity, and operations stack. Codex can use Amazon Bedrock for inference with supported OpenAI models. In this post, we show how to fit that path into the AWS identity, AWS Identity and Access Management (IAM), Regional, and observability practices your organization already uses. Codex still runs on the developer workstation. The main design choice is how its model requests reach Amazon Bedrock and where your organization applies policy and operational controls. We begin with a small, least-privilege pilot and work through the checks that matter before access expands. The examples use GPT-5.6 Sol. Before starting the pilot, review Supported models by AWS Region in Amazon Bedrock to confirm that Sol, Terra, or Luna is available in the AWS Region and inference path you plan to use. Recommended default: Start with Native AWS Access for a small, least-privilege pilot. Choose AgentCore Gateway, a capability of Amazon Bedrock AgentCore, when you want AWS managed gateway infrastructure for routing or Amazon Bedrock Guardrails. Choose an LLM Gateway when a platform team wants to enforce controls in the request path. A custom integration is the advanced version of the LLM Gateway pattern, not a quick start. The examples come from the open source Guidance for Codex on AWS repository. It includes quick starts for Native AWS Access, AgentCore Gateway, LiteLLM on ECS, Portkey, the AWS Distro for OpenTelemetry (ADOT), and the Amazon CloudWatch setup used later in the post. Choose the quick start that matches your architecture, use it for the pilot, and adapt it to your environment. Choose your rollout path Authentication is only one part of an enterprise rollout. Decide who can use the service and which models and Regions are approved. Also define where configuration lives, what telemetry to collect, how usage is allocated, and which skills or Model Context Protocol (MCP) servers are allowed. The following table maps those needs to an access path and an owning team. Choose the access path that provides the controls you need now. The most straightforward path that meets the requirement usually has the lowest operational overhead. Decision rules Native AWS Access is the usual starting point when AWS identity and IAM controls are enough for the pilot. Amazon Bedrock AgentCore is a platform to build, connect, and optimize agents at scale, with any framework or model. Within the platform, AgentCore Gateway fits teams that want AWS managed gateway infrastructure for routing, Amazon Bedrock Guardrails, or related controls. A large language model (LLM) Gateway fits organizations that already operate a gateway or want to enforce controls in the request path. Building a custom gateway is the advanced version of this option. The following diagram compares where identity, routing, policy, telemetry, and operational ownership sit across the three rollout paths. Figure 1: Codex runs on the developer workstation in each scenario. Native AWS Access uses AWS IAM Identity Center, a configured AgentCore Gateway can apply managed routing and Guardrails, and a configured LLM Gateway can apply request-path controls Native AWS Access If Native AWS Access fits the pilot, the repository’s Native AWS Access quick start provides the complete procedure and supporting files. The following abbreviated walkthrough focuses on the sequence and the checks that matter most. Use your workforce identity provider for sign-in Employees continue to sign in through the identity provider they already use. In this example, Okta handles authentication through Security Assertion Markup Language (SAML) and provisions users and groups into IAM Identity Center through System for Cross-domain Identity Management (SCIM). IAM Identity Center then issues the temporary AWS credentials used by Codex. The identity provider is not configured in Codex. Prerequisites Add each pilot user to a dedicated group in the workforce identity system and provision that group to IAM Identity Center. Keep the assignment limited to the pilot. Choose an Amazon Bedrock Region and an OpenAI model available to the pilot identity, plus an inference profile if the selected API requires one. Check Sol, Terra, and Luna separately for the chosen account, Region, and inference path. Grant only the Amazon Bedrock model inference permissions used by Codex, any direct validation commands, and the selected observability destination. Prepare a non-production repository and name a rollback owner. Configure The pilot has three checks. First, sign in using the IAM Identity Center profile configured for the AWS Command Line Interface (AWS CLI) and call Amazon Bedrock Runtime directly. Next, point Codex to the approved model. Finally, run a safe Codex task. The direct call isolates AWS access problems. The final step confirms the Codex configuration. Step 1: Sign in and validate Amazon Bedrock Runtime access. aws sso login --profile codex-bedrock export AWS_PROFILE=codex-bedrock aws bedrock-runtime converse --model-id us.openai.gpt-5.6-sol --messages '[{"role":"user","content":[{"text":"Reply with OK"}]}]' --region us-east-2 This command creates a short-lived AWS session and checks whether the profile can invoke the chosen model in the chosen Region. If it fails, resolve the profile, Region, model or inference-profile access, or IAM permissions before configuring Codex. Step 2: Configure the Codex provider. # ~/.codex/config.toml (or managed user configuration) model_provider = "amazon-bedrock" model = "openai.gpt-5.6-sol" [model_providers.amazon-bedrock.aws] profile = "codex-bedrock" region = "us-east-2" The model value is the Codex model ID. The profile selects the AWS IAM Identity Center session, and region tells Codex which AWS Region to use. Keep these settings in user-level or managed configuration so a repository cannot change the provider. Verify the pilot and confirm rollback Before adding users, make sure the pilot reaches the approved model, produces the expected records, and can be disabled cleanly. Identity: aws sts get-caller-identity returns the expected IAM Identity Center assumed-role session. Model access: The pilot profile invokes the approved model through the API and Region selected for the test. Codex access: The user completes a safe, read-only task in a non-production repository, and the expected request-path evidence is available. Evidence and rollback: The identity, invocation, audit, and optional telemetry records are present. Remove the configuration or IAM Identity Center assignment, handle any active session according to your procedure or wait for it to expire, and verify that a new invocation is denied. Watch the Native AWS Access walkthrough The walkthrough shows the complete pilot sequence: workforce sign-in, direct Amazon Bedrock Runtime validation, Codex provider configuration, and a safe test task. Figure 2: Native AWS Access walkthrough covering workforce sign-in, Amazon Bedrock Runtime validation, Codex provider configuration, and a safe pilot task Use the video to verify the order of the checks and the evidence to collect before adding more pilot users. Run a two-user identity-isolation check Two users are required to test identity isolation. A single user shows that sign-in works. A second user tests whether attribution remains distinct. Have two pilot users sign in separately and run the same harmless task. Their assumed-role sessions and audit records, and telemetry records if configured, should remain distinct. The following diagram shows how separate pilot identities should produce separate AWS sessions, request evidence, and optional telemetry while using the same approved Codex and Amazon Bedrock path. Figure 3: Use trusted identity enrollment for attribution. A loca