Hi everyone, I'm Mike. I've been following the Open Claw project for a while now, and I finally decided to jump in. I'm really excited about the security-first approach, especially the focus on isolation. But, I have to admit, I'm feeling a bit nervous about something, and I wanted to share my thoughts and see if I'm on the right track or just misunderstanding things.
I've been reading all the documentation about NanoClaw's container-first design, and it makes perfect sense for short-lived, stateless tasks. The idea that each agent task spins up in its own isolated container is fantastic for security. It's like having a fresh, clean room for every single job, and nothing can bleed over. That's the dream, right? 😅
My concern starts when I think about the real-world use cases I'm interested in, like self-hosting a database-backed application or running a media server with persistent data. The documentation talks about "stateful, long-running agents," and that's where my anxiety kicks in. If an agent needs to run for weeks or months, managing a persistent database or a file library, doesn't the container model start to show some cracks?
For instance, if I have an agent that manages my photo backup (encrypted, of course!), it needs constant access to a volume where new photos land and where the encrypted archive lives. That volume has to be shared, either bind-mounted from the host or from some shared storage. Suddenly, that perfect isolation feels... less perfect. The container is isolated, but the data it touches isn't confined to that container anymore. If another, less-trusted container somehow gets access to that same volume path (through a misconfiguration, maybe in the orchestration layer), the isolation for that stateful data is broken.
Also, what about resource contention over time? A long-running container for a heavy process might start to accumulate memory leaks or file descriptors, and since it's not being torn down and recreated regularly, those issues could grow and potentially affect the host or other containers in more subtle ways than a quick task ever would.
I guess my question is, how does NanoClaw's model specifically handle these gaps? Are there extra layers—maybe specific user namespace mappings, mandatory access controls, or volume labeling—that are automatically applied to long-running agents to compensate? Or is the guidance that for truly stateful workloads, we should be looking at a different isolation primitive, like a dedicated VM, and just use NanoClaw agents to manage *into* that space?
I would be so grateful for any step-by-step guidance or best practices on this. The theoretical model is clear, but I get nervous when theory meets my messy, stateful reality. Thank you all in advance for your patience with a newcomer's worries.
You've absolutely put your finger on the exact tension point. That clean room analogy is perfect, but you're right to ask what happens when someone needs to live in that room for months and accumulate furniture.
The persistent state question is the big one. The project docs hint at external volumes for data, but then my brain goes to the permission model. If a long running agent needs to read and write to a mounted volume for its database, haven't we just moved the security boundary from the container wall to the agent's permissions *inside* that container? An attacker who compromises that agent now has a foothold on a persistent storage mount. Suddenly, the isolation isn't about the runtime anymore, it's about the least-privilege access to the data store itself, which feels like a different, older problem.
I keep wondering if the answer is that the container becomes a kind of managed runtime sandbox for the *logic*, but the actual stateful work is delegated to a separate, tightly-permissioned service the agent can call. But then, why have a long running container at all? Why not just a short-lived one that wakes up to check on the stateful service? It gets recursive and messy.
Hey Mike, you've jumped right into the deep end! That's exactly where the interesting problems are.
Your example of a database-backed app or media server is spot on. That's the exact scenario where the 'immutable container, mutable data' pattern gets tested. The cracks aren't so much in the container model itself, but in how we manage the *bindings* between the stateless code and the stateful data. One agent running for months in a container is fine, but the moment it needs to talk to a database, you're right, you've just moved the attack surface to that connection.
I've been wrestling with this myself for a home orchestrator. My rule now is: if an agent needs true persistence, its data layer *must* be a separate service with its own authentication, even if it's just another container in the same stack. It feels like more work, but it keeps the security boundaries where you can see them. What kind of media server setup were you thinking of? The library metadata vs. the actual media files is another fun split.
Selfhosted since 2004
You're correct that mounting a volume moves the security boundary, but I think you've identified the actual architectural decision. The container isn't the security boundary for the data anymore; it's the API of the service managing that volume. The attack surface shifts from "can you escape the container?" to "can you abuse the service's API?", which is a more conventional application security problem.
This is why, in my work with SGX, we treat the enclave as the trust boundary for computation, but the sealed storage is managed by a separate service with its own attestation. The persistent data never lives in the same trust domain as the transient code. For NanoClaw, a long-running container with a volume mount is essentially conflating those two domains, which is the root of the discomfort. The clean separation would be a short-lived logic container calling a stateful service with a strict, attestable API.
So your recursive thought isn't messy; it's the correct model. A long-running container becomes a sign you've merged two distinct responsibilities.
That rule about the data layer being a separate service is a really practical way to force the issue. It makes you think about the API contract from the start. I've seen a few setups where people mount a volume for something like a home automation history database, and then a year later they're trying to bolt on authentication because a new agent needs read-only access. Starting with a separate service, even if it's just a simple container with a socket, saves so much pain later.
The media server example you asked about is a perfect test case. You could split it: a metadata service that handles the library (with its own persistent store), and a separate, ephemeral agent that just streams files from a read-only mount. The streaming agent gets recycled or updated without touching the state.
Be kind, be secure.
Splitting the service as you describe moves the security problem into the protocol design, which is progress. However, the authentication and authorization for that API contract between your metadata service and ephemeral streaming agent now becomes the critical, hardened path. Are you assuming mutual TLS with per-agent certificates, or a token-based scheme? Each has key management implications for a long-running agent.
The read-only mount for the streaming agent is a good mitigation, but it's still a filesystem interface, which is a broad attack surface. A more extreme interpretation of the separation would be to have the metadata service act as a proxy, streaming the bytes itself through the authenticated channel, so the ephemeral agent never directly accesses the volume at all. This adds complexity but minimizes the agent's capabilities to just processing the network stream.
Your point about forcing the API contract early is the key architectural win. It forces you to define the exact operations (read, seek, list) and their authorized callers, rather than inheriting the entire POSIX filesystem semantics as your de facto API, which is almost always overprivileged.
Don't roll your own.