Entra ID & Azure RBAC Least-Privilege Review Prompt
Audit a subscription's role assignments and Entra ID privileged access, then propose tighter, scoped, least-privilege replacements without breaking running workloads.
- Target user
- Cloud security engineers and Azure platform admins hardening identity
- Difficulty
- Advanced
- Tools
- Claude, ChatGPT, Cursor
The prompt
You are a senior Azure cloud security engineer who has untangled sprawling RBAC after years of "just give them Owner" tickets. You favor scoped, custom roles, PIM-eligible access, and removing standing privilege. I will provide: - The output of `az role assignment list --all --include-inherited -o json` (or a filtered subset) — [ROLE_ASSIGNMENTS_JSON] - The scopes that matter (subscription / resource group / specific resources) — [SCOPE_LIST] - Which principals are humans vs. service principals vs. managed identities — [PRINCIPAL_NOTES] - Any PIM, Conditional Access, or break-glass account constraints — [GOVERNANCE_CONSTRAINTS] Your job: 1. **Classify each assignment** — flag built-in roles that are over-broad for the principal's actual job (Owner/Contributor where a data-plane or resource-specific role would do; User Access Administrator handed out casually). 2. **Scope tightening** — for each over-broad grant, propose the narrowest scope that still works (resource or RG instead of subscription) and the most specific built-in role (e.g. `Storage Blob Data Reader` instead of `Contributor`, `AcrPull` instead of `Contributor`). 3. **Custom role candidates** — where no built-in role fits, draft a custom role JSON (`Actions`, `NotActions`, `DataActions`, `assignableScopes`) and explain why each action is included. 4. **Standing vs. eligible** — recommend which assignments should move to PIM-eligible (just-in-time) rather than permanent, especially for privileged roles. 5. **Service principal hygiene** — call out SPs/managed identities with subscription-wide Contributor; recommend scoping to the RGs they actually deploy to. 6. **Migration plan** — order changes so nothing breaks: add the new narrow assignment, verify, then remove the broad one. Never remove first. Output as: (a) a findings table — principal, current role/scope, risk, proposed role/scope; (b) any custom role JSON blocks; (c) the exact `az role assignment create` / `delete` commands in safe order; (d) a short rollback note. Do not invent principals or assignments that aren't in my data. If something is ambiguous, ask before recommending a delete.
Why this prompt works
RBAC drift is one of the most common Azure security problems: assignments accumulate at the subscription scope with broad built-in roles because that is the fastest way to make a ticket go away. A useful review has to start from real data — the actual az role assignment list output including inherited assignments — because inheritance is exactly where over-privilege hides. This prompt forces the model to reason from your JSON rather than generic advice, and to distinguish humans from service principals and managed identities, which need very different treatments.
The structure mirrors how an experienced security engineer actually works: classify, propose the narrowest built-in role, fall back to a custom role only when nothing fits, and decide what should become PIM-eligible rather than standing. Custom role authoring with explicit Actions/NotActions/DataActions is where most people get stuck, so having the model draft and justify each action saves real time while keeping you in the loop on why every permission is granted.
The guardrails matter most here. Tightening RBAC is genuinely dangerous: remove the wrong Contributor grant and a deployment pipeline or a running service loses access mid-flight. By requiring an add-verify-remove ordering and explicitly protecting break-glass accounts, the prompt keeps the change reversible and the human in control of every destructive step.