Automating Vault Monitoring and Audit with an AI Security Agent

Your Vault has an audit device and every request is logged — so who actually read that log this week? In most teams the honest answer is "nobody, unless something already broke," which makes the vault monitoring control on your compliance checklist a compliance artifact instead. Token hygiene decays the same way: the accessor sweep you ran last month was accurate last month. Since then, CI has minted thousands of tokens, someone attached a quick secret/* policy to unblock a deploy, and none of it will surface until an engineer next volunteers an afternoon.

That gap is what this final part of our Vault security audit series is about. Part one mapped the seven signals that matter — seal status and HA health, token sprawl, wildcard policies, silent audit devices, and the KV read patterns that suggest a leaked credential. Part two walked the same ground with native tools only: accessor sweeps, policy reviews, audit-log queries with jq, and the sys endpoints. Both stop at the same wall — every finding is a snapshot that starts decaying the moment it's written down.

This article covers the standing-watch alternative with Olivier, CloudThinker's security agent: how the connection works (read-only, about five minutes), what Olivier watches continuously, what a first audit of a typical mid-market Vault surfaces, and — because this is a secrets store — exactly what the agent will not do without your approval.

Connecting: a read-only token, about five minutes

Olivier connects to Vault the way you would want any third party to: with a dedicated policy you can read in full before you mint the token. The baseline policy is read/list only — health and seal status, auth method and policy listings, and token accessor enumeration:

# cloudthinker-auditor policy — read-only baseline
path "sys/health"          { capabilities = ["read"] }
path "sys/seal-status"     { capabilities = ["read"] }
path "sys/auth"            { capabilities = ["read"] }
path "sys/policies/acl"    { capabilities = ["list"] }
path "sys/policies/acl/*"  { capabilities = ["read"] }

# These two endpoints require sudo in Vault itself —
# scoped here to list/read only, no write paths
path "sys/audit"               { capabilities = ["read", "sudo"] }
path "auth/token/accessors"    { capabilities = ["list", "sudo"] }

Two notes worth making to your security reviewer. First, sys/audit and auth/token/accessors are sudo-protected endpoints in Vault — there is no way to list audit devices or token accessors without it, so the policy grants sudo on exactly those two read paths and nothing else. Second, the policy contains no KV data paths: Olivier audits metadata and access patterns, not your secret values. You create the policy, issue a token against it (periodic, so it renews rather than living forever — practice what part one preached), and paste it into the Vault connection guide. First scan starts immediately.

What Olivier watches continuously

The checks are the ones from parts one and two — the difference is that they run on a schedule measured in minutes, not quarters:

• Seal status and HA health. Continuous polling of sys/health and sys/seal-status across nodes. A standby that stopped standing by, or a node that came back sealed after a restart, is a finding within minutes — not a discovery during your next failover.
• Token sprawl. Accessor sweeps that flag tokens with no TTL, orphan tokens whose creator is gone, root tokens that outlived the break-glass moment they were created for, and creation-rate spikes from a single auth role.
• Policy anti-patterns. Every policy diffed on change, with alerts on wildcard data paths (secret/*), broad sudo grants, and policies that quietly widened between two points in time — the drift that part two warned lands silently between manual audits.
• Audit-device gaps. Whether an audit device exists at all, whether it is still writing, and whether log volume dropped in a way that suggests rotation ate your trail. Vault blocks requests if its only audit device fails — Olivier flags single-device setups before that becomes your outage.
• Anomalous KV read patterns. Baselines per auth role and entity: which paths, how many, when. A service account that normally reads 40 paths a day and suddenly enumerates 2,000 in an hour looks exactly like a leaked credential being harvested, and it gets flagged as such.
• Lease and TTL hygiene. Long-tail leases, auth mounts with default TTLs never tightened, and dynamic-secrets engines whose max TTL makes "dynamic" a polite fiction.

Each finding arrives with its evidence — the accessor list, the policy diff, the read-pattern baseline versus the spike — so you verify rather than trust.

Graduated autonomy: nothing is revoked without you

An agent with visibility into your secrets infrastructure earns skepticism, so the control model is explicit. Every action class gets an autonomy level you set per environment:

• Notify — Olivier reports the finding. Nothing else. This is the default for everything, and for a secrets store it is where most teams stay longest.
• Suggest — the finding arrives with a specific proposed remediation: the exact vault token revoke -accessor command, the tightened policy HCL, the audit-device configuration.
• Approve — Olivier stages the action and executes only after a named human approves it in the queue. Revoking 300 orphan CI tokens becomes one reviewed click instead of a scripted afternoon.
• Autonomous — reserved, deliberately, for narrow and reversible actions in non-production, and only after weeks of watching the agent be right at the Approve level.

The line that matters: no token is revoked, no policy is changed, no audit device is touched without an approval under whatever autonomy level you configured — and the read-only baseline policy cannot perform those actions at all until you explicitly widen it. Every proposal and every executed action lands in an audit trail with its evidence and its approver. Which answers the question this article opened with: now something reads the audit log continuously, and the humans read the findings.

What a first audit typically surfaces

Illustrative composite of first-scan results on a mid-market Vault — one HA cluster, a few dozen engineers, a few hundred workloads. Yours will differ:

Notice the shape. Nothing here is exotic — every row is detectable with the part-two commands, and the root token and the read anomaly are the kind of thing a manual quarterly audit finds three months late or not at all. The value is not cleverness; it is that this table refreshes daily and each row arrives with an approval-gated fix attached.

Prompts to try in your first session

Olivier is conversational — you ask in plain language and get answers backed by the same endpoints you used manually:

"List all tokens without an expiry, grouped by the auth method and role that created them, oldest first."

"Which policies grant write or delete on wildcard KV paths? Show me each policy's HCL and every entity it's attached to."

"Baseline KV read activity per AppRole over the last 30 days and flag anything reading more than three times its normal path count."

"Stage a revocation for the orphan tokens from the retired CI runner — I want to review the accessor list before anything happens."

That last prompt is the model in miniature: the agent does the sweep, builds the plan, and stops at the line you drew.

What Olivier will not do

Stated plainly, because "AI agent connected to Vault" should trigger exactly these questions:

• It cannot read your secret values. The connection policy has no KV data paths. Audits run on metadata, configuration, and access patterns.
• It revokes and changes nothing without approval. Read-only baseline policy, Notify-by-default autonomy, and an approval queue for anything above it.
• It does not bypass your unseal process, touch seal configuration, or hold unseal keys. Seal status is observed, never operated.
• It does not decide governance questions. It will show you that a policy grants sudo on sys/*; whether that team should have it remains your call.

If you did the part-two audit by hand, the right mental model is: that audit, running continuously, with a remediation queue attached — not an autopilot with your unseal keys.

From quarterly sweep to standing control

Part one told you what bad looks like. Part two proved you can find all of it with the CLI — once, at the cost of an afternoon, with the findings decaying immediately. The remaining problem is cadence, and cadence is an automation problem. Teams that move token and policy hygiene from periodic sweeps to continuous, approval-gated review typically catch drift in hours instead of quarters, and walk into their next compliance audit with the evidence already collected.

Try CloudThinker free — 100 premium credits, no card required — and follow the Vault connection guide to see your own first findings table within the hour.