Naevik’s Windows enforcement is driver-based: it governs what AI agents do in
native Windows. WSL2, however, runs a real Linux kernel inside a
lightweight VM — and Windows kernel drivers cannot see inside that VM. An AI
agent running inside a WSL2 distro (in a distro shell, or via VS Code
Remote‑WSL, where the agent lives in the in-distro vscode-server) is
therefore not governed by the Windows side of Naevik.
Naevik treats this fail-loud: the app enumerates your WSL distros, and when
an AI agent could be running unprotected inside one, the tray icon turns
red and the WSL tab lists the distro. The fix is to run the
Naevik Linux agent inside the distro — it enforces with
BPF_LSM, exactly as on bare-metal Linux.
On an Unprotected, running WSL2 distro, click
Install Naevik agent in the WSL tab. No UAC prompt is needed —
in-distro root is internal to the VM. The installer:
BPF_LSM capability +
BTF). If it can’t, nothing is changed.naevikd) so it starts with the distro.bpf LSM isn’t active yet, offers to add it to your
.wslconfig and restart WSL.wsl --shutdown, which stops every running distro and any unsaved work
in them. You can choose Later and finish your work first — the distro shows
“installed — restart WSL to activate” until you restart.
The bpf LSM must be on the WSL2 kernel command line. Read the distro’s
current LSM list first — never set lsm=bpf alone, which
would drop the kernel’s default LSMs:
$ cat /sys/kernel/security/lsm
capability,landlock,yama,apparmor
Then, in %USERPROFILE%\.wslconfig on Windows, append ,bpf to that
full list:
[wsl2]
kernelCommandLine = lsm=capability,landlock,yama,apparmor,bpf
Restart WSL (wsl --shutdown), then verify from inside the distro:
$ grep -qw bpf /proc/cmdline && echo "bpf on cmdline"
$ naevikctl statusA freshly installed agent monitors but does not block: its policy has no blocking rules yet, and Naevik never guesses one for you — a deny-all default would break your distro, and a permissive guess would be false protection. The distro shows Observing in the WSL tab, and it still counts toward the red tray alarm, because monitoring is not protection.
To actually protect the distro, give its policy blocking rules: open Rules in the Naevik app, select the distro as the scope, add deny rules, and Save & Apply. The badge flips to Protected once the policy is enforcing.
Container tooling registers infrastructure WSL distros of its own:
docker-desktop, docker-desktop-data,
rancher-desktop, rancher-desktop-data, and
podman-machine-*. These are not user environments — they run a minimal
rootfs owned by the tool, and are replaced wholesale when the tool updates, so they are
not a supported install target for the Naevik agent. Naevik does not list them, probe
them, or raise alarms about them. Governing the workloads inside containers is a
separate roadmap item.
WSL1 has no real Linux kernel, so there is no BPF_LSM to enforce with. WSL1
distros appear as WSL1 (unsupported), detect-only. If you need protection
in one, migrate it: wsl --set-version <distro> 2.
A custom WSL2 kernel built without CONFIG_BPF_LSM or BTF can’t run the
agent; the installer refuses with “this distro’s kernel can’t run
Naevik”. Use the stock WSL2 kernel (remove a custom kernel= line from
.wslconfig), or rebuild with CONFIG_BPF_LSM=y and BTF.
The Events pane shows one unified timeline: the Windows host’s own events plus a mirrored copy of each WSL2 distro’s agent events — no need to open a distro shell to inspect its audit log. Each distro gets a compact sync chip above the list; hover a chip for the full detail of its sync state.
Questions? hello@naevik.ai