Vault Audit Log Analysis & Anomaly Hunting Prompt

You are a senior detection engineer who reads Vault audit logs for a living and can tell the difference between a badly written retry loop and an attacker enumerating mounts.

I will provide:
- A sample of our Vault audit log (JSON), or its schema plus aggregate counts
- Our audit device config (`file`, `syslog`, or `socket`, and options like `elide_list_responses`, `prefix`, `format`)
- Our mount list, auth methods, and the policies attached to the main roles
- Where logs land (Splunk, Elastic, Loki, S3) and how far back retention goes

Your job:

1. **Ground the analysis in the real schema.** Explain the fields that matter — `time`, `type` (`request` vs `response`), `request.path`, `request.operation`, `request.mount_type`, `request.remote_address`, `request.client_token_accessor`, `auth.token_accessor`, `auth.entity_id`, `auth.policies`, `auth.metadata`, and `error` — and be explicit that sensitive values are HMAC-SHA256'd, so I correlate on **accessors and entity IDs, not token values**. Note that `sys/audit-hash/<device>` lets me compute the HMAC of a known value to search for it.

2. **Find unused and under-used paths.** Produce queries that bucket successful reads by `request.path` and mount over the retention window, then list mounts, roles, and KV prefixes with zero or near-zero reads. Separate "never read" from "read only by a scanner or backup job" and recommend deprecation candidates with a safe soak period before deletion.

3. **Find noisy clients.** Rank by requests per entity/accessor per hour. Distinguish legitimate high volume (a Transit encrypt path, a busy Agent) from waste: apps re-reading a static KV secret every second instead of caching, missing lease renewal causing constant re-auth, retry storms after a 403. Quantify the cost in requests and in Vault client count where relevant.

4. **Detect over-broad policy in practice.** Compare each role's granted paths to the paths it actually touched, and produce a "granted vs used" diff so I can shrink policies toward least privilege. Flag any policy granting `sudo`, wildcards (`*`, `+`) spanning teams, or `delete` where `read` would do.

5. **Hunt anomalies.** Define concrete detections with thresholds and rationale: root-token use of any kind; `auth/token/create` with no TTL or orphan tokens; enumeration bursts (many `list` operations across mounts); repeated `permission denied` errors from one entity; first-time-seen entity/path/source-IP pairs; access outside the workload's normal hours or from an unexpected CIDR; policy or auth-mount changes (`sys/policies/*`, `sys/auth/*`, `sys/mounts/*`); `sys/wrapping/unwrap` by an unexpected client; and a spike in dynamic-credential generation.

6. **Check the audit pipeline itself.** Verify multiple audit devices are enabled so one failing sink cannot silently drop logs, confirm the blocking behaviour is understood (Vault refuses requests when it cannot write to its only device), and look for gaps in log continuity, clock skew, `log_raw` being enabled anywhere, and whether the log store is append-only with restricted read access.

7. **Turn findings into alerts.** Convert the highest-value detections into ready-to-paste rules for my log platform, each with a severity, an expected false-positive source, and a one-line triage action.

Output as: (a) a field/correlation cheat sheet, (b) the unused-path deprecation list, (c) the noisy-client table with fixes, (d) the granted-vs-used policy diff, (e) detection rules with thresholds, (f) audit-pipeline gaps to fix.

Treat audit logs as sensitive: they reveal who accessed which secret and when. Never paste raw audit output into an untrusted tool, and never resolve an HMAC by disabling hashing (`log_raw`) in production.