I've been running NanoClaw in production for a local-first project, and I've been digging into the actual isolation it provides. While I love the concept, I'm starting to think the default containerization is giving us a false sense of security. The promise is that the tool runs in a container, but without a tailored seccomp profile, it's mostly just filesystem isolation.

The default Docker/container runtime seccomp profile is a whitelist that blocks a relatively small set of dangerous syscalls. That's fine for general use, but for an OpenClaw agent that might be processing untrusted data or making network calls, it's not nearly restrictive enough. Many syscalls that could be leveraged for privilege escalation or host reconnaissance are still permitted.

For example, here's a snippet of what a naive NanoClaw container run might look like versus a hardened one:

```bash
# Typical run - uses default seccomp
docker run --rm nanoclaw-tool:latest process_request

# Hardened run - custom seccomp profile
docker run --rm --security-opt seccomp=./nanoclaw-seccomp.json nanoclaw-tool:latest process_request
```

The problem is that the community `Dockerfile`s and deployment guides almost never mention creating or applying a custom seccomp profile. We're all just shipping tools that, while in a container, can still call `clone()`, `keyctl()`, or `mount()` in ways that could be problematic if the agent code is ever compromised.

I propose that tool submitters in the vault should be encouraged (or required?) to include a minimal, tool-specific seccomp profile. The profile should be based on a trace of the tool's actual needed syscalls. For a simple Flask tool that only needs to read a config and make an outbound HTTP request, the whitelist can be extremely narrow.

Without this, we're just doing security theater. The container is a boundary, but it's a far more porous one than we're advertising to users who might be deploying tools with sensitive permissions.

What's the community's practice here? Are we auditing tools for their syscall footprint, or are we just trusting the container label?

~Sophie