# IAM Policy Autopilot: baseline AWS IAM policies from static code analysis

> IAM Policy Autopilot is an Apache-2.0 Rust tool from awslabs that reads your application code or a Terraform plan and emits baseline identity-based IAM policies, as a CLI or as an MCP server for AI coding assistants.

**awslabs/iam-policy-autopilot** — IAM Policy Autopilot is an open source static code analysis tool that helps you quickly create baseline AWS IAM policies that you can refine as your application evolves. This tool is available as a command-line utility and MCP server for use within AI coding assistants for quickly building IAM policies.

- Repository: https://github.com/awslabs/iam-policy-autopilot
- Stars: 464 · Forks: 56
- Language: Rust
- License: Apache-2.0
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/awslabs-iam-policy-autopilot

## The blank-policy problem IAM Policy Autopilot targets

Writing an IAM policy by hand means reading your own application to work out which API calls it makes, then translating each call into an action name, then guessing whether the call needs a related permission you did not think of. The README frames the tool as a way to create a baseline identity-based policy that you refine as the application evolves, and it names the audience plainly: builders on AWS who use AI coding assistants, including developers, product managers, technical experimenters and business leaders. That audience matters. This is not a least-privilege enforcement tool and not a policy linter. It is a starting point generator, and the README says so in the section title it uses for its own caveats, "Review and refine policies generated by IAM Policy Autopilot". The scope is identity-based policies for application roles. If your problem is that a Lambda times out because its role lacks a permission, this tool is aimed at you. If your problem is that a role has far more access than it should, this tool does not shrink it.

## Static analysis over SDK calls, not runtime tracing

The mechanism is deterministic code analysis, and the README contrasts that with guesswork: "IAM Policy Autopilot's deterministic code analysis helps create reliable and valid IAM policies". The workspace layout backs this up. The Cargo workspace splits the product into iam-policy-autopilot-policy-generation, iam-policy-autopilot-cli, iam-policy-autopilot-mcp-server, iam-policy-autopilot-common, iam-policy-autopilot-tools, iam-policy-autopilot-wasm, iam-policy-autopilot-proc-macros and iam-policy-autopilot-access-denied, with integration-tests/runner and xtask alongside them. The generation crate carries resources/config/sdks and a resources/config/terraform subtree, which is where the SDK call tables and the Terraform provider data live. The workspace dependency list includes ast-grep-language, ast-grep-config and ast-grep-core at version 0.39, so the parsing layer is tree-sitter based rather than a hand-written regex pass. That is the part worth caring about: the tool resolves SDK calls against a shipped table of service operations instead of pattern-matching strings, which is why it can map a method name to a concrete IAM action. Nothing is executed. Your application is not run, no AWS credentials are needed for the analysis, and the README describes the analysis as local. The output is a policy document you can inspect before it goes anywhere.

## Installing from PyPI and generating a first policy

The package is published to PyPI as iam-policy-autopilot, and pyproject.toml sets requires-python to >=3.8 while building the CLI binary through maturin from iam-policy-autopilot-cli/Cargo.toml with bindings = "bin". The repository also ships an install.sh at the top level. The README's own example for a first run is a single command against one source file, with the service hints flag and pretty output:

```bash
iam-policy-autopilot generate-policies ./src/app.py --service-hints s3 iam organizations --pretty
```

Run that and you get a formatted identity-based policy for the AWS calls the analysis found in ./src/app.py, scoped to the three hinted services. Drop --service-hints and the same file is analyzed against every service the tool knows about, which is where the next section becomes relevant. To understand why a specific action ended up in the document, the README points at the explain flag with an action pattern:

```bash
iam-policy-autopilot generate-policies ./src/app.py --explain 's3:*'
```

That trace is the part I would use first. It answers the question a reviewer will ask, which is not "what is in this policy" but "which line of my code put it there". The README does not document a rollback or an uninstall path, and it does not describe a dry-run mode.

## Service hints, and why an unhinted run is noisy

Method names collide across AWS services, and the README gives a concrete example: a method called listAccounts() can generate permissions for both AWS Organizations and Amazon Chime, because both expose an operation with that name. The README's recommended approach is to pass --service-hints with only the services your application uses, and it shows the two commands side by side, labelling the hinted one "More accurate" and the unhinted one "Less accurate - may include unnecessary permissions". The README is careful about what hints actually do. They scope down which SDK calls get analyzed, but the final policy can still contain actions from services outside the hint list when the operations you perform require them, and it names KMS actions for S3 encryption as the example. So hints reduce noise without making the output minimal. The README also notes that when you use the MCP server integration, the assistant is expected to supply service hints from your code context automatically, and that --service-hints is primarily a CLI option. That division is worth remembering: the CLI gives you a flag, the MCP path gives you a convention.

## What IAM Policy Autopilot will not generate

The scope boundary is stated in the README and it is wide. IAM Policy Autopilot produces identity-based policies. It does not support resource-based policies such as S3 bucket policies or KMS key policies, and it does not cover Resource Control Policies, Service Control Policies or permission boundaries. The runtime-value limitation is the one that will bite most teams. The README's example is a call to s3.getObject(bucketName) where bucketName is determined at runtime: the tool does not predict which bucket will be accessed. That means the generated policy can name actions without naming the resources they apply to, and a policy that allows s3:GetObject on a wildcard resource is a different security posture from one that names a bucket ARN. The README also draws a line between its output and what your assistant does with it. When the MCP server hands a policy to an AI coding assistant, the assistant may add resource ARNs or KMS key IDs based on its own reading of your code, and the README attributes those edits to the assistant's interpretation rather than to the static analysis. Two different systems are writing into the same document, and only one of them is deterministic. The README's advice to review assistant-generated content before deployment follows from that, not from caution for its own sake.

## Terraform plans and the alternative of runtime-derived policies

IAM Policy Autopilot can also generate policies from a Terraform plan file in JSON format, which moves the input from source code to the planned infrastructure graph. The alternative most teams already run is a runtime approach: instrument the application, capture the API calls it makes in a test or staging environment, and derive the policy from that activity log. The difference is not incremental. Runtime capture sees what the code actually called, including calls reached through configuration or reflection that static analysis cannot follow, but it only sees the paths your test exercised, and a rarely hit error branch stays invisible until production. Static analysis sees every call site in the source, including branches that never ran, but it cannot resolve values that only exist at deploy time, which is exactly the s3.getObject(bucketName) case the README calls out. Pick based on which failure you can tolerate: a policy missing a permission that only appears on a cold path, or a policy carrying actions for code paths that never execute. A policy linter is a different tool again. It will tell you that your existing policy is too broad or malformed. IAM Policy Autopilot assumes you do not have a policy yet.

## Maintenance, licensing and the cost of staying current

The repository is not archived, and the last push was on 2026-09-06. Release 0.3.0 landed on 2026-08-18, after 0.2.4-rc.1 on 2026-08-07 and 0.2.3 on 2026-06-18, so the project is moving on a roughly two-month cadence at the version level. The README makes an explicit promise about currency: the tool "stays up to date with the latest AWS services and features". That promise has a cost, and the cost lands on whoever adopts it. The SDK call tables under iam-policy-autopilot-policy-generation/resources/config/sdks and the Terraform provider data under resources/config/terraform are shipped data, not something the tool fetches at analysis time, so a new AWS operation is only visible after a release that carries it. If your application calls a service added after your installed version, expect a gap, and check the release notes rather than assuming the analysis covered it. The licence is Apache-2.0 for the workspace, declared in Cargo.toml and in pyproject.toml as license = "Apache-2.0". That is a permissive licence with an explicit patent grant, and the repository carries a NOTICE file, which Apache-2.0 expects you to preserve when you redistribute. Whether that fits your organisation's policy is a question for your legal team, not for this article.

## Conclusion

Adopt IAM Policy Autopilot if you write AWS SDK calls in Python, Go, TypeScript, JavaScript or Java and want a starting policy instead of a blank JSON editor, and pass --service-hints so the analysis stays on the services you actually use. Do not adopt it if you need resource-based policies, SCPs, RCPs or permission boundaries, or if your bucket and key names only exist at runtime. Before you deploy anything it produces, run the generate-policies command against one service and read the output next to the --explain trace for the actions you did not expect.

## FAQ

### Which languages and SDKs can IAM Policy Autopilot analyze?

The README lists Python, Go, TypeScript, JavaScript and Java for policy generation, and the pyproject.toml description names Python, Go, TypeScript and Java. It can also generate policies from a Terraform plan file in JSON format.

### Does IAM Policy Autopilot need AWS credentials or network access?

The README describes the analysis as running locally against your application code, and the tool works by static analysis rather than by calling AWS APIs. The README has a Network Requirements section, so check that page for the details before running it in a restricted environment.

### Why does my generated policy include permissions for services I do not use?

Method names can match SDK calls from more than one service, which the README illustrates with listAccounts() matching both AWS Organizations and Amazon Chime. Passing --service-hints with only the services you use scopes down the analysis, though the README notes the final policy may still include actions required by the operations you perform.

### Can IAM Policy Autopilot generate S3 bucket policies or KMS key policies?

No. The README states that IAM Policy Autopilot produces identity-based policies and does not support resource-based policies such as S3 bucket policies or KMS key policies, nor Resource Control Policies, Service Control Policies or permission boundaries.

## Sources

- [awslabs/iam-policy-autopilot on GitHub](https://github.com/awslabs/iam-policy-autopilot)
- [Issues](https://github.com/awslabs/iam-policy-autopilot/issues)
- [License: Apache-2.0](https://github.com/awslabs/iam-policy-autopilot/blob/main/LICENSE)
- [README](https://github.com/awslabs/iam-policy-autopilot/blob/main/README.md)
- [Releases](https://github.com/awslabs/iam-policy-autopilot/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/awslabs-iam-policy-autopilot