Deep kernel security exposes the limits of eBPF observability

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Riptides's blog post: Kernel-level identity enforcement matters because observability alone cannot prevent compromised workloads from using legitimate credentials to reach internal services.

Why it matters: IAM and NHI teams need to distinguish between seeing workload behaviour and stopping unauthorised authentication, because telemetry without enforcement leaves blast radius unchanged.

Context

eBPF gives security teams visibility into network flows, system calls, and connection patterns, but visibility is not the same as enforcement. In workload identity programmes, the real governance gap is whether a process is allowed to authenticate at the point of connection.

The article’s core claim is that observability tools can reveal suspicious behaviour after credentials are already in motion. That leaves IAM, PAM, and NHI governance teams with a control problem, not just a detection problem.

The distinction matters because workloads often authenticate with embedded secrets, short-lived tokens, or certificates. If the identity boundary is only watched rather than enforced, compromise can still become lateral movement.

Key questions

Q: What breaks when eBPF is used for workload identity control?

A: eBPF breaks down when the job includes credential creation, certificate binding, or just-in-time delivery, because it is designed for safe inspection and lightweight enforcement rather than owning the identity lifecycle. In practice, the control gap appears when the runtime cannot create or protect the credential inside the same trust boundary that uses it.

Q: Why do ambient credentials increase lateral movement risk in workloads?

A: Because a valid token, password, or certificate can still be reused by an attacker who gains code execution inside the process. The credential may be legitimate even when the runtime is not, so the attack path shifts from initial compromise to authenticated access across internal services.

Q: How can security teams tell if workload identity is actually being preserved?

A: Look for identity continuity across every hop, not just at launch. If a request is authenticated at the edge but then forwarded through proxies or meshes without re-validation, the programme has lost the very signal it relies on. Effective designs preserve cryptographic binding and re-authorize at each boundary.

Q: Should teams prioritise point-of-connection enforcement over more telemetry?

A: Yes, when the threat is credential reuse after workload compromise. More telemetry improves detection, but it does not stop a shell, script, or binary from using stolen trust. Enforcement matters most when your incident path depends on preventing lateral movement, not just observing it.

Technical breakdown

Why eBPF observability cannot stop authenticated misuse

eBPF is designed to trace and inspect runtime activity, not to replace authentication or policy enforcement. It can show when a workload connects to a service, but it cannot itself issue scoped identity, bind credentials to a process, or deny a connection when the credential is still valid. That means an attacker who steals a password, token, or certificate may remain invisible only in the sense of intent, not in the sense of activity. The telemetry exists, but the trust decision is still made elsewhere, often too late.

Practical implication: treat eBPF as a detection and investigation layer, not the control point for workload trust.

Process identity vs credential possession

The article’s kernel-enforcement argument hinges on a simple difference: possessing a secret is not the same as being the trusted process that should use it. In many environments, ambient credentials are stored in environment variables, config files, or token stores, and any process that can read them can impersonate the workload. Kernel-based identity aims to authenticate the process itself, so the connection decision follows the runtime identity of the process rather than the static secret it found. That changes the enforcement model from secret possession to execution context.

Practical implication: map every workload authentication path to the identity of the process actually making the connection.

Why kernel-level enforcement limits lateral movement

Once an attacker gets code execution inside a workload, the next step is usually internal service access. If authentication is enforced at the kernel level, the attacker’s shell or injected binary may execute, but it cannot freely reuse ambient credentials to pivot across databases and APIs. The result is not immunity, but containment. The attack may still succeed locally, yet the organisation prevents the compromise from turning into a multi-system breach. That is a materially different security outcome from alerting after the connection has already happened.

Practical implication: design for containment at the connection boundary when workload compromise is a realistic scenario.

Threat narrative

Attacker objective: The attacker wants to turn one compromised workload into authenticated access across internal systems.

1. Entry occurs when an attacker compromises a workload and gains code execution inside the process boundary.
2. Credential access follows when the attacker discovers ambient credentials such as environment variables, tokens, or certificates.
3. Escalation happens as the attacker uses those credentials to reach internal services, databases, or APIs.
4. Impact is achieved when the compromise expands into lateral movement and a broader breach rather than remaining a local incident.

Breaches seen in the wild

• Kubeflow cryptomining attacks 2020: Exposed Kubeflow dashboards and a notebook's mounted Kubernetes service account let attackers run cryptominers on tens of ML clusters.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Visibility without enforcement is an identity governance gap, not a monitoring gap. Security teams often treat telemetry as if it were a control, but the article shows that seeing authenticated activity does not stop a workload from using a valid secret. The practical conclusion is that workload identity must be enforced where the connection happens, not inferred after the fact.

Ambient credentials create an identity blast radius that observability cannot shrink. If a process can read a token or password, then any compromise of that process inherits the same authority. That is why the central governance problem is not whether teams can detect movement, but whether they can prevent a compromised runtime from reusing trust it never earned.

Credential possession and process identity are different governance objects. The article sharpens a named concept we would call process-bound trust: authentication that follows the runtime identity of the executing process rather than the secret it can access. That distinction matters for NHI programmes because the control target moves from secret inventory to enforced connection policy.

The decisive control is point-of-connection enforcement, not post-compromise visibility. This is where zero trust claims succeed or fail in practice. If the identity boundary remains declarative, attackers can still use legitimate credentials inside a compromised workload, so practitioners should reframe workload security around enforced trust decisions.

Kernel-level identity is a containment model for non-human identities. For service accounts, workload certificates, and process-authenticated connections, the goal is no longer perfect prevention. It is reducing the breach from a sprawling lateral movement event into a bounded local incident that can be recovered without systemic fallout.

From our research library:

• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
• Read next: NHI Authentication Guide

What this signals

Process-bound trust: Workload security gets materially better when the authority to connect follows the running process instead of the reusable secret. That shift matters because a compromised binary can inherit ambient credentials even when every action is visible in logs.

Teams should expect more pressure to prove where enforcement happens in the workload path, not just where telemetry is collected. If identity is only declared at deployment time, a later compromise can still reuse it inside the same runtime boundary.

The practical programme change is to separate detection, authentication, and authorization more cleanly. Observability can explain what happened, but only enforced workload identity can decide whether the connection should be allowed in the first place.

For practitioners

• Map ambient credential paths Inventory where workload secrets live in environment variables, config files, token stores, and certificate material so you know which processes can impersonate which services.
• Separate observability from enforcement Keep eBPF-based tooling for telemetry and investigation, but assign a different control to actually permit or deny workload connections.
• Bind trust to process identity Require the connection decision to follow the running process rather than the mere presence of a reusable secret on disk or in memory.
• Limit lateral movement by design Use scoped, short-lived workload credentials so a compromised process cannot reuse static trust across internal services for extended periods.

Key takeaways

• The article’s core warning is that observability alone cannot stop a compromised workload from using legitimate credentials to reach protected services.
• The cited CircleCI incident illustrates how a staging database password in an environment variable can remain exploitable long enough for detection to lag by weeks.
• Point-of-connection enforcement, not more telemetry, is what prevents a local compromise from becoming a lateral movement event.

Key terms

• Ambient Credential Inheritance: Ambient credential inheritance is the accidental reuse of credentials already present in a user or developer environment. It is risky because a new tool can gain access without being provisioned as a distinct identity, which bypasses normal scoping, review, and revocation controls.
• Point-of-Connection Enforcement: A control model that makes the authorization decision when a process attempts to connect, rather than after the connection has already been observed. In workload identity programmes, this is the difference between watching access and actually preventing unauthorised authentication.
• Process Identity: The identity of the actual running process that generated a request, not just the pod, container, or proxy carrying it. In workload security, process identity matters because transport-level authentication can succeed even when the wrong runtime actor is speaking through a shared boundary.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.

Deepen your knowledge

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