IAM Policy Autopilot: baseline IAM policies from static analysis of your AWS SDK calls

The gap IAM Policy Autopilot fills: hand-written policies for code that already names its own API calls

An application that calls AWS SDK methods already contains the information needed to draft its own permissions. The call site names the operation, the SDK names the service, and the role that runs the code needs a policy that permits exactly those operations. In practice, teams still write those policies by hand, reading service documentation and guessing which actions a given call expands into. IAM Policy Autopilot takes the other direction: it reads the code and produces the baseline identity-based policy. The README describes the audience as builders on AWS using AI coding assistants, and lists developers, product managers, technical experimenters, and business leaders. That is a wide net, and the useful part of it is narrower. The tool is for people who have working application code and need a policy draft they can attach to an application role, not for people designing an authorization model from scratch. The README states the goal plainly: analyze application code locally and generate identity-based policies for application roles, reducing access troubleshooting time. The word baseline appears throughout, and it is load-bearing. Nothing in the documentation suggests the output is deployable without review.

How the analysis works: deterministic scanning of SDK call sites, with service hints as the main control

The mechanism is static code analysis, and the README calls it deterministic. The tool scans your application for AWS SDK calls and maps them to IAM actions, then emits an identity-based policy for the application role. Supported inputs are Python, Go, TypeScript, JavaScript, and Java, plus a Terraform plan file in JSON format. That Terraform path matters for teams whose infrastructure is defined declaratively: the plan JSON is a static artifact, so it can be analyzed the same way source files are. The main accuracy control is --service-hints. The README gives a concrete failure mode: a method named listAccounts() can match both the AWS Organizations ListAccounts API and the Amazon Chime ListAccounts API, so an unhinted run may include permissions for a service the application never touches. Passing --service-hints s3 iam organizations narrows which SDK calls are considered. The README warns that this does not guarantee a clean output: the final policy may still include actions from services outside the hints when the operations you perform require them, and it gives KMS actions for S3 encryption as the example. When the tool runs as an MCP server, the README states the assistant is expected to supply appropriate service hints from its own view of your code, and that --service-hints is primarily a CLI option. That split is worth understanding before you wire anything into an assistant: the hint quality becomes a property of the assistant's context, not of the tool.

Running it: the generate-policies command, the --pretty flag, and the --explain trace

The README shows the CLI invocation directly. The accurate form names the entry file and the services in use: iam-policy-autopilot generate-policies ./src/app.py --service-hints s3 iam organizations --pretty. The less accurate form drops the hints: iam-policy-autopilot generate-policies ./src/app.py --pretty. The README states the first significantly reduces unnecessary permissions and produces more targeted policies. The --pretty flag is used in both examples, so it controls output formatting rather than analysis. The other flag the documentation explains is --explain, used with action patterns such as --explain 's3:*' to show which operations caused an action to be included in the generated policies. That is the review tool, and it is the one to reach for when a policy contains an action you did not expect. The README lists network requirements as a documented section, but the supplied excerpt does not include its contents, so I cannot say what the tool contacts or whether analysis is fully offline. The README says it analyzes code locally; the network section exists, which suggests some part of the workflow reaches out, but the excerpt does not say which. Verify that before running it against code you would not otherwise send anywhere. Installation instructions appear under Getting Started, which the excerpt also omits; the PyPI badge indicates a Python package distribution, while the repository's primary language is Rust.

What the tool will not generate, and the runtime values it cannot see

The scope boundary is stated without hedging. IAM Policy Autopilot produces identity-based policies only. It 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. If your security model depends on any of those, this tool addresses a different layer of it. The second limitation is more likely to bite in day-to-day use. The README gives the example of code that calls s3.getObject(bucketName) where bucketName is determined at runtime: the tool currently does not predict which bucket will be accessed. So the generated policy can name the right actions while leaving the resource scope unresolved, which is exactly the part of an IAM policy that carries the most risk. A policy with s3:GetObject on a wildcard resource is not the same artifact as one scoped to a bucket ARN, and the difference is a human decision the tool does not make. The README also draws a boundary between the tool and the coding assistant. The tool produces actions from deterministic analysis; the assistant, when it turns that policy into an infrastructure-as-code template, may add resource ARNs or KMS key IDs based on its own reading of your code. The README attributes those additions to the assistant's interpretation, not to the static analysis, and tells you to review assistant-generated content before deployment. Two systems are writing the policy, and only one of them is the analyzer.

Where it sits against hand-written policies and against broad managed policies

The realistic alternatives are not other static analyzers, at least not in the material supplied here. They are the two habits most AWS teams already have. The first is writing the policy by hand from the SDK documentation and iterating on AccessDenied errors in a development account. That produces a policy that is usually well scoped, because a human chose the resource ARNs, but it costs a deploy-and-retry cycle per missing action. IAM Policy Autopilot front-loads the action list and removes most of that loop, at the cost of a draft that still needs the ARN work done by hand. The second habit is attaching a broad managed policy and moving on. That never fails at deploy time and is the reason so many roles carry permissions nobody can justify later. IAM Policy Autopilot sits between them: narrower than a managed policy, faster than the manual loop, and explicitly not a substitute for review. The --explain flag is what makes the middle position defensible, because it turns an opaque action list into a traceable one. Without that trace, a reviewer facing forty generated actions has little choice but to accept them or start over.

Maintenance, release cadence, and the licence terms you inherit

The repository is Apache-2.0, a permissive licence that allows commercial use and modification, with the usual requirements around preserving notices and stating changes. That is the licence text, not legal advice; if you redistribute the tool or embed it in a product, read the LICENSE file in the repository rather than this summary. On maintenance, the material shows releases 0.2.3 in June 2026, 0.2.4-rc.1 in August 2026, and 0.3.0 on 18 August 2026, with the last push to main on 6 September 2026. The 0.2.x line carried a release candidate, which suggests the project tests changes before tagging them stable. What the material does not show is a compatibility policy for the CLI surface or the generated policy format, so pinning a version before you build it into a pipeline is the safer reading of the evidence. The README also notes the tool tracks AWS services and features so permissions knowledge stays current. That is a maintenance commitment on the project's side, and it implies the action mapping is only as good as the most recent release you are running. An old binary will lag new AWS operations.

What to verify before the first generated policy reaches a real role

Start with the network requirements section, which the supplied excerpt does not include. Confirm what the tool reaches out to during analysis and whether that fits your code handling rules. Then run the CLI against a single service in a small application and read the output with --explain on the actions you did not expect. The listAccounts() example in the README is the shape of the problem: a method name that matches two services, resolved only by hints. If your codebase has generic method names wrapping SDK calls, expect the unhinted output to be noisy, and expect the MCP path to inherit whatever hints your assistant decides to pass. After the action list is clean, the remaining work is resource scoping, which the tool does not do when values are computed at runtime. That step stays with you, and it is the step that determines whether the deployed policy is tight or merely plausible. The tool's own documentation calls the output a starting point to refine as the application matures, and nothing in the material contradicts that framing.

Editorial conclusion

Adopt IAM Policy Autopilot if you are writing AWS SDK calls in Python, Go, TypeScript, JavaScript, or Java and want a deterministic first draft of an identity-based policy instead of hand-assembling actions from service documentation. Do not adopt it if you need resource-based policies, SCPs, RCPs, or permission boundaries, or if your access patterns depend on runtime values the analyzer cannot see, such as a bucket name computed at run time. Before trusting a generated policy, run the CLI with --service-hints limited to the services you actually call, use --explain with patterns such as 's3:*' to trace why an action appeared, and check the workspace layout and release history on the main branch for what changed between 0.2.3 and 0.3.0.

Official sources

1. awslabs/iam-policy-autopilot on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases