kernex-sandbox

OS-level system protection for AI agent subprocesses.

Uses a blocklist approach: everything is allowed by default, then dangerous system directories and the runtime's core data are blocked.

• macOS: Apple Seatbelt via sandbox-exec -p <profile> — denies reads and writes to {data_dir}/data/ (memory.db) and config.toml; denies writes to /System, /bin, /sbin, /usr/{bin,sbin,lib,libexec}, /private/etc, /Library.
• Linux: Landlock LSM via pre_exec hook (kernel 5.13+ minimum, 6.12+ for full ABI::V5 enforcement; older kernels apply best-effort protection using only the rights they support) — broad read-only on / with full access to $HOME, /tmp, /var/tmp, /opt, /srv, /run, /media, /mnt; restricted access to {data_dir}/data/ and config.toml.
• Other: Falls back to a plain command with a warning.

protected_command is best-effort and never fails: when the host cannot apply OS-level enforcement it returns an unsandboxed command and logs a warning. For deployments where running unsandboxed is unacceptable, set SandboxProfile::require_os_enforcement = true and call try_protected_command instead, which surfaces an std::io::Error when enforcement is unavailable. os_enforcement_available reports the host's capability without building a command.

Also provides is_write_blocked and is_read_blocked for code-level enforcement in tool executors (protects memory.db and config.toml on all platforms).

This crate is intentionally standalone with zero internal dependencies, making it usable outside the Kernex ecosystem.

kernex-sandbox

OS-level sandbox primitives for the Kernex AI agent runtime.

Wraps platform-native isolation so tool execution and skill subprocesses run with the smallest workable privilege set:

• macOS: Seatbelt (sandbox-exec) profiles generated as SBPL strings
• Linux: Landlock LSM (kernel 6.x+ for full enforcement, partial on older kernels)
• Other platforms: a no-op profile that compiles cleanly so cross-platform code does not fork

The crate exposes SandboxProfile (configurable read/write/exec rules) and a pre_exec helper that applies the active profile inside tokio::process::Command.

You usually consume this through kernex-runtime; use it directly only when building a custom executor.

Documentation

• API reference: https://docs.rs/kernex-sandbox
• Project overview: https://github.com/kernex-dev/kernex

License

Apache-2.0 OR MIT.