Okay, so I've been running IronClaw agents in NanoClaw for about six months now, mostly orchestrated through Proxmox VMs and a Kubernetes cluster on the side. I'm a huge fan of the container-first design—it's what sold me on the platform. But after stress-testing a bunch of concurrent workflows, I've hit a wall with the implicit resource sharing. It feels like we're missing a critical knob.
The promise is strong isolation per agent task. In practice, I'm seeing mounts and volumes leak between contexts unless I'm hyper-vigilant. For example, I had a data preprocessing agent and a model training agent, each in their own NanoClaw container, but because they were spawned from the same orchestration template, they ended sharing a `scratch` volume. The preprocessor dumped partial data, the trainer started reading, and... corrupted model. Took me a weekend to trace it back to a default `volumes_from` inheritance in my orchestration config.
Here’s a simplified snippet of the kind of YAML that bit me:
```yaml
agent_unit:
name: "data-preprocessor"
base_image: "ironclaw-python-nano"
volumes:
- host_path: "/mnt/lab/shared_scratch"
container_path: "/scratch"
mode: rw
agent_unit:
name: "trainer"
base_image: "ironclaw-python-nano"
# Implicitly inherits the same '/mnt/lab/shared_scratch' mount
# because it's defined at the orchestration layer
```
The problem? The volume mapping is often defined at the **orchestration layer** (like in a Kubernetes Pod spec or a Proxmox template), not the agent definition itself. NanoClaw respects the container boundary, but if the orchestration system says "these two containers share a volume," NanoClaw doesn't have a built-in mechanism to say "no, not even if the orchestrator says so."
My proposal: a `zero-trust-isolation: true` flag (or something similarly named) at the **NanoClaw agent spec level**. When set, it would:
* Disable all implicit volume inheritance from the orchestrator.
* Require all volumes to be explicitly declared within the agent unit's own spec.
* Enforce that any shared volume must have its `read_only` flag set to `true` unless a specific, auditable `rw` exception is granted (maybe via a signed config hash?).
* Drop any bind mounts that point to host paths outside a defined, secure allowlist (e.g., only `/opt/nanoclaw/isolated_workdirs/*`).
Where the current model breaks down:
* **Concurrent Workloads:** Orchestrators like Kubernetes might schedule two unrelated agent tasks on the same node and, for efficiency, reuse a volume template.
* **Misconfigured Orchestration:** A typo or a copy-paste error in a Pod or VM definition can instantly bridge isolation.
* **Legacy Shared Volumes:** The "well, it's always been mounted there" pattern from older homelab setups creeping in.
Without this, we're relying on perfect orchestration configs—and in a homelab, where we're constantly tinkering, that's just not realistic. I want my agents to *assume* hostility from any other process, including other agents launched by the same orchestrator.
Has anyone else run into these subtle leaks? How are you working around it—custom SELinux/AppArmor profiles? Static analysis on your orchestration YAML? Would love to compare notes.
- Greg
More VLANs than friends.
That's a pretty nasty bug to chase down over a weekend. I'm still getting my own NanoClaw lab set up, so this is good to watch out for.
> default `volumes_from` inheritance in my orchestration config
Is this an inheritance in your own templates, or is NanoClaw itself doing something implicit under the hood? I'm trying to picture where the flag would actually go. Would it be on the agent spec, or more like a global runtime policy for the whole enclave?
I wonder if a simple workaround for now is to just make the container path unique per agent, even if the host path is the same. Like `/scratch_agent_a` and `/scratch_agent_b` pointing to the same `/mnt/lab/shared_scratch`. Would that at least stop the accidental cross-read, or does the underlying volume sharing still cause conflicts?
I think you're asking exactly the right question about where the flag should live. It's a bit of both, which makes it tricky. From what I've seen poking at the API, the agent spec can suggest volumes, but the enclave's runtime policy seems to have final say on what actually gets mounted. That implicit handshake is where I think the leak happens.
Your workaround with unique container paths is a good tactical fix for the cross-read issue, and I've done something similar with symbolic links inside the container entrypoint scripts. But it doesn't solve the underlying conflict if both agents are trying to manage the same filesystem location on the host simultaneously - you still risk corruption from concurrent writes. It just adds a layer of obscurity.
> Is this an inheritance in your own templates, or is NanoClaw itself doing something implicit under the hood?
I lean towards it being a NanoClaw default. My templating is pretty vanilla, and I've seen the same behavior across fresh stacks. Maybe someone with more orchestration time can confirm if there's a daemon flag we're missing.
Trust no one, verify every packet.