🦄 Making great presentations more accessible.
This project aims to enhances multilingual accessibility and discoverability while maintaining the integrity of original content. Detailed transcriptions and keyframes preserve the nuances and technical insights that make each session compelling.
Overview
📖 AWS re:Invent 2025 - Implementing security best practices for serverless applications (CNS360)
In this video, AWS Principal Solutions Architects Heeki Park and Chris McPeek present security best practices for serverless applications using a fitness tracker architecture as an example. They cover foundational topics including account boundaries, encryption at rest and in transit, IAM policies (resource-based policies vs execution roles), least privilege principles, permission boundaries, SCPs, and API Gateway protection with AWS WAF. The session then deep-dives into OAuth 2.0 flows (authorization code and client credentials), explaining authentication mechanisms with Amazon Cognito, token management (ID, access, and refresh tokens), and identity-aware applications. They demonstrate how Amazon Verified Permissions with Cedar policy language enables fine-grained access control, and explore security considerations for agentic applications using Model Context Protocol (MCP) and the newly announced Agent Core services including Agent Core Runtime, Gateway, and Identity for simplified OAuth implementation in AI agents.
; 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: Security Best Practices for Serverless Applications with a Fitness Tracker Example
Welcome to this session. We're going to be talking today about security best practices for serverless applications. Just as a quick introduction, my name is Heeki Park. I'm a Principal Solutions Architect here at AWS. I've been here about 9+ years. I spent a lot of my time here at AWS focusing on serverless and more lately spending a lot of time with agentic applications. My name is Chris McPeek. I'm also a Principal Solutions Architect here at AWS. I've been here about 7.5 years, really focused on serverless application development and working a lot with our serverless teams.
We're going to be diving into this topic today around security best practices for serverless apps. Now, if you've never been in a silent session before, these can get a little bit weird. It's hard for you to hear me through headphones versus over a speaker. We like to get feedback, so head nods and thumbs up if something's resonating. We definitely appreciate that, but I want to do something a little bit different this morning. On the count of 3, I would love everybody just to cheer. That helps me and also tells everybody else you all chose the right session. Ready? One, two, three. Thank you.
As we dive into this, I'm going to start off with a survey of some different security practices for serverless applications, some foundation items that we need to really talk through to get started. Then I'm going to have Heeki come back up and he's going to dive deeper into some specific use cases, especially around some of the more modern application development that we've been working on, especially with agentic AI and some of the identity awareness that we need to think about with serverless security.
To help us out, we're going to frame this in the idea of a fitness tracker because I think sometimes it's a little bit hard to get our head around security without having an actual application to talk through or an architecture to talk through. So we're going to use this idea of having a fitness tracker and the basic architecture that we're going to work with is we're going to have our athlete. I love cycling. I've done a lot of cycling in the past, as you can tell though, I haven't been cycling a lot recently, so instead we're going to use Heeki. Heeki is training for a marathon right now. He actually ran a marathon last week and loves using fitness trackers, collecting all of his data and figuring out how he's doing with running.
So we're going to have this basic architecture: an API that's going to collect that data from our tracker, that's going to feed into an API Gateway. From that API Gateway will trigger a Lambda function that's just going to take that data and write it to a DynamoDB table. As we go through and talk about security, we'll be talking about some of the security that you need to consider on each of the different layers of this application.
Foundational Security Concepts: Account Boundaries, Encryption, and IAM Policies
The first thing that we need to talk about is account boundaries. Now I realize this isn't necessarily a serverless concept, but it is something important to consider as we're developing applications. How many of you in the audience are developers? How many are security engineers or focused on compliance? So as developers we love to move fast. We love to build very quickly. Often we'll have access to a sandbox environment where we can develop quickly, run our tests, and move fast. But this can pose some risks to a production environment when we're deploying directly into that account.
By creating these account boundaries, that actually allows us to separate those areas of control so that you as a developer can move fast and test and develop. Then as you're deploying out to production, you can have a structured deployment pipeline where as a developer you can commit your code and it will run those automated tests and deploy that out to production for you. That's a really important distinction between accounts that just helps provide a good separation of concerns.
Encryption is something we all love to talk about, and it's very important for us to consider with AWS serverless services. A lot of security is already built in for you, but there are some things to consider as you're using some of the different services. For example, with Lambda functions, one thing that you want to think about is your environment variables and whether or not you're storing data in environment variables that needs to be encrypted. You can use a KMS key to actually encrypt those environment variables and keep them safe. If you're using API Gateway and using a caching feature with API Gateway, you want to make sure that the cache is actually encrypted, and API Gateway gives you the ability to turn that on.
For each of the different services, those are available. Some have the option to use just an AWS KMS key, and in some cases you can also use a customer managed key to encrypt that as well.
Now all of the services do have encryption in transit by default, so we manage that for you. API Gateway only accepts HTTPS requests, so you can't even accidentally create an HTTP endpoint that doesn't run encryption on API Gateway. The next area that we need to think through is IAM, identity and access management. This is very important as you're building serverless applications. The control plane, where you're making API calls to AWS to make changes to Lambda functions or access different services, is one plane to think about and make sure is secure. The other is the data plane, where your application is calling different services and your application is running. There are a couple of different tools in IAM that we'll go through to consider as you're building out your applications.
The first is at an organization level. AWS Organizations policies, or SCPs, are going to be scoped at an organization level and can be applied across multiple accounts, versus resource policies, which are policies that you're going to apply to a specific service, and that will control access to that specific service. As you start digging into IAM policies at different layers, there are different areas that you can protect. When we think about our architecture for our Activities API, controlling what APIs are being called and how API Gateway is invoking our Lambda function, we'll want to make sure that we bound those permissions very closely.
With Lambda functions, specifically I want to talk a little bit about resource-based policies versus the execution role of that service. This is a little bit different than how you might consider security for an application running on an EC2 instance. With Lambda functions, you have two different policies that you're going to work with. The resource-based policy is what gets applied for any service that's triggering or invoking your Lambda function. There are a couple of other services that also follow this pattern, such as EventBridge, and so you want to make sure that you think through that resource-based policy for what services can invoke that Lambda function.
Now the execution role is on the other side of the Lambda function. That's the policy that's controlling what that Lambda function has access to as it's executing. So maybe it's a DynamoDB table, as we mentioned before in our architecture. That gives you a different policy to control what that Lambda function is accessing. For example, based on our application that we're working with, maybe that API Gateway we want to give it access to invoke our Lambda function as those activities are coming in and need to be processed. So we'll create a resource-based policy to do that, but we'll also give it that execution role so the Lambda function can write those activities out to DynamoDB.
Implementing Least Privilege Through Permission Boundaries and SCPs
Another concept that's really important, and maybe as developers we don't always think about, but is a really foundational idea, is around least privilege. Now I don't know about you all, but this was a little bit hard for me to get my head around as a developer because I like to move fast. I like to try things, and sometimes it's just easy to scope something very wide open. But for those that are security folks in the room, I can already see the cringing with having wide open policies. Least privilege is very important as you're developing in the cloud. You want to make sure that you're scoping those policies down to only the actions that service is allowed to take.
So if you think about your resource policies or your execution policies, you want to not give it a wildcard star. Instead, give it only the API actions that it's allowed to take.
We can think about this in an iterative way as we're developing, where we're setting permissions, running tests, and verifying actions. We can do all of this in our pipelines as well to verify that we have permissions set properly to meet the compliance requirements for our organization.
Now, the other side of that is as a developer, I might want to set the policies for my services wide open. We already talked about least privilege, and least privilege also matters for me as a developer. I need to make sure that I don't have access to things I shouldn't or that I can't take actions that might cause problems down the road or open up issues. One way to handle this is by empowering your developers to create the policies they need while also using permission boundaries applied to that developer that actually limits the scope of what they can open up.
You can set specific actions to deny on those permission boundaries so that you're limiting what a developer can actually do in their account. This is going to be a little bit different than the SCP roles and SCP policies that I mentioned before. SCPs are organization-wide, whereas a permission boundary is scoped just for that role specifically.
Let's take an example here. For our Activities API that I talked about before, maybe I want full access to all the Lambda APIs, full access to DynamoDB, and API Gateway. I set a policy for any Get actions so I can see what my API Gateway can do. But my security team really doesn't like that. They want me to scope that down further. They can actually put a permission boundary in place that only gives me access to Lambda InvokeFunction, DynamoDB UpdateItem, and API Gateway PutMethod.
You can see that when I bring these two permission boundaries and the policy that I put in place together, the actual effective permissions are just Lambda InvokeFunction, DynamoDB UpdateItem, and API Gateway PutMethod. Even though I've given myself some wildcard policies and permissions to move fast, using that permission boundary actually scopes what I have access to down very tightly.
Let's go back to SCPs and talk about this a little bit more. Usually when you get to an enterprise-level organization that's doing a lot of serverless application development, we don't want to have to apply specific controls at every single role. Maybe there are some policies for compliance that we want to apply across our organization and across all of the accounts that we have. Using SCPs, you can actually apply these policies across the entire organization, which limits the scope that any of those policies might have access to.
Let me talk through an example of something that could be helpful. In our case, we have that API Gateway sitting out front, and maybe what we want to do is limit access to that API Gateway from the public side. We don't want to create a public API endpoint. So what we can do is actually just allow private endpoints using SCP. As any of our developers create an API Gateway, they can only create it as a private endpoint, not a public endpoint.
Now we need to make this a little bit more real. Let's talk about a different scenario. In this case, we want any of the traffic coming from those clients to actually flow through a different VPC because maybe we want to run some security validation or we want to route traffic a certain direction within our AWS network. What we can do is lock down that public API access so that we can then just create a private API endpoint and stick it in its own VPC. As traffic is coming in, it's going to flow through that broader VPC. Maybe we do some security analysis on that traffic. We'll create ENIs in that account in that VPC that then allow traffic to flow into our API Gateway VPC on the backend, which just provides a little bit more security.
Securing the Development Lifecycle: API Integrations, Event Validation, and Endpoint Protection
Let me move on to the last foundational area to think about. API integrations. I won't talk too much about API integrations because Higgy will cover some of that in a few minutes. However, databases are also an important area. In our case, we use a DynamoDB table, and DynamoDB supports IAM, so I can give access to that Lambda function using an IAM policy to access the DynamoDB table.
But what if your database doesn't necessarily support IAM? Maybe it's a database running on an EC2 instance. In that case, you might consider using something like managed secrets. However, the last thing you want to do is hardcode those secrets in your code. That's where Secrets Manager is a good place to store those credentials and have your Lambda function access Secrets Manager to connect to your database. Let me cover a couple of other areas to think about as an organization. When we think about the development lifecycle and all the different stages within it, there are several security considerations to keep in mind. This includes how you're authoring your applications and where you're storing that code, making sure you have least privileged permissions. It also involves pushing code into repositories to trigger your pipelines, ensuring that IAM is scoped down so your pipelines are only deploying code from the right people.
Another really important area to think about is analyzing your source code and looking for dependencies that may have issues. Amazon Inspector is a good way to do that, analyzing your code and providing information about any dependency issues that may have crept in. Matt Garman's keynote this morning talked about a security agent that we recently released, which is also a really good tool to use for analyzing your source code. Another possible scenario is if you weren't inspecting your code and you allowed a dependency to be applied in your application that got through some of your testing. In this case, you might want to look for application anomalies to detect that the dependency got through. At runtime, Amazon GuardDuty can look at your VPC flow logs as a way to detect any anomalies that are happening in your application because something was missed earlier on.
Event payloads are another important area to consider as you're thinking about security. With event payloads in Lambda, there's a really good tool called Power tools that makes it easy for you to add things like strict typing to validate that input as it's coming through. You can see here a brief example where we're importing that Power tools dependency, which will help us validate very easily in Lambda. There are some really good Power tools sessions going on this week. There's a team at AWS now that's developing and owning that for us, so I definitely encourage you to take a look at that.
But what if we could also look at those payloads before they come to Lambda and look for maybe differences in schema before a request actually comes in? Within API Gateway, we can validate that input and do input validation to make sure we're getting what we expect from a schema perspective before we pass it on to that Lambda function to actually run.
There are 33 available configurations so you can look at the body, you can look at query string parameters, or make sure they're what you expect, or you can look at all of the above to validate that event that's coming through.
Let's cover a couple of foundational items regarding protecting your API endpoints. We talked a little bit about taking our endpoints and making them private, but another tool that you have access to is AWS WAF. This gives you the ability to protect those endpoints based on IP addresses, based on geographic regions that you might want to limit access to that API Gateway.
AWS WAF also has the ability to take in rule sets from third parties. This is a really helpful way to have a subscription applied that will actually protect those endpoints based on what's being seen out in the wild. If you go on the AWS Marketplace, there are a number of providers that will provide that subscription for you into AWS WAF. Those are some really good ways of protecting your endpoints using an outside tool like WAF.
Identity-Aware Applications: Understanding OAuth 2 Fundamentals and Terminology
Now I'm going to hand it over to Higgy who's going to dive into some identity-aware applications. Can you guys hear me? Alright, so Chris gave us a really good broad spectrum of a lot of different things that we need to be thinking about as we're building our serverless applications. Over the next 15 to 20 minutes, we're going to actually dive really deep on one particular kind of application stack security consideration which I'm seeing as a very common use case, especially as we start to think about both serverless applications but also agentic applications, which is a common thing that I see a lot of my customers starting to think about.
We're going to go back to that application that Chris presented before. Again, we have our fitness web application, which is the first component that the user is going to be interacting with. Of course, that web application is going to then interact with our serverless API Gateway. This is going to be the activities routes and other APIs, and then of course the business logic will reside within our Lambda functions.
A bunch of what Chris talked about already is going to be these resource policies, execution roles, and perhaps even those SEPs for doing deployments. The part that I'm going to spend a bunch of my time on is going to actually be here on the left side thinking about user authentication and authorization. How do we make sure that the user, so let's say Higgy is interacting with this fitness application, is doing things that he is allowed to do and is accessing resources that he is allowed to access?
Before we get into that, let's take a quick look at our serverless application. This is the one that Chris had introduced before, and again we have these different API endpoints that he had introduced before. The thing to notice that Chris had talked about was we have a number of different APIs that you can think about as the architects in the room. We're using domain driven design and these are some bounded contexts. These are the domains of logic so you can imagine different teams are provisioning these different APIs and maybe they have different auth schemes and we're going to get into that momentarily.
The key thing that a lot of organizations will do when they're protecting these type of API endpoints is going to be using a standard called OAuth 2. We're going to dive pretty deep into OAuth 2, but before we do, let's go over a couple of the terminology that we're going to be using throughout the rest of this talk.
When we think about OAuth 2, there are a number of different entities that we want to be aware of. The first is the owner of that resource. So you can imagine maybe there's some amount of data we are trying to protect, and let's say Higgy, maybe I'm a Strava user and I really like to run. So I have some of my data in this service, and I own, or in theory I own the data or I should be the one that grants access to that data.
I then use maybe a web browser, maybe a mobile client. In this example we'll just use a web browser that is going to be the user agent, so that is the mechanism by which I'm going to be interacting with these protected resources. Then you have the web application. My web browser of course connects to a particular web application. Maybe I have it deployed in Fargate. That web application or client then interacts with the API that we are trying to protect. So this is that serverless API that Chris was talking about before.
And last but not least, of course there is the authorization server. We need some entity, some identity provider to be able to determine who is allowed to access these resources and what resources are they allowed to access. These are the five key entities that we're going to be thinking about.
Another thing that we want to think through is how we actually get access to the resources. There's some process by which this access is going to be granted. There are actually a number of different processes, but in this talk we're going to focus on two. We're going to talk about one, and then you'll see how once you learn about one, you've already learned about the second one.
The first one is the authorization code flow, also called code authorization flow. This is the most common one that you're probably familiar with. You may have experienced this when you click on a web page and it says "Do you want to allow access to this particular application for these resources?" That is an example of code authorization flow. The second one is the client credentials flow. Where the first one is end-user facing—you're logging into a web page and then allowing access—client credentials is typically used in machine-to-machine communication. In the former, you have a user interactive experience where someone is clicking to essentially allow access. In a client credentials scenario, you want a machine to be able to do that, so there is no user clicking that approve or allow button.
These are the two flows we're going to talk about. We're going to dive really deep into code authorization, and then you'll see how you've already learned about client credentials. Some other things that we want to think about are the relevant credentials that you want to be aware of. When you are creating an application or when you as a developer are building an application, you actually need to register that application with your identity provider. The first thing that you end up creating is what we call the client ID. The simplest way to think about it is that it's somewhat like a username. Just as you as an entity interacting within the system might have a username associated with you, for an application, you would have a client ID associated with that application. When you register with the identity provider, it will provide you with a client ID.
Next is the client secret. As you can imagine, this is somewhat similar to having a password. So just as you have a username and password, you would have a client ID and client secret for the particular application. These two together are used to authenticate that this is the application interacting with the identity provider. All right, one more set of tokens, and then we're going to dive pretty deep into it and apply this to our serverless application. These are a number of different tokens that you get when you exchange your client ID and client secret and your user identity. The first is an ID token. This is a short-lived token. The simple way to think about this is that the ID token identifies who is interacting with this service. It might have information like your username or your email, though this is all dependent on what you want to include in your application.
The next is the access token, and this is perhaps the most important one. This is the token that defines what actions you are allowed to take now that you've authenticated. We call these scopes. This will say you're allowed to have read access to this particular endpoint or maybe you have write access to this particular endpoint. And then last but not least is what we call the refresh token. You can imagine in the code authorization flow as a user interacting with it, it might be painful to ask that user to reapprove the request every 15 minutes or every 60 minutes. The refresh token is then used to do that automatically. This may be a longer-lived credential. Maybe we're going to allow this credential to live for 24 hours, and we'll refresh the user's tokens by using this refresh token.
OAuth 2 in Practice: Authorization Code Flow and Client Credentials Flow
These are the credentials, tokens, and some of the identities within them. These are all the components necessary when you're building serverless applications or, as we'll show in a bit, how this is going to be used for your agentic applications as well. All right, so the first phase—I'm going to talk about two phases. For the code authorization flow, there are really two phases. In this first phase, what you want to think about is the user essentially logging in and getting an authorization code. You have this user—let's say Heeki—logging into the web browser. You can imagine getting redirected to a login page. After you log in, then you get that little pop-up that says "Do you want to allow Heeki access to this particular resource?" and it'll have a bunch of checkboxes. You go ahead and hit approve. Once you hit approve, on the back end the identity provider will generate an auth code. This is just basically a long string—a one-time use string. It then sends that back to the front end. The front end application receives this auth code. It already had the client ID and client secret, so this is something that you registered with your identity provider when you created the application.
When you deploy the application, it gets deployed alongside the application. So now the application has the client ID and client secret that it uses to authenticate with the identity provider. It now has the auth code, which is now user-specific, and it uses that to exchange for a set of tokens. This is the first phase, which is user interactive.
Now the second phase is this: we had the front-end application, and it was deployed with that client ID and secret. It just received that auth code from the exchange we just did. It is now going to go to the authorization server. In this case, I'm going to use Amazon Cognito, and it sends the client ID, the client secret, and that auth code. When Cognito validates these strings and credentials, it will then provide back the ID token, access token, and refresh token to the front-end application.
The one thing that I want to stress here is that as you're building your serverless applications, you are not going to expose these ID tokens, access tokens, and refresh tokens to the web browser. You want to make sure these stay within the bounds of the front-end application. These are not things that your end users should actually end up seeing. This is all happening in the back end. So what happens is you'll send, let's say, the ID token with API Gateway, which goes to the authorizer. API Gateway will then take that ID token, go back to the authorization server, and validate whether this is a valid ID token.
So again, it will go in and say, "OK, I see this is an ID token from Heeki. He wants to access the backend API." API Gateway, once it receives that validation and sees this is an allowed request, will then allow it to invoke the Lambda function on the back end. This assumes that you had already configured a resource-based policy with your Lambda function so that API Gateway is allowed to actually invoke it.
So we talked about phase one being the end user interaction. Phase two is on the back end where you have the front-end application doing a bunch of these token exchanges. The reason we break this up is actually a quick refresh of the whole flow. So the user comes in, connects to the front-end application, logs in, gets the auth code, and sends it back to the front-end application. It then validates that and invokes the API. The API Gateway will check with the authorization server, and then here's where we have that Lambda function that gets invoked with that resource server.
What's nice here is that within Lambda, for those of you who have built with Lambda functions, you have two parameters in your handler. One is your event payload and one is your context payload. You can actually see within the context payload a bunch of identity information. This could be something where, as a developer, you know that this was an authorized request, but maybe there are some additional things that you may want to do within your business logic. Maybe you have a grouping of users, and based on certain entitlements, you want to allow them to do certain custom actions. This is something you could then custom code into your Lambda functions. This is a lot of additional information you have available to you, even after you've already done the OAuth flow.
So what I was getting at before is that we talked about phase one and phase two. Phase one is the user interaction. Phase two is machine to machine. Well, with client credential flow, you can essentially strip off phase one, that login piece and the exchange for that auth token, and now for client credentials it's just phase two. So you've now basically learned both. Here you see that web application gets deployed with the client ID and client secret. Now it just exchanges the client ID and client secret for that set of tokens: the ID, access, and refresh token.
In this scenario, we no longer need the auth code because this is not interacting with any particular user. So again, we just do that same flow. We send, maybe, that bearer token along to API Gateway. It then goes and validates with your identity provider and then invokes your Lambda function. So you're asking, "OK, that was a lot to try to understand OAuth 2 well." With a lot of both serverless APIs and also with a lot of agentic applications, OAuth 2 is the foundation security mechanism for ensuring that users have access to the appropriate downstream resources.
Fine-Grained Permissions with Amazon Verified Permissions and Security for Agentic Applications
For folks that are building serverless APIs or if you're thinking about even building agentic applications, this is going to be a core flow that you're going to want to understand, and we're going to talk about how we make this a little bit easier for you in the next couple of slides. So we covered OAuth 2, but what about other ways for your serverless APIs to think about doing the same type of mechanisms for fine-grain permissions? Well, there is.
There is another way to handle permissions with Amazon Verified Permissions. The flow is similar: an end user comes in and authenticates with the identity provider. You then try to access your API Gateway endpoints, including that token as a bearer token within the header. With API Gateway, you can now use a Lambda authorizer. You can configure an authorizer to interact with the Verified Permissions service. You can take the header with whatever token it contains and run it against Amazon Verified Permissions. Amazon Verified Permissions will then come back and say allow or deny. Based on that response, you'll then invoke the backend if that was allowed.
You may be asking how we know or actually define who is allowed to do what. That is a great question. With Verified Permissions, it uses a policy language on the backend called Cedar, which is an open source policy language. Here is an example of what that might look like. For the security folks in the audience, you can use code to define the allowed actions for particular resources. Here is an example where we have a particular namespace. At re:Invent, we have a bunch of APIs defined for demos. There is also a group of users, so maybe the audience here in this particular session is included as part of this permission. This is then the Cognito user pool along with the Cognito user group, which defines the principle and the allowed identity. This then is the allowed action. The audience here, if you were to make a request to my particular API that uses this Lambda authorizer, will be allowed to make a GET request to the slash products API endpoint or maybe the slash activities API endpoint. This is an example of a policy you can define using Cedar. You would then configure Verified Permissions to use this policy when API Gateway makes these types of requests.
We have talked about OAuth in depth and using Verified Permissions to identify users coming in and ensure identity-aware interactions with your serverless APIs. Let us try to push the boundaries a little bit and think about whether there is a way we can continue to innovate from a security perspective in where we are seeing a lot of new applications being built. Coming back to our serverless fitness application, we have our traditional application with our different API endpoints. One thing you may want to think about, and you may have heard about this in the keynote this morning, is that Matt Gardman was talking about using and building agents. One way we can think about transitioning our serverless fitness application into an agent application is using something called tool calling. Within our agents, we build this agent using an agentic framework. We have the ability to create and define what we call tools. The simplest way to think about this is that a tool is just another function that we annotate as a tool, and we then call our different serverless APIs. The activities, routes, socials, and support API that we already have for our serverless fitness application, we just wrap it in a function and annotate it as a tool.
The nice thing here is that our agentic application, as it interacts with a model and an LLM, is able to very easily gain access to the data that is accessible from these different APIs. You can imagine maybe as a runner, I just did, let us say for the last thirty days I did ten runs over that period of time, and I actually want to do a little bit of analysis. I want to understand what is my average heart rate over this period of time for a particular weather condition. Am I actually improving in my fitness or am I actually getting worse? Is there something that I need to change? This is certainly something that in a serverless application I can go and build and write imperative code to do, but maybe as a developer, there is a simpler way to do this. Maybe I can actually leverage an agent application to do that on my behalf. This is perhaps where some of the ideation can come and why we may want to actually move in this direction.
Thinking about tool calling, you may be thinking, do I have to wrap a lot of my APIs and do a bunch of work in order to bring this data and this API data into my agent? Well, fortunately Anthropic created an open specification last year that you may have heard of.
How do you integrate all these different tools into your agent? Has anyone heard of the acronym MCP? A number of hands went up. MCP stands for Model Context Protocol. It is basically a specification that standardizes the way you do tool calling within an agentic application. As your fitness agent, you can essentially have a singular MCP client, and the different data providers can then provide an MCP server. You can imagine with the activities, routes, socials, and support APIs, those are actually provided by different development teams within your organization. Team A is doing the activities API, Team B is doing the routes API, and so on. Each of those teams, as data providers or API providers, would be responsible for vending an MCP server.
Now you may be asking, what does this all have to do with the security talk that we are really focused on here? Well, in this whole process, there continue to be security considerations. Here is an example where all of that OAuth 2 stuff that we just talked about and learned will be applied to this agentic application. You can imagine an end user interacting with an agent through the code authorization flow. As an end user, maybe I am accessing this through a web browser. I log in and then I click authorize, and now I have access to this fitness agent. I ask the question I asked before: help me understand the last 30 days of running. Can you do an analysis on my data? Am I improving? Do I need to change something in the way that I am training?
The fitness agent will then make a determination and call our activities tool, which will use the MCP client to talk to the MCP server. Because this is machine-to-machine communication, maybe we have configured client credentials to allow my agent to talk to this MCP server. But that is actually not the last step. The MCP server itself will then talk to my serverless API. Maybe we have a setup here where we will also use client credentials because this is also machine-to-machine communication. You may also want to think about making sure you are propagating identity information from me, as the end user accessing the agent, all the way down to the activities API. So maybe instead of client credentials, maybe we actually want to use the code authorization flow. For the astute in the audience, you are probably thinking how do you do that when my MCP server and activities API are way far in the backend? How do I actually propagate that end user request?
Simplifying Agent Security with Agent Core and Key Takeaways
Well, there is a way. You can actually stream that request back all the way to the front end so that I as a user can actually hit the accept button. We have talked about our serverless fitness application and thought maybe this is an opportunity to build an agentic application. We spent a bunch of time on the OAuth 2 flow and talked about Amazon Verified Permissions. This is a lot of security stuff that we want to think through. Is there perhaps a simpler way that we can do this? There is a simpler way, or perhaps an alternate way to do this. In our session in the keynote earlier today, there were a bunch of announcements around Agent Core. There are a couple of services that actually make this simpler. Agent Core Runtime is a serverless runtime similar to Lambda, similar to even Fargate. It allows you to run your agent applications. On top of that is something called Agent Core Gateway, similar to API Gateway where API Gateway is the front door for all of your API front ends. We think of Agent Core Gateway as a front end for all of your tools that you are going to expose to your agent applications.
There are a number of managed tools that you have available to you. For example, if you want your agents to be able to go and do research on the internet, maybe you want to hit other websites to glean information about the particular query that the user is asking, you could use Agent Core Browser. Code Interpreter is a situation where maybe your agent is actually going to be generating code on your behalf, and this is untrusted code. You do not want to actually run this within the context of your perhaps your enterprise. You want this code to be isolated, and this is where you might actually use something like Agent Core Code Interpreter. Where we will spend a little bit of time in the next slide is Agent Core Identity. We think about all of these OAuth 2 considerations, all of these security considerations in this OAuth flow, and is there a way that we could actually make it simpler? Agent Core Identity aims to make that process simpler, and we are going to dive into the next slide. There is also Agent Core Memory. In your experiences with different agent applications, one of the key experience benefits that we have seen customers wanting out of these applications is this personalized experience. So this desire to see that it actually remembers previous interactions and create a personalized experience is important.
The system remembers that Higgy is interacting with this fitness application and recalls previous queries about it. Memory enables this functionality. Observability allows you to understand the full flow of actions happening within the application and provides insight into login activities and tool calls being made.
Let's discuss identity and how to apply OAuth flows in agentic applications more simply. Previously, we talked about a user interacting through a web browser who now wants to interact with an agent. On the front end, there's something called inbound authorization OAuth. If an application is running on an EC2 instance or being invoked by a Lambda function, you could use IAM. IAM defines what actions an entity within AWS is allowed to perform. If an app runs in EC2, Fargate, or Lambda, that execution role allows you to invoke the agent.
Alternatively, if the application is external to your organization and not running on AWS but on your own infrastructure without an IAM role, you would use OAuth 2, which we discussed in great depth. Then there's outbound OAuth, which is configured based on the target. If your agent accesses an S3 bucket to extract information from PDF documents, you use an IAM role. Similar to what was mentioned before, depending on what you're accessing—whether an S3 bucket, DynamoDB table, or something else within your AWS account—you use an IAM role for outbound OAuth. For anything else, you use OAuth 2. This is why we spent considerable time on the OAuth flow to help you understand when to use different flows.
If an end user interacts with a protected endpoint, you use the code authorization flow. For machine-to-machine communication, you use something like the client credentials flow. Let me share some key takeaways from this discussion. The first is implementing least privilege policies. When writing a policy in your AWS account, if there's a star in your policy document, you should pause and reconsider. That said, some policies do require a star, and that's acceptable. If you're accessing a particular DynamoDB table or S3 bucket, be explicit about the resource and the specific actions you're allowing in that policy.
Defense in depth is another important principle. Don't apply just one or two security mechanisms; apply as many as possible. Use IAM execution roles, resource-based policies, WAF to protect public endpoints, and SECPs to ensure developers don't deploy resources that violate organizational policies. There are many different mechanisms your organization can apply to ensure secure serverless applications are deployed.
Leverage the deep integrations across AWS. One of the beautiful aspects of building serverless applications, whether synchronous APIs or asynchronous event-driven patterns, is that AWS manages those integrations on your behalf. You configure IAM roles or resource-based policies, create least privileged policies, and let AWS handle many of those integrations. This eases the burden of undifferentiated heavy lifting involved in configuring these integrations.
Finally, automate security protection mechanisms. Configure services like GuardDuty for runtime protection. In your CI/CD pipelines, implement protections whether on the developer machine, when committing code to a repository and triggering CI actions, or when deploying into environments. Ensure all these checks are included as part of the deployment process. We have a number of other sessions we recommend you explore. These are highly relevant as you think about building and securing your applications. There are also additional resources available that we recommend you check out. Thank you for coming.
; This article is entirely auto-generated using Amazon Bedrock.
Top comments (0)