FR
live

AWS opens Bedrock to OpenAI agents and hosts the Agents API natively with its own governance

In late September 2026, AWS launched Amazon Bedrock Managed Agents powered by OpenAI in public preview — an AWS-native version of OpenAI’s Agents API that runs agents inside your account with your identities and guardrails. If you want OpenAI agents without letting your data leave your AWS perimeter, this is the shortest path.

Two dark granite blocks standing face to face, joined by a single amber cable pulled taut between them.

Late September 2026. AWS opened the public preview of Amazon Bedrock Managed Agents powered by OpenAI. October 5, 2026. The AWS weekly roundup detailed the announcement and added three frontier models to Bedrock. Why it matters: for the first time, you can build agents optimized for OpenAI models and run them entirely inside your AWS account, under the IAM identities, permissions, and guardrails you already have — without routing the data through OpenAI’s own platform.

What “powered by OpenAI” actually means

The announcement rests on a customized version of OpenAI’s Agents API, re-engineered to be AWS-native and integrated with AWS resources. Concretely, the developer keeps the agent logic — the OpenAI model, the orchestration, the tools — but execution happens inside the AWS account, under the identities and policies the team already controls.

The choice of execution environment is explicit. You can use self-hosted compute — an existing development machine, a container, any compute environment — or switch to Amazon Bedrock AgentCore Runtime, which provides managed runtime sessions and configurable storage in your AWS account. It is AWS’s answer to a recurring enterprise objection: production agents must run where the data and the permissions live, not at a third party.

The AWS–OpenAI tie-up becomes structural

This is not just another model added to the catalog. Bedrock has long hosted third-party models — Anthropic, Meta, Mistral — but until now OpenAI was the exception, the competitor whose models were absent from the platform. The arrival of the Agents API in an AWS-native form marks a change in kind: it is no longer just the model that is integrated, but OpenAI’s orchestration layer itself.

The October 5, 2026 roundup confirms the shift by broadening the frontier model catalog on Bedrock. GPT-6.1 Sol, the successor to GPT-6 Sol, approaches GPT-6 Astra on demanding evaluations at roughly one-fifth of the cost — a direct pitch for agentic coding, computer use, and professional work. GPT-6 Astra gains an UltraFast mode, a premium speed tier up to six times faster at 300 tokens per second on the API. And Claude Sonnet 5.5 arrives as an evolution of Sonnet 5, stronger on coding and well-scoped tasks.

What it changes for governance

The real value of the announcement is not technical; it is organizational. Enterprises that block OpenAI on data residency, network perimeter, or compliance grounds face a dilemma: adopt the best-performing models, or reject them because they imply a flow to an outside platform. Bedrock Managed Agents cuts through that dilemma by keeping execution inside the account.

The financial services and healthcare example is telling. A bank may want an agent that reads internal documents and summarizes client files: with the Agents API called directly, every request leaves for OpenAI. With Bedrock, the agent runs in the company’s VPC, under its IAM roles, with its governance policies. The model is still OpenAI’s — but the perimeter stays the bank’s.

The trade-off is just as clear: the choice ties you closer to AWS. A team seeking multi-cloud portability, wanting to switch inference providers without friction, will see another dependency. Bedrock Managed Agents is not a neutral abstraction; it is an AWS integration — which is precisely its strength for those already on the platform.

The broader context of managed agents

The announcement sits inside a race where every hyperscaler wants to host everyone else’s agents. AWS already offered Bedrock AgentCore and pushes its own models, but opening up to OpenAI’s Agents API shows a deliberate strategy: to be the control plane for agents, whatever model powers them.

The same roundup announces service lifecycle changes as of September 29, 2026 — some services move to maintenance and stop accepting new customers from October 29, 2026. The underlying message is consistent: AWS is concentrating investment on the agent and generative AI layer, even if it means rationalizing the rest of the catalog.

For DevOps and SRE teams, the practical consequence is one more choice in agent architecture. Until now, deploying an OpenAI agent in production meant either calling the API directly or rebuilding the orchestration yourself. Bedrock Managed Agents offers a third way: OpenAI’s orchestration, AWS’s execution. What remains to be verified through the preview is whether the customized Agents API stays faithful enough to carry real workloads without surprises.

The concrete guardrails of the integration

Saying “inside your AWS account” is not enough; it is worth spelling out what it locks down. An agent run through Bedrock Managed Agents inherits the account’s IAM roles: it can only touch the resources its policy allows, whether an S3 bucket, a DynamoDB table, or a Secrets Manager secret. Calls are traceable in CloudTrail, which answers a basic audit requirement — knowing who triggered what, even when the actor is an autonomous agent.

The network follows the same logic. A deployment that places the runtime in a private VPC keeps the agent’s traffic inside the perimeter, away from the public internet. Combined with Bedrock Guardrails, which filter sensitive content and outputs, the whole forms a compliance contract that the raw Agents API does not provide on its own. A bank that already holds a SOC 2 or ISO 27001 posture on AWS can point at the same controls for its agents, instead of arguing from scratch about a third party.

This deep integration has a strategic downside. Microsoft pushes Azure OpenAI Service, Google pushes Vertex AI and Gemini: every hyperscaler wants to be where the others’ agents run. AWS, by opening Bedrock to OpenAI’s Agents API, chooses the role of neutral host — the platform that welcomes every model but holds the keys to deployment. It is a defensible position as long as customers value governance over portability.

For teams evaluating the preview, two things deserve scrutiny. First, fidelity: how much of the full Agents API surface survives the AWS-native re-engineering, and whether the gaps matter for your orchestration. Second, the cost model: the choice between self-hosted compute and Bedrock AgentCore Runtime changes both the bill and the operational burden, so measure the managed runtime against your own infrastructure before committing. A preview is the right moment to run a real workload through it, not just a demo.

Verdict

If you are already on AWS and want OpenAI agents without letting your data leave or giving up your IAM identities and guardrails, try Bedrock Managed Agents in preview now: it is the shortest path from an OpenAI model to a compliant deployment. If your priority is multi-cloud portability or independence from a single vendor, stick with the Agents API directly or a homegrown orchestration: the Bedrock integration is powerful, but it anchors you to AWS. If you are weighing frontier models, the simultaneous presence of GPT-6.1 Sol, GPT-6 Astra UltraFast, and Claude Sonnet 5.5 on Bedrock makes the platform a credible testbed for comparing price, latency, and quality before you commit. The preview is early, so treat it as a testbed rather than a migration target.

References

The cyber brief, every Tuesday

The flaws that matter and the patches to apply, in a ten-minute read.

No spam. One-click unsubscribe.
read next

On the same topic

Amazon ECS adds blue/green, linear and canary deployments through VPC Lattice

On October 2, 2026, Amazon ECS introduced blue/green, linear and canary deployment strategies driven natively by VPC Lattice, with lifecycle-hook validation and automatic rollback on CloudWatch alarms. Teams that already communicate across VPCs through Lattice can now shift traffic in stages without leaving ECS or deploying a service mesh.

GKE speeds up pod startup up to 2x without over-provisioning CPU

Google launched CPU startup boost for GKE in preview, temporarily raising a container’s CPU during initialization and stepping it back to steady state without a restart, built on Kubernetes In-place Pod Resize. Java, Node.js and Python services suffering slow cold starts get up to 2x faster startup without paying for idle CPU headroom.

← Back to the feed

Type at least two characters.

↑ ↓ navigate ↵ open esc dismiss