🦄 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 - From Code to Policies: Accelerate Development w/ IAM Policy Autopilot (SEC351)
In this video, AWS Principal Product Manager Kevin Luo and Principal Engineer Luke Kennedy introduce IAM Policy Autopilot, a newly launched open-source CLI tool that uses static code analysis to generate IAM policies deterministically from application code. They demonstrate building a multi-tenant S3 bucket creation microservice, comparing traditional approaches like AdministratorAccess, AWS managed policies, and handcrafted policies with their limitations. The tool analyzes code locally, maps SDK operations to IAM actions using AWS's published service reference data, and generates policies with 97% fewer permissions than typical developer policies. They showcase integration with Claude via MCP server, demonstrating automated policy generation, CloudFormation deployment, and a "fix access denied" workflow that enables coding assistants to self-correct permission errors. Current limitations include identity-only policies and manual resource scoping, with automatic resource identification planned.
; 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: Building a Multi-Tenant Microservice with IAM Challenges
All right, welcome everyone. You made it to the Mandalay Bay. For folks who had trouble finding it, you made it. My name is Kevin Luo. I'm a Principal Product Manager at AWS Identity, and I'm joined by Luke Kennedy. I'm a Principal Engineer on the AWS IAM team. Excellent.
Now, before we get started, even though this is a 300 level session, I want to get a sense of who's in the room. By show of hands, who's new to AWS? You're a new builder, like in the last year or so. All right. Then, are you an experienced builder? So you kind of know your way around, you can write IAM policies. Show of hands. Great. And then how many of you can write IAM policies with your eyes closed? You just know them. We got one hand there, two hands. Luke didn't raise his hand and he helped build IAM, right?
I've been building on AWS for 10 years now, and even I get hung up on it. Today we're going to talk to you about IAM Policy Autopilot. It's a new tool we just launched that can help accelerate your workflows so that you can get started faster with IAM when you just want to build. So this is a cool talk. We're going to jump into the scenario here.
Today we're going to build a microservice that creates and encrypts S3 buckets for a multi-tenant service. This is really important because when I have a multi-tenant service and I onboard customers, I want to make sure that there's data isolation between them. I want to create a bucket just for that customer, and then I want to make sure I have a KMS key just for that customer's data. What we're going to do is when a new customer signs up, we'll create a dedicated KMS key for this customer, we're going to create a bucket, and we're going to configure the bucket to use their KMS key.
From an architecture perspective, it's going to be really simple. We'll have a Lambda function. It's going to accept a customer ID and name as a parameter. The first thing we're going to do is call KMS and create a key there. Then we'll create a bucket, and then we're going to call the encrypt bucket function. So with that, let's jump into the code.
Walking Through the Lambda Function Code and Initial Permission Failures
All right, so I have my IDE open here, and I'll walk you folks really quickly through the code so you know what's going on. Here we have a Python-based Lambda function. At the top, I'm importing some of the clients that I'm going to need. I'm using the boto3 SDK. Here you can see that we're accepting a customer ID and customer name as a parameter for the event. The first thing we're going to do is we're going to check if the bucket exists because I don't want to create multiple buckets for that same customer.
We're going to keep the code simple. There's a lot of things we could do to make this super robust, but we're going to keep the code simple here. I'm calling HeadBucket, and if it exists, then we'll just return early. Otherwise, we're going to go ahead and create a key, a KMS key, and we're doing a few different things here. We're also adding some tags so it's easy for me to look it up later.
I'm passing in a key policy to determine who can manage the key. I'm going to call CreateAlias just to make it easier to reference. And then now I'm going to go ahead and call CreateBucket. The very last thing we need to do is call PutBucketEncryption to make sure that we're using the key we just created to encrypt all objects in that bucket. So fairly simple.
If I'm getting started, let's just say I'm going to go create a Lambda function. I'll go to the Lambda console here, and we're going to create a function. We'll call this Sec351-Demo. It's a Python function. We're going to go create. Then while that's creating, we're just starting with the default execution role here. We'll cover that in just a little second.
All right, so I'm going to paste my code in. I'm going to deploy, and then what I'm going to do is create a test event so that we could see if it works. As we mentioned, it's going to accept a customer ID and the customer name. Let's do, I don't know, ACME123.
Let's name it and save it so it's easier for us to reference, and then we're going to test it. Of course, it fails, right? Because this Lambda function needs permissions. Here it's saying there was access denied when calling the CreateKey operation because there's no KMS TagResource permissions.
So what does this mean? If I go here and look at the execution role, we could do a quick primer on what this means. For those who are newer to AWS, IAM stands for Identity and Access Management and controls who has access to what across everything. In this case, we have a Lambda function which needs an execution role, which is really just an IAM role. Then we're going to define IAM policies and attach them to that role to determine what this Lambda function has access to. In our case, we need this Lambda function to have explicit permissions to check if the bucket exists, create the KMS key, create a bucket, and then configure bucket encryption.
The Pitfalls of AdministratorAccess and AWS Managed Policies
If we go back here, then we can go and modify this execution role. This comes with some basic stuff, right? This Lambda function has permissions to go to CloudWatch Logs and create those logs so we could debug. Now we're here at the screen. How many of us kind of just use AdministratorAccess here? I'll just expand this. Show of hands, it's okay, be honest. You're just getting started. Nobody uses AdministratorAccess? Not for what? Not for a Lambda, right? Because it's really broad.
Well, when I got started for the first time, I'm like, hey, I want to just get this thing to work, and so I used to do this. Yeah, it's super broad, right? It allows star star. But there's some benefits. If you're just prototyping something, you're testing something, it has permissions to everything. So when I make an update, maybe I want to use a different service or I want to add DynamoDB to this, I don't want to constantly update my permissions. This is nice in the sense that it reduces some work, but we have to always scope down earlier, and we all remember to do that, okay.
So then what's the other option? The other option is you can use some of the other AWS managed policies that are scoped down some more. We use S3, and so I could look for S3 here. How many folks use AWS managed policies as a starting point for these policies? Okay, I see about a third of the room. AWS managed policies are a much better starting point. Here, if I'm looking at S3, well, I know I need to create buckets, right? If I look at my options here, I have read-only access or full access. These other ones are related to different parts of S3. If I look at read-only access, well, I can't create a bucket. So then my only other option here is I could start with read-only and then add the specific permissions I need, right? But now I'm jumping in between things.
Or maybe I start here. Okay, it's a better starting point. It's not the whole world, but it's still pretty broad, and we have to scope it down. Let's just say for argument's sake, we use AWS managed policies. I just want to get started, so we'll do S3 full access. Then we use KMS. I'm going to add the KMS managed policy that I have available here. Now the function should work, right? So let's go to the test tab. And it worked. Uh oh.
Let's see what we have here. We have an error message, and it says it's a malformed policy document exception when calling the CreateKey operation. The new key policy will not allow you to update the key policy in the future. Who knows what happened here? Does anyone know the root cause? Right, okay, so then we got to kind of search around. Oh, you raised your hand. I need to have a resource-based policy on a key? Not quite right. We have to kind of search around and figure this out. I'll save you some time. It's because we're missing an IAM permission.
If we go back to the code, when we call CreateKey, we're passing in a policy. This is saying, hey, when I create this key, I want it to have this policy by default. But to do that, you need a KMS PutKeyPolicy permission.
And so what this error message is saying is it's warning you about a lockout. You're saying, hey, because I couldn't put this key policy, you're going to run into a situation where you're going to be locked out and you can't manage this key anymore. And so that's what this error message is saying. But if you're just getting started and you're not familiar with this, it can take a lot of time to debug.
And so just to show you, I'm going to go ahead and now I'm going to have to create an inline policy because what we're seeing here is that AWS managed policies don't necessarily have all the permissions you need. There's a lot of permissions out there, and so sometimes you have to add the ones you know. And so here I'm going to go to KMS and this is about permissions management. So I'm going to add the PutKeyPolicy, and I'm going to scope it. And we're going to click next.
Alright, so now if I go back, it might need some time to propagate. Let's see what happened here. Let me just change this just in case, but I think it should work. Next, save. That's weird. Well, oh, create alias. OK, so it's because the key already exists. So let me just change the inputs here so we're starting fresh.
The specified bucket is invalid. What is going on? Is it too small? OK, yeah, I can zoom in. Specified bucket is invalid. Do you have a space in your name? I have a space, but I wasn't sure in the code. I'm sorry. No, no, in the inputs, sorry, but it looks like you're right. Yeah, that's weird. Well, for the sake of this, this is how you know it's a real demo, folks. It's not scripted. Yeah, so just trust me, it kind of works there.
Testing Coding Assistants: When LLMs Generate Incorrect IAM Policies
And so, OK, what are the other options? So let's see, it's 2025 and we're all using coding systems. I don't need to handwrite my policies anymore. I have coding systems that do that for me. And so how many of us here use coding systems? It's pretty much everyone, right? I love it. As a product manager, it's really great because it's allowed me to kind of get my ideas and build prototypes and really interact with my engineering teams. And so that's been really great.
And so now, OK, let's try using a coding system. And so I have my code here, and I have Carro. I'm going to say, hey, generate an AWS IAM policy for my code. And so what is Carro going to do here? So it's going to analyze my code and it's going to generate a policy. So it's reading this Python code. This file acts as restricted to a workspace attempted path. Hm, oh, it's great. What is it doing?
OK, I think I figured out a different way to read it. So we have an IAM policy here, and it looks like it's got stuff. So let's take this, and then we're going to go and modify that role. So I'm going to delete the stuff we just added, and then we're going to add an inline policy. And so I'm just going to paste in what I have. And so this should, this is the Carro generated policy. And here we see something interesting.
So when you use the IAM console, it comes with policy validation built in, which is really great. So it tells us, hey, is all this stuff real, right? Or if I'm doing like an anti-pattern. So we look at these error messages, what do we see here? It says the action S3 HeadBucket, I'll zoom in a little bit more, the action S3 HeadBucket does not exist. And indeed it does not exist. When you call HeadBucket, it's actually a ListBucket for the permission. This other one is interesting. PutBucketEncryption, that seems like it should work.
But actually, the IAM action is PutEncryptionConfiguration. And so if we think about why this is, why do coding systems and LLM elements tend to struggle with AWS IAM? They're trained on public information like documentation, code examples, and so on. And based on that, they learn patterns. And this is actually what humans do too. We learn patterns. Oh, I see the CreateKey method call. So therefore, the IAM action is probably KMS CreateKey. And that's a reasonable assumption to make most of the time. But then they don't understand things like hidden dependencies. So we talked a little bit earlier about CreateKey, and I put a policy as a parameter. Oh, it also needs the PutKeyPolicy action. Or there are these naming inconsistencies like PutBucketEncryption, that's the method call. But the action is PutEncryptionConfiguration. And then it's not always the case that one method call requires only one IAM action. Sometimes it requires more than one. For example, S3 CopyObject, you need, initially, you might write, oh, the permission is S3 CopyObject, but it's actually two. You need GetObject and PutObject, which makes a lot of sense.
So if we recap our options here, we have option one, which was administrator access. And for those who are really just kind of, hey, I'm just trying to blaze through, I'm in a sandbox environment, great. It's the fastest way to get started. And when I'm changing my code, I'm adding different services, I'm changing my mind, I'm not going to need to touch my permissions again. It just works. But of course, we know this is super broad, has powerful administrative permissions. And the security team wouldn't like that, right? But it's okay. I'm going to scope this down later. And we all remember to do that.
Okay, so then option two, we talked about AWS managed policies. And this is also fast, if you know what you're looking for, you know what services you're using, you know if you're using read or write permissions, or you're using permissions that require permission updates. And this is definitely a better starting point than star star. Now it comes with some trade-offs, right? When you're making code updates, you're adding new services, or you're changing, like, maybe I want to read from the S3 bucket now. Well, now you might need to change which AWS managed policies you use. And they also, we also learned they don't necessarily cover all the possible permissions like KMS PutKeyPolicy here. And so these are great. It's a good starting point, but it's still broad. And we definitely all remember to scope this out. How many people actually go and scope down these policies if they write for those who raised their hand on managed policies? Do we go and scope that down later? I see a lot fewer hands. Don't worry, I won't tell the security teams.
Okay, and so then we have option three, artisanal, handcrafted policies. And this is great. You know, it's closest to least privilege. Luke can write them with his eyes closed. But it's time consuming, if you're not like Luke and you didn't help build IAM, it's time consuming to research the exact permissions that you need. And again, we went through that kind of debugging flow there. And then also, every single time because it's least privilege, every single time you do something that requires additional permissions, you have to go back and modify these permissions. And so, sometimes this can slow things down, and you just want to build. Of course, LLMs solve that, right? It's fast. And a lot of times it does work until it doesn't. And then that continues to add to that debug cycle. Additionally, they're not always deterministic. They don't always generate the same policies. And that, you know, when it comes to access management, you really want some determinism there.
Introducing IAM Policy Autopilot: Deterministic Policy Generation Through Static Analysis
And so I want to introduce you to something we just launched on Sunday, and we made open source. It's called IAM Policy Autopilot. It's a command line tool that can statically analyze your code and generate policies based on what your code is doing. We've also exposed it as an MCP server so that your coding systems have access to the same deterministic policy generation capabilities. So let me talk a little bit about how it works.
So step one, we use static code analysis to parse your code. And we do this all locally on your machine. And so here we have the Lambda function on the left, and we pick out all the SDK operations, HeadBucket, CreateKey, CreateAlias, and so on. Then the next step is we map these operations to IAM actions. So, one thing we do is we've actually published our IAM service reference available.
Our IAM service reference is available, so I have a URL here. If you type that in, you'll get a big JSON blob of all the IAM actions and conditions for all the different services. This is great, super helpful reference data. Recently, over the last month, we just launched an enhancement to this and added operations to actions mappings.
Here's just a JSON snippet. What this does is it says, hey, we have this boto3 create key operation, and it tells you what are all the actions that are associated with that. Here it's saying, okay, when I call create key from boto3, I need the KMS create key action, the KMS put key policy action, and the tag resource action. Now, I don't always need them, but this is kind of like the outer boundary of what you might need when you typically call that, and this is based on actual service data that we have.
Now, the last step is we combine that. We got the method calls, we have our lookup, so now we can map out all the actions we need, and then we can generate a policy deterministically based on that. Now, I will say this policy is not a real one. I needed it to fit on one screen, but I'm trying to illustrate that based on this, we can now generate a policy.
There are three key benefits with this approach. The first is it's really deterministic. You give it the same code, and it generates the same actions and policies every single time, and that's really valuable when we want to think about access management. It's also up to date. It uses the live service reference data we publish. If we think about coding systems, their training data was like last Thanksgiving, something like that. There are tools and stuff that can help keep it up to date, but here, we just launched a whole bunch of services and all those actions are now available in the service reference data, so it has live up to date information.
It's reliable because we're using this service reference data. You're not going to see S3 head bucket as an action that shows up here. It's all based on real stuff. Now, we're just getting started here, and I do want to call out some limitations that you should be aware of.
Today, we just generate identity policies, and so we're not supporting cross account use cases where you might need a resource based policy and an identity policy to grant access to an S3 bucket there. These policies, as I touched on earlier, are not necessarily going to be the most shrink wrapped least privileged ones. We do the action mapping here, and these are typically the actions associated with that method call. Our intention here is to give you a better starting point than some of these other broad options that we have.
When we looked at some internal data, we looked at the developers' actual policies that developers wrote, and we compared them to the number of permissions that IAM Policy Autopilot generated. We found that it generated just 3% of the permissions of what's on live running code today. That's meaningful. What's out there is 97% overprivileged, even though we all have good intentions.
The other thing is static analysis today doesn't support automatic identification of resource names. You do want to scope your resources down to the specific ones. I don't want to just be able to read from every single S3 bucket in this account, so you definitely want to scope that down. Depending on your journey and where you are, it could be something you do later, or you want to do right in that moment. This is something that we definitely want to add coming soon.
Then we have that operation action mapping, and it generally catches the vast majority. But sometimes there are edge cases where certain complex cross-service dependencies might be missing there. I'll give you an example. Sometimes when you read from an S3 bucket and it's encrypted, you also need KMS permissions there, so there are some cross service mappings. We're continuously adding to this.
Live Demo: Setting Up IAM Policy Autopilot with Claude and Deploying via CloudFormation
I've done enough talking now. Let's actually see it in action. So I'm going to pass the mic to Luke. I'm going to take over and we'll start by setting up IAM Policy Autopilot. Today we're going to use Claude, and first we're going to get rid of this policy that we know is wrong. We're going to get rid of this session, which gave us the wrong data. But first, we need to set up IAM Policy Autopilot, so we're going to pop over into our terminal.
IAM Policy Autopilot has a variety of ways that we distribute it, but the easiest one to get started with is just doing pip install. So we'll just do a pip install of IAM Policy Autopilot, and it's that easy. So now I can just run IAM Policy Autopilot, and there it is. So as you can see, it does have functionality exposed here, but today we're going to focus mostly on the use case where you're using it with a coding assistant in your IDE.
So the first step of that is setting it up as an MCP server, and every coding assistant you use is going to have a different method of configuring an MCP server. For Kiro, you click on the little ghostty icon, you come down to modify your MCP servers, and you get this nice little configuration. We're just going to paste in IAM Policy Autopilot. Now, for those familiar with pip, you may be familiar with the uvx tool which allows you to run pip applications. I'm using uvx in this case so I can get the nice update functionality that comes with it, so it will always update the pip installation every time I run the server. So I'm going to save this, and you can see over on the left that it connected and it found all of my tools. So now IAM Policy Autopilot is available to Kiro as an agent it can use.
So let's go back to our code, and nothing has changed here, but we're going to try to generate a new policy now. Get rid of that session and start over. So I'm going to ask you once again to please create an IAM policy for this script. Now, this is the fun part of the demo because this is the non-determinism that you get with any model-based thing, so we're going to hope that Kiro behaves today and plays to our script. So it starts, reads our file and says, hey, I want to scope this appropriately, so tell me what region and what account ID you want to access. So we're going to use US West 2, and my account ID is also saved right here.
And so it's chosen to call IAM Policy Autopilot. It's going to pass these parameters. You know, we're just going to vibe today and not really read those and just say run. All right, and it spits out this policy. And here's a short description. Would you like me to save this file? Yeah, sure, please. And let's look at these permissions. So we'll start, we got these S3 permissions at the top. And most importantly, I don't see HeadBucket. I don't see any permissions that don't exist. It did give me the full closure permissions I may need for S3 based on the script, but I know they're all going to be correct and they're going to work. Here's my KMS permissions. You can see that the region is filled in, the account ID is filled in.
The resources are wildcards because these are all create operations and so we can't scope them to a specific thing. But now we have our policy. And so if we want to test out that policy, instead of going the long way, I'm going to use CloudFormation to do this. I encourage everyone to use some type of infrastructure as code setup to manage their entities across their account, and today I'm going to use CloudFormation, and Kiro's going to write it for me. Oh, I should, sorry, I need to accept those changes. Okay, so now Kiro has everything it needs. It has the code. It knows that if it's going to make a Lambda, it needs to run that using an IAM role, so it's probably going to create that role too.
Let's see what it spits out. All right, so here's my code, that's great. And here is my policy, and as we can see, it is exactly the same policy that we generated. It just took that in from the file and put it into here. Using CloudFormation, you can fill in variables and do substitutions for created resources. Our particular policy didn't have that because we're doing creates, but this is one of those cases where using something like infrastructure as code with IAM Policy Autopilot gives you a nice better together setup where it starts to least privilege down to the resources you need because it knows to fill in the variables at runtime and at creation time. So we have this now. We're going to ask it to deploy our template.
Alright, let's go. Okay, so while that's running, we can talk a little bit about the CLI. As Kevin mentioned, IAM Policy Autopilot does work as a CLI that also happens to have an MCP server endpoint exposed to it. When you use it as a CLI, it works just the same. So I can say iam-policy-autopilot, and then let's do generate-policies. I'm in the same directory, so we'll just say my customer onboarding. And I run that, and it immediately spits out that same policy.
Let's make it a little easier to read for everyone so we can see it is, in fact, the same. And that's the determinism that you get from this tool that it's always going to give you the same policy for your code. The CLI allows you to easily integrate this into other CI flows that you may have. So if you have an existing flow that takes your code and does some builds on it, we can now have that integrate with this and spit out your policies as you go.
Alright, let's go back to CloudFormation here. It says it's still running, but we can oh, it says it just finished, but let's check on it just to be sure. Hey, it's good, perfect. Okay, so now we need to test that Lambda function to make sure it works, because I've made these claims that we have the right permission. Let's enforce that, then back it up by saying let's invoke this function. Okay, it's going to ask to run the Lambda. We're going to say run. You can see here in the terminal, it ran the CLI command, and status 200. And Kira wants to run it again for some reason. We don't know why, but we'll just tell it to stop.
Iterating with SQS Integration: Agentic Workflows for Fixing Access Denied Errors
Okay, so that's great. I had some code, I ran it, it worked, and made a function that was good. But now let's say I want to iterate on this code, and I want to, instead of just creating the key, creating the bucket, I also want to get a notification that this is done because I want to do some further events on that. So let's add SQS as a notification queue. So I've got another script here I'm going to pull over because I don't have time to type this. But here's the same script. I've added an SQS client, I've given it a queue URL, and down at the very end, after we create the bucket and put the KMS configuration on it, we now send a message to SQS to let us know that we just created all the infrastructure we needed for this new customer, and here's the basic identifiers we need for it.
So from here, if we go back to our chat and say, please generate a CloudFormation template for, if I can spell, and apologies, for the current file, it's going to go through the same process again. It's going to create my template. Now, I didn't explicitly ask it to update the permissions on it, and so it's probably going to just pick up the IAM policy JSON it used here. I'll wait for the agent to do its thing. Still going. Okay, unfortunately, Kira was very helpful and decided to add this permission. Let's unfix that. So we're going to come down here, we're going to just remove this. We all know that it's needed, but, you know, for the sake of the argument, let's say that Kira decided not to mess with our policy. Okay, and now please deploy.
It'll go through again with the new change set. While it's running here, so in this case Kira did add the right permissions and we did probably this dry run, I don't know, ten times, Luke, and at least two dozen times, and, you know, going back to that nondeterminism, it did it some of the time, but a lot of times it didn't, so you're kind of coming down to chance on this.
So here we're going to simulate an example of what happens if it didn't add that permission, or sometimes ourselves, we're all humans too, right? And sometimes we deploy something and we're like, oh, I forgot to update the execution role. So now we can see IAM Policy Autopilot includes additional functionality to help you with this as well.
So we see a case where CloudFormation is just taking its time, taking its time, it's kind of stuck. We're going to, I have a feeling that stack will never finish, so we're just going to try from a different template. Doing a little bit of a cooking show, ever anyone watched that, you pulled it from the oven. All right, okay, so here we go.
It's deploying and we know this is going to break. So we know that it's going to create the template, it's going to create an IAM user, and it's going to create an IAM role. That role is not going to have the required SQS permissions. That's intended. So we're going to execute the Lambda function. Now we already deployed that. Okay, so let's run that function.
Okay, and we can see there is an error here. And that error is the KMS key already exists. Let's try a different input. Okay, so now we're using customer bouncy pancake, and okay, look, we got a message saying, as we expected, we do not have permission to do this thing. So this is where IAM Policy Autopilot has additional functionality that we can look at these messages and say, hey, you don't have permission to do this thing, why don't you fix that for me? And this is how we can do a full agentic flow with this by having the ability to analyze, hey, I got an error, can you go fix it for me?
And it chose instead to modify the template. So let's try this again. Okay, now it realizes, hey, I have a tool to fix these errors, so let's try running that. And this tool allows us to look at an access denied message and say, hey, I know what this resource is, I know what this principal is, I can generate a policy that's going to fix this and put all the necessary permissions in.
This is a simple case because it's just SQS SendMessage, but if it was a more complex case where it had dependent actions, IAM Policy Autopilot would also add those. So now I'm going to tell it to deploy it to my account. It's going to invoke a tool that I apparently just trust it all the way. And so now it is deployed in a policy on my account to give me those additional permissions.
And so it wants to test the function again, we can say run. Let's get to the bottom here, and we can see, oh, now it passed. And there's our valid response coming out of Lambda. And it might be important to talk about why this is really useful. So here we have kind of like a one-off instance, but with these agents, you want them to go run off by themselves. I want to say, hey, go complete this task for me, and I'm going to go walk away, grab a cup of coffee, and then come back.
And so with this, you know, it's easy enough for a human to go, hey, okay, this error message, I need to add this missing thing. But if I'm walking away, I'm not supervising it. I want my coding assistant in Kiro to be able to do that myself. And so now it has the tools to be able to do that. And let's say sometimes you have layered access denied errors, right? You have one that shows up, you fix it, you run it, another one shows up. And so for humans, it's kind of tedious. But now,
by exposing this as a tool, this coding assistant can go and unstuck itself. That's the power and why we expose this capability as one of the tools.
Recap and Call to Action: Open Source Development and Future Improvements
Okay, cool. So I'm going to do a quick recap here. We showed you how to use IAM Policy Autopilot to generate policies from your code. We showed that when you combine it with a coding assistant that finds issues in infrastructure as code, it can do things like variable substitution for scoping down my resources. There's a really great better-together story. We also talked to you a little bit about that fix access denied workflow, right? This empowers your coding system to get itself unstuck. It's the same tools that we ourselves would use if we looked at the access denied error.
We did this all without broad permissions like administrator access or AWS managed policies or just star even. It was deterministic. It only used real IAM actions and services, and it's up to date. Now, we're just getting started. We're only supporting identity policies today, and it's not guaranteed to be the least privilege, right? There's still some scoping down, but now you have a much better starting point.
We talked a little bit about how Policy Autopilot generates 3% of the permissions that developer policies are today. We're working on adding in the static analysis support to automatically identify your resources, so it will only get better over time. I have a call to action here. We've open sourced this for a reason. We want to collect your feedback. We want to do the development in the open.
Please go visit the GitHub repository and clone it. We built it in Rust, which we love very much. If you have feedback or you have questions, feel free to engage with us there. We're always planning to improve it, so keep on the lookout for that. All right.
So with that, I have my obligatory thank you. Luke and I will hang out here if you have some one-on-one questions, so happy to take them, or we can do a group discussion here up front. Otherwise, this is your reminder to please complete the survey in the mobile app.
; This article is entirely auto-generated using Amazon Bedrock.
Top comments (0)