Key Vault Access & Secret-Rotation Review Prompt
Review a Key Vault's access model and secret lifecycle, then propose tighter access, rotation, and monitoring without breaking the apps that depend on it.
- Target user
- Cloud security engineers and platform teams managing Azure Key Vault
- Difficulty
- Advanced
- Tools
- Claude, ChatGPT, Cursor
The prompt
You are a senior Azure security engineer who treats Key Vault as a controlled boundary: RBAC over access policies, managed identities over connection strings, rotation over static secrets, and full audit logging. I will provide: - The vault's permission model — access policies or Azure RBAC, and the assignments — `az keyvault show` / role assignments — [PERMISSION_MODEL] - Network config — public access, firewall, private endpoint, trusted services — [NETWORK_CONFIG] - What's stored and who consumes it — secrets/keys/certs and the apps/identities reading them — [CONSUMERS] - Rotation state — which secrets rotate, how, and which are static/old — [ROTATION_STATE] - Any diagnostic/logging setup (AuditEvent to Log Analytics) — [LOGGING] Your job: 1. **Access model** — if still on legacy access policies, recommend moving to Azure RBAC (data-plane roles: Key Vault Secrets User, Crypto User, Certificates Officer) and explain the migration risk. Flag any principal with broad data-plane access it doesn't need. 2. **Identity over secrets** — for each consumer, recommend managed identity + RBAC instead of storing/reading a static credential. Identify secrets that exist only because something didn't use a managed identity. 3. **Network exposure** — if public access is open, recommend private endpoint or firewall with selected networks + trusted services; note what could break (CI runners, app outbound IPs). 4. **Rotation** — for each secret/key, recommend rotation (Key Vault rotation policy for keys, event-grid-driven rotation for secrets), and call out long-lived static secrets that should rotate. 5. **Monitoring** — ensure AuditEvent diagnostics flow to Log Analytics and propose a KQL alert for unusual secret access. 6. **Safe ordering** — sequence changes so consumers keep working: grant new access, switch the app, then revoke old. Output as: (a) findings table — area, current state, risk, recommendation; (b) the exact `az` commands in safe order; (c) a rotation plan per secret; (d) a sample KQL alert; (e) a rollback note. Use only the vault config I provided. Don't assume a private endpoint or RBAC mode that isn't shown — ask.
Why this prompt works
Key Vault reviews fail when they treat the vault as a checklist instead of a live dependency. The most consequential change — moving from legacy access policies to the Azure RBAC permission model — alters how every single access decision is made, and doing it carelessly breaks app startup across the board. This prompt makes that migration risk explicit and forces a grant-verify-revoke ordering, because the whole point of a review is to tighten security without causing an outage.
It also pushes the right architectural direction rather than cosmetic fixes. The biggest win is usually eliminating static secrets entirely by having consumers authenticate with managed identities and the appropriate data-plane RBAC role, so the prompt asks the model to identify which stored secrets exist only because something skipped managed identity. Layered on top are network exposure (private endpoint or firewall with trusted services), real rotation policies, and AuditEvent logging with a KQL alert for anomalous access — the controls that make a vault genuinely defensible.
The guardrails target the two ways these reviews cause incidents: flipping the permission model before equivalent RBAC is in place, and locking network access without first enumerating every consumer, including the CI/CD agents that everyone forgets. By sequencing changes and keeping a rollback, the prompt keeps the human in control of a boundary that, if mishandled, takes down everything depending on it.