Kernel policy evaluation for workload identity: what changed?

TL;DR: Latency gains from moving OPA policy evaluation from kernel-space WASM to a user-space agent can be outweighed by memory fragility, debugging opacity, and maintenance drift, according to Riptides’ October 2025 engineering write-up. The deeper lesson is that workload identity enforcement works best when policy logic stays simpler than the kernel it protects.

NHIMG editorial — based on content published by Riptides: Kernel From Kernel WASM to User-Space Policy Evaluation

By the numbers:

• Only 5.7% of organisations have full visibility into their service accounts.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
• 73% of vaults are misconfigured, leading to unauthorised access and exposure of sensitive data.

Questions worth separating out

Q: How should teams decide whether policy evaluation belongs in kernel space or user space?

A: Teams should place policy evaluation where failure is easiest to contain and operate.

Q: When does kernel-level workload identity enforcement become too risky?

A: It becomes too risky when a policy bug, runtime defect, or memory leak can destabilise the host rather than just deny a request.

Q: What do security teams get wrong about low-latency identity controls?

A: They often treat lower latency as proof of better control, even when the architecture adds operational fragility.

Practitioner guidance

• Map policy failure domains before choosing enforcement location Document which parts of the identity path can fail without taking down the kernel, the agent, or the policy service.
• Separate policy evaluation from socket enforcement Keep the kernel responsible for fast-path enforcement and caching, while moving OPA evaluation, logging, and error handling into user space.
• Test policies against the real runtime boundary Validate Rego output, JSON handling, and numeric operations in the environment where the policy will actually execute.

What's in the full article

Riptides' full post covers the operational detail this post intentionally leaves for the source:

• The kernel-side wasm3 porting work, including memory handling, stack protection, and floating-point constraints.
• The full OPA-to-WASM execution flow, with code examples for request marshaling and module loading.
• The protobuf and nanopb message structure used between kernel and agent, including cache and reason fields.
• The performance comparisons and production observations that informed the move to user space.

👉 Read Riptides' account of moving workload identity policy evaluation to user space →

Kernel policy evaluation for workload identity: what changed?

Explore further

View Full Forum →  |  NHI Foundation Course →