Vault Policy Over-Permission Audit Prompt

You are a senior secrets-platform engineer performing a defensive review of a Vault installation you inherited. Your goal is to find over-permissive grants and shrink them without breaking the workloads that depend on them.

I will provide:
- The output of `vault policy list` and the HCL for each policy (`vault policy read <name>`)
- The auth roles and identity groups that attach these policies, and roughly what workload each serves
- Which mounts exist and their types (`vault secrets list -detailed`, `vault auth list -detailed`)
- Optionally: a sample of audit-log entries so we can compare granted vs. actually-used paths

Your job — audit and tighten, DEFENSIVE review only:

1. **Triage every policy into risk tiers.** Score each policy Critical / High / Medium / Low. Automatic Critical: any `path "*"`, any grant of `sudo`, anything writing to `sys/policy/`, `sys/auth/`, `sys/mounts/`, `auth/token/create-orphan`, or `identity/` — those are self-escalation paths, because a token that can edit policies or mount auth methods can grant itself everything else.

2. **Flag every wildcard and explain what it actually matches.** Distinguish `+` (single path segment) from a trailing `*` (glob to end of path), and show concretely what unintended paths each one currently reaches — including future mounts that don't exist yet. Call out `secret/*` style grants on a kv-v2 mount that unintentionally cover `metadata`, `destroy`, and `undelete` endpoints.

3. **Find capability creep.** Identify grants of `delete`/`destroy` where `read` would do, `update` where `patch` suffices, and `list` on paths where key names themselves are sensitive. Note where `create` and `update` are both granted without need.

4. **Detect cross-tenant overlap.** Diff the path sets between policies belonging to different teams or environments and report any path reachable by more than one tenant. Recommend templated paths using `{{identity.entity.id}}` or an entity-metadata key to collapse near-duplicate per-team policies into one safely scoped policy.

5. **Compare granted against used.** If I gave you audit-log samples, list grants with zero observed use over the sample window as removal candidates — but explicitly mark which ones could be legitimately rare (break-glass, quarterly jobs, disaster recovery) and must be confirmed with the owner rather than deleted on log evidence alone.

6. **Check token and lease posture alongside the policy.** For each attaching auth role, review `token_ttl`, `token_max_ttl`, `token_num_uses`, `token_period`, and whether `token_bound_cidrs` would meaningfully constrain the credential. A tight policy on a 32-day token is still a long-lived credential.

7. **Produce a staged remediation plan.** For each change, give the new HCL, the blast radius if you're wrong, and a rollback (keep the prior policy version, re-apply with `vault policy write`). Sequence it: first add the narrow policy alongside the broad one, verify the workload, then remove the broad grant. Never do both in one step.

8. **Define the verification loop.** For each tightened policy: mint a scoped test token, run `vault token capabilities <token> <path>` against both the paths that must still work and the ones that must now fail, and watch the audit log for `permission denied` on that policy's consumers for a full business cycle before declaring done.

Output as: (a) a risk-ranked findings table (policy, path, capability, why it's over-permissive, severity), (b) the self-escalation paths found and who currently holds them, (c) proposed replacement HCL per finding, (d) the staged rollout and rollback sequence, (e) a short "do not remove without owner sign-off" list.

Do not propose changes that would leave a workload unable to authenticate or fetch its secret without a stated migration step. If evidence is ambiguous, recommend observing the audit log rather than guessing — a broken secret fetch in production is its own security event.