The Alternatives section rules out kernel level enforcement on this basis:
AppArmor / SELinux: Profile authoring is notoriously painful and distro-specific. Agentveil delivers a portable, agent-shaped alternative.
That is a fair description of AppArmor and SELinux, and it does not carry over to the two mechanisms that are actually the closest competitors:
- Landlock (Linux 5.13+, unprivileged, per process). A process voluntarily restricts itself and its descendants to a set of path rules. There is no system policy file, no distro specific profile, nothing to install, and no root. Landlock 5 adds TCP connect and bind restrictions. This is very close to what the whitepaper wants the filesystem and network layers to do, and none of the AppArmor objections apply to it.
- Seatbelt (
sandbox-exec) on macOS. Deprecated in name for years, still present, and used in production by shipped coding agents to confine their own tool execution. Profiles are per invocation, not system wide.
Neither is a complete answer on its own. Landlock is Linux only and has no notion of "which tool asked", no audit trail, no MCP awareness, no review prompt, and no policy format a human wants to write by hand. Seatbelt is macOS only and its policy language is awkward and undocumented.
That is the interesting version of this project, and I think it is stronger than the one in the document: Agentveil as the policy layer, the audit layer and the agent aware layer on top of Landlock and Seatbelt, rather than a new enforcement engine underneath them. The trusted computing base stays small because the enforcement is the kernel's, the portability story becomes a compilation target problem rather than an interposition problem, and the project's actual contribution (an agent shaped policy format, taint aware decisions, a reviewable log, MCP tool awareness) is exactly the part that does not exist today.
It also reframes the Rust versus TypeScript open question. If the enforcement is the kernel's, the policy compiler does not need to be Rust for performance reasons, and sharing code with Nanocoder becomes the stronger argument.
What would help: address Landlock and Seatbelt directly in Alternatives, and say whether Agentveil builds on them or replaces them. If it replaces them, the document should say what a bespoke mechanism buys that they do not.
Raised during the public review window (closes 2026-09-19).
The Alternatives section rules out kernel level enforcement on this basis:
That is a fair description of AppArmor and SELinux, and it does not carry over to the two mechanisms that are actually the closest competitors:
sandbox-exec) on macOS. Deprecated in name for years, still present, and used in production by shipped coding agents to confine their own tool execution. Profiles are per invocation, not system wide.Neither is a complete answer on its own. Landlock is Linux only and has no notion of "which tool asked", no audit trail, no MCP awareness, no review prompt, and no policy format a human wants to write by hand. Seatbelt is macOS only and its policy language is awkward and undocumented.
That is the interesting version of this project, and I think it is stronger than the one in the document: Agentveil as the policy layer, the audit layer and the agent aware layer on top of Landlock and Seatbelt, rather than a new enforcement engine underneath them. The trusted computing base stays small because the enforcement is the kernel's, the portability story becomes a compilation target problem rather than an interposition problem, and the project's actual contribution (an agent shaped policy format, taint aware decisions, a reviewable log, MCP tool awareness) is exactly the part that does not exist today.
It also reframes the Rust versus TypeScript open question. If the enforcement is the kernel's, the policy compiler does not need to be Rust for performance reasons, and sharing code with Nanocoder becomes the stronger argument.
What would help: address Landlock and Seatbelt directly in Alternatives, and say whether Agentveil builds on them or replaces them. If it replaces them, the document should say what a bespoke mechanism buys that they do not.
Raised during the public review window (closes 2026-09-19).