IAM Policy Conflict Detector

When several policies apply to the same role or user, it is easy for one policy to grant an action that another policy explicitly denies — and in IAM, the explicit Deny always wins, which can be a surprising source of "access denied" even though a policy clearly grants the permission. IAM Policy Conflict Detector pastes 2–3 policy documents, scans every Allow statement against every Deny statement across all of them, and reports the pairs whose Action and Resource patterns overlap.

Overlap detection uses the same wildcard-pattern heuristic documented in the shared policy engine: two patterns are treated as overlapping if either, read literally, matches the other read as a wildcard. That is enough to catch the common cases — an exact match, a Deny wildcard that covers an Allow statement’s specific action, an Allow wildcard that covers a Deny statement’s specific action — but it is not a full regex-equivalence check, so unusual wildcard shapes can occasionally be missed, and statements using NotAction/NotResource/Principal-only forms are excluded from the check entirely rather than risk a wrong answer.

Finding a conflict does not change the outcome — an explicit Deny always overrides an overlapping Allow in real IAM evaluation, regardless of which policy it lives in or how many other policies grant the access. What this tool adds is visibility: instead of noticing the effect of a buried Deny only when a request unexpectedly fails, you can see the exact Allow/Deny pair up front and decide whether the Deny is an intentional guardrail or an accidental one.

• Cross-policy conflict detection between Allow and Deny statements across 2–3 pasted documents.
• Each conflict shown as an Allow/Deny pair, sourced back to its originating policy.
• Documented wildcard-overlap heuristic — not a full regex-equivalence engine, and it says so.
• Sample conflicting pair to see the tool in action immediately.
• 100% client-side — nothing is uploaded.

1. Paste Policy 1 and Policy 2 (and optionally Policy 3).
2. Click Detect Conflicts.
3. Review each conflict pair — the Allow statement and the overlapping Deny statement, shown together with their source policy.
4. Remember: the Deny always wins for the overlapping scope — use the list to check whether that is what you intended.

Example 1 — direct conflict. Policy 1 allows s3:GetObject on arn:aws:s3:::b/*, Policy 2 denies the same action on the same resource → 1 conflict reported.

Example 2 — wildcard guardrail. Policy 1 allows s3:* on a bucket, Policy 2 denies s3:DeleteBucket on the same bucket → reported as a conflict, since the Allow statement’s s3:* pattern covers the Deny statement’s specific action.

Example 3 — no overlap. Policy 1 allows S3 actions, Policy 2 denies an unrelated EC2 action → 0 conflicts.

• Surfaces hidden Deny effects before they show up as unexpected access-denied errors.
• Cross-policy visibility — conflicts between statements in different documents are easy to miss by eye.
• Honest about limits — clearly documents its heuristic instead of overclaiming exhaustive coverage.
• Private — everything stays in your browser.