What to look for when OpenAI comes to AWS Bedrock: Why agent runtime sovereignty and audit boundaries are more important than model performance

One-line problem definition: As OpenAI's latest model, Codex, and Managed Agents are introduced into AWS Bedrock, it is easy for companies to think, “Now I can use OpenAI directly within AWS.” However, the actual adoption decision depends more on where it runs, who authenticates it, what logs are left, and who controls long-term tasksthan on model performance. This article is intended for AWS-centric operations teams, platform engineers, security personnel, and AI adoption decision-makers. Conversely, this structure may be overkill for individual experiments or teams that only need simple prompt calls.

1. First, conclusion

Key one-line summary: The essence of this announcement is not that “OpenAI models have been added to AWS,” but To be able to move the control plane of agent execution into AWS governance. The point is that it is done.

For companies that already have AWS IAM, PrivateLink, CloudTrail, cloud commit budget, and internal approval procedures in place, Bedrock Managed Agents is worth a look. Conversely, if a team wants to be the first to use model features or wants to directly control tool configuration and orchestration in great detail, direct integration with OpenAI may be faster.

My judgment is clear. For organizations with strong regulations or where internal audit is important, Bedrock is more natural, and for startups where product speed and freedom of experimentation are more important, direct OpenAI API is better. For organizations focused on Microsoft 365, Teams, and Entra, Microsoft Foundry Agent Service is likely to be more consistent.

2. What is the real problem that this announcement targets

Key one-line summary: Companies want “AI that fits within the existing security, permission, and network system” rather than a good model.

Many organizations achieve AI PoC quickly but are stuck in operational transition. There are three reasons:

1. Separate permission system: The model is good, but if you play separately from the in-house IAM, network, and audit log system, operation approval will be delayed.
2. Tool execution anxiety: When agents start messing with files, repositories, ticket systems, and internal APIs, “where they are run” becomes important.
3. Lack of long-term task control: Multi-step tasks have more points of failure than a single API call, and retries, sessions, and isolation are key.

The structure introduced by AWS and OpenAI together targets this bottleneck. The OpenAI announcement emphasized the ability to use models, Codex, and Managed Agents while maintaining existing security, procurement, and compliance procedures within the AWS environment (2026-04-28), and the AWS announcement brought IAM, PrivateLink, CloudTrail, encryption, and AgentCore basic execution environment to the forefront (2026-04-28).

3. Core Structure Decomposition: What's New and How It's Connected

Key one-line summary: This structure does not add model API, but rather bundles model layer, agent layer, execution layer, and audit layer. This is the announcement.

• OpenAI model on Bedrock: Call an OpenAI model like GPT-5.5 on the Bedrock API surface.
• Codex on Bedrock: Codex CLI·Desktop App·VS Code extension to use Bedrock as inference provider.
• Bedrock Managed Agents powered by OpenAI: Runs OpenAI frontier model + OpenAI harness managed within AWS infrastructure.
• AgentCore: Execution base responsible for session, security isolation, scaling, version, endpoint, and microVM isolation, as per AWS documentation.

To put it simply, the model is the “brain,” OpenAI harness is the “work habit,” and AgentCore is the “secure office and access record system.” For businesses, the problem is the office rather than the brain. This is because without an office, audits and accident recovery are not possible.

4. Why did we choose this design: Design intent and trade-offs

Key one-liners: OpenAI gains speed of adoption, AWS gains operational control, and customers gain accelerated internal approvals.

From OpenAI's perspective, it is faster to build on the enterprise trust that AWS has already secured, rather than directly persuading all companies to pass a separate security review. From AWS's perspective, model competition alone weakens differentiation, so it is advantageous to sell the agent execution environment and audit system together.

Instead, it is clear that we are giving up. Customers gain more integration benefits compared to direct integration with OpenAI.Platform abstractionInsert one more. This means that the debugging path is longer, the range of available regions and features may be narrow in limited preview stages, and the latest features may always lag behind the direct API.

It seems to me that the real intention of this structure is not to “sell the best performing model everywhere”, but to make companies treat agents as procurable operational assets rather than experiments

5. Evidence and comparison: What should you compare with to make a judgment?

Key one-line summary: The comparison is not simply Claude or Gemini, but Who owns the agent runtime

The AWS announcement stated that all inference is done in Bedrock and each agent has its own identity and action log. On the other hand, the OpenAI direct method requires the team to create this control structure themselves. Microsoft Foundry provides managed hosting·scaling·identity·observability in its official documentation and distinguishes between Hosted agents·Workflow agents·Prompt agents.

6. Actual operation flow: In what order should practitioners verify

Key one-line summary: Permission·Session·Log·Network must be added before model testing.

1. Step 1 - Isolate why you are using it.
   Isolate whether you need chat responses, code work, or a multi-step agent. If it is a simple question and answer, there is no need to go to Managed Agents.
2. Step 2 - Determine trust boundaries.
   First decide which data should stay inside the VPC, which tools will be read-only, and how many minutes the maximum time for long-term operations will be allowed.
3. Step 3 - Determine the execution log schema first.
   At least request_id, runtime_session_id, tool_name, Please leave actor_identity, target_system, result_status
4. Step 4 - Divide permissions.
   Divide IAM roles for each agent and separate access to storage, tickets, documents, and distribution systems. “One strong role” later causes an accident
5. Step 5 - Test failure paths first.
   Insufficient permissions, network blocking, session expiration, incorrect tool parameters, intentionally creating long-term operation interruptions to check the recovery procedure.

For operational design examples, the following is sufficient to start with.

Agent A: Document search + summary (read-only)
Agent B: GitHub issue triage (read/write to issue tracker only)
Agent C: Prepare for distribution approval (only change request creation possible, actual distribution not possible)

Common rules:
- All sessions are given runtime_session_id
- All tool calls are recorded in audit logs
- Session ends after 15 minutes of idle time or policy violation
- Production changes require human approval

AWS AgentCore On paper, sessions are isolated on a dedicated microVM and terminated after 15 minutes of idle time or a maximum of 8 hours. What this means is, “You shouldn’t rely on session memory for only important state.” Long-term context must be stored separately in durable memory or internal DB.

7. Mistakes and pitfalls: I fall a lot here

Key one-line summary: Failures are more often due to poor operational boundary design than incorrect model answers.

1. Pit 1 - Opening only model access and lumping tool permissions
   Prevention: Apply the principle of least privilege per agent role.
   Recovery: Decommission a single public role after an incident; Reseparate by tool/resource unit authority.
2. Plot 2 - Misunderstanding session isolation as state storage
   Prevention: Use sessions only as a temporary execution space, and write the task state to an external durable store.
   Recovery: Use the resume protocol after session termination. Define and replace with checkpoint-based re-execution.
3. Plot 3 - When you mistakenly believe that “running in AWS is automatically safe”
   Prevention: Check read/write boundary, approval gate, log retention period, and prompt input source separately. Design.
   Recovery: Combine CloudTrail and app logs to reconstruct actual tool call paths and immediately disable risky tools.
4. Pit 4 - Treating limited preview like a production contract
   Prevention: Document region, support model, price, SLA, and feature differences separately
   Recovery: When preview is interrupted, use direct API or existing Leave a fallback path to the workflow:

8. Strengths and Limitations

Key one-liners: The strength of Bedrock Managed Agents is not performance, but Reduced operational friction; its limitations are Degrees of freedom and Some concessions to recency.

Strengths

• Integrated with AWS security, permissions, and procurement systems, internal approval time may be shortened.
• If Codex is bundled via Bedrock, the development team's tool usage can also be added to existing cloud commits.
• AgentCore's session isolation, version, and endpoint structure are advantageous for long-term operation.

Limit

• It is currently in limited preview, so it is difficult to fully introduce it right away.
• Don't expect the latest OpenAI features to always arrive in Bedrock at the same time.
• As it becomes easier to adapt to AWS standards, multi-cloud/multi-vendor abstraction may become more difficult.

Therefore, I view as a “company-wide agent runtime” a very good candidate, but for experimental frontier purposes, the direct API is still superior. View.

9. Points to study more deeply

Key one-line summary: To properly understand this presentation, you should read the runtime documentation rather than the model presentation.

• OpenAI on AWS Announcement: Please check first what is limited preview and scope.
• AWS What’s New + AgentCore Runtime Documentation: Be sure to understand identity, session, endpoint, and microVM isolation.
• GPT-5.5 Announcement: Reading the intent of agentic coding/knowledge work is more important than improving model performance.
• Microsoft Foundry Agent Service documentation: Comparing what managed agent abstractions different hyperscalers provide will make your judgment clearer:

Especially beginner developers will be much less lost if they first understand “who calls the tool on behalf of them and who leaves traces” rather than “where to call the model”.

10. Action Checklist + Author's Perspective

Key one-line summary: If you can't document the items below before PoC, it's not time for adoption yet.

• Have you defined a range of data accessed by this agent that requires VPC internal pinning?
• Have you separated the IAM role and read-only / write permissions for each agent?
• Have you standardized audit log fields across all tool calls
• Have you documented session termination/retry/checkpoint recovery rules
• Have you prepared a fallback path in case of Preview termination or functional disruption?
• Has a human approval gate been added to the actual production change work
• Should the cost indicator include completion rate, retry rate, and approval delay time per task rather than just tokens?

Definition of Done: If the operations team can track “which agent touched which system with what authority” within 5 minutes, it is ready for the first round of introduction.

Author's perspective: I quite strongly recommend this combination to any AWS-centric organization. However, the reason for recommendation is not because “OpenAI can be used on AWS,” but because agents can be treated as secure and auditable execution assets. Conversely, teams that have not yet decided which tools to add or what permission boundaries to set will be better off starting with smaller direct API experiments than Managed Agents. Agent platforms need to fix their operating philosophy before the model to reduce failure.

Reference material

• OpenAI models, Codex, and Managed Agents come to AWS (OpenAI, 2026-04-28)
• Amazon Bedrock now offers OpenAI models, Codex, and Managed Agents (AWS, 2026-04-28)
• Top announcements of the What’s Next with AWS, 2026 (AWS News Blog, 2026-04-28)
• How it works: Amazon Bedrock AgentCore Runtime (AWS Docs, accessed 2026-05-15)
• Introducing GPT-5.5 (OpenAI, 2026-04-23; API update 2026-04-24)
• What is Microsoft Foundry Agent Service? (Microsoft Learn, 2026-04-13; updated 2026-05-12)
• OpenAI’s New GPT-5.5 Powers Codex on NVIDIA Infrastructure (NVIDIA Blog, 2026-04-23)