Veto finds the executables. You just name them.

Content-addressable enforcement blocks executables by what they are, not where they live. Veto computes a SHA-256 hash of the executable's content at the BPF LSM layer and blocks execve before the process starts. Rename it, copy it to a new path, symlink it: the content hasn't changed, the hash matches, the block holds. We built that into Veto and wrote about it in the first post.

But you can only block what you've hashed. And AI agents keep introducing executables the deny list has never seen.

The discovery problem

Block npx. You add /usr/local/bin/npx to the deny list. Veto hashes it, blocks it, and blocks every copy regardless of where it's renamed or moved. That part works.

But /usr/local/bin/npx is the devcontainer's npx. Inside a Docker-in-Docker container, npx lives at /usr/bin/npx. Different path, different build, different bytes, different hash. Veto never saw it. It was never hashed. It runs.

And agents don't just use executables. They introduce new ones. npm install drops npx-cli.js in node_modules. A venv brings its own pip. A container pull brings another variant. Even installing a VS Code extension can pull in its own npx.

Compiled ELF binary or script with a shebang line: if it matches the name, it gets discovered, hashed, and blocked. Not because the admin remembered to add it, but because the system found it.

The enforcement model is sound. But the input was manual: you had to know every path, in every layer, ahead of time. Bare names fill that gap.

What changed

Type npx into the deny list. No path. No guessing.

A BPF-based discovery agent scans the devcontainer and every Docker-in-Docker container (however deeply nested). It finds every executable matching that name, hashes each one, and adds them to the enforcement map.

The scan is not one-time. The agent watches the filesystem in real time. Install a package, create a venv, pull a container image. A new npx appears, gets hashed, gets blocked. Automatically.

The name is the input. The content hash is the identity. Veto does not block anything called npx. It uses the name to discover executables, then enforces on their content hash. Same enforcement layer as the first post. The name tells Veto where to look.

Where it blocks

One deny list entry. Two execution contexts.

Watch now

The devcontainer's npx lives at one path. The DinD container's lives at another. Both blocked. The admin typed a name. The system found the rest.

How it fits

The first post proved the enforcement layer: content-addressable hashing at the kernel, blocking execve before the executable runs, no TOCTOU gap. That layer is unchanged.

What's new is the discovery layer above it.

Same enforcement. Every layer covered. No manual path hunting.

Try it

Veto is in early access. If you run AI agents in production and want kernel-level enforcement without the filesystem homework, let us know.