iTranslated by AI
re:Invent 2025: Securing AI Agent Access with Amazon Bedrock AgentCore Identity
Introduction
By transcribing various overseas lectures into Japanese articles, we aim to make hidden valuable information more accessible. This project, driven by that concept, features the following presentation!
Regarding the transcribed articles of re:Invent 2025, information is compiled in this Spreadsheet. Please check it as well
📖re:Invent 2025: AWS re:Invent 2025 - Securing agent access with Amazon Bedrock AgentCore Identity (SEC313)
In this video, Rahul and Ben, AWS Principal Product Managers, explain how to secure agent access using Amazon Bedrock AgentCore Identity. As an industry trend for agentic AI, Gartner predicts that by 2028, 33% of enterprise applications will incorporate agentic AI elements. Key challenges in agent construction include caller verification, consent management, scoped system access, and the need for custom code. AgentCore Identity solves these challenges by creating workload IDs, orchestrating OAuth flows, and managing credentials through a token vault. It supports both three-legged and two-legged OAuth access patterns and provides auditability through integration with AWS CloudTrail. At re:Invent, new features such as custom claims and scope support, three-legged OAuth support for Gateway, and AgentCore Policy were announced.
- This article is automatically generated, maintaining the original lecture content as much as possible. Please note that typos or incorrect information may be present.
Main Content
Session Start: Overview of Protecting Agent Access with Bedrock AgentCore Identity
Hello everyone, my name is Rahul. I'm a Principal Product Manager at AWS, focusing on generative AI, machine learning, and user authentication. Today, I'm delighted and excited to talk to you about securing agent access using Bedrock AgentCore Identity. So, without further ado, let's dive right in. But before we do, let me just confirm once again, can you hear me? Can everyone hear me? Perfect. Great. Let's start.
Today, we're going to cover a broad range of topics over the next hour. We'll start by broadly setting the industry context for agentic AI, and then we'll deep dive into each of those topics. We'll talk about the authentication challenges associated with securing access for agents. Then we'll introduce you to Bedrock AgentCore Identity and talk about how it addresses all of the challenges that we point out. We'll deep dive even further and talk about the agentic access patterns that Bedrock AgentCore Identity enables, and then finally, we'll talk about the new capabilities in AgentCore Identity. We've had a lot of announcements at re:Invent, so we want to update you on those so you can get started with the product.
All-in on Agentic AI: Industry Trends Accelerating Productivity and Time-to-Market
So, to set the agentic industry context, I'm going to pass the baton over to Ben. Can I get a quick show of hands, anybody building anything in the agentic AI space today? Not surprised. Well, it's clear, companies are all in on agents. I don't think that should be a surprise to anybody. You're here on day four, pretty packed audience. This is an important topic. You go out on the expo floor, you see how much investment is going around agentic AI. Personally, I see it every single day. Every customer conversation I've had this week has been, how do you help us get agents into production faster?
And it's not just us seeing this. Gartner says that by 2028, just a few short years from now, 33%, a full third, of all enterprise applications will have agentic AI elements. This is up from just 1% last year. Probably last year that 1% had some niche small use case that they had to throw this AI element into, but now it's becoming pretty mainstream. It's becoming common in how we build applications. Further, they say 15% of our decision making will be done autonomously. I don't know about you, but I'm not mad if 15% of my decision making from now on is done autonomously. That's replying to invites, dealing with tickets. The use cases are endless, but I am not mad if 15% of my decision making goes somewhere else and frees up my time.
So we have to ask ourselves, what's driving it? And I think some of this is pretty obvious. First and foremost, it's productivity. Again, personally, I use agentic AI tools every single day as a Product Manager. I use them for consolidating customer feedback, feature requests that you all provide us every day. I use it to accelerate documentation writing. As you know, Amazon is a big document culture. As PMs, we can use these to help get our documents into Amazon writing style.
More recently, we've gotten a great tool that's helped us build UX mocks. As a product manager, I used to want to make my ideas come to fruition, and the best way to do that is to get a mock. And before, you'd be in a queue for a UX designer and wait two weeks for that design to come out, and you just had anxiety waiting. And now, in 15 minutes, with some simple prompts and iteration, we have a tool that gets us these great UX mocks. So, obvious benefit, productivity at scale. And I'm sure you all are seeing this yourselves.
Next, we're starting to see these context-aware experiences and decision-making. So, situations where, as a developer, you might have written tens of thousands, hundreds of thousands of lines of code and business logic to make these experiences come to fruition. Now they can be context-aware and can be done with simple calls into LLMs. It just opens up a bunch of different opportunities. So, the type of experiences that we can enable, and this context awareness, is truly spectacular.
Finally, time to market. As I said before, not only are we getting productivity on the product side, but also on the engineering side with coding agents, automated development of documentation, etc., we're accelerating our ability to serve customers. Clear, clear benefits.
The Wall to Production: Three Challenges of Secure Access, Controlled Autonomy, and Evolved Governance
The benefits are clear. So the next question is, what does this actually mean for an organization? You have this great prototype. That prototype has proven to be really, really valuable. But then, you hit a pause. You actually have to make this real. And one of the first questions you get is secure access. Agents should have just enough access at just the right time to perform their tasks. So, how do you do that? Do you give agents their own identity? Do you give them their own access? Probably not the best decision. Agents are non-deterministic. So this is something that you have to think through as you start to build agents.
Next is this interesting controlled autonomy. We call this the healthy tug of war. Think back to when the cloud first came out. There was this tug of war that we wanted to give developers on-demand access to cloud resources so that they could be agile and move quickly. And then the operations teams were saying, wait a minute, we have security and compliance requirements. We're starting to see that same tug of war happen again. Organizations want to see the benefits of agents, and they understand that these cool things can happen, but then they ask how do we get controls and compliance in place? So that same tug of war happens. You need to move quickly, but you need to move quickly in a controlled manner.
Finally, evolved governance. Agents are not humans. Humans for governance, we've somewhat solved, right? It's been around for a long time. You have identity providers and human lifecycle management. Then machines came around. Machines are pretty easy to manage. They're deterministic, so when you give them access, it's safe. You know what they're going to do every single time. And now, all of a sudden, you have this new entity type, agents. What are agents? They're not human, and they're not machines. So it's truly a third entity that organizations now have to think about for governance. How do you do lifecycle management? How do you have proper ownership? How do you ensure that you're auditing the permissions that an agent has? These are new things that are coming out for organizations to think about, and they're hard.
Sales Executive Sarah's Case: Access Patterns and Authentication Challenges in Client Brief Creation
So with that context, I'm going to pass it off to Rahul, who's going to deep dive a little bit more about what this actually means in terms of the authentication challenges in dealing with these. Thank you, Ben. Thank you for setting up the industry context of why organizations are adopting agentic AI systems. And now that we understand why organizations are adopting agentic AI, let's take a show of hands once again. How many of you are actually building agents in production within your organizations? Quite a lot of you. So you're probably already aware of some of the authentication challenges, but we'll really deep dive into the challenges that we are hearing from a lot of our customers.
Before I talk about authentication challenges, it's important to understand what are the common access patterns. As I talk to customers, as I talk to you all, we're hearing two main categories. First and foremost, where an agent performs tasks on behalf of a human user. This is a typical example where a user delegates an agent to perform a task that they would have otherwise performed themselves. Within this category, we're seeing three examples or three scenarios. The first scenario is where a human user delegates a helper agent to perform a very specific task. For example, within an organization, you might have a high queue of support tickets. We're hearing customer use cases where they're using agents to summarize support tickets and do root cause analysis. That's a task-specific agent. The second example is where a human user uses or delegates a task to a general orchestrator agent, and that agent determines the nature of the action that the user wants to perform and then delegates it to a second agent or a sub-agent to perform those task-specific actions. A typical example would be, let's say you have a generic productivity AI agent assistant. You can ask that agent, can you set up a calendar event in my Google Calendar, can you write a summary of my emails, can you perform a root cause analysis for all the support tickets in my organization, or can you pull up sales records from my CRM system? You give this generic agent a task, and then that agent interacts with other task-specific agents to perform those actions.
And the third category is where a human user invokes an agent, and that agent invokes an MCP server to invoke various tools that the MCP server exposes to access target-specific resources. That's pattern number one. The second pattern that we are commonly hearing is where an agent performs tasks in response to an event or a pre-approved user consent. A typical example would be background jobs, scheduled tasks, or event-driven automation. For example, you might have an agent that's scheduled to query a specific database at 8:00 PM every Wednesday to generate weekly business reports. That's one example. A common example that we're hearing for event-driven automation is where, if there's a high-severity ticket in a queue, you might have an agent analyze logs to provide root cause analysis. These are some of the examples that we're broadly hearing from customers.
So let's deep dive into one of these access patterns and make the example a little bit more concrete. I'm going to talk about a sample use case for agent AI in organizations. I'm going to talk about the on-behalf-of flow. This is where a human delegates an agent to act. In this example, we have a sales executive. Let's call her Sarah. She wants to prepare for an upcoming client meeting, a customer meeting, and she basically wants to use an agent to help her prepare for these client meetings.
Previously, in a pre-agent world, what she would do is access the CRM system, manually go through all of the customer notes, and prepare a client brief before going into a customer meeting. Or she would delegate this task to her team to do the same. As you can imagine, this is a lot of manual work. The large-scale productivity gains that Ben talked about earlier that she's now looking to achieve using agents is what she's trying to achieve in this use case. So Sarah, instead of preparing these client briefs herself, she uses natural language to prompt an AI agent within her organization to help her prepare for an upcoming customer meeting. The agent, using this natural language query that it received, determines that it needs to access two systems. It needs to access the CRM system to retrieve all of the meeting notes and call notes from past discussions with this customer, and it also needs to access the financial system within her organization to retrieve past customer spend data. So the agent, once it determines that it needs to, it returns a prompt back to Sarah, asking for her consent to allow the agent to access these systems.
Once Sarah provides this consent, the agent can then use the permissions that Sarah has access to for the CRM system and the financial system to retrieve the notes and the financial spend data. Once the agent retrieves this information, it can then summarize it and create a personalized client brief for the sales executive. It uses another tool to summarize the brief and has write access to it, and outputs it to Sarah so that she can be prepared for her sales meeting.
So that is a sample use case. We'll be referencing this use case in multiple parts of this presentation as we walk you through some of the challenges. So let's quickly get to it. Even a relatively simple agentic workflow of preparing these client briefs comes with distinct identity and access management challenges. So let's first understand what these challenges are.
Four Authentication Challenges: Caller Verification, Consent Management, Scoped Access, and Custom Code Burden
First and foremost, there's a challenge of verifying who the caller is. This agent needs to know who is calling it, who is the human identity that's calling me to perform this job. And it also needs to identify whether this user is authorized or allowed to invoke this agent. That's first. Step one is caller verification.
Step two is consent management. Remember what I talked about in the previous example. Sarah needs to delegate consent for this agent to access the CRM system, the financial system, and even this email authoring system to prepare the brief. The agent needs to have specific read-write permissions to access these systems and do the job, and that too, only after Sarah provides consent. The third is enabling scoped system access. As I explained earlier, in this case, the agent will communicate with the CRM system, the financial system, and also the document summarization tool. Each of these tools have siloed authorization servers that issue their own tokens. In this case, the agent needs to have precise read access or write access and ensure that it's not taking more action than what it's expected to do, because it can be problematic if it takes more than that. It can have write access to sensitive systems that you don't want it to grant. So it's critical that we can solve strictly scoped system access. This allows the agent to have just enough access to perform actions on behalf of the user.
And last but not least, there is the challenge of writing custom code to stitch all of this together. Agent builders and developers often have to think about integrating identity providers. They have to think about handling credentials, API calls, exchanging credentials, authorization, and error handling in all of this. This is not a trivial task. It's a huge amount of custom glue code that agent builders and developers have to stitch together to make this happen. So you can see that even simple, lightweight agentic use cases expand into multiple identity orchestration related challenges.
So when we take this example and generalize it more broadly, what are we observing? As we talk to customers, we've been able to consolidate all of these problems into three categories. The first one is securely delegating authority to agents.
Agents need to be able to invoke multiple systems, be it 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. This results in agent builders often over-privileging agents or building brittle workarounds, and this has been a huge problem.
The second challenge is dealing with user consent fatigue. As you can imagine, in the previous example, the sales executive was preparing for one customer meeting. At re:Invent, I'm sure you all have had multiple customer conversations, dozens, or maybe 50 conversations. Imagine giving consent 50 times for each of those three systems. That's like 150 prompts for consent to a user. That's noisy. It's not a good end-user experience. Today's identity and access management systems don't have mechanisms to store persistent consent or task-specific consent for these agents.
And the third challenge is custom integrations and glue code. Builders have to write a lot of custom logic to stitch together the identity plumbing. Authentication management with initial identity providers, getting consent, handling credentials, error handling, and then exchanging credentials. So a lot of work that needs to happen to stitch together this custom integration code. These challenges are not theoretical. They exist in almost every agent deployment that needs to be done, and these challenges often slow down agents going into production. This is something that we are consistently hearing from our customers.
So why are the challenges that I just talked about important? First and foremost, as Ben talked about in the earlier part of the presentation, agents are key to unlocking productivity gains and reducing time to market. Without trust built into agents, without a mechanism to securely delegate authority to agents, organizations will not have the confidence to adopt agents or accept agents, and thus not unlock the benefits. So trust in agents is critical for broader adoption.
Secondly, organizations are not in a position to add additional burden on developers. They don't want additional developer burden to ease and solve the authentication plumbing required to secure agent access. Without it, developers will have to spend more time and effort, slowing down their experimentation and release cycles, and as a result, slowing down the pace of deploying agents into production.
And last but not least, the end-user experience needs to be seamless. We don't want a situation where the users invoking agents are constantly being presented with repeated consent prompts, severely degrading the experience. We don't want a noisy experience for end users. It needs to be seamless and yet secure. These problems directly impact how you build and can productionize agent systems. And we want to help you as you build agents in production or start to think about building agents in production. How do you get to market faster? How do you get to your end users faster?
The Birth of Amazon Bedrock AgentCore Identity: Enabling Secure Delegated Access and Eliminating Undifferentiated Heavy Lifting
So what was the opportunity here? All of these things that we talked about as challenges created an opportunity for AWS to solve this foundational IAM, identity and access management challenge. We realized that identity is that critical glue that will allow agents to get into production faster. That led us to solve this at scale. We wanted a solution that would enable secure delegation to agents and unlock broader agent adoption within organizations or externally. And thereby, we wanted to be able to get agents to market faster. This led to the birth of Amazon Bedrock AgentCore Identity. And now I'll have Ben talk in more detail about how Bedrock AgentCore Identity solves some of these challenges that we just talked about. Ben, take it away.
Thank you. All right, let's get another show of hands. How many folks have heard of AgentCore Identity? Okay. Keep your hands up if you've done any prototyping with AgentCore Identity. Not as many. How many are building production agents using AgentCore Identity or AgentCore in general? Anybody? Okay, we've got some work to do, which is good.
So, as Rahul articulated, we understand the challenges we've heard from customers.
And obviously, we built Amazon Bedrock AgentCore Identity to directly solve these challenges. First and foremost, we solve the challenge of secure delegated access for AI agents. We do this by creating a unique, stable workload ID for all of your deployments on AgentCore. So, when you deploy an agent, or you deploy a gateway, we're going to create a unique identifier for that. Second, we help enable streamlined AI experiences. As Raul mentioned, consent fatigue is a real thing. You don't want to build all these things, and then users get tired and don't want to use it. You want them to use it for productivity gains. So, AgentCore Identity helps to solve all that consent fatigue by persisting these tokens in a safe, secure manner, as Raul mentioned. And finally, we wanted to build AgentCore Identity to help you build agents faster. At AWS, you'll probably hear the term "undifferentiated heavy lifting" quite a bit. When we see situations where developers have to do the same thing over and over again, it's not adding business value for you, so we want to remove it. So, we've built this to do things like provide a managed service for orchestrating OAuth flows. How many of you, when building agents, want to deal with getting an authorization code, exchanging it for an access token, and then when the access token expires, getting a refresh token and getting a new one? It's not fun. It's not something you probably think adds value when building agents. So, AgentCore Identity removes that undifferentiated heavy lifting from you.
Identity at the Core of AgentCore: Inbound/Outbound Authentication and IDP-Agnostic Flexibility
So let's think about where it sits within AgentCore as a whole. For folks not familiar with AgentCore, it's a set of various primitives, and they all work together like one big service. You have AgentCore Runtime. This is your core runtime for hosting your agents. You have AgentCore Gateway. This is MCP protocol based, allowing you to talk to external tools. You have AgentCore Memory, that's pretty self-explanatory. You have AgentCore Observability, which gives you visibility and traceability into everything that your agents are doing. And then some helpful tools, AgentCore Browser and AgentCore Code Interpreter. We don't have time to go into all these in detail, but I highly encourage you to check them out. And then, at the very core, you have AgentCore Identity. And while it might be biased, we think this is kind of the glue that holds all of this together. And I'll touch upon that just a little bit.
When building agents, there are a couple of very fundamental things you really have to think about. First, users need to be able to access your agents. And in the AWS world, commonly, this is done through IAM, but not all of you want to use IAM in your applications to allow your users to invoke agents. So how do users actually access agents through your applications? And then on the other side, that agent needs to go perform tasks and invoke external tools, so how do you do that?
In our world, we call the left side inbound authentication and the right side outbound authentication. And the key questions that AgentCore Identity answers is first, who is the user? As Raul mentioned, when a user is acting on behalf of someone, we need to know who that 'someone' is, who that user is. How do we determine in a verifiable fashion who is the user invoking this agent? And is that user even allowed to access the agent in the first place? For example, if I have an HR agent, and I only want the HR department to invoke it, how do I ensure that basic authentication is set up? On the outbound side, we need to know, is this agent really what it says it is? Do I have a verifiable identifier for that specific agent? And then can that agent actually access these tools on behalf of that user? These are the core requirements on the inbound and outbound side, and as Raul mentioned, they're not as easy to solve once you get to scale.
So I'll show you a little bit about the core components of AgentCore, and then as Raul deep dives, you'll understand how they connect. As I said, we're going deeper, deeper, deeper. This is a 300-level talk, so we'll get there. Within AgentCore Identity, there are a few different components. First and foremost, you have an identity directory. This actually, for those who've used AgentCore Identity, isn't very visible. You might not even know that this is happening. Every time you deploy a runtime in AgentCore, we're creating an identity directory within your account, and that runtime is a workload ID, so that's tantamount to an agent identifier. Same thing for a gateway. Every time you deploy a gateway in AgentCore Gateway, we're creating a unique workload ID for that specific gateway. So you have this agent directory within Identity.
Next, you have an authorizer. We've taken an approach. We understand that many of you have very established identity access management solutions. You have an IDP, and if we were to tell you, hey, if you want to use AgentCore, you have to rip all that out and go put in a new IDP or only use IAM, that wasn't going to work for us. So we've taken an IDP-agnostic approach with the authorizer. What this means is if you're using Okta, Azure Entra ID, Ping, etc., you can configure us so that when a request comes in to invoke your agent, we're going to go talk to your IDP, validate it, and determine whether or not we should allow that invocation. So this authorizer is a key piece.
Next, you have this concept of resource credential providers. This is essentially, if your agent can access a tool, what is the credential that it's going to use to access that tool? If you're trying to access an API that's protected with a basic API key, think of an API key. If that agent can access a specific OAuth protected resource, think of an OAuth credential, like a client ID, client secret. So you have a secure credential provider that allows this specific agent to access these tools for credentials.
And finally, you have this concept of a token vault. The token vault, again, is probably pretty self-explanatory. It stores tokens, but it does more than that. I mentioned before the undifferentiated heavy lifting. What this actually provides is a managed set of OAuth grant workflows. So it will actually, when you say to the token vault, hey, I need access to Gmail, it's automatically going to check, see if an access token is available. If it's not, it's going to initiate a user authentication request, get the access code or the code, exchange it for tokens, etc. So it manages all of that heavy lifting for these different OAuth grant types for you.
So these are the four key components that make up AgentCore. Again, as we go deeper into the presentation, we'll reference these. So I want to quickly show you what this looks like. You have an inbound user interacting with an application, an agent operating and verifying, and then making outbound calls to external tools. If we double-click on that, a user gets an access token. That application goes to AgentCore and says, hey, here's my access token, I want to invoke an agent.
And our authorizer goes and does all that fun work of getting a key and authenticating and authorizing that specific user. But one of the unique things we're doing in AgentCore is once we verifiably identify who the subject of that specific request is, meaning the user, we're binding that user to the agent through something called a workload access token. Think of this as, hey, when I invoke an agent, now me and that agent are tied together through this one key, and that key is what allows me to unlock credentials for my specific session. And only that key allows me to get the credentials.
So this is how if Raoul wants to access Gmail through an agent, and I want to access Gmail through an agent, that agent is only going to act on my behalf or only act on Raoul's behalf. So once that user invokes that agent, we initiate that workload access token, and it's binding those two entities together. And then that access token is what actually is used to invoke the token vault, and the token vault essentially makes those requests out to those external tools.
Now, there's one thing we want to emphasize. It's not the same slide, but there's one small difference in the middle. It says, Bring your own agent runtime. So the primitives within Bedrock AgentCore are standalone. So you don't even have to be running your agent code within Bedrock runtime or a gateway to use AgentCore identity. It's a standalone primitive. So if you decide to, hey, I'm going to run my agent code in EKS or some other compute, you can still use AgentCore identity to create that unique agent ID, to create a credential provider, to use the token vault. So as we go through this presentation, I just wanted you to understand that it's not just AgentCore. If your business decided to, hey, I'm going to run this in my own EKS environment, no problem. You can use AgentCore identity as a standalone primitive. So that's AgentCore at a very high level. Now, what we thought we would do is show you how, what are the specific access patterns that it can unlock, and then go deeper into the actual details.
So, sorry for the momentary pause, but as I said, we have a lot of exciting things coming up. Ben, thank you for talking about Bedrock AgentCore identity and how it solves some of the authentication challenges that we mentioned. Before we get into the next level of detail, I think it's very important, and I'm still on this slide, to emphasize that the design principles and tenets behind why we even got to Bedrock AgentCore identity, and even Bedrock AgentCore itself, is that it's very flexible and it really meets you, our customers, where you actually are.
Bedrock AgentCore is, as Ben pointed out, framework agnostic. Bedrock AgentCore identity is identity provider agnostic, as you can see on the left, and it's also agnostic to where you actually host your agents. And I think this is an important design tenet and principle that we have. It's also important for us to emphasize this. So let's talk about it. Let's deep dive into what are the access patterns that Bedrock AgentCore identity supports today, and how the identity orchestration and orchestration really happens behind the scenes.
Three Access Patterns: AWS Resources, Three-legged OAuth, and Two-legged OAuth Mechanisms
So to recap some of the access patterns that we support today, AgentCore identity enables users to invoke agents to access AWS resources.
At the same time, it can also access resources outside of AWS that are protected by OAuth or API keys. As I talked about in one of the previous slides, I talked about two main categories. One is agents acting on behalf of a user, and the other one is agents acting on their own behalf using pre-approved user consent. Both of these categories are solved across both access patterns, be it accessing AWS resources or accessing resources outside of AWS.
So let's go deeper into the access patterns. First, I'm going to talk about AWS resource access. A typical example here is where a user invokes an AI agent, and that agent needs to invoke a Lambda function or read files from an S3 bucket, etc. Within AWS, when an agent needs to access AWS resources, what happens behind the scenes is that AWS uses Signature Version 4, or SigV4, as its signing protocol, and it adds credentials when making API requests. So what actually happens behind the scenes is, going back to the agent use case and scenario, when an agent attempts to access AWS resources, it signs the API call using SigV4. It then assumes an IAM role, and AWS validates this signed request and issues STS credentials, allowing that agent to access resources on behalf of the user. That's in a nutshell how AWS resource access works.
Now I'm going to talk about accessing non-AWS resources. First, I'm going to talk about the three-legged scenario. You might wonder why it's called three-legged. It's called three-legged because there are three parties involved. You have a user, an agent, and a resource. That could be Gmail, that could be GitHub, Slack, Salesforce, etc. This is the example that I described earlier in the presentation. The sales executive invoking an agent to access the CRM system, the financial tools, and also the document summary generator. This is an example of a three-legged authentication flow.
What's actually happening behind the scenes is, going back to the previous example, Sarah, the sales executive, logs into her application in a corporate or enterprise environment. The identity provider that the organization is using, be it Microsoft Entra ID, Okta, Amazon Cognito, or anything else, validates the incoming caller, Sarah, and issues an access token or a JWT token that contains the authentication context and information about the user that actually logged in. This token is then passed to AgentCore Identity. I'll describe this in more detail in the next slide. But once Sarah provides consent, the agent gets a unique token that it exchanges for Sarah's access token to pull CRM notes, financial system records, and generate documents. This is how three-legged OAuth essentially works.
And the last access pattern is two-legged OAuth. Two-legged is because there are two parties involved. You have the agent and the resource that it's trying to access. An example here would be scheduled jobs, event-driven automation, where an agent accesses resources or invokes APIs or invokes MCP servers based on pre-approved consent or some event. The example I talked about earlier is where if there's a high-severity ticket that comes in, you might have an agent programmed to go look into access logs or application logs to provide root cause analysis, or it runs scheduled analytics jobs. For example, you have an agent that queries a database at 8:00 PM every Wednesday to generate sales reports for the organization. This is an example of two-legged OAuth.
Detailed Flow Behind the Scenes: 5 Steps from User Verification to Credential Exchange
So let's deep dive one more level. Let's understand how AgentCore Identity works. I'm going to take the most complex example out of the three flows. I'm going to talk about the scenario where an agent accesses resources outside of AWS. We had the sales executive example. We'll keep referring to that example so that you understand what's happening behind the scenes. First and foremost, before Sarah, the sales executive, invokes an agent, she needs to log into an application. That application might have a specific identity provider. As I mentioned earlier, Bedrock AgentCore Identity is IDP agnostic. Your application can use any IDP that it currently supports. That issues to the user Sarah a unique JWT token that contains her user context. And this JWT token is then passed to AgentCore Identity.
As a part of Amazon Bedrock AgentCore Identity, it will verify who the caller is, confirm the user's access token. It validates the token signature from the issuing Identity Provider. Who is the issuer of this token, who is the audience, and it validates any custom claims that the agent builder wants to validate. For example, is Sarah part of a specific department or a specific group within the organization? All of this rich authentication context is captured in this JWT token, and the Authorizer component of AgentCore Identity, this is what Ben was referring to earlier, it validates that. And the decision from 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, then it moves to the next step. That is user consent and scope enforcement. Once we determine that the agent is allowed to act on behalf of this sales executive, the agent code, or the agent logic, determines what tools it needs to invoke, what MCP servers it needs to invoke or access. In this example, it was the CRM system, the finance system, and also the document generator. And it returns a prompt back to Sarah, acquiring her consent. Sarah needs to explicitly consent for this agent to retrieve or fetch the necessary records. These were the privileges that she herself would have had in the first place. This agent also needs to have the appropriate scope. As I mentioned earlier, a key principle for us is secure by default, least privilege access. If Sarah only has read access privileges to these systems and has write privileges to the document generator, the agent should also have the same level of access that was granted to it from Sarah when she provides consent. That's step two. It acquires that consent and acquires the necessary scope to perform the task.
Once this step is done, AgentCore Identity authorizes the agent to perform the task. What we do here is we take Sarah's user identity context and user identity. We have the user token, we have the agent's unique identity, and we issue an opaque workload access token using these. We call it a workload access token, but for the purpose of this talk, let's call it an agent token. This is basically the authority that we grant to an agent to perform tasks on behalf of the calling principal. This is an important 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 ensures two things. Impersonation doesn't happen. It's the right agent that's allowed to act on behalf of the user. And number two, it only acts in a state that is specific and tied to the context that Sarah has when she invokes the agent.
The next step is facilitating credential exchange. As you know, this agent token alone is not enough. This agent needs to interact with all three of these systems that we are talking about. Each of these three systems have their own token endpoint. They have their own authorization server. They will not accept these agent tokens, so it's critical for the agent to be able to get the appropriate, least-scoped access tokens that the user Sarah has to perform the action. So what actually happens? The agent token that we issued in the previous step acts as a key to unlock the token vault. The token vault contains access tokens for the user Sarah that have been issued by all of the authorization servers that you see on the right and on the bottom. The token vault, as Ben was talking about, is a critical component of AgentCore Identity.
Once this token vault is unlocked by the agent token that we issued, the agent acts as a bearer of Sarah's access token and unlocks access to all three of these tools. It fetches from the CRM system with Sarah's read access privileges and access token. Same thing for finance. And write access to generate the brief. And last but not least, once it's done, it basically brokers access to resources. This is the last wrapping up step that AgentCore Identity does in this entire example. The agent itself creates the document brief for the sales executive to prepare for a client meeting.
AgentCore Identity handles all of the undifferentiated heavy lifting behind the scenes. Remember, Ben was talking about how we love using the term undifferentiated heavy lifting in AWS, but think about it. The entire initial user authentication, acquiring consent, authorizing the agent to act on behalf of this user, facilitating this credential exchange.
All of this is done in the background by AgentCore Identity. So you, or your developers within your organization, don't need to stitch custom connection code to make this happen. That is what AgentCore Identity does in the background.
Leveraging Resource Credential Provider: Google Drive Access Implementation and CloudTrail Integration
Next, I'm going to talk about a different scenario. Ben talked about how AgentCore Identity is tightly integrated with the AgentCore Runtime that hosts your agents. I'm going to talk about a scenario where we use AgentCore Runtime and AgentCore Identity to enable agents to access resources outside of AWS, for example, Google Drive, Slack, GitHub, etc. As you know, many of these tools accept OAuth client credentials, like client ID and client secret, or API keys as a way to access the system. To make this happen, a critical piece that you need to understand here is that AgentCore Identity has a component called Resource Credential Provider. I'll talk about the benefits of this in a moment. But as a developer, what you first need to do to mediate and facilitate access for agents to access these third-party tools is to configure client credentials. I'll talk about this specific example. Let's say in this case, we're trying to access Google Drive. A developer needs to go to the Google Console and acquire the relevant client ID and client secret that your application needs to access these tools.
And then, because this is an agent application, what you then do is configure a credential provider, which is one of the key components of Bedrock AgentCore Identity. Using these client IDs and client secrets that you just acquired, you can register your agent. This registration can happen in the management console, it can happen via CLI, or it can even happen via the SDK. A key differentiator here that I want to emphasize as a benefit of AgentCore Identity is that you do not need to embed these secrets, client IDs, and client credentials, or API keys, as a part of your agent code. You don't need to embed it in your CI/CD pipelines or your repositories. You can use AgentCore Identity's own secret management components to securely store it. This is how you ensure that only the relevant agents are allowed to invoke this Google Drive tool by retrieving the appropriate credentials that you stored on behalf of the agent.
The third step is adding annotations. I've shared a code snippet here, and this basically allows the agent to acquire an OAuth access token to access Google Drive on behalf of the user. This code annotation that you are seeing specifies what scope it's requesting when it's trying to acquire this access token on behalf of a user. In the case of Google Drive, you specify the provider name of who you are actually trying to get an access token for. And then the next step here is actually adding code to your agent to use this OAuth access token and access this resource on behalf of the user. In this specific example, if I magnify the screen a little bit, in this particular example, it's requesting a read scope. This allows it to list all of the IDs of the first 10 files that the user has access to on Google Drive. So that's what essentially is happening behind the scenes with AgentCore Identity.
Once you store these credentials, register your agent with AgentCore Identity, then you provide code annotations to acquire access tokens, and how this code is actually used within your agent code. Ultimately, this allows users to use agents to access, in this case, a specific tool, Google Drive. I've talked a lot about configuring the control plane, registering agents, and then also talked about the data plane flow of how access to this resource is mediated. But a critical component here is that this is not the end of the agent lifecycle. It's also important from a governance and observability perspective that customers have visibility into what actions the agents are taking on behalf of a user or on its own behalf with pre-approved 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. And whenever an agent accesses AWS resources, you can track who accessed it, who called this specific API against an AWS service resource, what was the identity of that agent? You can actually do all of these traces yourself through CloudTrail. The second item is pre-built integrations with AgentCore observability. This allows you to trace and monitor inbound and outbound authentication requests to the agent, success rates, how many tokens and API keys were acquired. Both CloudTrail and AgentCore observability integrations provide you with the right level of auditability and visibility that you need to understand what actions your agents are taking. And it also provides you with tools to diagnose and troubleshoot problems if needed, and to meet compliance requirements within your organization when you want to see a trace of what that agent has done, especially when it's accessing AWS resources.
New Features This Week and Future Roadmap: Custom Claims, AgentCore Policy, and Getting Started
So I'll pass it over to Ben to talk about the new updates that we have added to Bedrock AgentCore Identity. So Ben, take it away. Thank you. All right, so you all have a pretty good understanding now of what AgentCore Identity is. Hopefully, you've learned something about AgentCore Identity. Hopefully, you'll take something away and try to see if you can implement it. As I mentioned earlier, this has been a busy week for us. Not only talking to so many customers here, but we had a slew of launches on Tuesday, and of course, we had to prepare for this session. So, what I want to do is talk about the specific launches that happened this week.
We launched AgentCore in preview several months ago, and it went GA just a few months ago. And since then, we've been working on a lot of additional improvements. Now, what I'm showing you here is only what's related to identity access management authentication. AgentCore Identity had a lot more launches this week. We launched a whole new primitive around evaluation, a lot of enhancements around memory, but I want to deep dive into the specific launches around identity this week.
First, within AgentCore Identity, we launched custom claims and scope support. What this means is that in that inbound authorizer, you used to be able to do things like validate audience and client ID, but now you can add any arbitrary custom claims inside your authorizer. So for example, you can say, hey, this person can invoke this agent only if their group equals HR or some other claim. This allows you to provide coarse-grained access control for that inbound authentication. We don't call it fine-grained access control, but it's coarse-grained access control.
The next thing we did was we launched three-legged OAuth support. This is really what we should call Gateway user consent. Again, Gateway is an MCP-based component that allows you to access external tools. We've always supported three-legged OAuth directly from the Runtime itself. Runtime is just code. You can handle all of your authorization URLs and everything within your own code. When we talk about MCP, it became a little bit harder. So you'd send this URL back when you needed to request authorization, and there was no easy way to handle it. Thankfully, MCP and collaboration launched URL elicitation. And now MCP, as a protocol, provides a standardized way to return that URL to your application. So we've taken advantage of that within Gateway, catching up with what the protocol is providing. And now we also provide three-legged support. So this means you can now use Gateway to use user-consent-based authorization.
Now, Gateway also launched some really exciting things. Actually, custom Lambda interceptors were launched late last week. This is exactly what you would expect. When you want to invoke a tool with Gateway, you now have the ability to run a custom Lambda authorization against it. So you say, hey, I'm going to invoke this specific target, and it sends that request to a Lambda function. The Lambda function can do whatever it wants with it. It returns a pass or fail, and then the tool is invoked. So this is ultimate flexibility.
Another thing that we launched was AgentCore Policy. This is super exciting. This is probably one of the most requested things we've heard from customers. You said, hey, I need to get my agents into production, but I need a level of authorization to make this safe. And AgentCore Policy works against Gateway. It leverages Cedar. If you're not familiar with Cedar, it's an open-source policy language. And you can write fine-grained access control against various invocations within Gateway. Coarse-grained for the Gateway invocation, fine-grained for the actual tool that you're trying to invoke. So let's take a use case. I should only authorize this agent to do this if the amount is less than 100. This policy is what allows you to do that really fine-grained access control. We're super excited about this. We've gotten great feedback from customers so far this week.
Looking forward, we're going to continue to improve the developer experience. I mentioned the SDK. We still think there's a little bit of friction in the getting-started experience. So we need to continue to evolve that experience around the SDKs, continue to evolve things around automation, and continue to provide better samples. This is a huge focus for us on improving your experience as a developer building agents and using AgentCore, not the end-user experience.
The second area is we need to continue to keep up with newly emerging access patterns and protocols. As you can imagine, this is a very fast-moving space. MCP didn't exist a year ago, and now it actually does, and it continues to evolve. And we need to keep up with that. As I mentioned before, URL elicitation just launched, and we're going to leverage that and put it into Gateway. Various types of protocols. We currently support OAuth, API keys, IAM, but there's a lot of protocols out there, and we're going to continuously enhance and evolve those.
And finally, a big focus for us is how do we evolve this On-Behalf-Of capability? We talked about in detail today how we currently support On-Behalf-Of, but at the end of the day, the protected resource is still seeing the user's access token, and we can do more than that. So we're looking at OAuth token exchange RFC 8693, and we want to actually have the agent be added to that claim as an actor. And we'll evolve that through multiple agent chains and other scenarios. The other big focus is Human in the Loop. This is something we constantly hear. It's great that we have policies that limit what an agent can do, but sometimes a human needs to be able to confirm this. These are the areas where we're continuously improving.
Excellent. So, getting started with AgentCore Identity. We've got a ton of resources. We've got product detail pages, developer guides. I highly encourage you to look at our GitHub samples. We've really tried to provide a lot of examples. These are examples for all those different access patterns I mentioned. You want to try that three-legged OAuth in a runtime, we have a sample for that. You want to authenticate with an IDP, we have an example for that. So please check out the GitHub samples. It's a great place to get started, not just for AgentCore as a whole, but for Identity specifically. We also have types of guides that you can get started in about 10 minutes.
So with that, thank you all so much. I know it's been a long, long week for you. Appreciate you coming out during lunch.
- This article is automatically generated using Amazon Bedrock, maintaining the information from the original video as much as possible.
Discussion