Agent security is moving into silicon. You still need a portable layer above it.
NVIDIA’s RTX Spark and Microsoft’s Windows agent primitives push enforcement down toward the hardware — validation that the boundary belongs below the agent. But the result is platform-locked, hardware-gated, and opt-in. The portable layer is what’s missing.
The industry is converging on the right place
NVIDIA and Microsoft have announced a push to move agent control into the platform itself. RTX Spark-powered systems, due this fall, will carry new Windows agent security primitives (identity, containment, policy), alongside NVIDIA’s OpenShell runtime for defining what an agent is allowed to do. In the data center, NVIDIA’s BlueField DPUs enforce file and network policy in silicon, in a trusted domain isolated from the host.
Strip the branding and it is the same principle this column argued for with least agency: enforce an agent’s actions below the agent, at a layer it can’t talk its way around. When the largest hardware and OS vendors start pushing enforcement toward the silicon, that isn’t a threat to the idea — it’s confirmation of it.
Convergence isn’t coverage
The catch is where each of these actually applies.
RTX Spark’s agent primitives are new in every sense: they depend on new RTX Spark hardware arriving in systems this fall, they run through an opt-in runtime (OpenShell), and agents have to be built for them — the first adopters are projects like Hermes Agent and OpenClaw. They are Windows-bound. BlueField’s in-silicon enforcement is for AI factories: DPUs embedded in data-center servers, not the laptop someone runs an AI agent on.
So someone running Claude Code on last year’s MacBook, an Ubuntu workstation, or a Windows PC bought before fall 2026 doesn’t get the full RTX Spark, hardware-backed stack — and no team can treat it as a fleet-wide enforcement layer yet. The enforcement is real. The coverage is narrow.
The real problem is fragmentation
Each platform already has a genuine enforcement primitive, and they don’t speak to each other. BPF LSM on Linux. Endpoint Security and Network Extension on macOS. The native security path on Windows — and, arriving on top, Windows agent primitives, hardware roots of trust, and data-center DPUs. Every one has its own model, its own scope, its own policy format, and its own telemetry.
A team running mixed machines and mixed agents does not want six policy languages and six audit trails. It wants one answer to a simple question: what are our agents allowed to do, and what did they try? — across the whole fleet.
More enforcement substrates don’t solve the portability problem. They make it worse. The constant a security team needs is one policy and one audit trail that outlive whatever silicon is underneath.
What Naevik is not
Naevik is not a chip, and not a replacement for any of this. It does not compete with a hardware root of trust, with BlueField in the data center, or with Microsoft’s Windows agent primitives. Where those exist, they are better enforcement substrates than anything in user space, and Naevik should sit on top of them, not beside them. Naevik is the portability, policy, and audit layer — the part that stays constant while the substrate underneath keeps changing.
Where the portable layer fits
Naevik is one policy model and one audit trail that ride whatever primitive each system provides.
| Where enforcement lives | What Naevik provides on top |
|---|---|
| Linux kernel (BPF LSM) | One policy and audit trail — on hardware you already own, no new silicon |
| macOS (Endpoint Security + Network Extension) | The same policy and audit trail, enforced |
| Windows (kernel-mode driver; OS agent primitives as they ship) | The same policy and audit trail, enforced |
| Hardware roots of trust / DPUs (emerging) | Consumed as backends, not reinvented |
Same posture model (Strict, Bumpers, Observe), same process / file / network rules, same events — regardless of operating system, agent, or hardware generation. As Windows agent primitives and hardware roots of trust ship, they become additional backends underneath that policy, not a new silo beside it.
Designed for the fleet you actually have
The move into silicon is the best validation the category could ask for: the boundary belongs below the agent. But a boundary that only exists on one vendor’s newest hardware isn’t one your fleet can rely on yet. Most of the machines running AI agents today shipped before any of this, and they will keep running agents for years.
That is the layer Naevik holds: one policy for the machines and agents you already run — mixed OS, mixed tools — built to enforce on the primitive each system already provides, and the ones shipping next year. No new silicon required.
← All insights