Announcing IAM Armor: ESLint for AWS IAM in Terraform

We built IAM Armor for a simple reason: IAM mistakes are still entering production through normal pull requests, even in strong engineering teams.

Most incidents are not caused by one dramatic policy. They come from small permission decisions that accumulate over time—wildcards that stay longer than intended, trust relationships that are broader than needed, and exceptions that no one revisits. Teams move fast, so these changes look acceptable in isolation.

IAM Armor turns those patterns into deterministic checks during review.

What ships today

Static IAM risk detection for Terraform-based workflows
Severity-based findings so teams can separate urgent fixes from cleanup work
CI-friendly output for pull request gating and dashboards
Configurable rules and exceptions through repo-managed policy files

How teams are rolling it out

The practical rollout we are seeing in startups and platform teams is:

Start in advisory mode to establish a baseline.
Block merges only on high-severity findings.
Add exception ownership and expiry so temporary risk does not become permanent.
Track trendlines weekly instead of waiting for audit season.

For teams already using LLMArmor in application-layer workflows, IAM Armor fits naturally as the identity and access control counterpart in the same PR-first operating model.

Quick start path

Add scanner checks to IAM-related Terraform pull requests.
Keep high-severity findings merge-blocking.
Route findings to owning teams with explicit remediation dates.

Helpful references:

FAQ

Is IAM Armor only for large security teams?

No. It is designed for engineering teams that need predictable IAM guardrails without adding heavy review bottlenecks.

Will this slow shipping velocity?

It usually improves it over time by reducing late-stage security rework and incident-driven permission cleanup.

Can we adopt it gradually?

Yes. Advisory-first rollout and severity-based gating are the intended path for most teams.