AI agent security: five layers of isolation for a self-hosted autonomous agent

An agent that can execute code and reach the internet is a different security object from a chatbot. It deserves a different architecture. This is the one I built, layer by layer, and, more usefully, the specific thing each layer is there to stop.

The machine

The hardware is deliberately unremarkable: a 2016 MacBook with no fan, propped open like a tent so it does not cook itself. It runs headless. I never look at its screen; I reach it over the terminal from my main machine. The point of a separate machine is not performance. It is that a compromised agent should not be sitting inside the same operating system as your photographs, your password manager and your logged-in browser sessions.

Layer 1 — identity isolation

The machine was wiped to factory settings and the Apple ID removed entirely. Nothing installs through an app store; everything installs through the terminal.

What this stops: theft of authentication tokens. If the agent is compromised and gains read access to the file system, there are no iCloud session keys, no Keychain entries, no iMessage history and no browser cookies to take. Session hijacking is worse than a stolen password, because a stolen session needs no second factor and produces no login alert. The cheapest defence is to have nothing there to steal.

Layer 2 — network and hardware isolation

Headless server, lid closed, no inbound ports. The agent reaches its control surface, in my case a Slack workspace, over an outbound secure WebSocket.

What this stops: external network attack. An adversary scanning your router finds no listening service, because the machine only ever initiates connections and never accepts them. This is not a theoretical concern for this class of software: CVE-2026-25253, a WebSocket hijacking flaw with a CVSS score of 8.8, was reported alongside thousands of instances exposed directly to the internet.

Layer 3 — operating system access control

The agent runs under a dedicated account with no superuser privileges and no sudo.

What this stops: escalation after a container escape. If the adversary breaks out of the container into the host, they arrive in an unprivileged account. They cannot install a rootkit, alter the firewall, or read protected system files. This is the principle of least privilege applied at the layer where it is cheapest to enforce.

Layer 4 — containerisation

The agent runs inside a container with hard resource limits.

What this stops: file system and process visibility. The agent sees only the paths explicitly mounted into it. It has no route to the host user directory. Note the honest limitation: a container is a static boundary. It decides what can be reached, not what is intended.

Layer 5 — runtime sandbox

This is the layer that did not exist in usable form until recently. Yesterday at GTC in San Jose, NVIDIA announced NemoClaw, a stack that installs onto OpenClaw in a single command, and with it OpenShell, a runtime that sandboxes agents at the process level using kernel primitives (Landlock, seccomp, network namespaces) together with an out-of-process policy engine and a privacy router.

The design decision that matters is out-of-process enforcement. The policy layer sits outside the agent process, so the agent cannot argue its way past the controls that are supposed to contain it. Prompt-level guardrails can be talked around; a syscall filter cannot.

What this adds on top of a container: intent, not just boundary. If a script inside the container tries to open an outbound connection to exfiltrate data, or to read a credentials file, the specific syscall is blocked without killing the whole workload.

Two caveats worth stating plainly. NVIDIA labels the project alpha and explicitly not production-ready. And on x86_64 hardware, where the container runtime is already inside a hypervisor-managed virtual machine, adding another inspection layer costs latency: expect complex commands to take a second or two longer.

Why five and not one

The property this architecture has is the absence of a single point of failure. A zero-day in the runtime sandbox is caught by the container. A container escape is caught by the unprivileged account. A compromised account finds no credentials, because of layer one. No individual layer is trustworthy. The stack is.

This is overkill for testing a chatbot. It is the minimum for a system that has permission to run code and reach the internet on your behalf.