IAM Least-Privilege From CloudTrail Usage Prompt
Turn actual CloudTrail and Access Analyzer usage data into a tightly-scoped, deny-by-default IAM policy that keeps the workload running.
- Target user
- Cloud and security engineers right-sizing AWS IAM roles and users
- Difficulty
- Advanced
- Tools
- Claude, ChatGPT, Cursor
The prompt
You are a senior AWS security engineer who has driven hundreds of IAM principals from wildcard grants down to true least privilege without breaking workloads. Reason like an EXPLAIN plan: derive the policy from observed events, not from guesses. I will provide: - The current IAM policy JSON: [CURRENT_POLICY_JSON] - What this principal actually does (workload or human role): [PRINCIPAL_PURPOSE] - CloudTrail / Access Analyzer / IAM last-accessed data: [USAGE_DATA] - The principal's ARN and the resource ARNs it should touch: [ARNS] Do the following, numbered: 1. Parse the usage data and list every distinct `eventSource:eventName` (e.g. `s3.amazonaws.com:GetObject`) the principal actually invoked over the observed window, with a count and last-seen timestamp where available. 2. Map each observed call to the IAM action that authorizes it (e.g. `GetObject` -> `s3:GetObject`), noting any calls that require companion actions (`s3:ListBucket`, `kms:Decrypt`). 3. Compare against the current policy: classify each existing statement as used / unused / wildcard / over-scoped, in a table. 4. Write a rewritten least-privilege policy that grants ONLY the actions observed (plus required companions), scopes `Resource` to the exact ARNs in [ARNS] instead of `*`, and adds conditions (`aws:SourceVpce`, `aws:RequestedRegion`, MFA) where they reduce risk without breaking the workload. 5. List actions that appear in the policy but have NO usage evidence, and recommend a staged removal with a CloudTrail observation window before deletion. Output as: (a) the observed-calls-to-actions table, (b) the per-statement verdict table, (c) the rewritten policy JSON, (d) the staged-removal plan. Validate with the IAM policy simulator and monitor Access Denied events before enforcing. Never broaden a grant to silence an error without confirming the call is legitimate; never apply a tightened policy to a production principal without simulation and review.
Why this prompt works
Least-privilege IAM fails most often because engineers author policies from imagination rather than evidence. They either copy an AWS managed policy that grants far too much, or they paste in "Action": "*" to make an error disappear. This prompt forces the opposite discipline: it starts from CloudTrail and IAM last-accessed data and treats every grant that lacks a corresponding observed call as suspect. By mapping each real eventSource:eventName to its authorizing IAM action, the model produces a policy you can defend line by line.
The companion-action step matters because AWS calls rarely stand alone. A single s3:GetObject against an encrypted bucket also needs kms:Decrypt, and listing a prefix needs s3:ListBucket scoped to the bucket ARN with a prefix condition. A naive usage-to-policy mapping that ignores these dependencies produces a policy that passes simulation on the happy path and then throws Access Denied in production. Asking the model to flag companions explicitly catches this class of failure before rollout.
Finally, the staged-removal plan keeps a human in control. Rather than deleting unused actions immediately, the prompt produces a removal candidate list plus an observation window, so you reveal cuts gradually and monitor Access Denied events. That converts a risky big-bang tightening into a reversible, evidence-driven sequence — the only safe way to shrink permissions on identities that real workloads depend on.