AWS IAM Drift Detector

The problem I wanted to solve

IAM drift usually starts with a reasonable request. Someone needs access, a policy changes, and the work moves forward. The exception can stay long after the original need is gone, leaving the account with more access than anyone intended.

Manual CloudTrail review made that gap easy to miss. I built the IAM Drift Detector to catch changes as they happen, evaluate the risk, and give the reviewer enough context to decide what should happen next.

The goal is a shorter path from an IAM change to a useful security decision. Engineers can keep moving while high-risk changes get attention quickly.

How the event flow works

1. CloudTrail records activity affecting IAM users, roles, and policies.
2. EventBridge matches the relevant events and sends them to Lambda.
3. Lambda extracts the actor, account, region, affected resource, and policy change.
4. The function checks the change for risk signals and assigns a severity.
5. n8n routes the result to the appropriate response workflow.

This design keeps each part focused. EventBridge handles event routing, Lambda handles normalization and scoring, and n8n handles notifications and response. That separation makes it easier to test the scoring logic without triggering every downstream action.

How the risk scoring works

My first version treated too many changes as high risk. It found activity, but it did not give a reviewer enough help deciding which events deserved attention.

I tuned the scoring around context. A wildcard attached to a narrow read action is different from iam:*. A change made by an expected CI service role is different from the same change made by an IAM user at an unusual time. Cross-account trust and access to services such as KMS or Secrets Manager also deserve more scrutiny.

The detector evaluates details such as:

• The identity that made the change
• The affected account, region, user, role, or policy
• The policy before and after the change
• Wildcard actions or resources
• Cross-account role assumptions and trust changes
• Access to IAM, KMS, Secrets Manager, and other sensitive services

The result is a severity based on the change and the context around it. High-severity events create a ticket, post the details to Slack, and can start a rollback workflow. Medium-severity events enter a review queue. Low-severity events stay recorded so I can look for patterns and continue tuning the rules.

Human approval before rollback

Blindly reverting an IAM change can break a legitimate workload. A risky-looking policy might be temporary, expected, and tied to active work. I added an approval gate before rollback so the workflow can flag the change, pause, and wait for a person to confirm the action.

That guardrail keeps the response fast without giving the automation permission to make every final decision. The system collects the evidence and prepares the action. A person controls the destructive step.

Making the alert useful

Raw CloudTrail JSON slows down the first few minutes of an investigation. Each alert includes the identity that made the change, the account and region, the affected resource, the policy before and after, the assigned severity, and the reasons behind the score.

That summary gives the reviewer a starting point without requiring them to search through the original event first. The raw event is still available when they need the full record.

What this project demonstrates

• Monitoring AWS control-plane activity with CloudTrail
• Routing security events with EventBridge
• Parsing and scoring IAM changes in Lambda
• Reviewing policy scope, wildcard access, and cross-account trust
• Separating detection logic from response orchestration
• Building severity-based workflows in n8n
• Adding human approval before a rollback
• Turning raw cloud events into investigation-ready alerts

What I learned

I ran the detector for several months and used it to surface a handful of issues that manual review could have missed. The scoring needed the most iteration. Detection without context produced noise, and automation without an approval boundary created unnecessary risk.

I am still tuning edge cases, but the working path is clear. An IAM change creates an event, Lambda evaluates it, n8n routes the response, and the workflow pauses for human approval before a rollback when the decision could affect a live workload.