Wazuh and Vault monitoring: what secret access telemetry changes

At a glance

What this is: This is a how-to analysis of integrating Wazuh with HashiCorp Vault to monitor audit and operational logs, with the key finding that visibility and automated response are essential to prevent secret exposure and service disruption.

Why it matters: It matters because IAM and NHI teams need evidence-based monitoring around privileged secret stores, not just storage centralisation, or policy drift and exfiltration can remain invisible until damage is done.

By the numbers:

• 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded.
• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.
• 44% of NHI tokens are exposed in the wild, being sent or stored over platforms like Teams, Jira tickets, Confluence pages, and code commits.
• 60% of NHIs are being overused, with the same NHI utilised by more than one application, increasing the risk of widespread compromise if exposed.

👉 Read Wazuh's guide to monitoring HashiCorp Vault with Wazuh

Context

Secrets management is only effective when teams can see who accessed a secret, what changed, and whether the system responded to suspicious activity. In a Vault deployment, centralisation reduces sprawl, but it does not remove the need for auditability, policy control, and rapid containment across NHI access paths.

This article focuses on the governance gap between storing secrets centrally and monitoring their use continuously. For IAM and NHI programmes, the practical question is not whether a vault exists, but whether its access, policy, and operational events are visible enough to support detection, investigation, and response.

That starting position is typical for distributed environments that rely on a shared secrets store and layered logging. The operational challenge is common, but the control depth varies widely across organisations.

Key questions

Q: How should security teams implement Vault monitoring for secret access and policy changes?

A: Teams should collect Vault audit logs, parse them into meaningful fields, and alert on request types, secret paths, and actor identity. The goal is not just log retention, but making access patterns searchable, reviewable, and actionable when policy changes or repeated reads suggest misuse.

Q: Why do centralised secrets stores still need active response controls?

A: Centralisation reduces sprawl, but it does not stop misuse after credentials are exposed or abused. Active response gives defenders a way to reduce blast radius quickly, which matters when suspicious access patterns appear faster than manual investigation can keep up.

Q: What breaks when Vault audit logging is not enabled or cannot write?

A: You lose the ability to reconstruct who accessed what, when, and under which policy context. That means investigation, accountability, and detection all weaken at the same time, especially in environments where Vault is the main source of secrets and token issuance.

Q: Who is accountable when automated sealing interrupts Vault availability?

A: The security and platform teams are accountable together because sealing is a governance decision as much as a technical one. Frameworks such as the NIST Cybersecurity Framework and NIST SP 800-53 place responsibility on access control, logging, and incident response discipline.

Technical breakdown

Vault audit logs and operational logs

Vault produces two distinct telemetry streams. Audit logs record every request and response, which gives teams the who, what, and when of secret access and policy changes. Operational logs track service health, sealing, unsealing, cluster leadership, and storage or connectivity failures. Audit logging is not enabled by default, so the visibility needed for forensic review and control validation has to be deliberately turned on and preserved. In practice, these two log types answer different governance questions: access accountability versus service integrity.

Practical implication: enable and retain both audit and operational logs so access review and incident response have evidence to work from.

How Wazuh collects and normalises Vault events

Wazuh uses an agent on the monitored host to collect the Vault audit file and forward it for analysis. The blog then shows custom decoders and rules that distinguish Vault audit entries from operational entries and parse fields such as request operation, auth display name, and request path. That parsing matters because raw logs do not become control evidence until they can be searched, correlated, and alerted on consistently. Without normalisation, even high-value events such as repeated reads or root token use are just text.

Practical implication: map Vault log fields into rule logic so access, deletion, and error events become actionable alerts rather than review backlog.

Active response and automatic sealing

The integration uses Wazuh Active Response to run a sealing action when specific alert thresholds are met. That changes the control model from detection-only to detection plus containment. The blog’s example uses repeated read activity as a trigger, then executes a local script that seals the Vault cluster. Sealing is a blunt control, but in a secrets store it can be the right emergency boundary when exfiltration or misuse is suspected. The key design point is that response is tied to evidence from the same telemetry stream that detects abuse.

Practical implication: predefine containment triggers and test them against safe scenarios so emergency sealing does not become an untested last resort.

Threat narrative

Attacker objective: The objective is to use legitimate Vault access to extract secrets or disrupt secret availability before defenders can intervene.

1. Entry begins with valid Vault credentials and access to a secret path, which is why the article emphasises user authentication, audit logging, and policy-scoped reads.
2. Escalation appears as repeated reads, forbidden lookups, or suspicious activity that suggests abuse of legitimate NHI access rather than infrastructure compromise.
3. Impact is secret exposure or service disruption, and the article’s response model shows how automated sealing can stop further reads once suspicious behaviour is detected.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Vault monitoring is an NHI governance problem, not just an observability problem. A secrets vault is itself a non-human identity control surface because it brokers access to credentials, tokens, and certificates. Once access is centralised, the question becomes whether policy changes, read behaviour, and sealing events are visible enough to support lifecycle governance. The practitioner implication is that vault telemetry must be treated as identity evidence, not just operational noise.

Continuous auditability is the control boundary that separates storage from governance. Centralising secrets without audit trails creates a false sense of control because the sensitive event is not secret storage, it is secret use. The article’s emphasis on audit logs, request attribution, and response logging shows the right pattern: if you cannot reconstruct access, you cannot govern it. The implication is that access accountability must be built into the secrets platform from day one.

Automated containment is justified when repeated secret access becomes the symptom, not the cause. Wazuh’s sealing response illustrates a broader NHI principle: once a vault begins to show signs of exfiltration or policy abuse, the control objective shifts from perfect diagnosis to blast-radius reduction. That aligns with OWASP Non-Human Identity Top 10 thinking around secret sprawl and access misuse. The implication is that teams should design for fast containment, not rely on after-the-fact investigation alone.

Secret store overexposure is a lifecycle failure when read access outlives need. The article’s test case with a read-only user still demonstrates how even narrowly scoped access can become risky when usage becomes repetitive, unreviewed, or opaque. That is where identity lifecycle controls matter most: provisioning, review, and revocation need to follow actual access behaviour. The implication is that secrets governance must be tied to active use, not static role assignment.

From our research:

• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation, according to The State of Secrets Sprawl 2026.
• Our research also shows that 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded.
• For a broader control model, see Guide to the Secret Sprawl Challenge for the lifecycle issues that make detection-only approaches fail.

What this signals

Secret monitoring is becoming a lifecycle discipline, not a logging exercise. Once Vault access is treated as identity evidence, teams have to connect detection to offboarding, policy review, and revocation workflows. That is the same governance shift seen across NHI programmes where standing access and hidden usage create more risk than the vault architecture itself.

With 64% of valid leaked secrets still exploitable today, detection gaps are now operational risks, not theoretical ones, and that changes how teams should budget for response automation. The practical signal is that monitoring without containment will continue to underperform across OWASP Non-Human Identity Top 10 control areas.

Identity blast radius: the useful metric is no longer how many secrets a vault stores, but how quickly the organisation can detect misuse and cut off access. Teams that cannot do both should treat their vault telemetry as incomplete.

For practitioners

• Enable Vault audit logging before production use Turn on audit devices, preserve logs outside the vault host, and verify that request, response, and policy-change events are captured with usable identity context.
• Normalise Vault events into alertable identity fields Map request.operation, auth.display_name, and request.path into rules so repeated reads, root usage, and policy updates can be correlated quickly.
• Test automated sealing as a containment control Run controlled exercises that validate the sealing script, the alert thresholds, and the service recovery path after a suspicious access pattern is detected.
• Review read-only access as a governance risk Recheck service and user accounts that can read sensitive secret paths, then tie those permissions to explicit business need and revocation triggers.

Key takeaways

• Vault monitoring matters because centralised secrets are only safe when audit, policy, and operational events are visible enough to govern access.
• Repeated reads and root token usage are strong indicators that detection alone is insufficient without automated containment.
• The control that changes outcomes here is a combination of audit logging, normalised alerting, and tested active response.

Key terms

• Audit Logs: Audit logs are time-stamped records of identity and access events. In enterprise SSO, they provide the evidence needed to review who authenticated, when provisioning changed, and whether access paths behaved as expected during compliance checks or incident investigations.
• Active Response: An automated security action triggered by an alert or rule match. In endpoint contexts, it can isolate, uninstall, terminate, or quarantine a threat or policy violation, but it is only effective when the triggering logic and verification steps are tightly governed.
• Vault Sealing: A Vault state in which secret retrieval is blocked until the system is unsealed again. It is a high-impact containment mechanism used when the integrity or exposure of the secrets store is uncertain, and it must be governed carefully because availability stops with access.
• Secrets Store Telemetry: The logs and event fields that describe how a secrets platform is used, including authentication, policy updates, read activity, and operational health. It becomes security evidence only when it is normalised, retained, and mapped to alerting and review workflows.

What's in the full article

Wazuh's full post covers the operational detail this post intentionally leaves for the source:

• Step-by-step Vault audit device configuration for file-based logging and prefixing.
• Custom decoder and rule files for parsing Vault audit and operational events in Wazuh.
• Active Response script wiring for automated sealing when suspicious access patterns are detected.
• Hands-on test commands that generate sample reads, denials, and exfiltration-like activity.

👉 The full Wazuh post covers the decoder, rule, and active response setup in detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.