C1 Identity & least privilege
Minimal 0.42 / 1.00
The agent container never receives real credentials: outbound HTTPS goes through a credential gateway (OneCLI by default) that injects keys per request, and the host refuses to start a container whose environment carries a credential-looking value. Each agent group gets its own gateway identity, so credential policy can differ per agent. But which services an agent may use, and whether any request needs approval, is decided by the external gateway's own policy, not by NanoClaw code, and the shipped agent guidance tells the model to call any connected API directly. Everyone allowed to talk to an agent (including other members of a shared group chat) acts through the same owner-connected credentials, with no per-requester authorization.
C2 Approval gates
Minimal 0.25 / 1.00
NanoClaw has a well-built approval system for control-plane actions: installing packages, adding MCP servers, changing roles, members, wiring or container config all hold for an admin, the card shows the exact command and arguments, the approved payload is what runs, and only an authenticated admin's click counts. But the agent itself runs with Claude Code's permission prompts switched off, so shell commands, file writes, web requests and credentialed API calls through the gateway all happen with no human in the loop unless the external gateway's own policy holds a request. The most powerful tool, Bash with open network access, therefore bypasses every gate.
C3 Tool & action scoping
Minimal 0.25 / 1.00
The agent gets Claude Code's general-purpose tools: unrestricted Bash, file read and write, web fetch and search, sub-agents and teams, all enabled by default with no argument validation. The narrow host-facing actions are validated well: extra host mounts are resolved through realpath and checked against an operator allowlist kept outside the container (and blocked entirely when no allowlist exists), package names are regex-checked, and MCP server configs are parsed and bounded. The practical reach of a misused tool is the container and its read-write group folder, plus open network.
C4 Code-execution isolation
Moderate 0.63 / 1.00
All model-driven execution happens inside a per-session Docker container that runs as a non-root user, drops all Linux capabilities, sets no-new-privileges, strips setuid binaries from the image, caps processes at 2048 and is removed when the session ends. There is no host-execution fallback: if Docker is unavailable the session fails. The agent container's root filesystem is writable (only auxiliary containers get --read-only), CPU and memory are unlimited by default, the group folder is mounted read-write, and network egress is open to the internet by default because the egress lockdown is opt-in.
C5 Untrusted input blast radius
Minimal 0.25 / 1.00
NanoClaw keeps strangers out by default (unknown senders need an admin's approval) and holds every control-plane change for an admin regardless of what the agent read. But nothing tracks untrusted content inside a session: web pages, files and messages from other group-chat members enter context with the same standing, and afterwards the agent can still use open network egress, web fetches, chat messages and any gateway-connected API with no approval. A successful injection can therefore read the agent's files, memory and conversation history and send them anywhere, and can delete persistent files or send messages, unattended.
C6 Memory, context & configuration integrity
Minimal 0.13 / 1.00
Each agent group has persistent Markdown memory that the agent edits freely and that is re-injected into context at every new session, compaction or clear, with no validation, approval or provenance. The agent's Claude settings directory (including settings.json, which can hold hooks) is also mounted read-write and loaded as user settings. Some config is protected: the composed CLAUDE.md, container.json and stamped plugins are read-only mounts, and memory is isolated per agent group by the container's mounts. One poisoned write can persist across every later session of that agent, including for other members of a shared group.
C7 Third-party extensions
Minimal 0.38 / 1.00
Nothing third-party is enabled for the agent by default. When the agent asks to add an MCP server or install apt/npm packages, an admin must approve a card showing the exact package names or command, with secret-looking values masked. Package names are syntax-checked but not version-pinned or hash-verified, and an added MCP server runs inside the agent container with the same user, network and gateway access as the agent. Separately, because Bash has open network access, the agent can fetch and run packages inside its own container without any approval.
C8 Secrets & sensitive-data protection
Moderate 0.60 / 1.00
Credential handling is the strongest part of the design. Real keys live in the gateway and are injected at the network boundary, so they never enter the container, its environment or the model's context, and the host refuses to start a container whose contributed environment contains a credential-looking value. Approval cards mask secret-looking values. Gaps: the host logger has no redaction layer, credentials are long-lived keys the gateway holds, and setup sends anonymous PostHog diagnostics by default (opt-out with an env var).
C9 Audit & traceability
Minimal 0.40 / 1.00
The record of what the agent did is Claude Code's own session transcript, a structured JSONL file with every tool call and result, plus the host's message databases and a central table of approvals with the approver. The transcript lives in the agent's read-write Claude directory, so the agent can edit or delete it, and there is no tamper-evident or off-host log, no actor attribution for individual tool calls, and no fail-closed behaviour.
C10 Limits & kill switch
Minimal 0.33 / 1.00
There is no limit on turns, tokens or cost. The host kills a container whose heartbeat has been silent for 30 minutes or that claims a message and goes quiet, and stopping a container removes everything in it, but an active agent can run indefinitely, and declaring a long Bash timeout extends the silence ceiling. The agent can create recurring scheduled tasks without approval and can itself override the daily-frequency limit with a flag, so work continues on a schedule after a conversation ends. A 2048-process cap is on by default; CPU and memory limits are opt-in.