🦄 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 - Securing agent access with Amazon Bedrock AgentCore Identity (SEC313)
In this video, AWS Principal Product Manager Rahul and colleague Ben introduce Amazon Bedrock AgentCore Identity, a solution addressing authentication challenges in agentic AI systems. They explain how enterprises face difficulties with secure delegated access, consent fatigue, and custom integration code when deploying AI agents. The session demonstrates how AgentCore Identity solves these through unique workload IDs, managed OAuth flows, and IDP-agnostic architecture. Key components include identity directory, authorizer, resource credential providers, and token vault. The presenters detail access patterns for AWS and non-AWS resources, three-legged and two-legged OAuth flows, and walk through a sales executive use case accessing CRM and finance systems. Recent launches include custom claims support, three-legged OAuth for Gateway, Lambda interceptors, and Cedar-based Policy in AgentCore for fine-grain access control. Integration with CloudTrail and AgentCore Observability provides audit trails and monitoring capabilities.
; 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: The Rise of Agentic AI in Enterprise Applications
Yes, hello everyone. I'm Rahul. I'm a Principal Product Manager at AWS, and I'm focused on generative AI, machine learning, and user authentication. I'm super excited and thrilled to be here to talk to you all about securing agent access using Bedrock AgentCore Identity. So without much ado, let's get started. Before I do, just again, a quick show of hands. Am I audible? Is everyone able to hear me? Perfect. That's awesome. Let's get started.
So today we're going to cover a breadth of topics over the next hour. We'll start broad by setting the agentic AI industry context, and then with each subsequent topic we'll keep digging deeper. We will talk about the authentication challenges associated with securing agents' access. We will introduce Bedrock AgentCore Identity to you all and talk to you about how this would address all the challenges that we call out. And then we'll go deeper into talking about the agentic access patterns that Bedrock AgentCore Identity unlocks, and finally we'll talk to you about what's new with AgentCore Identity. We did a bunch of announcements at re:Invent, so we would love to keep you updated on what those are so that you can start using the product.
So with that, I'm going to tee it off to Ben to set the agentic industry context. Quick show of hands, who out there is building something today in the realm of agentic AI? Doesn't surprise me. Okay, the obvious thing is enterprises are doubling down on agents. I don't think there's any surprise there. You're here day four, pretty full audience. This is an important topic. If you go down to the expo hall, it's amazing how much investment we see happening around agentic AI. Me personally, I see it daily. Every customer conversation I had this week was around how can you help me get my agents to production faster.
And we're not alone in seeing this. So Gartner says 33%, one third of all enterprise applications are going to have an agentic AI element by 2028, just a few years away, and this is up from just 1% last year. So maybe 1% last year had some niche little use case where we had to throw in this AI element to it, but now it's pretty much mainstream. It's commonplace in how we're building applications. Additionally, they say 15% of our decisions are going to be made autonomously. I don't know about you. I don't mind 15% of my decisions being made autonomously moving forward. These are things like responding to invites or responding to tickets. Use cases are endless, but I'm not disappointed in having 15% of my decisions go somewhere else and free up some time.
Driving Forces and Organizational Challenges in Agent Adoption
So then we've got to ask ourselves what's driving it. I think some of this is going to be pretty obvious. First and foremost, productivity. Again, me personally, I use agentic AI tools daily as a product manager. I use them for things like synthesizing customer feedback, feature requests that you all provide to us on a daily basis. I use them to help accelerate authoring documents. As you know, Amazon's a big document culture. As PMs, we're able to use these things to tailor our documents into the Amazon writing style.
Recently we were given an amazing tool that helps us build UX mocks. So as a product manager, I wanted to have my ideas come to life, and there's no better way to do that than having a mock. Previously I'd get in a queue with our UX designer and maybe wait two weeks to have that design come to life, and I'm just waiting anxiously. And now I have a tool that in simply 15 minutes, a couple quick prompts and iterations, I have these amazing UX mocks coming to life. So the obvious benefit here, productivity at scale. I'm sure you all are seeing this.
Next we start to see these context aware experiences and decisions, you know, situations where maybe as a developer you were writing tens of thousands, hundreds of thousands of lines of code, business logic to try to make these experiences come to life. Now they're context aware, simple call to an LLM. You're opening up all these different opportunities. So the types of experiences we're able to do and there's this context awareness, is really quite amazing.
I think last, faster time to market. As I said, the productivity gains that we get not only from a product side but the productivity gains we get from engineering in terms of coding agents, auto developing documentations, etc., our ability to get services to our customers faster is just accelerating. Some clear, clear benefits.
So the benefits are clear. Now the next question is what does this actually mean for organizations? You have this awesome prototype. The prototype's proving really, really valuable, but then it's like, well, hold on. I actually have to try to make this thing real. And one of the first questions we hear is secure access. Agents should have just enough access just in time to perform their task. And how do you do that? Do you give them an own identity? Do you give them their own access? Maybe not the best decision. They're nondeterministic. So this is something that you have to think through as you're starting to build out these agents.
The next is this funny controlled autonomy. We kind of call this this healthy tug of war, right? I think of this back when cloud first came into existence and we had this tug of war of, hey, I want my developers to have access to cloud resources on demand, be agile, move fast, and then ops teams like, whoa, whoa, hold on, we have security and compliance requirements. We're starting to see that same tug of war come to life now.
Organizations want to see the benefits of agents and know that they can do all these cool things, but they're asking how to have the controls and compliance in place. So you end up with the same tug of war: we've got to move fast, but we've got to move fast in a controlled way.
Last, evolved governance. An agent is not a human. We have human governance kind of solved, right? It's been around for a long time. We have our identity providers and life cycle management of humans. Then machines came about, and machines are pretty easy to manage. They're deterministic, so it's safe to give them access. You know what they're going to do every single time. And now suddenly you have this new entity type called an agent. What is an agent? It's not a human, it's not a machine. It's really a third entity that organizations now have to think about governing. How do you have life cycle management? How do you have the right ownership of it? How do you ensure that you have auditing of the permissions it has? So all these new things are coming up for organizations to have to think about, and they're hard.
Authentication Challenges in Agentic AI: A Deep Dive into Access Patterns
So as we set that context, I'm going to turn it over to Rahul and he's going to dive a little bit deeper into actually what that means in terms of authentication challenges when you're dealing with these. Perfect, thanks a lot, Ben, for teeing up the industry context around what's really driving organizations to embrace agentic AI systems. Now that we have understood why organizations are increasingly embracing agentic AI, again, a quick show of hands, how many of you are actually building agents in production at your organizations? Quite a few of you, so some of you will be familiar with authentication challenges, but we'll go really deep into some of the challenges that we hear from a lot of our customers.
Before I go through the authentication challenges, it's important for us to understand what are some of the common access patterns. When we speak to our customers, including yourself, we hear two key categories. First and foremost is when an agent performs tasks on behalf of a human user. This is a classic example wherein a user delegates an agent to perform tasks which they otherwise would have been able to do themselves. In this particular category we see three examples or three scenarios.
The first scenario is where you have a human user delegating a helper agent to perform a very specific task. For example, you may be getting a high queue of support tickets in your organization. We hear customer use cases around using an agent to summarize the support ticket and do a root cause analysis. That's a task-specific agent. The second example there is around a human user who uses or delegates a task to a general purpose orchestrator agent which then determines the nature of actions that a user wants to perform and then delegates to second or sub-agents to perform task-specific actions. A classic example is you have a general productivity AI agent assistant. You want to ask that agent, can you help me set up a calendar event on my Google Calendar, or write me an email brief, or do a root cause analysis of all the support tickets in my organization, or even fetch sales records from my CRM systems? So you can give this task to a general purpose agent, and that agent then interacts with other task-specific agents to perform those actions.
The third category there is a human user invokes an agent that in turn calls an MCP server to then access resources that are target-specific by basically calling various tools that the MCP server exposes. So that's pattern number one. The second pattern that we hear commonly is where an agent performs tasks in response to events or pre-authorized user consent. Classic examples here are background jobs, scheduled tasks, or event-driven automation. An example there could be you have an agent that is scheduled to query a certain database every Wednesday at 8:00 p.m. to generate weekly business reports. That's one example. An event-driven automation example that we hear commonly is you have a high severity ticket in your queue, you want an agent to analyze your logs and then provide a root cause analysis. So these are some examples that we are hearing from our customers more broadly.
Let's dive into one of these access patterns in a little bit more detail to help make the examples more concrete. So we're going to talk to you about a sample agentic AI use case in an organization. We're going to talk about on-behalf-of flows, which is a human delegating action to an agent. In this example we have a sales executive, let's name her Sarah. She wants to prepare for an upcoming client meeting or a customer meeting, and she wants to essentially use agents to help prepare for these client meetings.
Before, in the pre-agentic era, what she would have done is she would have gone to her CRM systems, gone through all the customer notes manually, and prepared her client brief before she would have gone into the customer meeting. Or she would have delegated this task to her team to do the same. As you can imagine, it's a lot of manual work. Ben talked to you earlier about the productivity at scale that you get by having agents involved, and that's what Sarah plans to do now in this use case.
So Sarah, instead of preparing these client briefs herself, she prompts an AI agent in her organization using natural language to help prepare her for an upcoming customer meeting. The agent, using this natural language query that it receives, determines that it needs to access two systems. It needs to access a CRM system to fetch all the meeting records and call notes from prior discussions with this customer, and even the finance system within an organization to fetch prior customers' spend data. So when the agent determines that it needs to, it goes back to Sarah and asks Sarah for her consent to allow the agent to then access these systems.
So once Sarah grants this consent, the agent is able to use the permissions that Sarah has access to for the CRM systems or finance system and retrieve notes and financial spend data. After this agent retrieves this information, it can then summarize and create a personalized client brief for the sales executive. It uses another tool to summarize the brief, it has write access to it, and then outputs this out to Sarah so that she's prepared for a sales meeting.
So this is a sample use case. We will reference this use case in multiple parts of this presentation to walk you through some of the challenges. So let's dive straight into it. Even this relatively simple agentic workflow of preparing a client brief comes with distinct identity and access management challenges. So let's understand what these challenges are in the first place.
First and foremost is the challenge around validating who is the caller. The agent here needs to know who is invoking, who is the human identity that's invoking me to perform this job. It also needs to identify whether this user was allowed or authorized to invoke this agent or not. That's number one. Step one is validating the caller.
The second step is managing consent. Remember in the prior example we talked about Sarah needs to delegate this consent for this agent to access the CRM systems, the finance systems, and even this email writing system to prepare the brief. The agent needs to have specific read-write permissions to access these systems and do that only after it has been granted consent by Sarah to do so.
The third thing is enabling scoped system access. As we discussed, the agent in this case talks with the CRM system, the finance system, and the document summarization tool as well. Each of these tools have siloed authorization servers that issue unique tokens. The agent in this case needs to have precise read access or write access so that it does not take any action beyond what it is supposed to do, because if it does take actions beyond that, it can be challenging because you can have write access to sensitive systems which you do not want your agents to be granted. So it's important to be able to solve for scoped system access, tightly scoped, so that the agent has just enough access to perform actions on behalf of the user.
And last but not the least is the challenge around authoring custom code to stitch all of this together. Agent builders and developers often need to think about identity provider integrations. They need to think about credential handling, API calls, credential exchange, authorization, error handling amongst all of this. This isn't easy work. This is a lot of custom glue code that agent builders and developers have to stitch together to make this happen. So you can see even a simple and lightweight agentic use case fans out to multiple identity orchestration related challenges.
Three Critical Problems Slowing Agent Productionization
So what are we observing when we take this example and generalize it more broadly? When we speak with our customers, we were able to distill all of these problems down into three buckets. First is around delegating permissions safely and securely to your agents.
Agents need to be able to call multiple systems: file systems, APIs, and MCP servers. The problem here is that existing identity and access management solutions were not designed to work with multiple dynamic delegation flows. What this results in is a system where agent builders oftentimes find themselves over-permissioning their agents or building fragile workarounds, which is a big problem.
The second challenge is around handling user consent fatigue. As you can imagine, in the last example I talked about the sales executive preparing for one customer meeting. I'm sure at re:Invent you all have had multiple customer conversations, dozens or even 50 of them. Imagine giving consent to each of those three systems 50 times. That's 150 times being prompted to grant consent to the user. That's noisy. That is not good from an end user experience standpoint. Today's identity and access management systems do not have a mechanism to store persistent consent or task-specific consent for these agents.
And the third challenge is around custom integration and glue code. Builders have to write a lot of custom logic to stitch together the identity plumbing: to manage authentication with the initial identity provider, capturing consent, handling credentials, error handling, as well as credential exchange. So there's a lot of work that goes into stitching together this custom integration code. These challenges are not theoretical. They exist in almost every agentic deployment that you need to make, and these challenges can often slow down productionizing your agents. This is what we consistently hear from our customers.
So why do these challenges that we just discussed matter? First and foremost, as Ben talked about in his presentation earlier, agents are key to unlocking faster productivity and faster time to market. If you do not have trust built into your agents, if you do not have a mechanism to securely delegate permissions to agents, organizations do not feel confident in adopting agents or embracing agents and therefore unlocking the benefits. So trust in agents is essential for broader adoption.
Second of all, organizations are not in a position to tax their developers further. We do not want additional developer burden to facilitate and solve the authentication plumbing required to secure agent access. In the absence of that, developers often have to spend a lot more time and effort, slowing down experimentation cycles, release cycles, and therefore slowing down the velocity at which you're rolling out agents in production.
And last but not least, the end user experience must be seamless. You do not want a situation where users who are calling agents are constantly bombarded with repeated consent prompts, really degrading their experience. You don't want a noisy experience for end users. You want a seamless yet secure experience. So these problems directly impact how agentic systems can be built and productionized, and we want to enable you as you build your agents in production or start thinking about building agents in production. How do you get them faster to market? How do you get them faster to your end users?
Introducing Amazon Bedrock AgentCore Identity: Architecture and Core Components
So what was the opportunity ahead? Everything that we talked about in terms of challenges created an opportunity for us at AWS to solve this foundational IAM, or identity and access management, challenge. We realized that identity is a key glue that's going to enable agents to be productionized quickly. That's what led us to solve this problem at scale. We wanted a solution that would allow you to have secure delegation to your agent and unlock broader agent adoption within your organizations or even externally, and therefore come to market faster with your agents. This is what led to the birth of Amazon Bedrock AgentCore Identity, and I'm going to hand it over now to Ben to talk to you more about how Bedrock AgentCore Identity solves some of these challenges we just talked about. Over to you, Ben.
Thank you. All right, another quick show of hands. How many of you have heard about AgentCore Identity? All right, keep them up if you are using AgentCore Identity to build some sort of a prototype. Not too many. I assume that not too many of you are using AgentCore Identity or AgentCore in general to do production agents. Anybody? All right, we have our work to do here. This is good.
So as Rahul mentioned, we know the challenges we heard from customers.
Clearly, we built Amazon Bedrock AgentCore Identity to directly solve those challenges. First and foremost, it solves the secure delegated access challenge for AI agents. We do this by creating a unique, stable workload ID for every single deployment on AgentCore. So you deploy an agent, you deploy a gateway, we create a unique identifier for that.
Second, it helps with streamlined AI experiences. As Raul mentioned, consent fatigue is a real thing. You don't want to build these things only to have your users get tired and not want to use them. You want them to be used for productivity gains. So AgentCore Identity helps solve all of that consent fatigue, as Raul mentioned, persisting these tokens in a secure and safe way.
Last, we want to build AgentCore Identity to help you all build agents faster. At AWS, you probably hear the term a lot, undifferentiated heavy lifting. If we see developers having to do something repeatedly over and over, it's not adding business value for you all, we want to take that off of you. So we built this such that we do things like provide a managed service around orchestration of OAuth flows. How many of you want to go and build your agent and have to deal with going and getting an authorization code and exchanging it for an access token and then getting a refresh token when the access token expires, going and getting a new one? That's not fun stuff. It's not stuff that we think you all are going to be adding value when you build your agents, and so AgentCore Identity takes that undifferentiated heavy lifting off of you.
So if you think of where it fits in the overall AgentCore, for those that aren't familiar with AgentCore, it is a set of different primitives that all come together to work as kind of one big service. We have AgentCore Runtime. This is your core runtime for where you host your agents. We have AgentCore Gateway. This is an MCP protocol base which allows you to communicate with your external tools. We have AgentCore Memory, pretty self-explanatory. We have AgentCore Observability, which gives that visibility and traceability across everything that the agent is doing. We have some nice tools, AgentCore Browser and AgentCore Code Interpreter. I'm not going to go through all of those in detail. We don't have the time here, but do encourage you to take a look. And then at the center of that we have AgentCore Identity, which of course, biasedly speaking, we think kind of is the glue that stitches all these things together, and I'll touch on a little bit about this.
How AgentCore Identity Handles Inbound and Outbound Authentication
So as you're building agents, really there are some very fundamental basics you have to think about. First is your users need to be able to access the agent. In the world of AWS, generally this is through IAM, but not all of you want to use IAM in your applications to allow your users to invoke an agent. So the question is, how do users actually access the agent through the application? And then on the other side is that agent needs to go and perform a task or go call an external tool, so how do you make that happen?
In our world we call it on the left-hand side inbound auth and on the right-hand side outbound auth. And the key questions that AgentCore Identity helps answer is, first, who's the user? As Raul mentioned, if you're doing things in terms of a user acting on behalf of, well, we have to know who that of is, who is that user. How do we verifiably determine who that user is that's invoking this agent? And then is that user even allowed to access the agent? So maybe you want to say only my HR department can invoke the HR agent. How do you ensure you have that basic auth set up? On the outbound side we have to know, is this agent actually who it is? Do we have a verifiable identifier for that particular agent? And then is that agent actually able to access these tools on behalf of that user? So these are core requirements on the inbound and outbound side, and as Raul mentioned, not actually that easy to solve when you get to scale.
Okay, so we thought it would show a little bit of the core components of what AgentCore is, and then we'll help connect that as Raul gets into deeper and deeper. As you mentioned, we're going to get deeper and deeper and deeper. This is a 300-level talk, so we're gradually going to get there. So within AgentCore Identity we have a few different components. First and foremost is an identity directory. This isn't actually that visible if you have ever used AgentCore Identity. You may not even know this is happening. So every time you deploy a runtime in AgentCore, we create an identity directory in that account, and that runtime equates to a workload ID, that is, an agent identifier. Same thing with gateway. Every time you deploy a gateway in AgentCore Gateway, we create a unique workload ID for that particular gateway. So we have this agent directory within identity.
The next is an authorizer. So we took an approach. We understand many of you have very well-entrenched identity access management solutions. You have your IDPs, and coming in and saying, hey, if you want to use AgentCore, you've got to rip all that out, come in with a new IDP or just use IAM, that wasn't going to work for us. So we took an approach with our authorizer to be IDP agnostic. What that means is if you use Okta, Azure Entra ID, Ping, etc., you can configure that such that when you send a request to invoke an agent to our authorizer, we go, we communicate with your IDP, we do the validation, we allow that invocation to happen or not. So a key piece of this is that authorizer.
Next we have a concept of resource credential providers. This is essentially saying if your agent is able to access a tool, what are the credentials that they'll use to be able to access this? Think of this as API keys if you're trying to access an API that's protected by basic API keys. Think of this as OAuth credentials, so client ID, client secret type stuff if that agent is able to go and access a specific OAuth protected resource. So we have this secure credential provider that allows for those credentials for that specific agent to access these tools.
And last we have a concept of a token vault. So token vault again, probably pretty self-explanatory. It does just that. It stores your token, but it does a lot more. So I mentioned earlier the undifferentiated heavy lifting. What this actually provides is a set of managed OAuth grant workflows. So think of this as saying, hey, token vault, I need to access Gmail. It will automatically look and say, okay, do you have an access token available? No, launch a user authentication request, getting the access code or the code, go and exchange it for a token, etc. So it manages all of that kind of heavy lifting of those different OAuth grant types.
So these are four key components of what make up AgentCore. Again, we're going to reference these as we get deeper and deeper into the presentation. So quickly we thought we'd just flash this up in terms of what does this look like. So inbound users interacting with applications, the agent's going, it's doing its validation outbound, it's got to go and do its calls to external tools. Double clicking, the user will go obtain an access token. That application is going to go, it's going to ask AgentCore to say, hey, here's my access token. I want to invoke you, agent.
We then, our authorizer will go make a call out, grab keys, do all the fun stuff of authenticating and authorizing that particular user. But one unique thing that we do here in AgentCore is once we verifiably identify who the subject of that or the user of that particular request is, we bind that user to the agent through something that we call a workload access token. So think of this as saying, hey, I invoked my agent and now me and that agent are bound together through this one key, and that key is what's going to allow me to go and unlock to get credentials for my particular session. And only that key is going to allow me to get credentials.
This is how we will say if Raoul wants to access Gmail through the agent and I want to access Gmail through the agent, this is what's ensuring that that agent's only acting on behalf of me or only acting on behalf of Raoul. So when that user invokes that agent, we're initiating that workload access token which is doing that binding of those two, the two entities together. And then that access token is what's actually used to go and call the token vault, and the token vault essentially is what is going to go and make those external tools, right, make a request to those external tools.
Okay, so one thing we didn't, we wanted to make sure we highlight, though this isn't the same slide, there's one little difference in the middle here. It says bring your own agent runtime. So the primitives within Bedrock AgentCore are standalone. So just because you're not running your agent code within Bedrock runtime or gateway, you can still use AgentCore identity. It is a standalone primitive. So let's say you decided to run your agent code in EKS or some other compute, you could still use AgentCore identity to create that unique agent ID to be able to go and create credential providers, use the token vault, etc.
So we wanted to make sure that as we went through this, you understood that it's not just AgentCore. If your business decided, hey, we decided to run this in our own EKS environment, great, you could still use AgentCore identity as a standalone primitive. So that's AgentCore at a very high level now. What we thought is how do we show you what are the specific access patterns that it can unlock and start to get a lot more detail into the actual.
Supported Access Patterns: AWS Resources, Three-Legged OAuth, and Two-Legged OAuth
So, apologies for the temporary interruption, but as I said, we have a lot of exciting things coming up. So thanks Ben for talking about Bedrock AgentCore identity and how it solves some of the authentication challenges we mentioned. Before I go into the next level of depth, I think it's very important, and that's why I'm still on this slide, very important to emphasize some of the design principles or tenets behind what led us to have Bedrock AgentCore identity and even Bedrock AgentCore be so fluid and really meet where you are or where our customers really are.
Bedrock AgentCore is framework agnostic as Ben called out. Bedrock AgentCore identity is identity provider agnostic as you can see on the left side, any identity provider of your choice and also agnostic of where you host your agent. So I think that's an important design tenet and principle we have. It's important for us to emphasize that as well. So let's talk. Let's go deeper into understanding what are the access patterns Bedrock AgentCore identity supports today and see behind the scenes on how the identity orchestration and orchestration really is taking place.
So just to reemphasize what are some of the access patterns we support today, AgentCore identity allows your users to invoke agents in order to access AWS resources.
At the same time, it also allows you to access resources outside of AWS that are OAuth or API key protected. As I mentioned in one of our earlier slides, we talked about two key categories. One was an agent acting on behalf of a user, or an agent acting on behalf of itself using pre-authorized user consent. Both these categories are solved for both access patterns, whether you're accessing AWS resources or resources outside of AWS.
So let's go deeper into the access patterns. Let's first talk about AWS resource access. A classic example here is a user invokes an AI agent that needs to invoke a Lambda function or read files from an S3 bucket, amongst others. Within AWS, when an agent needs to access AWS resources, what we do behind the scenes is AWS uses Signature Version 4, or SigV4, as its signing protocol that adds in authentication information while making API requests. So what really happens behind the scenes here is, bringing it back to agent use cases and scenarios, an agent, when it's trying to access an AWS resource, signs the API calls using SigV4. It assumes an IAM role subsequently, and then AWS validates this signed request and vends STS credentials, enabling that agent to access resources on behalf of the user. So that's in a nutshell how AWS resource access works.
Let's talk about non-AWS resource access. I'm going to talk first about the three-legged scenario. You may wonder why it's called three-legged. It's called three-legged because there are three parties involved. You have the user, you have the agent, and you have the resource. It could be Gmail, it could be GitHub, Slack, Salesforce, amongst others. So this is an example which we discussed earlier in our presentation. It was the example of the sales executive invoking an agent to access a CRM system, finance tool, and even the document brief generator. That's an example of a three-legged auth flow.
What really happens behind the scenes is Sarah, the sales executive, going back to our example, logs into her application in her enterprise or corporate environment. The identity provider that her organization uses, be it Microsoft Entra ID, be it Okta, be it Amazon Cognito, amongst others, validates the incoming caller Sarah and issues an access token or a JWT token that contains the authentication context as well as user information about who has really logged in. This token then gets passed along to AgentCore Identity, and we'll go into some more details in the next slide. But once Sarah grants consent, the agent gets a unique token and exchanges it for Sarah's access token to go fetch the CRM notes, finance system records, and then generate documents. So that's essentially how three-legged OAuth works.
And then the final access pattern is two-legged OAuth. Two-legged because there are two parties involved. You have the agent and you have the resource that it's trying to access. The example here is that of scheduled jobs, event-driven automation, amongst others, where you have an agent that essentially accesses a resource or invokes an API or invokes an MCP server based on pre-authorized consent or some events. An example that we talked about before was you have a high-severity ticket that comes through. You may have an agent programmed to go through your access logs, your application logs, and do a root cause analysis, or run a scheduled analytics job. Like you have an agent querying a database every 8 p.m. on a Wednesday and generating sales reports for your organization. So that's an example of two-legged OAuth.
Behind the Scenes: Step-by-Step Identity Orchestration in Action
Let's go a layer deeper. Let's understand how does AgentCore Identity work. We'll take the most complex example amongst the three flows. We'll talk about a scenario where your agent is accessing a resource outside AWS. We had the sales executive example. I'm going to keep referencing that back so that you can understand what's happening behind the scenes. So first and foremost, even before the sales executive Sarah invokes the agent, she needs to log into her application. That application may have a specific identity provider. As we mentioned, Bedrock AgentCore Identity is IDP agnostic. The application could be using any IDP that we support today. That issues a unique JWT token to the user, Sarah, with her user context. And then this JWT token is passed along to AgentCore Identity.
As part of Amazon Bedrock AgentCore Identity, we validate who the caller is and verify the user's access token. We verify the token signature from the issuing Identity Provider. We verify the issuer of this token, who the audience is, and any custom claims that the agent builder wants us to verify. For example, does Sarah belong to a specific department or a specific group in our organization? All of this rich authentication context is captured in this JWT token, which AgentCore Identity's authorizer component, which Ben was referencing earlier, validates. The decision of this validation step is whether Sarah is allowed to invoke this agent or not. It's a simple yes or no decision.
If the answer is yes, we move to the next step, which is enforcing user consent and scopes. Once we determine that the agent is now permitted to act on behalf of the sales executive, the agent code or the agent logic determines which tools do I need to invoke, which MCP servers do I need to invoke or access. In this example, it was the CRM system, the finance system, and the document generator. It then prompts Sarah back to capture her consent. Sarah needs to explicitly consent for this agent to take and fetch the necessary records, which otherwise she would have had permission to. This agent also needs to have the right scope. As you mentioned, a key principle for us is secure by default, just enough access. If Sarah only has read access permissions to these systems and write permissions for the document generator, then the agent should have the same access levels as granted by Sarah when she's giving her consent. That's step number two. We capture that consent and we capture the scopes needed to perform the task.
Once this step is done, AgentCore Identity then authorizes the agent to go ahead and perform the task. What we do here is we take Sarah's user identity context and user identity. We have a user token and we have the agent's unique identity to vend an opaque workload access token. We call it workload access token, but for the purposes of this talk, let's call it the agent token. It is basically the permission that we grant the agent to then go ahead and perform tasks on behalf of the calling principal. This is a key concept to note here. We are issuing this agent-specific token by a unique combination of who the end user or the caller is and the agent identity. This does two things. It ensures that you don't have any impersonation. You have the right agent that's allowed to take action on behalf of the user. Secondly, it only acts tied specifically to the context or the user context that Sarah has when she invokes the agent.
The next step here is facilitating credential exchange. As you know, this agent token alone is not enough. This agent needs to interact with all of these three systems that we're talking about. These three systems have their own token endpoint. They have their own authorization servers. They don't accept these agent tokens, so it's important for the agent to be able to get the right, just enough scoped access token that the user Sarah has in order to perform the action. So what really happens? The agent token that we issued in the earlier step acts as the key to unlock the token vault where we store the user Sarah's access token, which is issued by all the authorization servers on the right side and on the bottom that we see. Token vault is a key component, as you would remember, of AgentCore Identity that Ben talked about.
Once this token vault is unlocked by the agent token we had issued, the agent serves as the bearer of Sarah's access token to then go unlock access to all of these three tools. It fetches from the CRM system, which has Sarah's read access permissions and the access token. Same for finance, and then the write access to help generate the brief. Last but not least, once that happens, you essentially finally broker access to the resources. That's the final concluding step that AgentCore Identity does in this entire example. The agent in itself prepares the document brief to help the sales executive be prepared for the client meeting.
AgentCore Identity handles all the undifferentiated heavy lifting behind the scenes. I know Ben talked about how at AWS we love to use the word undifferentiated heavy lifting, but think about it. The entire authentication of the initial user, capturing consent, authorizing the agent to take action on behalf of this user, facilitating this credential exchange.
All of this takes place behind the scenes by AgentCore Identity so that you or developers in your organization don't have to stitch together any custom glue code to make this happen. That's what AgentCore Identity is doing behind the scenes.
Practical Implementation: Resource Credential Providers and Observability
I'm going to talk to you next about another scenario. Ben talked about how AgentCore Identity is tightly integrated with AgentCore Runtime where you host your agents. We're going to talk about a scenario where you're using AgentCore Runtime with AgentCore Identity to facilitate your agents to access resources outside of AWS, let's say Google Drive, Slack, or GitHub. As you all know, many of these tools accept OAuth client credentials like client ID and client secrets, or they accept API keys as a way to access their systems. To facilitate this, a key part that you need to understand here is AgentCore Identity has a component called Resource Credential Provider, which we'll talk about the benefits very shortly. But as a developer, the first thing that you need to do to broker access and facilitate access of your agent to these third party tools is to set up your client credentials. We're going to talk about this specific example. In this case, let's say you're trying to access Google Drive. Your developers would need to go to Google Console and they would need to fetch the relevant client ID and client secret that are necessary to enable your application to access these tools.
Since it's an agentic application, the next thing that you would do is set up a credential provider, which is one of the key components of Bedrock AgentCore Identity. You can register your agent with these client ID and client secrets that you have just fetched. You can do this registration either on our management console, you can do it through CLI, or you can even do it through our SDKs as well. A key distinction that I want to draw here in terms of benefit of AgentCore Identity is that these secrets, client ID and client credentials or API keys, you don't need to embed them as part of your agent code. You don't need to embed them in your CI/CD pipelines or your repositories. You can securely store them using AgentCore Identity's own secrets management component. This way you make sure that only the relevant agent is allowed to call this Google Drive tool by fetching appropriate credentials that you have stored on behalf of the agent.
The third step here is adding an annotation. We have shared a code snippet here which would basically enable your agent to obtain the OAuth access token on behalf of the user to access Google Drive. So this code annotation that you see specifies what scopes you are requesting when you try to fetch this access token on behalf of the user. It specifies which credential provider, if it's Google Drive, you specify the provider name for whom you are actually fetching the access token. And the next step really here is adding code in your agent to use this OAuth access token that would allow you to go access this resource on behalf of the user. In this specific example, when you blow up the screen a little further, you see this specific example you're requesting a read scope. It's allowing you to list all the IDs of the first ten files the user has access to in their Google Drive. So that's essentially what's happening behind the scene with AgentCore Identity.
Once you store these credentials and register your agent with AgentCore Identity, you specify and annotate your code with the access token to be fetched and specify how this code is actually used in your agent code. Ultimately it helps enable your users to access the specific tools, in this case Google Drive, using your agents. So we talked a lot about control plane configuration, registering your agents, and we talked about data plane flow on how the access gets brokered to this resource. But a key component here is this is not the end of the entire agent lifecycle. From a governance and observability standpoint, it's also important that our customers have visibility to understand what actions an agent is taking on behalf of a user or on behalf of itself with preauthorized user consent.
To enable this, AgentCore Identity is natively integrated with AWS CloudTrail.
All API calls to Bedrock AgentCore Identity are stored as immutable logs in CloudTrail. Also, any time your agent accesses an AWS resource, you're able to trace back who accessed or who called this specific API to an AWS service resource, who that agent identity was. You can actually make all those traces yourself through CloudTrail. The second item here is we have pre-built integration with AgentCore observability. This will allow you to trace and monitor inbound and outbound authentication requests to agents, the success rates, the number of token and API key fetches, amongst others. Both CloudTrail and AgentCore observability integration provide you the right level of auditability and visibility needed for you to understand what actions agents are taking. It also gives you the tools to diagnose and troubleshoot issues as needed and to meet internal organizational compliance requirements when you want to see a trace of what that agent has been doing, especially when it's accessing AWS resources.
What's New: Recent Launches, Future Roadmap, and Getting Started Resources
So with that, I want to pass it over to Ben to talk to you about some of the new updates that have come with Bedrock AgentCore Identity. So over to you, Ben. Thank you. So hopefully now you all have a really good context of what AgentCore Identity is. You've learned something about AgentCore Identity. Hopefully you'll take something away and go back and see if you can get it implemented. As I mentioned, this is a busy week for us. We were not only here talking to lots and lots of customers, but Tuesday we had a bunch of launches, and of course we're having to prep for the session.
So what we want to do is just talk about launches specific to this week. We launched AgentCore in preview several months ago. It went GA just a couple months back, and since then we've been working on a lot of additional improvements. Now what I'm showing here is only related to identity access management authentication. AgentCore Identity had a lot more launches this week. We launched a whole new primitive around evals, a lot of enhancements around memory, et cetera, but I wanted to just double click into some specific launches for identity this week.
So first off, within AgentCore Identity, we launched support for custom claims and scopes. So what this means is on that inbound authorizer, we previously were able to do things like validate the audience or maybe the client ID. Now you can add any custom claim that you want within that authorizer. So let's say you say this person should only be able to invoke that agent if their group is equal to HR or some other claim. So now it makes it easier to provide that coarse-grain access control. I'm not calling it fine-grain access control, but coarse-grain access control on that inbound authentication.
The next thing we did was launch three-legged OAuth support. We really should call this user consent for Gateway. So again, Gateway is our MCP-based component that allows you to go and access external tools. We always supported three-legged OAuth directly from Runtime itself. Runtime is just code. You can handle authentication URLs and all that stuff within your own code. When we're talking about MCP, it was a little bit more difficult. So when you go and you need to request authentication, send this URL back, there's no easy way to handle that. Thankfully, MCP and collaboration launched URL elicitation, and so now MCP as a protocol allows you a standardized way of presenting that URL back into your applications. So we took advantage of that within Gateway, kind of kept up with what the protocol provides, and so now we've also provided three-legged support. So think of this as I can now use Gateway to go and use that user consent-based authentication.
Now Gateway also launched some really exciting things. Actually, custom Lambda interceptors was launched late last week, and this is what you would expect it to be. You want to invoke a tool in Gateway, you now have an ability to run custom Lambda authorization against it. So you say go invoke this particular target, and you send that request to your Lambda function. The Lambda function can do whatever the heck you want with it. You send back a pass or fail, and then the tool can be invoked. So that's just the ultimate flexibility.
The other thing we launched was Policy in AgentCore, so this is super exciting. I think this is the one that we've heard the most in terms of customers saying I need to get my agents to production, but I need the level of authorization to be able to make this safe. And so Policy in AgentCore works against Gateway. It leverages Cedar. So if you're not familiar, Cedar is our open source policy language. It allows you to write those fine-grain access controls against different invocations within Gateway. So coarse-grain on invoking the Gateway, fine-grain on the actual tools that you're trying to invoke. So let's think of the use cases of I should only authorize this agent to be able to do this if the dollar value is less than $100. This policy is what allows you to do that real fine-grain access control. So super exciting about this. So far this week we've gotten fantastic feedback from customers on it.
So looking forward, we're going to continue to improve the developer experience. We talked about the SDKs.
We still think there's a little bit of friction in the getting started experience. So we need to continue to evolve the experience around the SDKs, we need to continue to evolve things around automation, and we need to continue to provide you better samples. That's a big focus for us in improving not the end user experience, but your experience as developers building agents and using AgentCore.
The second area is we've got to keep up with new and emerging access patterns and protocols. This is a fast-moving space, as you all can imagine. A year ago, MCP wasn't a thing, and now it's a real thing, and it's evolving, and we have to stay up to date with it. Just like I mentioned, URL elicitation just came out, and we're going to take advantage of that and add it into Gateway. There are different types of protocols—today we support OAuth, API keys, and IAM, but there's so many out there, and we'll continue to enhance and evolve that.
The last thing is a big focus for us is how do we make sure we evolve this On-Behalf-Of capability. I went through a lot of detail today on how we currently support On-Behalf-Of, but at the end of the day, what the protected resource is seeing is still the user's access token, and there's more we could do there. So we're looking at OAuth token exchange RFC 8693 to be able to actually add in more of the agent acting as an actor in that claim. We'll evolve that through multiple agent chainings and other scenarios. Another big focus for us is Human in the Loop. It's something we hear all the time—it's great we have this policy we're restricting what the agent can do, but sometimes I just need a human to be able to take a look at this. So these are areas that we'll continue to improve on.
Awesome. Okay, getting started with AgentCore Identity. We've got lots of resources out there. We've got our product detail page and our developer guide. I really encourage you to go to the GitHub samples. We've really tried to provide lots and lots of examples out there. These are examples of all the different access patterns I've mentioned. Hey, I want to try to do this 3-Legged OAuth thing in my runtime—we have samples for that. Hey, I want to go and authorize using my IDP—we have examples for that. So take a look at the GitHub samples. It's a great place for you to be able to go and get started, not only for AgentCore overall but down into identity specifically. We have getting started under 10-minute type of guides.
So with that, I just want to say thank you very much. I know it's been a long, long week for all of you. I appreciate you coming here at lunchtime.
; This article is entirely auto-generated using Amazon Bedrock.
Top comments (0)