AWS re:Invent 2025 - Keep Your Agents Out of Trouble with Amazon Bedrock AgentCore (AIM3330)

🦄 Making great presentations more accessible.
This project enhances multilingual accessibility and discoverability while preserving the original content. Detailed transcriptions and keyframes capture the nuances and technical insights that convey the full value of each session.

Note: A comprehensive list of re:Invent 2025 transcribed articles is available in this Spreadsheet!

Overview

📖 AWS re:Invent 2025 - Keep Your Agents Out of Trouble with Amazon Bedrock AgentCore (AIM3330)

In this video, Sarthak Handa and Vivek Bhadauria from AWS Bedrock AgentCore team present a comprehensive framework for AI agent safety in production environments. They explain how agents' unpredictable runtime behavior and potential to take unintended actions create real-world risks. The session demonstrates AgentCore's layered safety approach: Runtime provides isolated execution environments using Firecracker and Micro VMs; Gateway offers MCP-compliant tool curation with Lambda interceptors; Identity manages authentication and on-behalf-of flows; Policy enables fine-grained access control using Cedar language for deterministic enforcement; and Observability with Evaluation tracks agent decisions and validates performance against 13 pre-built evaluators. A live demo showcases an insurance agent use case, demonstrating how policies restrict tool access based on coverage amounts and user department attributes, with all enforcement decisions logged in CloudWatch for complete auditability.

; This article is entirely auto-generated while preserving the original presentation content as much as possible. Please note that there may be typos or inaccuracies.

Main Part

Introduction: Keeping AI Agents Out of Trouble

It's great to see you all here. My name is Sarthak Handa. I'm a principal product manager with the Bedrock AgentCore team, and I'm joined by Vivek Bhadauria, who's my principal engineer counterpart. Today we are going to talk about something that every team building AI systems deeply cares about: how to keep your agents out of trouble.

We are at an exciting point in the industry where how software is getting built and used is rapidly evolving. Startups and enterprise teams are building completely new agentic applications that can understand users' goals and then work across tools to get the job done. But the moment you start giving agents the ability to take real-world actions, like calling APIs, updating records, or making transactions, every misstep can have real-world consequences.

In today's session, our goal is to explore how we can ensure that agents act safely within their intended boundaries so that we can deploy them in our most valuable workflows and give them increasing levels of autonomy. We'll first start with why this matters: the promise of AI agents and what can go wrong if the right control mechanisms are not in place. Then we'll walk through different layers of agent safety controls that are needed to put agents in production. Finally, we'll go deeper on how you can implement these controls using AgentCore and walk through a deep-dive example.

The Promise and Perils of AI Agents in Enterprise Workflows

Let's jump right in. AI agents are a new, uniquely powerful class of software system that are able to understand users' intent, plan actions, and execute multi-step workflows in order to achieve a goal. It's a fundamental shift in what software is capable of doing. Unlike traditional programs, which follow a fixed set of rules, agents figure out how to achieve a goal dynamically, which makes them much more adaptive, context-aware, and flexible.

This adaptability is already transforming how enterprises are using software in their daily workflows. We're seeing customers across every single industry vertical gaining immense value from agents in automating complex workflows. Think of automating IT ticketing processes where you triage and resolve certain tickets. Agents are also being used to generate structured content like knowledge artifacts, design assets, or even software code in ways that were completely unthinkable just a year ago.

Finally, we are seeing a lot of adoption of agents for decision support, where agents assist humans by gathering the right context, surfacing key insights, and taking actions on their behalf. But what makes agents powerful also makes them high stakes. AI agents can take unsafe actions without the right boundaries and controls, and this is a big problem for organizations trying to scale their agentic workloads.

In the real world, using AI agents can produce several risks and challenges. First, agents have unpredictable runtime behavior. Even when you design your agents carefully, the agent's decisions at runtime often depend on the evolving context of the user's input and tool responses, all of which cannot be predicted completely during the design phase.

Second, agents may attempt to take actions that are outside their intended scope. Think of agents trying to trigger workflows that are only meant for admins, or agents trying to kickstart a high-value transaction without the right authorization. Agents may try to access and modify sensitive data, or they may completely misinterpret business rules, for example, taking actions that are aligned with users' intent but not aligned with companies' internal policies.

So the real question is: how do we give agents the freedom to act while making sure that they follow the intended boundaries? Let's try to understand that with an example. The right mental model to think about agent safety is to treat it as layers of protection. You want to control how the agents run, control what it's allowed to do, and also verify what it actually did.

A Layered Approach to Agent Safety: Runtime, Gateway, and Observability

Agent safety starts at the runtime layer. In this particular place, the key goal is to ensure that the agents execute in a fully isolated environment so that one user's workload does not interfere with that of another. This is your first line of defense where you establish a safe boundary that contains what can actually happen during execution.

Now, once your agent is safely executing, the next step is to give it access to tools so that it can take meaningful actions at runtime. You want to give your agents access to tools, APIs, and services via a gateway that acts as a controlled boundary through which every single tool call must pass. It is exactly at this boundary that you want to implement policies which allow you to define and enforce fine-grained rules on what your agent can do and under what conditions.

So for example, in this particular case you can define a policy which says don't approve a claim above a certain threshold.

Now, let's say your agent has executed. The next obvious step is to know what it actually did and how it performed, and that's precisely where observability and evaluations come into play. In this particular layer, the key goal is to be able to trace every single agent decision that was made during execution so that you can see which tools the agent tried to invoke, whether those tools were allowed or denied based on policies, and what the final outcome was. Now this brings together the entire safety framework where different layers help you contain, control, and verify agents' behavior so that you are sure they actually follow the intended boundaries that you plan for.

Implementing Safety Controls with AgentCore: From Isolation to Evaluation

Now, to dive further into how you can implement some of these controls with AgentCore, I would like to welcome Vivek on stage. Thanks, Aar. I'm going to dive deeper into how specifically AgentCore helps here. I'm going to start with maybe a quick raise of hands. How many of you have built an AI agent? Cool. Quite a few. How many of you have actually put into production? Okay. One. How many of you who have put in production actually feel safe about the security controls that you have in production for AI agents? Yeah, and that's expected. That's the current state, right?

That's there because as an agent developer we have to constantly make a trade-off between how much autonomy to give to an agent and how much safety controls we want to put. The more agentic we make an agent, the more autonomous it becomes. We feel that, and because of indeterminism and because of the lack of safety controls in the agent development frameworks, we don't have the full safety guarantees that we have. With AgentCore runtime we are trying to solve a few of them with a layered approach. Let's dive deep into it.

This is where we contain what can happen within your agent. My definition of an agent is a simple one where it's an LLM in a loop. You have a task at hand, you're using an LLM, and that LLM runs in a loop to achieve the purpose and use the tools that it provides. That's what AgentCore really is. You can use any agent development framework, sometimes you have some controls, sometimes you have less controls, but effectively you're using an LLM for reasoning and then you're acting through tools. That's the code that runs in AgentCore runtime, and we provide a strong isolation boundary across every user session.

Think of it this way: every user session has its own memory, its own file system, and CPU resources that are not shared by anyone else. Two user sessions cannot cross boundaries, cannot access each other's data, and there's no cross-firing that can happen inadvertently or even if there's an adversarial attack going on. That provides a very strong guarantee for you. It's as if there's a clean room that is created for every user session. Better yet, once that user session is done, everything is removed, so no after-the-fact user session can come in and use any residual data or context from that.

That's a great guarantee for agent sessions. Imagine if there was a concurrent session running in typical workloads like microservices. There could be a possibility that if an agent has access to the state, it can store state on behalf of one user and may access that same state on behalf of another user. That would not be possible with strong security and isolation boundaries with AgentCore runtime. We are using a lot of our technology that we have built over the years in AWS, like Firecracker and Micro VM, that we use for driving a lot of our serverless architectures within this.

After that, we are containing what an agent scaffold or agent code can do, but agents interact through their external environment via tools, right? That's how they can do so. Even if we are containing what it can do within that runtime, there is still a possibility that through the tools that we have provided, it can do a lot more. It can access state, it can affect the environment, it can exfiltrate data, or it can access inadvertent data that you don't want or it's not trusted. That's where it's important to curate the tools that you're providing to your agents.

It's the same as least privilege that we try to do with every other microservice tool. What actions it cannot do, do not provide it. A simplistic example would be that if you're building a chatbot that should not give refunds to your customers, don't provide a refund tool. Curation of tools does help. With AgentCore Gateway, it makes it simpler because you can provide your API resources, your Lambda targets, or even your MCP targets and create this abstraction where you are curating the tools for an agent.

This works totally with MCP compliance. Let me do a quick raise of hands—how many of you already know about MCP or Model Context Protocol? Quite a few, but for those who do not know, there is a protocol that was launched last year in November. What it does is provide two functionalities to an agent in a simplistic way. An agent can discover tools through the protocol, so it can know what tools are available to it, and then it can invoke tools in a very uniform manner. That is what MCP protocol dictates. So any agent can use those MCP servers to discover what tools are available and then use those tool definitions when required and invoke them.

Agent Gateway is fully compliant MCP server that you get out of the box. But what is more important is that even if you have curated those tools with Lambda interceptors that we have launched, you can do fine-grained access control. These are the interceptors that work before every tool call and even after every tool call. You can now enforce policies which are much more fine-grained. A certain identity may have access while another may not. A user that has booked a ticket should only be eligible for a refund versus a user who is not. You can actually implement your own business logic and business rules there. It is a nice abstraction because it gives you those controls which are outside the boundary of an agent code.

This helps because it is more enforceable and everything goes through it. There is still a problem here. Now that we have contained what an agent can do and given a curated set of tools, there is still the issue of what happens when agents work on behalf of users. They obtain an identity from a user and work on behalf of it. If there are multiple users that an agent is working on behalf of, how should it not crosswire? How does it implement on-behalf-of flows in the right way where the identities are propagated and the authorization controls are implemented when accessing external resources? This is where we developed Agent Core Identity to serve three purposes.

First, it gives an identity to your agent. Second, it does inbound authentication, so your end user can bring your own IDP and authenticate much like any other services that we have. We authenticate who is coming in. But more importantly, it also does outbound authentication. Agents are built to interact with their environment. We are giving tools to interact with their environment. It can do on-behalf-of flows, and Agent Core Identity manages credentials for you, token management, and credential exchange for you. Agent code itself does not have access to those credentials. It only gets a token for the identity that it is working on behalf of, and then it can use it to access the tools.

Now that we are also ensuring that the identities are right and we are using the right tools, there is also still the need to know what an agent is doing. We define an agent with a simplistic definition: it is an LLM in a loop calling tools. It is incredibly hard to debug this. There are no pretty workflows. There is no code to go back to and see what is going on and why it is happening. Every request can take a different path in that whole flow. Agents are incredibly resourceful too. If a path fails, they can take another undefined path that you do not know ahead of time. That is where observability comes in. You can see all the session traces across all the components including tool calls, LLM calls, Agent code, and so on, and create a view over time of what your agent is doing.

You can query CloudWatch logs or you can have ready-made dashboards that you can see. You can also see over time ready-made dashboards that show how much token usage there is, which tools are failing often, which tools are not, what are 4XX errors, 5XX errors, and all of that is available. With this, there is observability, but there is still a problem. If I know what is happening but I do not know what is right versus what is wrong, making all the tool calls successful does not still mean that the agent was helpful, achieved the goal, or is relevant to my end user. This is where the next thing comes: Agent Core Evaluation that we have launched today.

AgentCore Policy: Deterministic Control Using Cedar Authorization Language

This is how it looks. There is a user making an agent call, and then we already know with Agent Core Observability all of those traces whether from Agent code or from related Agent code services like Gateway, Runtime, and Identity. All of them get into observability and all of them track through one session ID that you can see all the traces. Now what you can do on top of it is that as an agent owner you can define what your criteria are for saying that what is right versus what is wrong.

You can define your auto verifiers, auto graders, or what we call evaluators for your agent. There are 13 pre-built evaluators that we offer, but you can write your own. The typical way to write them is using an LLM as a judge. You define the session trace as input, and you specify what is right and what is wrong, and you can evaluate them. The good thing is all of this also comes back to agent observability. You can go to observability and session, and you can see based on your evaluation whether it was helpful, accurate, and whatever dimension you're interested in. You can also see a dashboard showing over time which sessions are falling short of your expectations and which sessions are exceeding them. That's the monitoring traces.

The good thing about this is you can do it online, so you can continuously evaluate. You can set up your pipeline with samples of a certain percentage of requests, and whatever evaluators you have configured, it can keep evaluating them continuously. You can use predefined evaluators—there's a dozen of them—or you can define your own. You can use it at testing phases too, which doesn't have a dependency on CloudWatch. You can just call it when you're developing an agent to test your evaluators or test your agents as you're developing them.

Now this is great. I can know what my agents are doing and verify continuously how they are performing. But with safety, I don't want to take chances of finding out after the fact that maybe it didn't do the right thing. I need more deterministic controls right before an agent is acting, or if I know what is going bad, I want to affect it so it doesn't do bad. That's where policy comes in. Policies work on top of the gateway. Let's take a flow that happens without the policy. There's an agent, there's an inbound tool call where an agent calls the gateway for tool invocation, and the tool invocation happens from the gateway.

Now with AgentCore gateway as that interception layer, you can assign policies. You can write deterministic policies that apply at every tool invocation and get deterministically enforced. The nice thing is that you're not relying on agent code to enforce it. You're not relying on tools to have that business logic. As an agent developer, you can deterministically put it in the AgentCore gateway. Similar to evaluators, you can define it ahead of time. There's a policy admin which comes and defines those policies, and once they are defined and associated with the agent or gateway, they get evaluated for every tool call you make through that gateway.

With everything else, all the policy allow and deny decisions get locked in the AgentCore observability against the same session trace, so you can see the full trace of what's happening. AgentCore policy provides unified protection for you. It intercepts and governs all agent-to-tool interactions. There's operational simplicity to it. No developer integration is required for each tool because it's applied at the gateway level, not per tool. You can also associate the same policies to multiple gateways for agents. There is auditability. All the enforcement decisions are logged and traced into the AgentCore observability. Performance is a key metric here because imagine it's happening on your transactional path in your online path and you want to have millisecond latencies overhead. If it takes a lot of time or is very resource intensive, it cannot be applied for every tool call without performance trade-offs.

Let's dive deep into a use case and understand how overall policy will work. We are taking an insurance agent as an example. A typical agent flow starts when a user sends a prompt. There's an agent running an agent runtime, which is the container unit. It has its instructions and its tools. Some of the tools are local, implemented within the agent scaffold, and then there's an agent context that's available. It makes model calls which are external to the runtime, and it makes tool calls which are also external via gateway. That's the general flow. There are three tools that we have provided. There's an application tool which helps it create an application. There's an invoke risk model tool which helps assess the risk model for that application that is created, and then there's an approval tool where somebody can approve the insurance application. That's a very simplistic insurance application.

If I were to put policies on it, these are the three steps that it looks like. Step one is policy authoring. In here I want to enforce a policy which says, in natural language, allow the user to call the application tool with the coverage amount under $5 million.

The second statement is much more interesting to me. If you're not able to read, I can just repeat it. If a user has a principal tag called department, so if an identity that is calling has an additional attribute that department is finance, then only they should be able to do risk modeling. This is something where if there's a different user that is calling not from the finance department, they should not see the risk modeling. This is an identity-based kind of validation, not a simplistic validation on just the tool inputs.

How many of you are aware of Cedar? Good to find one. For this you don't have to know Cedar, but I'm just showcasing it here. We are enforcing these through Cedar, and that's very important because Cedar is a policy authorization language that has been developed before Gen AI. It's already supported in API gateways, Lambda functions, and Amazon Verified Permissions, which was developed and open sourced by Amazon. It's a very formal policy for policy authorization, much more like Rego if anybody is aware of other capabilities and stuff. Very similar to Cedar. What is important here is that even though there's a natural language definition, there is a formalization of it through Cedar, so you can actually see and enforce it through that. That also gives it much more performance and determinism. The natural language really helps in ensuring that if you're not good at authoring these, you can just start with natural language. There's a lot of verification that we do to ensure that it's actually right. In here it already shows that these are valid policies, and then you can apply them.

Live Demo: Enforcing Insurance Application Policies with AgentCore Gateway

Once we have created these policies and associated them with the gateway, now you can just start calling your tools or start running your agents. The same flow looks like this. We send a prompt. The agent reasons through the model and decides on a tool. But before invoking the tool, now there's an interception for the policy. The policy gets enforced whether it's an approved or a denied decision. In this case it's approved, so it goes ahead and makes the tool call. The tool result comes in and goes back as a response to the end user. If it was a deny call, it would have returned directly from there and would not have moved forward.

The third step is observability. Whether it's allow or deny, you can come to your observability traces and see what is going on, what policies are approved, denied decisions of it. You can see the payload information. You can see which resources, and you can also see, which is not captured in here but we'll show it in the demo, you can also see over the period of time how your policies are working, how many sessions or traces they're denying, how many they're allowing, and you can see the distribution over a period of time.

With this, we can actually see it in action too through a demo. This is AgentCore console. Let's start with the gateway. I've already created a gateway in here. The gateway name is what we selected, and you can see inside this gateway. The gateway is associated with an identity provider, Cognito. So there's a Cognito identity that I'm using for inbound. There are three tools configured going inside, and these are tools that we already talked about.

There are two properties it has. It needs coverage amount and region as an input. These are the definitions that go into the model. This is how the model knows how to call it. Now with these tools and with this gateway, there is also log delivery. This is where the tracing comes about. There are vendor logs that you can configure where this log should go, and the tracing is enabled as well. So all the observability will be enabled for this. Let's quickly run it. There are no policies yet, right? It should just run. It's a very bare bones agent.

Forget about custom claims now. We did not add any claims. There are four tools here that are created, but we only added three tools. Does anybody know where this fourth tool came from? I'm not surprised because it's very custom for the gateway that we have added. The way to think about it is that in this case it's not useful, but there's a search tool that we have added. Now it's not there in MCP yet, the search functionality, but you can actually do contextual search based on what your agent is processing and just get the list of tools from there versus all the list of tools. There are just three tools here, so it doesn't matter. We can just list all the tools and provide it in the context, but imagine there are thirty or three hundred tools that you're providing. You don't want to provide all of this in your LLM definition. Then search can come in and help.

Let's move forward with the demo. So in here, now I'll just try to make an application request providing the US region. We wanted a region and a dollar amount, ten million dollars.

This is a dummy implementation, so it will approve and create an application for me. This works right now without any policy enforcement so far. Now we can go back to the console and try to see how to create and enforce our policies. This is the policy preview. You can go to create a policy engine. A policy engine is a container of policies, so you can create many policies that all go into one policy engine. We'll name it in this case "underwriting use case." Now we will select a resource. Our resource will be our gateway, which is where we are applying these policies. We'll select the resource. This is the same natural language that we talked about and went through. So again, the same natural language where we're saying don't allow if it's more than $5 million and don't approve. Only risk model access should be enabled for a principal or a user which has the attribute finance. In real time you can see Cedar policies being created. You can even iterate through that as you're authoring these policies. In this case I'm showcasing that I got it right in one flow. You may take a few iterations. You can see your policies and whether they're valid or not. Even without going through a lot into Cedar, there are three to four sections to it. There's principal, action, and resource, which identifies who is accessing, what the action is (the tool), and what the resource is (the gateway). The "when" is the important part here—at what conditions are you allowing it. We validated both. Both look fine. One is on the principal hashtag department name and the other one is the right dollar amount that we wanted to do. All of this looks fine now, so we can just create these policies. There's a validation mode. I'm just choosing "permissive" for test purposes. We created these policies. Now they're still not associated with the gateway. So the next step is to associate them with a gateway. I'll just associate with my existing gateways. We already created a gateway that we had before. I'll just go select it. There are two modes for testing. You can do "emit log only," but it doesn't enforce. It just says what the decision would have been. It's very useful for you to see and do a dry run on it before enforcing it. But in here I want to show it in a demo where it actually prevents calling that tool, so it's enforced. We can go back to our agent now that the policy is enforced and run the same agent. Again, there are no custom claims yet, so it all shows none. And here it's very interesting. If anybody is noticing, we only see one tool available right now instead of the four tools that we had before. Can anybody guess the reason why there's only one tool now?

Well, what it means is that with Cedar, the deny all is the default. So by default, unless you have a permit policy, it's deny all. Now we only configured permit for two tools. The first two—the search tool—there was no permit, so that's denied. The third tool that was there for approval had no permit, so that's denied. This user doesn't have the right department. There's no department set, so the risk model tool is denied. The only one that could be allowed is if the dollar amount is less than $5 million, which is the create application tool, and that's what the agent sees. This is a very good way where your agent never even sees the tools that it cannot use, and that's pretty important because then it cannot hallucinate. There are no loops where the agent tries something and then it fails because the policy denies it and then it comes back.

We'll move forward. I'm going to try the same thing. I want to create an insurance application in the US region for a coverage amount of $1 million. This should be allowed based on our policy and it should go forward. This works. Now we can try a number which is greater than $5 million. Let's say in this case $10 million is what we can try. Application creation in the US region with an amount of $10 million.

The agent may try to make the tool call again because it's in the same context and the agent sees that it already created an application. It generally sometimes says I already created an application, so I'm providing additional information here. If you see it, it actually failed to call it because the intercept happened with the policy and it failed. We can go back and check. Now you can see there are a few traces that were there before. We can go there and see if observability is helping us.

You can come here. This is an auto filter that gets configured here because you come through the traces based on the policy engine. There is one interaction that we have had so far, one deny, and you can see that one trace, which is why you can come here and find the information for that. Yes, so it says policies enforced, and it says the interaction that is out there. Now these are the metadata that is there for the system to see, and you can actually filter and configure metrics on all of these.

These are pretty useful if you want to have these dimensions of deny, access, policy engine, or metadata around agent or gateway where you're applying these. Now we can go back and try the other policy too, which to me is a far more interesting one, which combines the principal attributes and the context that we are providing.

Okay, we'll go back and try this again. Good. This time, I will add custom claims to my identity. By custom claims, I'll add those tags that the department of the user will be finance and there will be other things like cost center and stuff in that. We can see here what this means is that in your job token, the JSON web tokens that gets to here, those claims will be present, those attributes will be present, and then you can run your policies against that.

In this case, if you see now, the department name is finance, employee level is senior, and cost center is XYZ. These are three attributes that are provided by the IDP that gets all the way propagated to the gateway, and now you can implement policies on this. Now in this case, and this is something that is important, previously we did see that there was only one tool that was listed. Now you can see there are two tools listed because the other two we didn't have any permit policy. They'll never come unless we add any permit policy. But for the other two, both conditions are satisfied right now.

So there's a department in finance, which is why the risk invoke risk model tool is available to the agent and it can use it now. We can go forward and try the same approach now where we'll try to just trigger the risk model and see if it makes the call or not. If you cannot see, yes, I'm typing in. I first typed in I want to do the risk model, but I didn't provide all the information and it said it needs more information, and that's what I'm providing in here.

Once I provided it, it did the risk modeling and it provided me the status as success. So the call did go through. The counterexample to that would be I can add a department and say the department is other than finance, say engineering, which people do not maybe trust us enough for engineers to make this finance decision. You will see that the list tools itself will not show. In here you can see the list tool itself is now showing just the create application and not the risk model. If you make the invoke call, the same interception will happen and it will not go through.

I'm going to move forward from this. So that's the full policy in action that you can see. Both policies got applied, and the nice thing about it is that it gets applied to both the tools available to the agent and at the invoked time and across all the tools that are available via the gateway.

Conclusion: Building Safe Agents Without Trading Off Autonomy

Now, coming back to the agent safety framework and the layered architecture that we have, runtime helps to contain what can happen. Identity helps to control who is allowed to act and what actions they can take. Gateway controls what tools you are providing to an agent and what an agent can do. With observability, you know what happened. We're enhancing both gateway and observability now with policy to have fine-grained access control over this.

Imagine this lambda interceptor that we talked about is another way to implement fine-grained access control, much more do-it-yourself, and policy is much more managed for you. Then observability helps you. Beyond observability, evaluation helps you verify if your agents are working right for you. With all these features, where you want to get to is that this trade-off between agent performance and agent safety should not be pushed to the application developer. There should be foundational controls that are provided through agent platform infrastructure that helps you build safe agents without trading off autonomy for AI agent applications.

If you need more resources, here is a launch block for the policy, and there are more GitHub code samples that are ready to try for you. Thank you and I'm open for any questions.

---

; This article is entirely auto-generated using Amazon Bedrock.