TL;DR: Centralised audit and operational telemetry can help teams detect secret reads, policy changes, and seal events while triggering automated response when suspicious behaviour appears, according to Wazuh. The governance issue is that centralised secrets are only as safe as the visibility and response wrapped around them, not the vault itself.
At a glance
What this is: This is a practical guide to monitoring HashiCorp Vault with Wazuh, showing how audit telemetry and active response can surface secret access, policy changes, and seal events.
Why it matters: It matters because centralised secret storage still fails without usable telemetry, alerting, and response around secret reads and admin actions, which is exactly where NHI governance lives.
Context
Vault monitoring is the missing control layer between centralised secret storage and real governance. A vault can hold API keys, tokens, passwords, and certificates, but without audit logging and operational telemetry, teams cannot reliably tell who accessed what, when policy changed, or whether a seal event represents normal administration or suspicious activity.
Wazuh's article focuses on the operational reality of monitoring Vault rather than the vault itself. The issue is not whether a vault exists, but whether secret access becomes observable, searchable, and actionable enough for security teams to detect abuse before it turns into credential exposure or service disruption.
For NHI programmes, this is a familiar pattern: secrets are only governable when lifecycle events and access events are tied to detection and response. The article's value is in showing how audit trails, policy-change monitoring, and active response can turn an otherwise opaque secret store into a monitored identity surface.
Key questions
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: Why do repeated secret reads create a governance risk?
A: Repeated reads can indicate exfiltration even when each individual request is technically authorised. The risk comes from volume, timing, and repetition, because those patterns show credential harvesting rather than normal application use. Security teams need controls that evaluate behaviour, not just individual request validity.
Q: How do security teams know whether vault telemetry is working?
A: Telemetry is working when audit events, operational state changes, and response actions can be correlated into one timeline. If a seal event, a policy change, or a burst of reads cannot be connected to a source identity and a control action, the monitoring design is still incomplete.
Q: What should teams do when a suspicious access event may be legitimate?
A: Validate it against role, location, historical behaviour, and organisational context before taking action. Legitimate travel, a project change, or a restructuring can explain an anomaly. The right response is proportionate review, not automatic accusation or automatic dismissal of the alert.
Technical breakdown
Vault audit logs: who, what, and when
Vault audit logs record each request and response, which gives teams the basic facts needed to reconstruct secret access. Unlike operational logs, audit logs answer who acted, what path was touched, and when the action occurred. That matters because secret abuse often looks like legitimate application traffic until access patterns are assembled over time. In a governed environment, audit logging becomes the evidence layer that connects a credential to a human, workload, or process. Without it, security teams can see that Vault is running but not whether secrets are being used within policy or outside expected behaviour.
Practical implication: treat audit logging as mandatory evidence for secret governance, not as an optional troubleshooting feature.
Operational logs and seal events as control signals
Vault operational logs describe service state, including startup, sealing, unsealing, and cluster changes. These events matter because a sealed vault blocks secret retrieval, while repeated seal or unseal activity can indicate either administration or disruption. In security operations, the signal is not the state change alone but the context around it. If audit telemetry and operational logs are correlated, a seal event can be distinguished from a routine maintenance action, and an unexpected seal can become a containment marker rather than an outage surprise.
Practical implication: correlate service-state events with authentication and access logs so that sealing is visible as both an availability event and a security event.
Active response for suspicious secret access
Active response turns detection into immediate action by automating a containment step when a rule fires. In this article, the example is sealing a Vault cluster after suspicious activity, which demonstrates that response can be tied directly to secret abuse signals such as repeated reads. The technical point is not automation for its own sake. It is that secret access patterns can cross a threshold where human review is too slow to protect the credential estate. The moment detection and control are linked, secret governance becomes time-sensitive rather than purely forensic.
Practical implication: define response triggers for anomalous secret reads before incident pressure forces you to improvise containment.
Threat narrative
Attacker objective: The objective is to read secrets repeatedly enough to exfiltrate sensitive credentials without immediate detection.
- Entry occurs through legitimate Vault access, because the article's test scenario uses a valid user account with read permissions rather than an external exploit.
- Credential abuse follows when repeated reads of the same secret path create a pattern consistent with data exfiltration.
- Impact is the uncontrolled exposure of stored secrets, including passwords and API keys, with the additional possibility of service disruption if sealing is triggered.
- Containment can be forced by automated sealing, which cuts off secret retrieval but also shifts the event into an availability incident.
Breaches seen in the wild
- Azure Key Vault Contributor escalation 2024: Datadog found Azure Key Vault Contributor could add itself to access policies and read every secret, key and certificate in a vault.
- Smithery.ai MCP hosting breach 2025: A Smithery.ai build flaw gave GitGuardian a live fly.io token controlling 3,000+ hosted MCP servers and the API keys their clients sent.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Secret governance is a telemetry problem before it is a storage problem: centralisation does not create control unless access, policy, and service-state events are observable in one place. Vault can store the right things, but governance fails if teams cannot prove who accessed them or whether the access was expected. The practical conclusion is that visibility has to be treated as part of the secret-control design, not as an afterthought.
Seal events are dual-purpose signals, not just availability noise: a sealed vault is both a service-state event and a security boundary event because it blocks secret retrieval. That makes operational telemetry part of identity governance for machine credentials, not just uptime monitoring. Security teams should read seal and unseal activity as a control signal that changes access conditions for every secret inside the vault.
Repeated secret reads are the behavioural marker that matters: a single legitimate request rarely tells you enough, but bursts of read activity expose whether a credential is being used normally or harvested. Identity blast radius: when secret access can be replayed quickly, the exposure is not the vault itself but every downstream service that trusts those credentials. Practitioners should judge secrets by downstream reach, not by storage location alone.
Active response changes the governance question from detection to timing: once automated sealing exists, the issue is whether the rule fires early enough to stop abuse before it spreads. That elevates access telemetry from forensic logging to operational control. The field implication is that secret monitoring is converging with response orchestration, which is where NHI programmes will increasingly be measured.
Auditability is now a requirement for secret trust: a central secrets platform without durable request and response history leaves too much room for silent misuse. Organisations that rely on Vault, or any similar secret store, need to assume that access will be scrutinised after the fact and during an incident. The conclusion is straightforward: if access cannot be reconstructed, it cannot be governed.
From our research library:
- Only 44% of organisations are currently using a dedicated secrets management system, according to the 2024 State of Secrets Management Survey.
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to the Ultimate Guide to NHIs.
- Read next: Secrets Management Buyer's Guide
What this signals
Secret telemetry is now part of identity governance: once secret access can be logged and correlated, the control boundary shifts from storage to observability. That matters because access reviews cannot protect what they cannot see, and incident response cannot contain what it cannot attribute.
Behaviour-based detection is the real differentiator: repeated reads, policy changes, and seal events create a pattern that is more useful than a static inventory of secrets. Teams that still treat vaults as passive stores will miss the operational evidence needed to separate legitimate administration from credential abuse.
Operational response needs a defined containment trigger: if a vault is part of production trust, then active response should be pre-approved for clearly abnormal secret access. Otherwise the monitoring stack produces alerts without an enforceable action path.
For practitioners
- Implement vault audit logging everywhere Enable audit devices for every production vault and keep request and response history durable enough for incident reconstruction. Prioritise paths that hold API keys, tokens, passwords, and certificates.
- Correlate secret access with service-state changes Join audit logs with operational logs so seal, unseal, startup, and cluster-leadership events can be evaluated alongside secret reads and policy updates.
- Define thresholds for suspicious read bursts Create rules that flag repeated reads of the same secret path within a short interval and tie them to an operational response before exfiltration can continue.
- Test active response before incidents Validate that automated sealing or equivalent containment actions work when audit rules detect abnormal access, and confirm the response does not fail silently.
Key takeaways
- Vault centralisation does not remove secret risk unless telemetry makes access, policy changes, and service-state changes visible to security teams.
- Repeated reads of the same secret path are a useful behavioural signal because they can indicate exfiltration rather than ordinary application activity.
- Active response turns vault monitoring into a control mechanism, but it only helps if containment is triggered by well-defined access patterns.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Vault audit gaps make leaked or misused secrets harder to detect. |
| NHI-05 — Overprivileged NHI | Repeated reads and broad access paths reveal excessive secret authority. | |
| NHI-07 — Long-Lived Secrets | Vault holds durable credentials that remain high value until rotated or revoked. | |
| Recommendation — Instrument secret stores to detect exposed credentials and suspicious access patterns quickly. Review secret access scope and remove overbroad permissions from accounts and workloads. Shorten secret lifetimes and revoke credentials that remain valid beyond their business need. | ||
| NIST CSF 2.0 | DE.CM-01 — Monitoring for anomalous events | The article centres on log-based detection of unusual secret access and seal events. |
| Recommendation — Use continuous monitoring to detect abnormal secret access and service-state changes. | ||
| NIST SP 800-53 Rev 5 | AU-2 — Event Logging | Vault audit logs are the evidence source for who did what and when. |
| Recommendation — Log secret access and administrative actions with enough detail to reconstruct incidents. | ||
| MITRE ATT&CK | TA0006;TA0010 — Credential Access; Exfiltration | The test scenario models repeated reads consistent with credential harvesting and exfiltration. |
| Recommendation — Map repeated secret reads to credential access and exfiltration behaviours in detection logic. | ||
Key terms
- Secure Audit Log: A secure audit log records AI activity in enough detail to reconstruct what happened during inference and tool use. For AI systems, that includes prompts, retrieved sources, model versions, and actions taken. It supports investigation, compliance, and control validation when something goes wrong.
- 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.
- Secret Telemetry: Secret telemetry is the operational data generated by secret stores, including access requests, policy changes, and service-state events. It lets teams distinguish routine credential use from abnormal behaviour and is essential for governing machine and service identities that rely on stored secrets.
- 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.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle 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.
Published by the NHIMG editorial team on August 19, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org