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 last part of the 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 part covers the standing-watch alternative with CloudThinker for security teams: how the connection works (read-only, about five minutes), what it watches, how it investigates a suspicious read pattern, what a first audit of a typical mid-market Vault surfaces, and, because this is a secrets store, exactly what it won't do without your approval.

---

Why a sweep isn't an investigation

Part two's sweeps are worth having. They tell you that an AppRole read 41 distinct KV paths yesterday against a usual four. Then the real work starts, and none of it is in the sweep. Is it a leaked secret ID being used from somewhere new? A release that started reading more config? A client whose cache broke after an SDK upgrade? Each answer means something different: rotate everything the role read, do nothing, or file a bug.

A script can't make that call, because the next check depends on the last answer. If the source addresses are all known pods, you go look at deploy times. If they aren't, you look for list operations before the reads. That branching is why audit-log review gets done in batches, late, by whoever has time. And it's the part CloudThinker takes on.

---

Connecting: a read-only policy, about five minutes

01Secrets store

Vault

• Health and sealsys/health, sys/seal-status
• Tokensauth/token/accessors, lookup by accessor
• Policies and authsys/policies/acl, sys/auth
• Audit trailsys/audit, plus the store you ship logs to

No KV data paths granted

02Investigation

CloudThinker

• SweepTokens, policies, devices, leases
• BaselineRead patterns per role and entity
• InvestigateAddresses, list operations, deploys
• ProposeRevocation, narrowed HCL, device config

Read-only by default

03Where the team works

Chat and tickets

• Slack or TeamsFindings and approvals in the thread
• PagerDutyPages only on a likely leak
• JiraHygiene fixes with evidence attached

Same channels, better input

CloudThinker connects to Vault the way you'd want any third party to: with a dedicated policy you can read in full before you mint the token. The baseline is read and list only, covering health and seal status, auth method and policy listings, and token accessor lookups:

# 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 and read only, no write paths.
path "sys/audit"               { capabilities = ["read", "sudo"] }
path "auth/token/accessors"    { capabilities = ["list", "sudo"] }

# Token lookup by accessor is a POST, so Vault calls it "update".
# It returns metadata only and cannot change the token.
path "auth/token/lookup-accessor" { capabilities = ["update"] }

Three notes for your security reviewer. First, sys/audit and auth/token/accessors are sudo-protected endpoints in Vault. There's 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, lookup-accessor needs the update capability because it's a POST, but it only returns metadata. Third, the policy contains no KV data paths. CloudThinker audits metadata and access patterns, never your secret values.

You create the policy and issue a token against it. Make it a periodic token, so it renews instead of living forever (practice what part one preached). Paste it in following the Vault connection guide and the first scan starts. KV access baselines come from the audit log, so if you ship it to a log store, connect that store too.

---

What it 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. 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 instead of 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 findings on wildcard data paths (secret/*), broad sudo grants, and policies that quietly widened between two points in time. That's the drift part two warned lands silently between manual audits.
• Audit-device gaps. Whether an audit device exists at all, whether it's 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, so single-device setups get flagged before that becomes your outage.
• Unusual 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 investigated as one.
• 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 baseline next to the spike) so you can check it rather than trust it.

---

One read spike, end to end

01Signal

Read spike

One AppRole reads far more distinct paths than its baseline.

02Readings

Hypotheses

Leaked credential, new release, or a client bug.

03Evidence

Check each

Source addresses, list operations, deploy times, path counts.

04Output

Finding

The reading the evidence supports and the proposed response.

05Close

Verify

Confirms the revocation held and the pattern stopped.

Here's a typical case. At 01:52 the reporting-etl AppRole, which reads about 40 KV paths a day, reads 1,900 distinct paths under secret/data/ in 50 minutes.

1. Name the readings. A leaked secret ID being used to harvest secrets. A new release that walks a whole config tree. Or a client bug looping over a list it should have cached. Each predicts different evidence, so CloudThinker checks rather than guesses.

2. Check source addresses. It pulls the role's requests from the audit log for the window and groups them by request.remote_address. The usual ETL runs from three pod addresses inside the cluster CIDR. Tonight, 1,850 of the reads came from one address outside it. That weakens the release reading straight away, because a release would run from the same pods.

3. Check for enumeration. Before the reads, the same address issued 212 list operations against secret/metadata/, walking the mount one level at a time. A buggy client re-reads known paths. It doesn't map the tree first. The client-bug reading is out.

4. Check for a change. No deploy of reporting-etl in the last 48 hours, and no change to its role or policy. Nothing on the legitimate side explains the spike.

5. Write the finding. The thread gets one message: likely leaked secret ID for reporting-etl, used from an unknown address, with the list-then-read sequence, the address, the paths read, and links to the audit entries. The proposal: destroy the role's outstanding secret IDs, revoke tokens issued from them, rotate the secrets on the 1,900 paths in priority order, and page security because this is an incident, not hygiene.

Each of those writes is a proposal until you approve it. Paging the on-call doesn't; it's the existing escalation path, just with the investigation attached. Once the revocation is approved and applied, CloudThinker watches the role and confirms that requests from the unknown address now fail and the pattern has stopped.

---

Nothing is revoked without you

An agent with visibility into your secrets infrastructure earns skepticism, so the control model is explicit. CloudThinker acts within Auto Mode, so you decide what runs on its own and what waits for approval.

The line that matters: no token is revoked, no policy is changed and no audit device is touched outside what you've allowed. On top of that, the read-only baseline policy can't perform those actions at all until you explicitly widen it. Two independent gates: Vault's own policy, and Auto Mode. Every proposal and every executed action lands in an audit trail with its evidence and its approver. That answers the question this post opened with: now something reads the audit log continuously, and people read the findings.

---

What a first audit typically surfaces

An 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.

Look at 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 cadence: the table refreshes daily, and each row arrives with a fix that waits for your approval.

---

Why this beats the traditional approach

The deeper difference is the shape of the work. A sweep answers "what does the cluster look like today?" The risk in Vault lives in "what changed, and is it someone we know?" That question branches on every answer, and it's the part that used to wait for a free afternoon.

---

Getting started

Three steps. None needs write access on day one.

1. Create the read-only policy and a periodic token. Use the HCL above, or the version in the Vault connection guide, and paste the token into CloudThinker.

2. Run a read-only audit. Nothing changes in Vault. Ask from chat:

"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. Propose only, change nothing."

3. Stage the first cleanup.

"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: CloudThinker does the sweep, builds the plan, and stops at the line you drew.

---

What it won't do

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

• It can't 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. A read-only baseline policy, and Auto Mode deciding which writes wait for your approval in chat.
• It doesn't touch your unseal process. It doesn't hold unseal keys or change seal configuration. Seal status is observed, never operated.
• It doesn't decide governance questions. It will show you that a policy grants sudo on sys/*. Whether that team should have it is 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. It's not an autopilot with your unseal keys.

---

Related reading

• Part one: the 7 Vault security signals that actually matter
• Part two: auditing Vault with native tools only
• Auto Mode: you decide what runs on its own
• CloudThinker for security teams

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 right away. What's left is cadence and judgment, and both can run continuously. 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 with 100 premium credits and no card required, and follow the Vault connection guide to see your own first findings table within the hour.