Runtime identity for workloads and agents without application changes

At a glance

What this is: This is a runtime identity demo showing host-enforced mTLS, passthrough authorization, and egress credential injection for unmodified workloads.

Why it matters: It matters because IAM and platform teams need to govern non-human identities where they actually execute, not only where applications declare them, especially as workload and agent identity patterns expand.

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.

👉 Read Riptides' demo of runtime identity without application changes

Context

Runtime identity changes where security controls sit. Instead of trusting the application to hold keys, present tokens, or negotiate policy correctly, the identity layer is enforced in the host or platform path and observed through packet and policy behaviour. That matters for NHI governance because the subject being controlled is a workload, not a person, and the control point is not always inside the application boundary.

The article’s core claim is that identity controls can be added without modifying the app, then verified with concrete evidence rather than a slide deck. That is relevant to platform teams trying to reduce secret exposure, narrow credential handling, and support service-to-service access patterns that are easier to govern centrally than inside every codebase. For context on the broader NHI model, see the Ultimate Guide to NHIs.

The demo also hints at a growing operational pattern: credentials may be injected after process execution rather than stored in the workload itself. That is structurally different from classic application secret management, and it shifts the governance question toward who can authorize runtime identity, how it is revoked, and how evidence is produced when policy is working.

Key questions

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. The control needs explicit issuance, narrow scope, revocation, and evidence that the token never becomes a reusable workload secret. If the platform can inject credentials after process execution, then the audit trail and the revocation path matter as much as the application call itself.

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. That leaves policy gaps hidden inside transport security and makes revocation harder to prove. The practical risk is that teams mistake secure transport for governed access, even when the workload identity layer has not been enforced.

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. If you can trace each workload-to-service request, see the context used for the decision, and revoke access without breaking unrelated systems, the controls are doing real work.

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.

Technical breakdown

How host-level workload identity enforcement works

The demo places identity enforcement beneath the application stack, on the host, rather than inside code or sidecars. The kernel observes traffic, the policy layer associates labels with the running process, and authorization is applied as connections are created or mediated. That separation matters because the application can remain unmodified while still being governed as an identity-bearing workload. In practice, this shifts control from developer implementation to platform enforcement, which is easier to standardise but still depends on trustworthy workload attribution. It also changes what evidence matters: packet counts, reset behaviour, and policy state become the proof of control.

Practical implication: verify that workload identity decisions are enforced outside the app and can be observed independently of code changes.

mTLS, passthrough, and policy revocation in runtime identity

The article distinguishes three operational modes. First, mTLS can be applied so that traffic is authenticated and encrypted between services. Second, passthrough mode lets the platform authenticate both ends without placing itself in the data path, which matters when decryption is unnecessary. Third, policy revocation should immediately break the connection and force re-evaluation. The technical point is that authorization and transport security are separable. A workload may still speak TLS itself, but that does not answer who is allowed to talk to whom, or whether access can be revoked cleanly at runtime.

Practical implication: treat transport encryption and authorization as separate controls and test revocation, not just connection establishment.

Egress credential injection without exposing tokens to the workload

The demo’s egress step shows a GitHub token reaching an API request without ever appearing in the workload environment, image, or process command line. The header is injected after the bytes leave the process, which means the workload can complete its job without ever holding the secret directly. That reduces secret exposure inside the runtime, but it also moves trust into the platform path that performs injection. For NHI governance, this is a powerful pattern only if issuance, scope, and revocation are themselves tightly governed and auditable.

Practical implication: confirm that outbound credential injection is logged, scoped, and revocable without leaving reusable secrets in the workload.

Threat narrative

Attacker objective: The objective is to abuse runtime trust in the platform path to make authorised-looking service calls while keeping the credential out of the application itself.

1. Entry occurs when a workload or agent obtains runtime access to a downstream API or service path without holding the credential in-process.
2. Escalation occurs when that access can be reused, injected, or revoked by policy rather than by the workload itself, creating a platform-controlled trust boundary.
3. Impact occurs when the runtime path can authorize service calls, egress requests, or cross-service communication without exposing the underlying secret to the workload.

Breaches seen in the wild

• CoPhish OAuth Token Theft via Copilot Studio — CoPhish campaign exploits Microsoft Copilot Studio agents to steal OAuth tokens via AI-assisted phishing.
• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.

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

NHI Mgmt Group analysis

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.

Credential injection changes the meaning of secret exposure. If a token reaches the API but never exists inside the workload, then the old assumption that the process boundary is the secret boundary no longer holds. This is an NHI governance shift, not just an implementation detail. The practical conclusion is that governance must follow the egress path, the injection path, and the policy state together, because those are now part of the identity lifecycle.

Policy revocation only matters if it produces an observable runtime change. The demo is careful to show connection reset and packet-count collapse after a policy edit, which is the right way to prove control in an NHI system. A named concept here is runtime identity proof: controls are only credible when they can be shown to alter live traffic, not merely configuration. Practitioners should treat unverifiable policy as design theatre rather than governance.

The secrets problem is shifting from storage to delegation. Traditional NHI work focused on where secrets are kept and how often they rotate. This demo shows the next problem: who can delegate, inject, or revoke identity at runtime without exposing the credential itself. That widens the governance scope from secrets hygiene to runtime authorisation, which is where cloud and workload identity programmes are heading.

Workload identity and agent identity are converging on the same control plane. The article’s final AI comments are important because they show where this model is heading: model calls, MCP requests, and database queries will all need the same runtime identity discipline. That means IAM, PAM, and NHI teams should stop treating AI agents as a separate category of problem and start governing them as high-mobility non-human identities with dynamic action paths.

From our research:

• 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.
• That is why runtime identity proof matters: follow the 52 NHI Breaches Analysis for the breach patterns that expose where secrets and runtime trust diverge.

What this signals

Runtime identity proof: the next control standard for non-human identity programmes will be whether policy changes produce observable traffic changes, not whether a configuration exists. That aligns directly with host-enforced identity models and with the direction of workload and agent governance.

The operational signal is clear: secrets handling is moving away from static storage problems and toward delegation problems. With 6 distinct secrets manager instances on average in the market research, fragmentation itself becomes a control risk because runtime identity logic gets split across too many places.

Teams should prepare for a combined workload and agent identity model in which egress credentials, model-tool requests, and service-to-service calls are all governed by the same runtime path. That is where the Ultimate Guide to NHIs remains the right baseline, while NIST SP 800-53 Rev 5 Security and Privacy Controls provides the control vocabulary for enforcement and audit.

For practitioners

• 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. Prioritise systems where the workload never needs direct access to the secret. A useful starting point is the Ultimate Guide to NHIs for the broader lifecycle model.
• Test revocation as a live-traffic control Do not stop at successful connection setup. Revoke policy during an active session and confirm that traffic resets or ceases immediately, then verify that the same policy change is visible in logs and packet capture. This is the clearest check that runtime authorisation is real rather than declarative.
• 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. A secure transport does not prove the right identity was approved. Use the 52 NHI Breaches Analysis to pressure-test what happens when credentials are present but governance is weak.
• Govern egress credential injection as a privileged control Treat any mechanism that adds tokens after process execution as a high-risk identity function. Require traceability for issuance, scope, and removal, and make sure injected credentials are not reusable outside the intended call path.

Key takeaways

• Runtime identity shifts governance from application-held secrets to host-enforced control, which changes where trust must be proven.
• Packet-level evidence and live revocation are the only credible proof that workload identity controls are working as intended.
• As secrets move into runtime injection and delegation, IAM and NHI teams must govern the enforcement path, not just the credential store.

Key terms

• Runtime Identity: Runtime identity is the practice of making identity and authorization decisions at the moment an action occurs. For agents and workloads, it means access is validated against live context, not only against the identity state set during onboarding or provisioning. That makes accountability and scope enforcement possible inside fast-moving workflows.
• Credential Injection: Credential injection is the controlled replacement of one credential with another at execution time, usually before a request leaves the host or service boundary. It lets the workload operate with a harmless token or placeholder while the real secret remains protected by infrastructure.
• Runtime Identity Verification: Runtime identity verification is the process of proving a workload's identity at the moment access is requested rather than trusting a pre-stored secret. It ties access decisions to the current workload instance, which is more suitable for ephemeral services and short-lived sessions.
• Workload Attribution: Workload attribution is the ability to tie an action, connection, or token use back to a specific running workload or process. It is central to NHI governance because without attribution, policy enforcement, incident response, and access review all lose precision.

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

👉 The full Riptides post shows the packet traces, policy edits, and runtime behaviour behind the demo.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an identity security programme, it is worth exploring.