Vault-sourced credentials on the wire change NHI runtime risk

At a glance

What this is: This is an analysis of on-the-wire credential injection for Vault/OpenBao-sourced NHI access, with the key finding that secrets can be consumed by workloads without ever appearing in user space.

Why it matters: It matters because IAM, PAM, and NHI teams need to decide whether runtime secret exposure is a solvable delivery problem or a governance assumption that must be redesigned around kernel-level enforcement.

👉 Read Riptides's analysis of Vault-sourced credential injection for AI and cloud APIs

Context

Vault-sourced credential injection removes a familiar failure point in non-human identity governance: the workload no longer needs to materialize a secret before it can authenticate to an external API. In this model, Vault or OpenBao remains the authority for short-lived credentials, but the access path is enforced at request time rather than inside the application.

That matters for NHI programmes because the usual controls around files, environment variables, SDK wrappers, and secret stores only reduce exposure if the credential ever reaches the workload. When enforcement moves into the kernel, the governance question changes from secret storage to identity-bound egress control and lifecycle handling for the underlying workload identity.

Key questions

Q: How should teams reduce secret exposure for workloads that call external APIs?

A: Use a model where the workload never receives a reusable secret object in user space. Bind identity to the workload, keep the issuer authoritative, and inject the credential only at request time so files, environment variables, and logs do not become exposure points. That is most effective when egress policy, issuance policy, and revocation are managed together.

Q: Why do short-lived credentials still need strong identity governance?

A: Short-lived credentials reduce exposure time, but they do not remove the need to decide who can request them, which service they can reach, and when they must be revoked. Without workload-bound policy, ephemeral delivery can still enable over-privileged access at machine speed. Governance remains about subject, scope, and revocation.

Q: What breaks when secrets never leave the kernel boundary?

A: What breaks is the assumption that the application process is the right place to handle credentials. Logging, debugging, and accidental reuse become much harder, but policy drift can still create overbroad access if the workload identity is too permissive. The control shift is from secret handling to identity-bound authorisation.

Q: How do security teams decide whether secretless injection is enough?

A: Treat secretless injection as one control in a larger NHI design, not as the whole answer. If the workload can still call too many destinations, or if revocation is slow, the architecture only narrows the exposure path. Teams should pair the model with service-level allowlisting, TTL enforcement, and audit review.

Technical breakdown

On-the-wire credential injection in kernel space

On-the-wire credential injection means the credential is added to the outbound request as it leaves the node, rather than being handed to the process first. That changes the trust boundary: the application never reads the secret, cannot log it accidentally, and does not need a Vault client or token. Riptides uses kernel-level interception to attach the correct credential based on workload identity and destination service. In practical terms, this is a delivery mechanism for short-lived NHI credentials, not a replacement for policy, issuer control, or audit logging.

Practical implication: treat kernel-enforced injection as a control boundary and verify that egress policies, workload identity binding, and audit trails are all enforced together.

Vault/OpenBao as the credential authority for APIs and cloud services

Using Vault or OpenBao as the source of truth keeps issuance, TTLs, and revocation under a central credential authority while changing how the secret is consumed. The model works for OpenAI API keys, cloud credentials, and other short-lived secrets, including cases where the organisation already relies on secrets engines and wants to preserve that governance. The important point is that the workload receives an authenticated request path, not a portable secret object. That reduces handling risk, but the authority still needs lifecycle discipline for the credential source and the workload identity that can trigger issuance.

Practical implication: align credential TTLs, issuance policies, and revocation logic to the workload identity that requests access, not to the application code that consumes it.

Why secretless delivery still depends on identity-based egress control

Secretless delivery does not mean identityless access. The request still needs an authenticated subject, a destination service, and a policy decision about whether that combination is allowed. If the workload identity is too broad, the injection layer simply becomes a faster path to over-privileged API use. This is why the governance value lies in combining workload identity, credential source, and service declaration into one control plane. The architecture removes exposed secrets from the process, but it does not remove the need to define who can call what, and under which conditions.

Practical implication: review outbound service access as an identity governance problem, not only as a secrets management problem.

Breaches seen in the wild

• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

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

NHI Mgmt Group analysis

On-the-wire injection is a runtime control, not a secrets-management substitute. The post is really about moving the exposure boundary from user space into the kernel so the credential never becomes process-visible. That is valuable, but it changes the failure model rather than eliminating it: the governance issue shifts from leaked files and environment variables to whether request-time enforcement is actually authoritative. Practitioners should read this as a control relocation, not a control disappearance.

Secretless access becomes meaningful only when the workload identity is the real policy subject. Riptides ties issuance to a specific process identity and destination service, which is the right model for NHI governance. The field-level lesson is that static application accounts are the wrong abstraction when a workload can be bound, authorised, and constrained at runtime. Teams should stop treating the application as the identity and start treating the workload or agent as the governed subject.

Vault policy alone is not enough if the last mile still leaks the credential. This architecture shows why TTLs and audit logs can be strong while the operational path remains weak. The named concept here is runtime secret elimination boundary: the point at which a secret stops existing as an exposed object and becomes an enforced request attribute. Practitioners need to evaluate where that boundary actually sits in their stack.

Kernel-enforced secret delivery narrows blast radius, but only for the identities actually bound to it. That means the discipline now looks like access governance for workloads, not just secrets rotation for platforms. If an organisation extends the model to AI agents or automation pipelines, the same principle holds: the access subject must be explicit, bounded, and revocable. The practitioner takeaway is to govern the issuer, the subject, and the egress path as one unit.

This is part of a broader shift from secret storage to credential mediation. Modern NHI programmes are increasingly judged by whether they can issue, bind, and revoke credentials without exposing them to workloads at all. That direction aligns with OWASP-NHI and zero-trust expectations, but it also raises the bar for operational discipline because every exception becomes a governance decision. Practitioners should assume the next design review will be about mediation boundaries, not just secret vaults.

From our research:

• 64% of valid secrets leaked in 2022 are still valid and exploitable today, according to The State of Secrets Sprawl 2026.
• 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.
• Guide to the Secret Sprawl Challenge extends this analysis into the operational controls that reduce exposure before revocation becomes the only option.

What this signals

The programme signal here is clear: workload identity is becoming the control plane for API consumption, not just the authentication layer. If your estate still relies on secrets reaching the application before policy can act, you are carrying unnecessary exposure into every outbound call. Runtime secret elimination boundary: the governance point where a secret is never process-visible and therefore cannot be mishandled by the workload.

For IAM and PAM teams, this should trigger a review of where credential authority ends and runtime enforcement begins. The model is strongest when short-lived issuance, destination allowlisting, and revocation are treated as a single design problem. For broader context, compare the operational patterns in the 52 NHI Breaches Analysis with the control goals in OWASP-NHI.

For practitioners

• Map the last-mile credential path Document where Vault-issued credentials become visible today, including files, environment variables, SDK wrappers, and logs. Replace each exposure point with a control that keeps the credential out of user space or proves that exposure is time-bounded and monitored.
• Bind issuance to workload identity Require every short-lived credential to be requested by an explicit workload identity and a declared destination service. Do not let application code or shared platform accounts stand in for the identity subject.
• Review egress as a governance control Treat outbound API access as an authorisation decision, not just a network route. Confirm that destination services, request-time injection, and policy evaluation are all tied to the same control plane.
• Validate revocation and TTL enforcement Test whether short-lived credentials actually expire at the expected boundary and whether revocation removes the ability to inject new credentials without touching the workload.

Key takeaways

• This post shows that the real control improvement is moving credential handling out of user space and into enforced request-time delivery.
• The scale problem is not only exposure, but persistence, because leaked secrets often remain exploitable long after discovery.
• Practitioners should govern workload identity, credential issuance, and egress policy as one system if they want secretless access to hold up operationally.

Key terms

• On-the-wire credential injection: A delivery pattern where a credential is attached to an outbound request at the moment it leaves the host. The workload never needs to store or process the secret in user space, which reduces accidental leakage and narrows the exposure window to the enforced network boundary.
• Runtime secret elimination boundary: The point in a system where a secret stops being a visible object and becomes an enforced request attribute. In mature NHI designs, that boundary should sit before user space so the workload cannot read, log, or reuse the credential outside policy.
• Workload identity binding: The act of attaching an identity to a specific process, service, or execution context so policy can decide whether it may request credentials. This is the governance layer that makes short-lived credential issuance auditable and prevents shared or ambiguous identities from widening access.
• Identity-based egress control: Authorization for outbound traffic based on the identity of the calling workload and the destination it is trying to reach. Instead of treating all network egress as equivalent, the control plane decides whether a specific identity may call a specific service under specific conditions.

Deepen your knowledge

On-the-wire credential injection for secretless access is a core topic in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are redesigning workload access around Vault, OpenBao, or AI and cloud APIs, it is worth exploring.

This post draws on content published by Riptides: Federation Zero-Touch Secrets, on-the-wire injection of Vault-sourced credentials. Read the original.