NemoClaw Security Explained

Security Overview

NemoClaw doesn't have one security feature. It has four interlocking layers. Each layer protects against a different threat. Together, they create a defense-in-depth approach where breaching one layer doesn't compromise everything.

Layer 1: Landlock — The Filesystem Jail 🗝️

What it is: Landlock is a Linux Security Module (LSM), a feature built directly into the Linux kernel. It enforces filesystem access restrictions at the most fundamental level of the operating system.

The analogy: Imagine the agent lives in a room in a large building. Landlock is the physical walls of that room: the actual concrete and steel, not just a sign saying "Do Not Enter." The agent physically cannot reach anything outside that room. It's not a policy rule that could be overridden or bypassed. The building's structure itself prevents access.

What the agent CAN read/write:

• /sandbox — the agent's home directory. Full read and write access. This is where it stores its work, memory files, and workspace.
• /tmp — temporary storage. Full read and write access. Used for intermediate files.

What the agent can read (but NOT write):

• /usr, /lib, /proc — system files it needs to function
• /dev/urandom — random number generation (needed for cryptography)
• /app, /etc, /var/log — application and system config files

What the agent CANNOT access at all:

• Your home directory (~) — your documents, downloads, pictures
• Other users' files
• System configuration files (write access)
• OpenClaw's workspace on the host machine
• Anything not on the explicit allowlist

What this means for your data: Even if an AI model were manipulated into trying to access your tax documents, it physically cannot. The kernel blocks the access before it can happen. This isn't a safety guideline. It's a hardware-level enforcement mechanism.

Layer 2: seccomp — The System Call Filter 🔧

What it is: seccomp (Secure Computing Mode) is another Linux kernel feature. It controls which "system calls" a process is allowed to make.

Background: Every program communicates with the operating system through system calls: requests like "create a file," "open a network connection," "start a new process," "read from this address in memory." These are the primitive building blocks of everything a program can do.

The analogy: Imagine the agent is a contractor in your office. seccomp is a list of approved tools they're allowed to use. They can use a keyboard, a phone, a PDF reader. But they can't use a drill, a welding torch, or a lockpick. Even if they brought their own lockpick, security would confiscate it before they could use it, at the building entrance (the kernel), not just at the door to your office.

What system calls are blocked:

• setuid / setgid — becoming root/admin. Even if the agent wanted to escalate privileges, the kernel refuses.
• ptrace — attaching to other processes (the mechanism for debuggers and some types of attacks)
• execve with arbitrary paths — running arbitrary programs from outside the allowed set
• Several dozen other dangerous or unnecessary calls

Why this matters beyond the filesystem restrictions: Even if Landlock were somehow bypassed, seccomp prevents the agent from escalating privileges or breaking out of the container. Two independent layers mean both must fail simultaneously for a breach to occur.

Layer 3: Network Namespace — The Private Network 🌐

What it is: Linux network namespaces create completely isolated network stacks. The agent runs in a network environment that is separate from your actual computer's network, with its own virtual network interfaces, routing tables, and firewall rules.

The analogy: The agent has a private phone line inside the jail. This phone line is completely separate from your office phone system. The only numbers it can dial are the ones pre-programmed by the jail administrators, and all calls go through a monitored switchboard before reaching the outside world.

What this means:

• The agent cannot see your LAN (local network devices, printers, file shares, other computers)
• The agent cannot initiate direct connections to the real internet
• ALL network traffic must pass through the OpenShell gateway. There is no other way out
• Your internal network is completely invisible to the sandbox

This is critically important for businesses. An unsandboxed agent with access to your network could theoretically discover and interact with your internal systems: your accounting server, your client database, your email server. The network namespace makes all of that invisible.

Layer 4: Egress Policy — The Approved Contacts List 📋

What it is: A YAML file that defines exactly which external servers the agent is allowed to contact. The OpenShell gateway enforces this list on every outbound connection attempt.

The analogy: Continuing the phone analogy: the switchboard has a pre-approved contacts list. The agent can only call numbers on that list. If the agent tries to call an unlisted number, the switchboard intercepts the call, tells you someone tried to call [destination], and asks if you want to approve it.

Default approved endpoints:

egress:
  rules:
    # AI inference
    - host: api.anthropic.com
      port: 443      # Claude API
    - host: integrate.api.nvidia.com
      port: 443      # NVIDIA cloud inference

    # Development tools
    - host: github.com
      port: 443
    - host: api.github.com
      port: 443
    - host: registry.npmjs.org
      port: 443      # npm packages (GET only)

    # OpenClaw ecosystem
    - host: clawhub.com
      port: 443      # Skills marketplace
    - host: openclaw.ai
      port: 443

    # Messaging
    - host: api.telegram.org
      port: 443

The hot-reload advantage: Unlike the first three layers (locked at sandbox creation), the egress policy can be updated while the sandbox is running. You can add a new allowed endpoint by editing the YAML file and saving, no restart required. This is essential for business deployments where you need to gradually add approved integrations.

How to add a business-specific endpoint:

# Add your CRM's API endpoint
- host: api.your-crm.com
  port: 443

# Add your practice management software
- host: app.your-pms.com
  port: 443

What Happens When the Agent Hits a Blocked Host

When the agent tries to contact a server not on the egress allowlist, here's the exact sequence:

1. Agent attempts to initiate a TCP connection to the target host
2. The request reaches the OpenShell gateway (the only egress point)
3. Gateway checks the request against the egress policy YAML
4. Host not found in allowlist → connection rejected
5. Gateway logs the attempt with full details: hostname, port, timestamp, which process attempted the connection
6. The OpenShell TUI (terminal dashboard) displays a notification showing the blocked request
7. The connection returns an error to the agent, so it knows the request was refused
8. The agent reports back to you: "I tried to reach [host] but it was blocked"

The Approval Flow

When a network request is blocked and shown in the TUI, you have two choices:

What Data Can and Cannot Leave the Sandbox

With vs Without NemoClaw