Notifications
Clear all
Topic starter
02/09/2026 1:29 pm
TL;DR: Workload identity, mTLS, and credential injection can be enforced on the host without changing application code, according to Riptides’ demo, and it demonstrates packet-level evidence for policy enforcement, passthrough, and egress token injection on a single Linux machine. The practical issue is not whether identity can be added at runtime, but whether teams can trust identity decisions that are decoupled from the application and its deployment path.
NHIMG editorial — based on content published by Riptides: Identity Run It Yourself: The Riptides Core Capability Demo
By the numbers:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes , and as quickly as 9 minutes in some cases.
Questions worth separating out
Q: How should teams govern workload identity when credentials are injected at runtime?
A: Teams should govern runtime injection as a privileged identity event, not a convenience feature.
Q: What breaks when mTLS is added without runtime authorization?
A: You get encrypted traffic without a clear decision about who is allowed to talk to whom.
Q: How can organisations tell whether workload identity controls are actually working?
A: Look for evidence that access decisions are being enforced by policy rather than by shared secrets.
Practitioner guidance
- Audit where identity is enforced in your workload stack Map whether service authentication depends on code, sidecars, proxies, or host-level enforcement, then identify which paths can be changed without application redeploys.
- Test revocation as a live-traffic control Do not stop at successful connection setup.
- Separate transport encryption from access approval Review service-to-service paths that already use TLS and confirm whether they also have explicit authorisation, attribution, and revocation.
What's in the full article
Riptides' full post covers the operational detail this post intentionally leaves for the source:
- Step-by-step demo flow for reproducing the packet capture and policy-change checks on a Linux machine
- Command-level evidence showing how traffic changes when policy is applied, revoked, or restored
- Implementation notes for running the control plane on AWS or a local VM without changing application code
- Details on how the same runtime identity model is expected to extend into Kubernetes, CI runners, and agent workflows
👉 Read Riptides' demo of runtime identity without application changes →
Runtime identity for workloads: does host-level enforcement close the gap?
Explore further
02/09/2026 1:30 pm
Runtime identity enforcement is becoming a platform control, not an application feature. The demo’s central claim is that workload identity can be attached underneath unmodified containers and still produce enforceable policy outcomes. That matters because NHI governance has long depended on teams knowing where credentials live inside applications, while this model moves the trust point into the host and control plane. The implication is that IAM teams must assess whether identity assurance now depends on runtime instrumentation rather than developer-managed secret handling.
A few things that frame the scale:
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
- 43% of security professionals are concerned about AI systems learning and reproducing sensitive information patterns from codebases.
A question worth separating out:
Q: Should organisations centralise workload secret handling or keep it inside applications?
A: Centralising the control path is usually better when the goal is consistent governance, but only if the platform can prove attribution, revocation, and least privilege at runtime. Keeping secrets inside applications creates hidden exposure and makes lifecycle governance inconsistent. The better test is whether the workload can function without ever holding the secret itself.
👉 Read our full editorial: Runtime identity for workloads and agents without application changes
