Bedrock Managed Agents treats an AI agent like a workload, not a chatbot
AWS and OpenAI put IAM roles, durable sessions, approvals and CloudTrail inside the agent runtime. What that changes for AWS-heavy enterprises, and what it doesn't.
Listen to this article · 6 min
AI-generated narration of the full article.
Most enterprise agent projects spend their first months rebuilding the same plumbing: a way to keep state between steps, a service identity, a permission model for tools, an approval step, and logs that security will accept. On September 29, AWS put much of that plumbing into a managed service.
Amazon Bedrock Managed Agents, powered by OpenAI, is now in preview. AWS says it was developed jointly with OpenAI and is built on a customized version of OpenAI’s Agents API, adapted to run inside AWS and integrate with AWS resources.
The interesting part is not that another agent service exists. It is which responsibilities the runtime now takes on.
What was announced
According to AWS, the service manages how the model keeps state, selects and uses tools, executes code and coordinates multi-step work. Specifically:
- Durable sessions keep messages, tool calls and intermediate results, so work can resume later.
- Reusable skills package specialized procedures, and agents can connect to tools, including MCP servers.
- Each agent operates with its own IAM role.
- Agents support human approval before consequential actions.
- Supported API activity is recorded in AWS CloudTrail.
During the preview there is no additional charge beyond the AWS resources the agents consume, and AWS notes that pricing may change at general availability. The preview runs in US East (N. Virginia), US West (Oregon) and US East (Ohio) only.
The shift: agents as governed workloads
For the last two years, most enterprise agents have been treated as application features: a chat surface with some tools behind it, running under whatever credentials the app happened to have. That model does not survive a serious security review.
Bedrock Managed Agents describes a different model. An agent has its own identity, its own permissions, a persistent state that belongs to it, a controlled way to reach tools, and an audit trail in the same place the rest of AWS is audited. That is how enterprises already treat a microservice or a scheduled job. Agents are being pulled into the same operating model.
The pattern is not unique to AWS. In the same month, Microsoft described its Autopilot agent as living in the tenant with its own identity, and Google added resource-level IAM for Gemini Enterprise apps and data stores. We map that convergence in our 2026 stack guide.
- Request
- Agent with its own IAM role
- Durable session
- Tools and MCP servers
- Human approval for consequential actions
- CloudTrail record
Mechanism provided by the managed runtime (preview)
What still belongs to your team
A managed runtime gives you the mechanisms. It does not make the decisions:
Scope per agent. A dedicated IAM role only helps if it is narrow. Someone has to decide what each agent may read and change, and review that scope as the agent grows.
What counts as “consequential”. Human approval is available, but the runtime cannot know which of your actions need it. Refunds above a threshold? Emails to customers? Changes to master data? That list is a business decision, and it should be written down.
What lives in the session. Durable sessions retain messages, tool calls and intermediate results. That is valuable for continuity and also means the session store is now a place where sensitive data can accumulate. Classification, retention and access to that store need an owner.
Which tools you trust. MCP makes it easy to connect agents to more systems. Every MCP server is also part of your supply chain, with its own permissions and failure modes.
Evaluation. Nothing in the announcement tells you whether the agent is good at the job. You still need test cases, acceptance criteria and a way to rerun them when the model or the prompt changes.
“Supported” activity. CloudTrail records supported API activity. Before relying on it as your audit trail, check which events are covered and whether the reasoning and tool outputs you need for an investigation are captured somewhere else.
For AWS-heavy US enterprises
If your organization already runs on AWS, the preview is worth a structured evaluation rather than a quick demo:
- Start in a sandbox account in one of the three preview regions, with synthetic or non-sensitive data.
- Design the IAM model first. Decide on one role per agent, permission boundaries and how roles are reviewed.
- Route CloudTrail events to your existing SIEM and check with your security team what an agent incident investigation would need.
- Write the approval policy before wiring consequential tools.
- Treat preview terms as preview terms. Do not plan production cost or support assumptions until general availability.
The bottom line
Bedrock Managed Agents is a strong signal that the agent runtime is becoming infrastructure, with identity, state and audit built in. That removes a real amount of undifferentiated engineering. It also moves the hard questions to where they belong: which permissions, which approvals, which evidence, and who owns the agent once it is live.