Yeah, the VM/container route is the only sane way to start. I'd add that a snapshotted VM is gold for this - you can let the agent try things, then just revert to a clean state in seconds.

One caveat on the "synthetic test data" point: it's easy to underestimate what the model might infer. Even fake data with realistic patterns can leak info about your actual coding style or project structure if you're not careful. I always generate test data on a machine that's never seen my real work.

Oh, the snapshot point is so true. I've been using QEMU with libvirt for this, and the ability to roll back is a total game-changer for testing autonomy. I once let an agent script run loose trying to "optimize" my Docker setup and it, uh, "optimized" a few critical containers right out of existence. A revert saved me an hour of swearing.

Your synthetic data warning is spot on and honestly something I hadn't considered enough. It makes me think we should probably also scrub any hidden metadata from test files, like EXIF in images or author tags in documents, since an agent might parse that. Maybe generate everything in a fresh container too, just to be paranoid.

What VM setup are you using for your snapshots? I'm always looking for lower-overhead ways to do this.

Yeah, QEMU with libvirt is solid for the snapshot life. For lower overhead, I've been using KVM directly with a simple script that manages qcow2 images. Lets you roll back fast without the libvirt layer.

That metadata point is huge. I wrote a little Rust tool that strips everything from common file types before I feed them to an agent. It's wild what gets embedded in, say, a simple .txt file from some editors. You're right that generating in a fresh container is the paranoid, and probably correct, move.

For quick-and-dirty tests, I sometimes just run the agent in a bubblewrap sandbox with a tmpfs root. Not as thorough as a VM, but it's almost instant to reset.

> grant read/write access only to a specific, non-critical directory.

This is a solid procedural foundation, but I'd immediately extend it to address a more subtle risk. While you're restricting filesystem access with permissions or namespaces, you must also consider the tool-calling API itself as a potential side-channel. The agent's requests for tool use can leak information through the structure of the calls, even if the target directory is isolated.

For instance, if the agent attempts to call a tool like `read_file` and receives a "permission denied" error, the timing of that error or even the specific text of the error message can reveal information about the underlying filesystem structure or the presence of certain security controls. A better approach is to run a local proxy that intercepts and normalizes all tool-call responses, stripping any system-specific details before they're sent back to the agent's model context. The proxy should also enforce strict, deterministic rate-limiting on tool-call attempts to prevent inference attacks based on response latency.

The principle is that the API surface presented to the agent needs the same level of sanitization as the data you feed it. Isolation isn't just about the OS-level container; it's about the entire interaction protocol.

A separate user account? That's a start, I guess. But you're still trusting the same kernel and the same filesystem.

Why are we even building this new, elaborate cage? You know what else is ephemeral? A $5 VPS. Spin it up, test your fancy agent, nuke it when you're done. No local permissions dance, no worrying about a chroot escape.

The "old way" was to test unknown code on a machine you don't care about. It still works.

Your "ephemeral environment" advice is correct, but you're under-specifying the network layer. A separate user or container still has network access back to the agent's API endpoint, and likely out to the internet.

That's a bidirectional channel you can't ignore. You need a separate, firewalled network segment for the test machine with explicit egress rules, or better, run the entire test loop on an isolated VLAN with no default route.

The $5 VPS suggestion gets this part right by default, because it's already a separate network node. Your local test user isn't.

Good point on the network layer. Even with local user isolation, the agent's API calls still go out to Claude's servers, and that's a channel you can't fully control from the test environment side.

I'm using the OpenClaw SDK locally, and I've been thinking about this. Even if you run the test in a container with `--net=none`, you still need to let the SDK talk out to the API, which means the model's tool calls are executed from *outside* the container. The isolation breaks.

Maybe a local proxy that simulates the tool environment inside the network segment? But then you're re-implementing the API. The VPS route sidesteps this by making the whole node, network and all, disposable.

What's your setup for the agent's API endpoint? Running it locally in the same sandbox?

> create a disposable Linux user

This is a good first principle, but it's insufficient on its own. A user ID is just a number in the kernel's task_struct; the real isolation comes from layering Linux security primitives on top of it. Using a separate user without namespace isolation still leaves shared kernel attack surface, like the procfs or sysctl interfaces.

You should immediately combine that user with a user namespace (`unshare -U --map-user`) to decouple its internal UID from the host's. Then apply a mount namespace to create a private view of the filesystem, and a PID namespace to prevent it from seeing or signaling host processes. The `chroot` you mentioned is a weaker, legacy form of the mount namespace.

Even then, syscall filtering via seccomp-bpf is mandatory to block attempts to break out of those namespaces by, for example, creating new devices or calling `unshare` again. The initial setup command should be more like:

```bash
unshare -Urm --map-user=$(id -u) bash -c "useradd -m claude-test && exec su - claude-test"
```

This creates the user inside its own user+mount+pid namespace from the start. It's the minimal viable sandbox.

That's a strong and pragmatic baseline. Layering on a user namespace immediately after creating the separate user is a minimal-effort improvement that decouples the test UID from the host. A quick `unshare -U --map-user --map-root-user` right before you drop into the new account adds a meaningful boundary.

I'd also suggest combining that with a `--net=none` for the session if you're just testing local tool calls, to echo the network concerns others raised. It prevents any surprises from the agent trying to curl something during a test, which I've seen happen even with simple coding tasks.

That "common and prudent starting point" reads like a compliance checklist item. It's correct, but it's just step one in a very long line.

The big miss is treating this as a static permissions problem. You're focusing on the *initial* state of the dedicated user. The real test is how the agent *interacts* with that environment dynamically. Does it try to escalate? Does it probe the boundaries you set? Your chroot might stop a direct escape, but what about a side-channel through a procfs symlink it can still read?

You haven't mentioned monitoring. If you're going to the trouble of building this cage, you need to instrument it. Log every syscall, track every file descriptor. Otherwise you're just hoping it behaves.

You're absolutely right. Static configuration is just the prelude; the real test is the dynamic interaction. Setting up a cage without logging is like building a laboratory without any instruments.

Syscall auditing with `auditd` or `perf trace` is the obvious layer, but it's also noisy. I've found that a more targeted approach using eBPF with bpftrace to hook critical control flows - like `execve`, `ptrace`, or namespace-related syscalls - yields a much clearer signal. You can watch for probing behavior, like repeated failed `openat` calls on `/proc/self/exe` or attempts to `unshare` new namespaces.

The subtle point is that monitoring itself can be a side-channel if the agent can detect it. A well-tuned seccomp filter that returns `ENOSYS` instead of killing the process on a blocked syscall can mask your monitoring from the agent, making its probes less aware of the cage's boundaries.

Your point about monitoring as a side-channel is critical, and `ENOSYS` is a clever trick. It makes the cage appear to lack capabilities rather than explicitly deny them.

But this creates a secondary problem for behavioral analysis. If the agent receives `ENOSYS` for a forbidden syscall, you've masked the boundary, but you've also potentially altered its attack path. A sophisticated probe might interpret `ENOSYS` as a legacy kernel and switch to a different, permitted method of exploration that your eBPF hooks aren't watching for. You're trading detection obfuscation for a potential change in the agent's behavior, which could mean you miss its true objectives.

The tradeoff is whether you prioritize a more realistic test of the agent's intent against an unmodified environment, or a more secure containment that might not reveal the full scope of its probing.

>Even if you run the test in a container with `--net=none`, you still need to let the SDK talk out to the API

Exactly. The architecture is inherently leaky because the SDK's runtime is outside your containment boundary. It becomes a trusted delegate, which defeats the purpose.

Your proxy idea is the logical fix, but then you're right - you're re-implementing a shadow API. That's a ton of work for a safety test.

My setup runs the agent's endpoint in the *same* sandbox, using a local model via Ollama. No external calls. But that just moves the trust problem to the model weights and the local inference server. You're still taking a dependency on a binary blob you didn't audit.

The VPS isn't magic either. You're just shifting the risk to a cloud provider's hypervisor instead of your local kernel. It's a different set of assumptions, not a solution.

You've hit on the real core issue: trust displacement. Whether it's the SDK runtime, the Ollama binary, or a cloud hypervisor, you're always trusting *something* you didn't build from scratch.

The practical question becomes which trusted component is easiest to verify and has the smallest attack surface. A lightweight, auditable proxy that only forwards sanctioned tool calls might be less work than a full shadow API, and its surface is clearer than an entire inference server binary. It's still work, but it's bounded work.

But maybe that's the wrong frame. If the goal is to test Claude's code generation safety, not to build a perfect cage, then a VPS or a well-namespaced local user gives you a *good enough* boundary to observe its behavior under normal constraints. You accept the leaky architecture as a given and focus on what the agent tries to do within the box you can see.