IAM Policy Autopilot gained Terraform plan support on 18 August 2026 — 4 limits AWS did not mention

Summary. On 18 August 2026 AWS added Terraform plan files as an input to IAM Policy Autopilot, the open source policy generator awslabs shipped at re:Invent 2025. You pass a plan file, the tool runs a deterministic analysis, and it emits a policy scoped to the CRUD functions of the resources in that plan, referencing specific resource ARNs "rather than wildcards, when possible". AWS calls this the most requested capability since launch, says the tool is available at no additional cost and "runs on your own machine". Four things sit underneath that. The tool makes outbound HTTPS calls to servicereference.us-east-1.amazonaws.com at runtime, so it is local but not offline. It generates identity-based policies only, and does not cover resource-based policies, Service Control Policies, Resource Control Policies or permission boundaries. Its static analysis can pull in actions for AWS services your code never touches. And the input file itself — a Terraform plan — stores sensitive values in plaintext, which HashiCorp documents with an explicit warning never to commit one to version control. The repository is Apache-2.0 with 369 stars, 40 forks and 27 open issues as of 21 August 2026.

What shipped

Before this change, IAM Policy Autopilot analysed application source code. AWS states plainly that "until now the tool analyzed application source code, but it was not possible to generate policies for deploying AWS infrastructure defined via Infrastructure as Code". That gap is what closed. You now pass a Terraform plan file and get back a policy for the deployment role, not the application role.

AWS describes the mechanism as a deterministic analysis producing "a policy scoped to the CRUD functions of the resources in that plan", and says it "complements the existing Terraform-aware analysis, which cross-references Terraform resource definitions with SDK calls in your application code to resolve ARNs". Two distinct analyses, then: one for what your app does at runtime, one for what your pipeline does at deploy time.

The tool itself is a Rust binary distributed on PyPI and installable through uvx iam-policy-autopilot, pip install iam-policy-autopilot, or a shell installer that drops it at /usr/local/bin/iam-policy-autopilot. It ships three commands: generate-policies, fix-access-denied and mcp-server. The MCP server means an AI coding assistant can call it directly, and the repository carries configuration for Kiro, Kiro CLI and Claude Desktop.

Limit 1: local is not offline

The announcement says the tool "runs on your own machine". The repository is more specific, and the difference matters for anyone in a locked-down network.

Under Network Requirements, the README states that "IAM Policy Autopilot makes HTTPS requests at runtime to the AWS service reference endpoint to fetch up-to-date AWS service metadata used for policy generation. This endpoint must be reachable from the machine running the tool." The firewall allowlisting table names exactly one endpoint: servicereference.us-east-1.amazonaws.com over HTTPS.

Two consequences for regulated estates. A build agent on a restricted egress policy needs that host allowlisted or the tool cannot generate a policy. And if your network performs TLS inspection, the README says the inspection CA certificate must be present in the operating system certificate store, because the tool uses the OS native store for TLS verification. Proxy users set HTTPS_PROXY. None of that is in the announcement.

Limit 2: identity-based policies only

The repository is direct about scope. IAM Policy Autopilot "produces IAM identity-based policies, but doesn't support resource-based policies such as S3 bucket policies or KMS key policies, Resource Control Policies (RCPs), Service Control Policies (SCPs), and permission boundaries."

For a deployment role that is a real gap. Most organisations that care enough about least privilege to run a policy generator are also running SCPs at the organisation level and permission boundaries on delegated roles. A generated policy that looks correct in isolation can still be denied at apply time by a boundary or an SCP the tool never read. The generator narrows the identity policy; it does not tell you the effective permission.

Policy type	Covered by IAM Policy Autopilot	Where it is still enforced
Identity-based policy on the role	Yes, generated	IAM
Resource-based policy, for example an S3 bucket policy	No	The resource
Permission boundary	No	IAM, as a ceiling on the identity policy
Service Control Policy	No	AWS Organizations
Resource Control Policy	No	AWS Organizations

Limit 3: name collisions inflate the policy

The README documents a failure mode worth knowing before you trust the output. "IAM Policy Autopilot's static analysis may include permissions for AWS services your application doesn't use. This happens when method names in your code match AWS SDK calls from multiple services." The example it gives is a method called listAccounts() that generates permissions for both AWS Organizations and Amazon Chime, because both services expose a ListAccounts API.

The mitigation is the --service-hints flag, which narrows analysis to the services you name. The repository is careful not to oversell it: using hints "significantly reduces unnecessary permissions", but "the final policy may still include actions from other services if they're required for the operations you perform", such as KMS actions for S3 encryption. There is also an --explain option that takes an action pattern like s3:* and reports which operations caused an action to be included, which is the flag to reach for during review.

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

That over-inclusion pressure now runs into a limit on the other side. A single customer managed policy caps at 6,144 characters, and that limit is not adjustable. AWS raised the number of managed policies a role can carry on 19 August 2026, the day after this release — see our analysis of the IAM managed-policy quota moving from 10 to 20. A generator that emits broader policies than you expected and a quota that just doubled are a combination worth watching in the same review.

Limit 4: the plan file is the sensitive artefact

This is the one most likely to bite, because it moves a secret-bearing file into a new place in the pipeline.

HashiCorp's own documentation is unambiguous. "Terraform stores values with the sensitive argument in both state and plan files, and anyone who can access those files can access your sensitive values." The Terraform plan tutorial carries a warning in bold: "Terraform plan files can contain sensitive data. Never commit a plan file to version control, whether as a binary or in JSON format." A second warning on the same page adds that "although you marked the input variable as sensitive, Terraform still stores the value in plaintext in the plan file".

So the workflow AWS is encouraging — terraform plan -out "tfplan", then hand tfplan to a policy generator — puts a plaintext-secret-bearing artefact into a new tool's hands. Three controls follow from the HashiCorp guidance and cost nothing:

1. Keep the plan file inside the job that created it. Do not publish it as a build artefact for the policy-generation step to pick up later.
2. Pass provider credentials through environment variables. HashiCorp states that "unlike input variables, Terraform does not record the values of any environment variables used for your configuration in your plan files", and calls environment variables one of the recommended ways to pass sensitive values.
3. Use write-only or ephemeral arguments where the provider supports them. HashiCorp's example has the aws provider using a password_wo value to create a database instance, after which "Terraform discards that value without storing it in the plan or state file".

The unknown-at-plan-time problem

AWS says the generated policies reference specific resource ARNs "rather than wildcards, when possible". The qualifier is doing real work, and Terraform's JSON format explains why.

A saved plan is a binary file; terraform show -json <FILE> renders it. In that representation, planned_values is "a description of what is known so far of the outcome in the standard value representation, with any as-yet-unknown values omitted", and after_unknown replaces "all unknown leaf values" with true. Anything a resource cannot know until apply — the classic + id = (known after apply) line — is simply not an ARN yet. Terraform's own reference warns that in the values representation "any unknown values are omitted or set to null, making them indistinguishable from absent values".

That sets a practical expectation: for a green-field stack where most identifiers are computed at apply, expect more wildcards; for a plan that mostly updates existing resources with known ARNs, expect tighter scoping. The tool is deterministic, not clairvoyant. The real constraint is not the analyser, it is what Terraform knows at plan time.

A second-order effect is worth planning for. If the generated deployment policy is tightest on the second run, the sensible sequence is to generate once against a plan for an existing environment rather than against the very first terraform apply in a new account.

Who should look at this now

Teams running Terraform through CI against a long-lived deployment role are the clearest fit, particularly where that role has drifted toward * because nobody had time to enumerate what a plan actually needs. Teams standardising on OpenTofu should check compatibility before planning work around it; AWS names Terraform plan files specifically and the repository's language support table covers application SDKs, not IaC dialects. Anyone already running posture management will want the generated policy compared against detective controls rather than trusted on sight, which is the same discipline described in our guide to AWS Security Hub and multicloud posture decisions. Teams mid-upgrade on the Terraform side should sequence this after the version work covered in our note on Terraform 1.16 and destroy protection.

India-specific considerations

Indian services firms running client infrastructure from a shared delivery account have a specific reason to care about limit 4. A plan file for a client environment can carry that client's initial database passwords or API tokens in plaintext, and under the Digital Personal Data Protection Act, 2023 the fiduciary obligations attached to that data do not soften because the file is a build artefact. The practical rule is the one HashiCorp already publishes: the plan file never leaves the job that produced it, and provider credentials arrive through environment variables rather than input variables. Egress control is the other India-specific detail — locked-down delivery VPCs will need servicereference.us-east-1.amazonaws.com allowlisted before the tool runs at all.

What is still unknown

AWS has not said which Terraform versions or plan-format versions the analyser accepts, nor whether OpenTofu plan files parse. It has not published how the tool handles a plan whose resource identifiers are entirely unknown at plan time, beyond the "when possible" phrasing. It has not stated whether Terraform provider coverage matches the AWS SDK coverage listed for application code, which spans Python, Go, TypeScript, JavaScript and Java. And the repository's own security posture for handling a secret-bearing plan file — whether anything is buffered, logged or cached — is not documented in the README as of 21 August 2026.

FAQ

What changed in IAM Policy Autopilot on 18 August 2026?

AWS added Terraform plan files as an input. You pass a plan file and the tool applies a deterministic analysis to produce an IAM policy scoped to the CRUD functions of the resources in that plan. AWS says this was the most requested capability since the tool launched at re:Invent 2025.

Does IAM Policy Autopilot cost anything?

No. AWS states the tool is available at no additional cost and runs on your own machine. The repository is licensed Apache-2.0 and distributed through PyPI, so there is no AWS service charge attached, though the machine running it still needs outbound HTTPS access to one AWS endpoint.

Does the tool work without internet access?

No. The repository states that IAM Policy Autopilot makes HTTPS requests at runtime to the AWS service reference endpoint to fetch service metadata, and that this endpoint must be reachable. Firewall allowlisting covers a single host, servicereference.us-east-1.amazonaws.com, reached over HTTPS.

Will the generated policy account for my SCPs and permission boundaries?

No. The repository states the tool produces identity-based policies and does not support resource-based policies such as S3 bucket or KMS key policies, Resource Control Policies, Service Control Policies, or permission boundaries. Those controls still apply at apply time and can deny an action the generated policy allows.

Why does the generated policy include services my code does not use?

Static analysis matches method names against AWS SDK calls, and names collide across services. The repository's example is listAccounts(), which can generate permissions for both AWS Organizations and Amazon Chime. Narrow the analysis with the --service-hints option and audit the result using --explain with an action pattern.

Is it safe to hand a Terraform plan file to another tool?

Treat the plan file as a secret. HashiCorp documents that values marked sensitive are stored in both state and plan files, that anyone who can read those files can read the values, and warns never to commit a plan file to version control in binary or JSON form. Keep it inside the job.

Why does AWS say ARNs are scoped only "when possible"?

Because Terraform does not know every identifier at plan time. The JSON plan format omits as-yet-unknown values from planned_values and marks them in after_unknown, which is what the familiar "known after apply" line represents. Where an ARN is not yet determined, the generator has nothing specific to reference.

How eCorpIT can help

eCorpIT reviews AWS deployment permissions for teams running Terraform in CI, covering the identity policy, the boundaries and organisation policies the generator does not read, and the handling of plan artefacts in the pipeline. That work runs alongside our multicloud security posture management practice, delivered by senior engineering teams and backed by CMMI Level 5 and ISO 27001:2022 certification. If your deployment role still carries a wildcard because enumerating it was never worth the week, we can scope it properly. Talk to us at /contact-us/.

References

1. IAM Policy Autopilot now supports Terraform plan files — AWS What's New, posted 18 August 2026.
2. awslabs/iam-policy-autopilot README — GitHub, retrieved 21 August 2026.
3. awslabs/iam-policy-autopilot repository — GitHub, Apache-2.0.
4. Manage sensitive data in your configuration — HashiCorp Terraform documentation.
5. Create a Terraform plan — HashiCorp Terraform tutorial.
6. JSON output format — HashiCorp Terraform internals.
7. terraform show command reference — HashiCorp Terraform CLI documentation.
8. AWS IAM now supports 20 managed policies per role by default — AWS What's New, posted 19 August 2026.
9. IAM and AWS STS quotas — AWS Identity and Access Management User Guide.
10. AWS Identity and Access Management endpoints and quotas — AWS General Reference.
11. Managed policies and inline policies — AWS Identity and Access Management User Guide.

Last updated: 21 August 2026.