Vault writes every request to its audit log, including the requests it refuses. Most teams look at that log only after an incident. The assistant reads it every day. It groups the denials and decides which ones are a policy gap and which look like probing. It proposes a policy change only for the first kind.
A stdout audit device makes Vault print one JSON record per request and one per response. Your log collector already sends pod logs to Loki. So the audit trail lands there with no extra agent.
The assistant runs a read-only LogQL query (a Loki query) against that stream. It holds no Vault token and cannot change Vault.
The assistant parses each audit record as JSON. A denial is a response that
carries permission denied. The record also shows who asked
(the entity and its bound policies), what they asked for (path and
operation) and when.
The assistant skips records that do not parse, and counts them. A failed read never turns into "no denials".
246 denials in about two and a half days is usually one misconfigured client, not 246 problems. The assistant clusters denials by entity and path. Each cluster shows a count, the first and last time seen, and how many distinct path prefixes Vault refused the entity on.
A single occurrence is noise. A cluster must repeat before the assistant considers it.
The classifier is rule-based code. No AI model (LLM) is involved:
sys/, auth/, the audit device, key-management paths). An unknown entity also counts as a probe, and so does a refusal on three or more different prefixes.The assistant never turns probe and ambiguous clusters into a policy change. They roll into a single audit-denial digest issue for each Vault repository. A cause table in the issue is recomputed on every run. So you get one place to look, and not a new issue for each entity.
Each row says how the denials arrived. A steady rhythm suggests a misconfigured client. A burst suggests something else. If there are too few timestamps to support that label, the assistant withholds it and states the shortfall.
Take 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 stays byte for byte as it was.
This path is built and switched on. As of October 2026, it has not fired on a real production denial. That is why it is marked in development.
Every finding passes one guard before the assistant sends it. A widen can
never target an escalation surface (sys/,
auth/, identity/, CA and key management).
It can never grant sudo, touch an audit device or 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. You can see "the denials stopped and the service now reads the path" in the issue itself.
That lookup runs only when the entity is a real, unique Vault entity id. A shared login name or IP address would mix up clients. In that case the assistant skips the lookup, 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 · allowedThis MR is illustrative, and every number on this page comes from one example run. The widen path is built and enabled. As of October 2026, it has not fired on a real production denial. So this is the shape of an MR, not a copy of one the assistant sent.
gitops-ai/vault-widen-shop-orders-api-5b21 into main · 1 file · +4Vault refused the entity for orders-api (Kubernetes auth, namespace shop) read on secret/data/shop/payments/psp-key 246 times in about two and a half days. Its only non-default policy is shop-orders-api. That policy grants nothing under shop/payments/.
The entity is known. There is one path prefix and one plain operation. There is no wildcard, and the path is not an escalation surface. This is the pattern of a missing grant, not of probing.
The assistant cannot know if orders-api should read the payment provider key. That is a product decision. Confirm it before you merge. 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 that a client retries on a schedule.
1,380 successful responses for the same entity in the window, all on secret/data/shop/orders-api/*. None are 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. It has no sudo and no new write verb.The diff is a single read grant on one exact path, with no wildcard. The grant scope matches the evidence. Whether the service should hold this key is a product decision. LGTM on shape.
A mistake in Vault can do a lot of damage. Everything here is rule-based code, with no AI model in the loop.
sys/, auth/, identity/, audit devices or CA and key management, whatever the evidence says.