AWS IAM Policy Autopilot: creating IAM policies straight from Kiro
AWS IAM Policy Autopilot: creating IAM policies straight from Kiro
Creating IAM policies by hand is one of those tasks everyone knows needs to be done right, but in practice ends up becoming a copy-paste of "Effect": "Allow", "Action": "*" just to "get it working for now". The problem is that "for now" becomes permanent.
What is IAM Policy Autopilot?
It's a static code analysis tool that reads your source code, identifies which AWS services and actions it uses, and generates a baseline IAM policy with the necessary permissions.
In practice, it does the tedious work for you:
- Scans the code looking for AWS SDK calls
- Identifies which actions (
s3:GetObject,dynamodb:PutItem, etc.) are used - Generates an IAM policy with those permissions as a starting point
- You refine it as the project evolves
The important point here: it generates a baseline policy, not a final policy. The idea is to give you a much better starting point than beginning from scratch or copying a generic policy.
Why does this matter?
The "Allow *" problem
How many times have you seen (or written) something like this?
{
"Effect": "Allow",
"Action": "*",
"Resource": "*"
}
Does it work? It works. Is it secure? Not at all. This type of policy violates the least privilege principle and is one of the most common findings in security audits.
The problem is that creating granular policies takes effort. You need to know exactly which actions your application uses, which resources it accesses, and under which conditions. Autopilot automates the most tedious part of this process.
The cost of misconfigured policies
Overly permissive policies are a gateway to:
- Privilege escalation: an attacker who compromises a role with
*has access to everything - Lateral movement: from a compromised service, the attacker reaches others
- Data exfiltration: unrestricted access to S3, DynamoDB, Secrets Manager
Autopilot doesn't solve all these problems on its own, but it drastically reduces the chance of starting with excessive permissions.
How it works as a Kiro Power
Before Kiro Power, using Autopilot required manually setting up an MCP server, installing dependencies, and integrating with your IDE. Now the process is:
- One-click installation directly from the Kiro IDE or web interface
- No manual MCP configuration
- Integrated into the development workflow, you generate policies without leaving the editor
Usage flow
The workflow looks like this:
- You're writing code that uses AWS services (a Lambda that reads from S3, for example)
- You ask Kiro to generate the IAM policy
- Autopilot analyzes the code and identifies the necessary actions
- It generates the baseline policy
- You review, adjust resources and conditions, and apply
All of this without leaving Kiro, without opening the AWS console, without consulting the IAM actions documentation.
Practical use cases
Rapid prototyping
You're creating a new project and need a role for Lambda. Instead of guessing the permissions, let Autopilot analyze the code and generate the policy. Even if it's a prototype, you start with reasonable permissions.
New AWS projects
When the project is new, you don't have CloudTrail history to use tools like IAM Access Analyzer. Autopilot fills this gap because it works with static analysis — it doesn't need runtime data.
Refactoring existing policies
Have a role with excessive permissions and want to tighten it? Run Autopilot on the code that uses that role and compare the generated policy with the current one. The difference shows what can be removed.
Security code review
During a review, instead of manually checking whether the policy aligns with the code, use Autopilot to generate the expected policy and compare it with the one in the PR.
Limitations and caveats
Like any static analysis tool, Autopilot has limitations you need to be aware of:
Static analysis isn't complete: if your code builds action names dynamically or uses reflection, Autopilot may not capture everything. Resources need refinement: the tool identifies actions, but resource ARNs usually need manual adjustment. It may generate"Resource": "*" for an action where you should restrict to a specific bucket.
Conditions aren't automatically generated: conditions like aws:SourceAccount, aws:SourceArn, or IP restrictions need to be added by you.
It doesn't replace IAM Access Analyzer: Autopilot works with what the code says it needs. Access Analyzer works with what was actually used in production. Ideally, use both: Autopilot during development, Access Analyzer in production.
Autopilot + Access Analyzer: the ideal combo
A mature IAM workflow combines both tools:
- Development: Autopilot generates the baseline policy from the code
- Deploy: the policy goes to production with reasonable (not excessive) permissions
- Production: IAM Access Analyzer monitors which permissions are actually used
- Refinement: with Access Analyzer data, you tighten the policy by removing what wasn't used
This cycle ensures your policies start good and get better over time.
Getting started
The project repository is on GitHub: awslabs/iam-policy-autopilot
To use it as a Kiro Power:
- Go to the Kiro Powers page
- Find IAM Policy Autopilot
- Install with one click
- Open your project in Kiro and ask it to generate the policy
Conclusion
IAM Policy Autopilot as a Kiro Power is one of those integrations that makes immediate sense. Creating IAM policies is a task every AWS dev needs to do, few do well, and most put off. Having this integrated directly in the editor, with one click, removes the friction and increases the chance of starting with proper permissions from the very first deploy.
It's not a silver bullet. You still need to review, adjust resources, add conditions, and monitor in production. But the starting point changes completely: from "Action": "*" to a policy that reflects what your code actually does.