Most teams set up Vault in the UI or with one-off CLI calls. A few go further. They declare policies, auth roles and secret engines in a repository that CI applies. That is already beyond what most teams automate. The assistant reads that repository every day. It flags the grants that a careful reviewer would stop. A planned next step is to keep the repository in step with the Kubernetes workloads that use it.
Policies live under policies/ and auth roles under
roles/. Auth methods and secret engines sit
next to them. A pipeline plans on every MR. It applies on
the default branch, with a short-lived token from your own CI.
The assistant never applies anything. It reads the repository like any other reviewer. It proposes changes through the same MRs your team uses.
Vault policies are flat. Each has a path and a list of
capabilities. The assistant parses them with a focused,
dependency-free reader. The reader copes with either brace style. It also loads the role JSON, so every later check works on structure, not on
text matching.
On a real Vault setup with 14 policies and 4 roles, this reader and the rules below produced zero findings. That clean baseline is the point. The assistant speaks only when something is actually wrong.
sudo on an escalation surface.
The assistant flags a grant that gives sudo, or
create / update / delete, on a
path that controls Vault itself:
*, sys/*, auth/*sys/, auth/, identity/pki/, transit/, ssh/A companion check catches broad read/list access on those same wildcard surfaces.
A service that issues certificates needs update on
pki/issue/<role>. That grant has the right scope.
It is not a finding. So the check fires on everything under the
consumer engines except a curated list of consumer leaves.
These leaves are issue, sign, encrypt, decrypt, creds, and the public read endpoints.
Anything not on that list keeps firing. This includes management verbs that nobody thought to list. Key export and verbatim signing stay off the list on purpose.
An auth role lists the policies that its tokens receive. If one of them is
missing from policies/, the role mints tokens bound to
nothing. Today that does nothing and gives no warning. The day someone creates a
policy with that name, it becomes an unreviewed grant.
Each finding says which file, which path and which capability. It also says how much of the policy it concerns. It passes the same fail-closed safety layer as the audit story. The assistant never flags or edits the protected root policy. It never proposes anything that touches an audit device.
Lint findings are issue-only. The audit-driven policy widen from the previous story can open draft MRs against this repository. That path is in development. It is switched on, but as of October 2026 it has not fired on a real production denial.
Planned: join the Vault repository to the cluster side. Take each ExternalSecret or agent-injected path. The policy that
its ServiceAccount gets through a Kubernetes auth role should allow that read.
Every role should also point at a ServiceAccount and namespace that still
exist.
Today the assistant sees Vault on the cluster side only as an External Secrets backend. So this join is not built yet.
The assistant could use a read-only Vault token (list and read on policies, auth methods and mounts). It could then flag policies, roles or engines that exist in Vault but not in git. This is the classic "someone fixed it in the UI" drift. It needs a token that an operator provides, and it is not built yet.
policies/ 14 files · HCL shop-orders-api.hcl payments-worker.hcl pki-issuer.hcl … roles/ auth roles · JSON kubernetes-shop.json approle-ci.json … auth/ kubernetes · approle · oidc engines/ kv-v2 · pki · transit .gitlab-ci.yml plan on MR · apply on main
path "secret/data/shop/payments/*" { capabilities = ["read"] } path "transit/encrypt/payments" { capabilities = ["update"] }
path "pki/issue/shop-internal" { capabilities = ["update"] } path "pki/root/*" { capabilities = ["create", "update", "sudo"] } path "sys/mounts" { capabilities = ["read"] }
{
"bound_service_account_names": ["orders-api"],
"bound_service_account_namespaces": ["shop"],
"token_policies": ["shop-orders-api", "shop-orders-api-v2"]
}
This example is illustrative. Static-lint findings are issue-only today. A Vault capability change needs a person to decide the intent. This is the shape of the issue the assistant writes.
acme/vault-config · policies/pki-issuer.hcl · 1 of 3 pathsPolicy pki-issuer grants create, update and sudo on pki/root/*. That subtree manages the root CA. It can generate, import and replace it. Any token with this policy can mint a new root for the whole PKI engine.
The assistant flags 1 of 3 paths in this policy. pki/issue/shop-internal (issuing leaf certificates) is a least-privilege consumer path. The assistant does not flag it.
| Path | Capabilities | Verdict |
|---|---|---|
pki/issue/shop-internal | update | consumer leaf, exempt |
pki/root/* | create, update, sudo | sudo_grant on CA management |
sys/mounts | read | read on an exact path, no finding |
Roles binding this policy: approle-ci.
If the CI role only issues certificates, drop the root block:
path "pki/issue/shop-internal" {
capabilities = ["update"]
}
-path "pki/root/*" {
- capabilities = ["create", "update", "sudo"]
-}
If you really need root rotation, move it to a separate policy. Bind that policy only to the operator identity that performs rotations.
Removing a capability can break a job that depends on it. Only you know if the CI role rotates the root CA. The assistant files the evidence. The suggested change in this example is the kind of fix to consider. The decision stays with you.
On the roadmap: turn lint findings into draft MRs where the narrowing is provably unused. That means no successful request on that path in the audit window.
Precision matters more than coverage here. A wrong Vault finding teaches people to ignore the next one.
sudo.