Notifications
Clear all
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.
NHIMG editorial — based on content published by Riptides: Federation Zero-Touch Secrets, on-the-wire injection of Vault-sourced credentials
Questions worth separating out
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.
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.
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.
Practitioner guidance
- Map the last-mile credential path Document where Vault-issued credentials become visible today, including files, environment variables, SDK wrappers, and logs.
- Bind issuance to workload identity Require every short-lived credential to be requested by an explicit workload identity and a declared destination service.
- Review egress as a governance control Treat outbound API access as an authorisation decision, not just a network route.
What's in the full article
Riptides's full post covers the operational detail this post intentionally leaves for the source:
- Concrete YAML examples for defining the external OpenAI and AWS services in Riptides.
- The full Vault and OpenBao credential source configuration, including JWT auth method paths and secret engine paths.
- Process-level workload identity bindings that decide which workload can receive which credential.
- Kernel-space injection specifics for OpenAI bearer tokens and AWS SigV4 request signing.
👉 Read Riptides's analysis of Vault-sourced credential injection for AI and cloud APIs →
Vault-sourced credential injection: what it means for IAM teams?
Explore further
12/06/2026 6:12 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Vault-sourced credentials on the wire change NHI runtime risk
