Topic starter
10/06/2026 11:50 pm
TL;DR: Vault/OpenBao-sourced API keys and cloud credentials can be injected directly into outbound requests in kernel space, so workloads never see secrets in user space and existing Vault policies, TTLs, and audit logs remain the system of record, according to Riptides. That shifts runtime risk from secret handling to enforcement boundaries, where identity-based egress control matters most.
Editorial analysis by NHI Mgmt Group, based on content published by Riptides: “Zero-Touch Secrets: On-The-Wire Injection of Vault-Sourced Credentials”.
Key questions
Q: What breaks when credentials still have to appear in user space before an API call is made?
A: The control boundary becomes too wide because applications, files, logs, and memory all become possible exposure points.
Q: Why do short-lived Vault credentials still need destination-level egress controls?
A: Short lifetime reduces exposure time, but it does not answer which workload may use the credential or where it may be sent.
A: Use runtime injection when the primary risk is secret handling in the workload and the destination can be tightly bound.
Practitioner guidance
- Define the enforcement boundary for credential use Map where a workload can request an external credential, where it is injected, and where policy is actually enforced.
- Preserve Vault as issuance authority, not runtime exposure Keep Vault or OpenBao as the credential source of record while removing user-space handling from workloads.
- Bind workload identity to destination-specific egress Require destination-aware rules for each external service so injected credentials are only usable by the intended process and endpoint.
Bottom line: The article is about removing credential handling from workload user space, which changes the NHI control problem from secret storage to request-time enforcement.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 2 days ago by NHI Mgmt Group
12/06/2026 6:12 am
On-the-wire credential injection is a boundary-control pattern, not just a secret-delivery optimisation. The governance question changes from whether a workload can receive a secret to whether it should ever be able to hold one in user space. That distinction matters because user-space materialisation creates a broader inspection, logging, and reuse surface than kernel-enforced injection. The practitioner implication is that NHI risk ownership moves toward enforcement points, not application plumbing.
A few things that frame the scale:
- 69% of organisations still authenticate machine identities with long-lived API keys, according to the 2026 State of AI Agent Identity Security Report.
A question worth separating out:
A: Vault-issued credentials keep the source of truth in the secret store, while workload-managed credentials move more of the lifecycle into the platform that consumes them. The choice is not only about issuance, but about where policy enforcement and exposure control happen during use.
👉 Read our full editorial: Vault-sourced credentials on the wire change NHI runtime risk
This post was modified 2 days ago by NHI Mgmt Group