TL;DR: Kernel tracepoints can be carried through eBPF, OpenTelemetry, and Prometheus to turn raw file-creation events into labeled metrics, according to Riptides. But the deeper lesson is that kernel-level telemetry only helps if identity and workload posture are already governed, and the real gap is not visibility alone, but whether workloads have disciplined, reviewable identity boundaries.
At a glance
What this is: This is a hands-on walkthrough of moving a kernel file-creation event through eBPF, OpenTelemetry, and Prometheus, with the key finding that telemetry only becomes useful when workload identity boundaries are already governed.
Why it matters: IAM, NHI, and platform teams should treat telemetry as an enforcement and evidence layer, not as a substitute for identity lifecycle, posture, and access control around workloads.
Context
Kernel telemetry is the observation of low-level system events, but observation alone does not establish who or what is allowed to act. In workload environments, the governance problem is whether service identities, workload permissions, and runtime boundaries are already defined before the signal is captured.
The article frames eBPF tracing as a way to enrich raw kernel events and export them into operational telemetry, which is useful for visibility but not sufficient for control. For identity programmes, the real question is whether workload identity governance exists at the point where the action is initiated, not after it has already been observed.
Key questions
Q: How should teams use telemetry to govern workload identity?
A: Teams should use telemetry to verify whether workload behaviour matches declared identity and access intent. The useful signals are connection patterns, handshake failures, peer changes, and process activity that reveal drift from policy. Telemetry only becomes governance input when it can support a decision about access, investigation, or containment.
Q: Why does eBPF visibility not solve NHI risk by itself?
A: Because visibility does not reduce privilege or assign accountability. eBPF can surface runtime behaviour with high fidelity, but it cannot determine whether a service account, workload, or token should have existed, who owned it, or when it should have been removed. That remains an identity governance problem, not an instrumentation problem.
Q: What are the signs that workload telemetry is masking identity gaps?
A: The main signs are rich runtime data with weak ownership, unclear entitlement scope, or stale workload credentials. If teams can describe every event path in the telemetry stack but cannot explain who owns the workload, what it is allowed to do, or how it is offboarded, telemetry is compensating for missing governance.
Q: What is the difference between telemetry and workload authorisation?
A: Telemetry records and exports what happened. Authorisation decides whether the workload should have been able to do it in the first place. In NHI programmes, that distinction matters because a highly instrumented workload can still be overprivileged, unowned, or left active after the business need has changed.
Technical breakdown
How kernel tracepoints become workload telemetry
The post shows a kernel event flow that starts with a tracepoint triggered by file creation, then uses eBPF to move the event into user space, and finally exports it through OpenTelemetry into Prometheus. The value of this pattern is that raw kernel activity becomes structured telemetry with labels such as path and name. That makes the signal queryable, correlatable, and suitable for operational dashboards. But the architecture is still observational. It tells you what happened at runtime, not whether the workload had justified access to perform the action in the first place.
Practical implication: use kernel telemetry to evidence workload behaviour, but pair it with identity controls that decide whether the action should be possible.
Why eBPF visibility does not equal identity governance
eBPF can intercept and transport very detailed runtime data, yet it does not define workload ownership, entitlement scope, or offboarding. Those are identity governance problems, not instrumentation problems. A system can be richly instrumented and still have ambiguous service identity, overly broad permissions, or stale workload credentials. In that situation, telemetry helps detect activity faster, but it does not reduce the underlying trust surface. The governance gap is that visibility can improve before accountability does, which leaves teams with better evidence of exposure rather than less exposure.
Practical implication: treat eBPF as a detection and evidence source, while enforcing workload identity lifecycle, permission scoping, and revocation separately.
Why reviewable workload boundaries matter for NHI controls
Workload identity behaves like a non-human identity when its actions are autonomous within the runtime environment, even if the article is focused on tracing rather than access control. That makes workload boundaries the decisive governance layer. If the workload can create files, emit telemetry, and communicate service posture without clear ownership or lifecycle control, the organization has an NHI problem disguised as an observability problem. The technical stack is working, but the identity model may still be weak. That is why runtime insight and governed workload identity have to be designed together.
Practical implication: inventory workloads as governed identities, not just as monitored processes, and assign lifecycle ownership for each one.
Threat narrative
Attacker objective: The practical objective in this pattern is to make runtime workload activity visible enough for operators to detect and investigate identity or posture gaps more quickly.
- Entry occurs when a workload or process executes a file-creation operation that the kernel tracepoint can observe. Credential or privilege abuse is not the point of the demo, but the runtime path still depends on the workload already having local capability to act.
- Escalation is not attacker-driven in this example, but governance escalation happens when telemetry is treated as a substitute for access control rather than evidence of it. The workload keeps operating within whatever permissions it already has.
- Impact is the production of labeled metrics from kernel events, which improves visibility but does not prove that workload identities are constrained, reviewed, or properly offboarded.
Breaches seen in the wild
- ArtiPACKED 2024: Unit 42 found public GitHub Actions artifacts in major open source projects leaking live GITHUB_TOKENs, runtime tokens and cloud tokens.
- reviewdog Action compromise 2025: A stolen maintainer token poisoned reviewdog/action-setup, leaking CI secrets including the tj-actions bot token used in the next attack.
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
Telemetry without workload identity governance creates a visibility surplus and a control deficit. Riptides' pattern shows that kernel events can be enriched, labeled, and exported with precision, but that only improves what operators can see. It does not answer whether the workload was entitled to act, who owns that entitlement, or how it is revoked when the workload changes. The practitioner conclusion is that observability must sit downstream of governed identity boundaries, not in place of them.
eBPF tracing is a runtime evidence layer, not an access model. The article demonstrates how tracepoints, ring buffers, and OTEL can turn kernel activity into operational metrics. That architecture is valuable for forensics and detection, but it does not create least privilege, workload ownership, or lifecycle control. The implication is that teams should stop treating telemetry depth as proof of identity maturity.
Workload posture becomes reviewable only when identity is assigned before runtime, not inferred after the fact. A file-creation event can be measured precisely, yet the control failure remains invisible if no one has defined the workload's accountable identity boundary. That is the same governance problem that appears across service accounts, APIs, and other NHIs. The practitioner conclusion is to govern the actor first and instrument its behavior second.
Kernel-level observability exposes the runtime identity boundary gap: the distance between what a workload can do and what the IAM programme can explain. This gap widens when teams rely on telemetry to compensate for missing workload inventory, unclear ownership, or stale access. The article is a reminder that metrics are evidence of action, not evidence of authorisation. The practitioner conclusion is to close the boundary gap before it becomes a permanent blind spot.
For NHI programmes, the real question is not whether workloads can be traced, but whether their identity boundaries are durable enough to govern. A tracepoint can tell you that something happened in the kernel; only an identity programme can tell you whether that something was still appropriate for the workload that did it. The practitioner conclusion is to align observability with governed workload lifecycle and entitlement review.
What this signals
Kernel observability and NHI governance solve different problems: one captures runtime evidence, the other controls whether the runtime action should be allowed. Teams that fuse them too early often mistake better telemetry for better identity discipline, which leaves service accounts and workloads under-governed even when dashboards look healthy.
Runtime identity boundary gap: this is the distance between a workload's observable behaviour and the identity programme's ability to explain, own, and revoke that behaviour. The gap matters because telemetry can reveal file creation, service calls, and posture changes while still leaving entitlement scope and lifecycle ownership unresolved.
For practitioners, the strategic shift is to map every high-value workload to an explicit identity owner and lifecycle state, then use telemetry to validate that governance model in operation. That sequencing turns observability into evidence rather than a substitute control.
For practitioners
- Define workload identity boundaries first Assign each workload an accountable owner, explicit entitlement scope, and lifecycle state before relying on runtime telemetry to explain its actions.
- Separate observability from authorisation Use kernel telemetry to capture behavior, but keep access decisions, privilege scope, and revocation in the identity control plane.
- Inventory service posture alongside traces Correlate runtime events with workload posture records so you can tell which identities are active, stale, or unowned.
- Treat runtime labels as evidence, not policy Do not let labels in Prometheus or OTEL become a proxy for governance. They help investigation, but they do not prove that the workload was authorised.
Key takeaways
- Kernel telemetry can expose workload activity with precision, but it does not replace identity governance for the workload behind the signal.
- The article's architecture shows how eBPF, OTEL, and Prometheus move data from the kernel into operational metrics, which improves visibility but not authorisation.
- Practitioners should manage workload identity boundaries first, then use telemetry to validate those boundaries in production.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | The article's core concern is governed workload boundaries, not telemetry alone. |
| NHI-08 — Environment Isolation | Kernel-level tracing highlights how workload behavior must be separated by clear runtime boundaries. | |
| Recommendation — Map workloads with excessive runtime capability to NHI-05 and tighten entitlement scope before relying on monitoring. Apply NHI-08 to isolate workload identities so one runtime context cannot blur into another. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Identification and Authentication (Service and Device Accounts) | Workload identities are service-like actors whose access must be controlled explicitly. |
| Recommendation — Use IA-9 to govern workload authentication and limit service-account-style access. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article's gap is whether observed workload actions were properly authorised. |
| Recommendation — Apply PR.AA-05 to keep workload entitlements reviewable and aligned to actual runtime need. | ||
| MITRE ATT&CK | TA0007;TA0006 — Discovery; Credential Access | The topic sits close to runtime discovery and credential exposure concerns around workloads. |
| Recommendation — Map workload runtime activity to TA0007 and TA0006 to hunt for exposed or overused credentials. | ||
Key terms
- Kernel Tracepoint: A kernel tracepoint is a predefined hook that emits an event when a specific operating system action occurs. It provides structured, low-level visibility into runtime behaviour without changing the kernel code path, which makes it useful for observability and detection engineering.
- eBPF Ring Buffer: An eBPF ring buffer is a shared transport mechanism used to pass event data from the kernel to user space efficiently. It is central to high-throughput telemetry pipelines, but its value depends on correct sizing, stable readers, and reliable decoding of the samples it carries.
- Workload Identity: The identity assigned to a software workload, such as a containerised application, serverless function, or microservice, enabling it to authenticate to other services without storing static credentials.
- Runtime Evidence Layer: A runtime evidence layer collects and structures behavior after it has occurred so teams can investigate, correlate, and alert. It is valuable for operations and forensics, but it is not an authorisation system and cannot substitute for entitlement governance.
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.
Published by the NHIMG editorial team on June 11, 2026.
Updated on October 10, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org