OpenAI frontier models and Codex land on AWS Bedrock: what changes for agent builders

OpenAI's GPT-5.5, GPT-5.4, and Codex went GA on Amazon Bedrock on June 1, 2026. Here is what is actually in the box, how access works, and what it means for how you handle credentials.

Authsome

Authsome

Product & engineering

June 2, 202610 min read

OpenAI frontier models and Codex land on AWS Bedrock: what changes for agent builders.

On June 1, 2026, OpenAI and AWS flipped the switch on what had been in limited preview since April. GPT-5.5, GPT-5.4, and Codex are now generally available on Amazon Bedrock (OpenAI, AWS News Blog). For anyone running agents in production, this is a real change in the shape of the market, not just a marketing slide. Below is what was actually announced, what is in the box, how access works, and the part most posts skip. What it means for how you handle credentials.

What was actually announced, and when

There are two announcement moments that get conflated. Worth pulling them apart.

On April 28, 2026, AWS and OpenAI announced an expanded strategic partnership and put three offerings into limited preview. OpenAI frontier models on Bedrock, Codex on Bedrock, and Bedrock Managed Agents powered by OpenAI (AWS What's New, April 28, OpenAI announcement post).

On June 1, 2026, GPT-5.5, GPT-5.4, and Codex went GA on Amazon Bedrock (AWS What's New, June, AWS ML Blog). The Bedrock product page for OpenAI models is live at aws.amazon.com/bedrock/openai.

One thing the headlines tend to gloss. Bedrock Managed Agents powered by OpenAI did not ship to GA on June 1. It remains "coming soon" per the launch posts. So if you read anywhere that "OpenAI Agents on AWS are available now," that is wrong for the Managed Agents product specifically. Codex (the product) is GA. Managed Agents (the runtime) is not.

This sits on top of a longer arc. OpenAI's open-weight models (gpt-oss-20b, gpt-oss-120b, Apache 2.0) shipped on Bedrock and SageMaker JumpStart back on August 5, 2025 (AWS blog). The proprietary frontier models on Bedrock are the new piece.

What is actually in the box

Three things, and the labels matter.

GPT-5.5. Model ID openai.gpt-5.5. 272K-token context window, text plus image input, text output. AWS positions it for "the hardest customer workloads" (GPT-5.5 model card).

GPT-5.4. Positioned as "best price-performance" (AWS News Blog).

Codex. This is the disambiguation that will trip people up. "Codex" on AWS is not a Bedrock model ID. There is no openai.codex listing. Codex is OpenAI's coding agent product suite. The Codex desktop app, the Codex CLI, and IDE extensions for VS Code, JetBrains, and Xcode. What is new is that these clients can now route inference through Amazon Bedrock instead of OpenAI's direct API. The model powering Codex on Bedrock is GPT-5.5 (AWS News Blog, OpenAI). The usage stat both sides keep quoting. More than 4 million weekly active Codex users.

Open-weight gpt-oss-* was already there. The frontier line is the news.

Regions, surfaces, pricing

Three sharp edges worth knowing before you wire anything up.

Regions at GA are narrow.

ModelRegions at launchCross-region inference
GPT-5.5US East (Ohio / us-east-2)In-Region only, no Geo or Global routing
GPT-5.4US East (Ohio), US West (Oregon / us-west-2)In-Region
gpt-oss-*US West (Oregon) on Bedrock, broader on SageMaker JumpStartvaries

Confirmed in the GPT-5.5 model card and the AWS News Blog. No EU, UK, APAC, or AWS GovCloud availability for the frontier models at launch. That is a blocker for GDPR-bound European customers and for FedRAMP / IL workloads.

The API surface is new, and narrower than you might assume.

The proprietary frontier models are not served on bedrock-runtime. They live on a new endpoint called bedrock-mantle, with URLs of the form https://bedrock-mantle.{region}.api.aws/openai/v1/responses (Bedrock Mantle docs).

At GA, GPT-5.5 and GPT-5.4 support the OpenAI Responses API only. They do not support the Bedrock Converse API and they do not support the Chat Completions API, which is a clean break from how gpt-oss-* and the Anthropic, Llama, and Nova families work on Bedrock (AWS docs, model-parameters-openai). If you built your stack on Converse so you could swap models with one parameter change, porting to GPT-5.5 is more than a model ID switch. Service tier at launch is Standard pay-per-token only. No Priority, no Flex, no Reserved.

Warning

If you have a Bedrock-shaped abstraction layer that calls Converse, plan for a real porting tax to talk to GPT-5.5 / GPT-5.4. They speak Responses, not Converse. Tool calling, streaming, and structured output all live on a different surface than the rest of your Bedrock fleet.

Pricing is "matches OpenAI first-party rates, no additional AWS fees," with usage counting toward existing AWS commitments (AWS News Blog). Specific per-token figures were not in the launch posts. The canonical source is the Bedrock pricing page. The "no AWS premium" framing is the load-bearing claim here. Verify against your own account's published rates before you build budget around it.

How access actually works

Three paths are documented, and they are not interchangeable. Knowing which one you are on tells you what your credential model has to look like.

1. Standard AWS IAM. The canonical Bedrock path. You grant bedrock:InvokeModel (and the equivalent on the Responses endpoint) by model ARN through IAM policy, your SDK signs requests with SigV4, and you can issue short-lived credentials via STS / SSO. This is the production path for any enterprise that already runs on AWS, and it is the one your security team will want.

2. Amazon Bedrock API key. A long-term key minted in the Bedrock console, used as a Bearer token via the AWS_BEARER_TOKEN_BEDROCK environment variable. This is the auth method documented for use when calling via the OpenAI SDK or the OpenAI Chat Completions API path. AWS docs are explicit. "If you use the OpenAI Chat completions API, you can only authenticate with an Amazon Bedrock API key" (AWS docs). This is what lets you point an off-the-shelf OpenAI client at Bedrock by overriding OPENAI_BASE_URL.

3. Not an OpenAI API key. Worth saying out loud. You do not bring a sk-... to Bedrock. The "Bedrock API key" is an AWS-issued credential that happens to be acceptable as a Bearer token to OpenAI-shaped endpoints.

For the Codex CLI specifically, the documented production setup is option 2. Set the Bedrock API key as OPENAI_API_KEY and point OPENAI_BASE_URL at the bedrock-mantle endpoint. Codex CLI's ~/.codex/config.toml also supports an amazon-bedrock provider that can pick up AWS profiles and SSO.

Credential-model implications, honestly

This is the part most launch coverage skips, and it is where multi-cloud AI starts costing real engineering hours. Three different paths, three different secrets stories.

If your agent talks to Bedrock the AWS-native way (SigV4 / IAM). Your credential story is an AWS credential story. The right answer is short-lived STS credentials sourced from an OIDC trust (AWS IAM Roles for Service Accounts in EKS, GitHub Actions OIDC, or aws sso login for developer machines), scoped by IAM policy to the specific model ARN and region. No long-lived AKIA... keys on disk, ever. SigV4 signs the entire request including the timestamp and body hash with a derived key, so there is nothing static to inject on the wire. If you are on this path, what you want is OIDC-to-STS and tight IAM policies, plus CloudTrail on the model invocation. Tools like aws-vault and the AWS SDK credential chain are doing the work here.

If your agent uses an OpenAI-shaped client against bedrock-mantle (Bedrock API key). Now you are back in a familiar shape. There is a long-lived Bearer token (AWS_BEARER_TOKEN_BEDROCK) that the OpenAI SDK reads from an environment variable. Same risks as any other API key in env. Prompt injection that pages os.environ, plugin processes that inherit env, shell history, accidental log lines. The same hygiene that applies to OpenAI direct keys (openai-api-key-hygiene-for-ai-agents) applies here. Keep it out of .env files, prefer per-process scope, and rotate.

If your agent uses Codex CLI in either mode. Check the config. Codex CLI happily accepts a Bedrock API key in OPENAI_API_KEY, and most quickstart guides will tell you to put it there. That is the moment you should ask whether you want a long-lived AWS-minted Bearer token sitting in your shell environment for the duration of your work session.

For the Bedrock-API-key path specifically, a local credential broker is one tool that fits the shape. AWS is not a bundled provider in Authsome today and SigV4 is not something a header-injection proxy handles cleanly. So for the IAM / SigV4 path, the right answer is short-lived STS credentials via OIDC, not a broker. For the long-lived AWS_BEARER_TOKEN_BEDROCK path, the broker pattern (described in agent-credential-brokers-in-2026) reduces blast radius the same way it does for OpenAI direct or any other Bearer-token API. You would register Bedrock as a custom provider via a local JSON entry and the agent process would never hold the token. Pick the path that matches how you call Bedrock, and use the credential tool that fits.

A useful read alongside this. aws-secrets-manager-isnt-built-for-ai-agents, which covers why "fetch the secret from Secrets Manager into your agent process" is a different question from "keep the secret out of the agent process."

Open questions worth tracking

A few honest gaps in what was announced.

Data residency. GPT-5.5 in us-east-2 only at GA, in-Region only, no cross-region routing. Nothing in EU, UK, APAC, or GovCloud. For data-residency-sensitive workloads this is the blocker.

Fine-tuning. Not mentioned in any AWS or OpenAI primary source for GPT-5.5 / GPT-5.4 / Codex on Bedrock at GA. Treat as unsupported until AWS publishes a workflow.

Versioning lag. No public statement on whether Bedrock will trail OpenAI direct on intermediate releases. "Available the same day" was not promised.

Managed Agents. Bedrock Managed Agents powered by OpenAI, announced in April, remains "coming soon" as of June 1. The differentiated agent runtime is announced-but-not-shipped.

Function calling and tool use. The Responses API on bedrock-mantle "supports hosted tools, function tools, or richer tool orchestration" per the AWS News Blog. Parity with OpenAI direct on the full Responses tool surface, including streaming tool deltas and structured outputs, is the thing to test before you migrate production traffic.

Guardrails, PrivateLink, CloudTrail. These work via Bedrock's standard headers (X-Amzn-Bedrock-GuardrailIdentifier and friends) for the new models. A real selling point of the Bedrock path versus OpenAI direct, especially if you already have those controls in place for Claude or Nova.

What to watch next

Three things, roughly in order of how soon they will matter.

  1. Region expansion for GPT-5.5 and GPT-5.4. Until EU and APAC light up, this is a US-only frontier story on Bedrock.
  2. Managed Agents GA. The "Codex on Bedrock" story today is "point your client at our endpoint." The "Managed Agents" story is supposed to be a different runtime with per-agent identity baked in. Watch for the GA post.
  3. Whether Converse API support arrives. If you have a multi-model Bedrock abstraction, this determines whether GPT-5.5 ever becomes a one-line swap or stays in its own Responses-shaped corner forever.

If you are setting up agent stacks against Bedrock this week, the practical short version. Figure out which of the three access paths you are on (IAM, Bedrock API key via OpenAI SDK, or Codex CLI), and pick the credential model that matches. The paths have genuinely different answers, and that is a feature of the underlying design, not a thing any tool can paper over.

Authsome

Authsome

Product & engineering

Local credential broker and vault for AI agents.