IAM Access Analyzer reads up to 90 days of CloudTrail activity for a role and drafts a policy containing only what the role used. For a CI role that started broad, this is a practical way to cut permissions, as long as you review the draft and know what it cannot see.
What policy generation does
AWS describes the feature this way: Access Analyzer reviews your CloudTrail logs and generates a policy template with the permissions the entity used in the date range you choose. You can then replace a broad policy on the role with the generated one.
A CI role is a good candidate. Pipelines are repetitive, so 30 to 90 days of history usually covers every real code path, including the monthly or release only jobs.
Steps
- Confirm a CloudTrail trail is enabled for the account. Policy generation needs one.
- Pick the role in the IAM console and choose the option to generate a policy from CloudTrail events.
- Choose the shortest time range that still covers your release cycle. AWS notes a range of up to 90 days is possible and shorter ranges generate faster.
- Select or create the service role that lets Access Analyzer read your trail, and select the trail.
- When generation finishes, review the actions and the list of services used. For some services you must add actions by hand.
- Replace the placeholder resource ARNs with real ones where the action supports resource level permissions.
- Save it as a managed policy, attach it to the role in a test account first, and run your pipeline.
- Detach the old broad policy once the pipeline passes.
AWS says you can view a generated policy in the console for seven days, so plan to finish the review in that window.
What it cannot see
AWS lists several limits. Read them before trusting the output.
| Limit | Effect on a CI role |
|---|---|
| No action level data for data events such as S3 object operations | Artifact uploads may show up at service level only |
iam:PassRole is not tracked by CloudTrail | A deploy role that passes roles will be missing that permission |
| Denied actions are included in the review | Failed attempts can leak into the draft, so check them |
| Not meant for auditing | Use CloudTrail itself to investigate activity |
The PassRole gap matters most for deploy roles. If your pipeline creates a Lambda function or a compute service that takes a role, the generated policy will not include the pass permission, and the deploy will fail until you add a scoped statement. Our post on PassRole for deploy roles shows how to write one.
Review it like code
Treat the draft as a pull request against your own infrastructure. Look for wildcards that remain on resources, services you do not recognize, and actions that were only tried during a one time migration. Put the final policy in version control next to the pipeline so changes get reviewed.
Repeat the exercise every quarter. Pipelines drift, and permissions that were needed once tend to stay.
Quick check
How far back can Access Analyzer look?
Up to 90 days of CloudTrail events, per the AWS documentation. A shorter range generates faster.
Will the generated policy include iam:PassRole?
No. AWS states that PassRole is not tracked by CloudTrail and is not included, so add a scoped statement yourself if the role needs it.
Safeguard does not manage your cloud accounts. It scans your code and dependencies, applies pull request policies and gates, and automates compliance evidence. Try a free scan at gold.safeguard.sh/scan.
Sources
- AWS IAM User Guide: IAM Access Analyzer policy generation
- AWS IAM User Guide: Security best practices in IAM
Last reviewed: 19 October 2026.
