Deep kernel security exposes the limits of eBPF observability

At a glance

What this is: This is an analysis of why eBPF-based observability falls short when workloads authenticate with ambient credentials, stolen tokens, or certificate-based identity.

Why it matters: It matters because IAM, NHI, and zero trust programmes need enforcement at connection time, not just better telemetry, if they want to contain workload compromise.

👉 Read Riptides' analysis of why eBPF falls short for deep kernel security

Context

Workload identity becomes a governance problem when credentials are present in the runtime path but not bound to the process that uses them. eBPF can show what happened, but it does not change whether an untrusted process can authenticate to internal services once it is inside the workload boundary.

The article argues that enterprises are often treating visibility as control, which leaves a gap between detection and prevention. For IAM and NHI teams, the practical issue is whether the identity model enforces trust at the point of connection, or merely records it after the fact.

Key questions

Q: How should security teams stop compromised workloads from using valid credentials?

A: Security teams should enforce identity at the point of connection, not rely on visibility after the fact. If a compromised process can still present ambient credentials or tokens to internal services, the architecture is permissive. The control objective is to make unauthorized processes unable to authenticate, even when they already have code execution.

Q: Why do observability tools fail to prevent lateral movement in workloads?

A: Observability tools fail because they can show scanning, token use, and suspicious connections without stopping them. Lateral movement is prevented only when the runtime can deny access to internal services or databases. If the secret is still valid, the log entry arrives too late to change the outcome.

Q: What breaks when workload identity is only declared and not enforced?

A: Declared identity breaks when policy says a workload is trusted but the runtime cannot prove or enforce that trust at connection time. In practice, that means a compromised process can still use local secrets to reach protected services. The result is monitoring without containment.

Q: How can organisations tell whether their zero trust model is real or just visible?

A: A real zero trust model can block an unauthorized process from reaching a protected service even when telemetry shows the attempt. If the environment can only detect the connection after it happens, the model is observational, not enforced. Containment is the test, not log volume.

Technical breakdown

Why observability does not stop credential abuse

Observability tools are designed to trace activity, not to deny it. In this pattern, a compromised workload can still scan the network, locate internal services, and use legitimate secrets that were already present in memory, config files, or environment variables. eBPF can surface those events in real time, but it cannot revoke the token, block the handshake, or replace the trust decision with a process-bound identity check. That distinction matters because the attacker is not exploiting a missing signal. They are exploiting a valid authentication path that was never meant to be the control boundary.

Practical implication: treat telemetry as detection support, not as the enforcement layer for workload access.

How kernel-enforced workload identity changes the trust boundary

Kernel-level identity enforcement binds access decisions to the process rather than to whatever secret the process happens to possess. That shifts the control point from network observation to authentication at connection time. A shell, injected binary, or lateral movement tool may achieve code execution inside the workload, but it does not inherit standing authority to reach databases or internal APIs unless the runtime identity layer permits it. This is especially relevant for environments using short-lived tokens or certificate-based identity, where the control problem is less about discovery and more about whether trust can be asserted continuously at runtime.

Practical implication: require process-bound identity controls where workloads are expected to talk to sensitive internal services.

Why zero trust fails when identity is only declared

Zero trust architecture depends on continuous verification, but many enterprise implementations still declare workload identity without enforcing it. That creates a gap between policy intent and runtime reality. If the system can observe a connection but cannot prevent an unauthorized process from using ambient credentials, the architecture is still permissive at the moment that matters. The article’s core point is that enforcement must exist at the same layer where trust is consumed. Otherwise, the environment remains monitorable but not meaningfully contained.

Practical implication: map each protected service to an enforcement point that can block unauthorized process-to-service connections.

Threat narrative

Attacker objective: The attacker aims to convert workload compromise into authenticated access across internal services without triggering controls that only observe network activity.

1. Entry begins when an attacker gains code execution inside a workload and uses the compromised runtime as a foothold into the internal environment.
2. Escalation occurs when the attacker discovers ambient credentials, stolen tokens, or certificates that allow authentication to internal services and data systems.
3. Impact follows when those legitimate credentials are used to move laterally, reach protected resources, and turn a contained compromise into a broader breach.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Sisense breach — unauthorized GitLab access led to exfiltration of access tokens, API keys and certificates.

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

NHI Mgmt Group analysis

Visibility without enforcement is a control illusion. The article shows that eBPF can expose network behaviour while leaving the authentication decision untouched. That means security teams can see lateral movement in progress and still be unable to stop it if the credential is valid. The implication is that governance must distinguish between telemetry, detection, and authority to deny.

Process-bound identity is the real control boundary for workloads. When identity follows the process instead of the secret, the attack surface changes materially. An attacker may own the runtime, but they do not automatically own trust into internal services. For NHI governance, that makes the runtime authentication path the primary object of control, not the network trace.

Standing credential exposure window: This article illustrates a failure mode where credentials remain usable long enough for a compromised process to consume them, even if the compromise is already visible in logs. That assumption was designed for environments where detection and response could intervene before misuse. It fails when authentication is still possible after execution has been lost, and practitioners must rethink how long a secret is allowed to remain valid inside a live workload.

Zero trust for workloads fails when trust is only declared. Declaring workload identity does not equal enforcing it. The article’s central point is that policy without runtime denial leaves the environment watchable but not containable. The implication is that identity governance for workloads has to prove it can block, not just report.

eBPF is an observability substrate, not an access governor. That is the important separation this article surfaces for the market. Enterprises that build their security story around visibility tools alone will keep discovering compromise after the fact, while enforcement-capable identity layers change the breach outcome before lateral movement can complete. Practitioners should treat this as an architectural boundary, not a product category debate.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, with 38% reporting no or low visibility and a further 47% only partial visibility, according to The State of Non-Human Identity Security.
• That same research found that only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared with nearly 1 in 4 for securing human identities.
• For the broader governance picture, read the NHI Lifecycle Management Guide for the lifecycle controls that help close exposure gaps before access is abused.

What this signals

Identity blast radius: the next control debate for workload security is not whether teams can see every connection, but whether they can stop a compromised process from inheriting trust. That is where observability programmes need to evolve into enforceable identity programmes, with stronger alignment to NIST SP 800-207 Zero Trust Architecture.

The governance signal for practitioners is clear: if your NHI programme still depends on secrets that can be observed in motion, you are managing evidence rather than containment. The practical next step is to align workload access paths with the identity lifecycle, especially where service accounts and certificates outlive the processes that use them.

For practitioners

• Separate detection from enforcement Map which controls only observe runtime activity and which controls can actually deny a process from reaching internal services. If the answer is only observability, the environment is still vulnerable to valid credential abuse.
• Bind workload access to process identity Require runtime identity checks that authenticate the process making the request, not just the token it presents. This is the point where ambient credentials stop being enough to cross the trust boundary.
• Review internal service exposure paths Identify which databases, APIs, and internal services remain reachable once a workload is compromised, then verify that an unauthorized shell cannot use those paths even with locally available secrets.
• Test containment before the next incident Use a controlled compromise exercise to confirm whether lateral movement is blocked at connection time or merely logged after it succeeds. The test should end with denial, not just alerting.

Key takeaways

• The article’s core warning is that visibility alone cannot stop a compromised workload from authenticating with valid credentials.
• The evidence pattern is familiar: once ambient secrets are present in a runtime, detection often arrives after lateral movement has already started.
• The control that matters is enforcement at connection time, because that is what turns a logged incident into a contained one.

Key terms

• Workload Identity: A workload identity is the cryptographic or runtime identity used by a machine process to prove who it is to another system. In practice, it should be bound to the process and its context, so access can be granted or denied without relying on secrets that can be copied or reused.
• Ambient Credentials: Ambient credentials are secrets that exist in a runtime environment and can be used by any process that can reach them. They are convenient for automation but dangerous when a compromise turns the runtime into a credential source, because possession alone can be enough to authenticate.
• Kernel-Level Enforcement: Kernel-level enforcement is the practice of making access decisions inside the operating system layer rather than only at the application or network layer. This matters for workload security because it can block unauthorized processes from using identity paths even when monitoring tools can already see the attempt.
• Standing Credential Exposure: Standing credential exposure is the condition where a secret remains valid and reachable long enough to be used during or after compromise. For workload programmes, the risk is not just that a secret exists, but that it stays usable inside the runtime beyond the moment it should have lost authority.

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 or identity security programme, it is worth exploring.

This post draws on content published by Riptides: Why Deep Kernel Security Matters for Enterprises, when eBPF falls short. Read the original.