Vault writes every request to its audit log, including the ones it refuses. Most teams only look at that log after an incident. The assistant reads it every day, groups the denials, decides which ones are a policy gap and which ones look like probing, and only ever proposes a policy change for the first kind.
A stdout audit device makes Vault print one JSON record per request and one per response. Your log collector already ships pod logs to Loki, so the audit trail lands there with no extra agent.
The assistant runs a read-only LogQL query against that stream. It holds no Vault token and cannot change Vault.
Each audit record is parsed as JSON. A denial is a response that
carries permission denied, together with who asked
(the entity and its bound policies), what they asked for (path and
operation) and when.
Records that do not parse are skipped and counted. A failed read never turns into "no denials".
246 denials in two days is usually one misconfigured client, not 246 problems. Denials are clustered by entity and path, with a count, first and last seen, and how many distinct path prefixes the entity was refused on.
A single occurrence is noise. A cluster needs to repeat before it is considered at all.
The classifier is deterministic code, with no LLM involved:
sys/, auth/, the audit device, key-management paths), or the entity is unknown, or it was refused on three or more different prefixes.Probe and ambiguous clusters are never turned into a policy change. They roll into a single audit-denial digest issue per Vault repo, with a cause table that is recomputed on every run, so you get one place to look instead of a new ticket per entity.
Each row says how the denials arrived: a steady rhythm reads as a misconfigured client, a burst reads differently. When there are too few timestamps to support that label, it is withheld and the shortfall is stated.
For a widen cluster with exactly one candidate policy and one
operation, the assistant renders the change against the policy file
in git: it adds the missing capability to an existing
path block, or appends a new block for the denied path.
The rest of the file is left byte for byte as it was.
This path is built and switched on, but has not yet fired on a real production denial, which is why it is marked in development.
Every finding passes one guard before it is emitted. A widen can
never target an escalation surface (sys/,
auth/, identity/, CA and key management),
never grant sudo, never touch an audit device, and
never edit the protected root policy.
If the renderer is unsure about anything, the finding stays an issue.
For each entity the assistant also looks for its successful responses in the same window. "The denials stopped and the service now reads the path" is visible from the issue itself.
That lookup only runs when the entity is a real, unique Vault entity id. A shared login name or IP address would mix up clients, so the lookup is skipped and the issue says so.
09:41:02 request entity=8f2c… orders-api read secret/data/shop/orders-api/db 09:41:02 response entity=8f2c… orders-api read secret/data/shop/orders-api/db 200 09:41:07 request entity=8f2c… orders-api read secret/data/shop/payments/psp-key 09:41:07 response entity=8f2c… orders-api read secret/data/shop/payments/psp-key permission denied 09:43:15 response entity=1a90… ci-deployer update secret/data/platform/ci/token 200 09:51:07 response entity=8f2c… orders-api read secret/data/shop/payments/psp-key permission denied 09:52:40 response entity=— approle list sys/policies/acl permission denied 10:01:07 response entity=8f2c… orders-api read secret/data/shop/payments/psp-key permission denied
{
"type": "response",
"time": "2026-09-18T10:01:07Z",
"auth": {
"entity_id": "8f2c…",
"display_name": "kubernetes-shop-orders-api",
"policies": ["default", "shop-orders-api"]
},
"request": { "operation": "read", "path": "secret/data/shop/payments/psp-key" },
"error": "1 error occurred:\n\t* permission denied\n\n"
}
| entity | path | count | prefixes |
|---|---|---|---|
| orders-api | secret/data/shop/payments/psp-key | 246 | 1 |
| approle (no entity) | sys/policies/acl | 31 | 1 |
| report-job | secret/data/* (5 prefixes) | 58 | 5 |
| billing-worker | secret/data/shop/billing/… | 12 | 2 |
| ci-deployer | secret/data/platform/tmp | 1 | below threshold |
| cause | class | timeline |
|---|---|---|
sys/policies/acl · approle | probe | 31 over 4h, single burst |
| report-job · 5 prefixes | probe | 58 over 2d, ~1 per 50m (steady) |
| billing-worker · 2 prefixes | ambiguous | rate withheld (3 of 12 timestamped) |
path "secret/data/shop/orders-api/*" { capabilities = ["read"] } path "secret/metadata/shop/orders-api/*" { capabilities = ["list"] } + +path "secret/data/shop/payments/psp-key" { + capabilities = ["read"] +}
sys/policies/acl escalation surface · refusedpki/root/sign-intermediate CA management · refusedsudo never renderablesys/audit/* audit device is untouchablesecret/data/shop/payments/psp-key ordinary path · one policy · allowedIllustrative. The widen path is built and enabled but has not yet fired on a real production denial, so this is the shape it takes, not a copy of one it sent.
gitops-ai/vault-widen-shop-orders-api-5b21 into main · 1 file · +4The Vault entity for orders-api (Kubernetes auth, namespace shop) was refused read on secret/data/shop/payments/psp-key 246 times over two days. Its only non-default policy is shop-orders-api, which grants nothing under shop/payments/.
Known entity, one path prefix, one plain operation, no wildcard, not an escalation surface. That is the pattern of a missing grant, not of probing.
The assistant cannot know whether orders-api should read the payment provider key. That is a product decision. Confirm it before merging, or close this MR and fix the client instead.
246 denials over 2d13h, ~1 per 15m (steady). First seen 2026-09-16 21:04Z, last seen 2026-09-19 10:01Z. A steady rhythm like this usually means a client retrying on a schedule.
1,380 successful responses for the same entity in the window, all on secret/data/shop/orders-api/*. None on the denied path.
{namespace="vault"} |= "permission denied" | json
| auth_entity_id="8f2c…" | request_path="secret/data/shop/payments/psp-key"
path "secret/metadata/shop/orders-api/*" {
capabilities = ["list"]
}
+
+path "secret/data/shop/payments/psp-key" {
+ capabilities = ["read"]
+}
sys/, auth/, identity/, an audit device, or CA / key management.read only. No sudo, no new write verb.Diff is a single read grant on one exact path, no wildcard. Grant scope matches the evidence. Merge is a product call on whether the service should hold this key. LGTM on shape.
Vault is a high-blast-radius system. Everything here is deterministic code, with no model in the loop.
sys/, auth/, identity/, audit devices or CA and key management is refused, whatever the evidence says.