Notifications
Clear all
Topic starter
22/06/2026 10:21 am
TL;DR: Kernel-level enforcement matters because observability alone cannot stop workloads from authenticating with ambient credentials or stolen tokens, and the article points to a 2024 CircleCI incident where a staging database password in an environment variable went undetected for weeks. The governance gap is not visibility but whether identity is enforced at the point of connection.
NHIMG editorial — based on content published by Riptides: Why Deep Kernel Security Matters for Enterprises, when eBPF falls short
Questions worth separating out
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.
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.
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.
Practitioner guidance
- Separate detection from enforcement Map which controls only observe runtime activity and which controls can actually deny a process from reaching internal services.
- Bind workload access to process identity Require runtime identity checks that authenticate the process making the request, not just the token it presents.
- 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.
What's in the full article
Riptides' full article covers the operational detail this post intentionally leaves for the source:
- How the kernel-level enforcement path is implemented without application code changes
- What the vendor claims about transparent identity binding for Linux workloads
- Which operational trade-offs matter when replacing visibility-only tooling with enforcement
- How the approach is positioned for zero trust and audit requirements
👉 Read Riptides' analysis of why eBPF falls short for deep kernel security →
eBPF observability is not enforcement: what IAM teams miss?
Explore further
22/06/2026 11:12 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Deep kernel security exposes the limits of eBPF observability
