A container is not a policy: governing API calls from NanoClaw agents

You message your NanoClaw agent on WhatsApp: "Refund the last order from Priya."

NanoClaw already did the hard part of agent safety. The agent runs in its own container. It can't read your home folder. It never holds a raw API key. So the refund is safe, right?

Not quite. The container keeps the agent away from your machine. It doesn't decide whether this refund should happen, for this amount, without asking you first. That's a question about the API call, not the sandbox.

This post covers why NanoClaw is a great home for a personal agent, what Swytchcode adds on top, and how to wire them together.

Why NanoClaw

NanoClaw is an open-source personal assistant built on Anthropic's Claude Agent SDK. It started as a reaction to agent frameworks that grew too big to audit. Its answer: "one process and a handful of files."

• Small enough to read. You can understand the whole codebase in an afternoon. When something goes wrong, you can find out why.
• Each agent in its own container. Agents run in Linux containers on Docker. As the project puts it, that's "filesystem isolation, not merely behind permission checks." An agent sees only the folders you mount.
• No raw keys in the agent. Outbound requests go through a credential gateway that injects keys at request time, so the agent never holds them.
• Every chat app you use. WhatsApp, Telegram, Slack, Discord, Teams, iMessage, Matrix, Google Chat, email and more. You add a channel with a skill, not a config file.
• Agents that work on a schedule. Recurring jobs, with script gates that skip a wake-up when there's nothing to do.
• Yours to change. NanoClaw prefers code changes over config. Fork it and have Claude Code tailor it.

NanoClaw answers one question very well: what can the agent reach? Its container is the wall.

It leaves a second question open: which API calls should go through, and who says yes? The container can't tell a balance check from a refund. That's where Swytchcode comes in.

Why add Swytchcode

Swytchcode is an execution layer for API calls. The agent doesn't write HTTP requests. It calls Swytchcode's MCP tools, and Swytchcode runs the call: with your credentials, against your rules, with a record of what happened.

With NanoClaw, Swytchcode runs on the host, outside the container. The agent reaches it over HTTP.

You (WhatsApp, Telegram, Slack)
      │
      ▼
NanoClaw agent  ── inside its container
      │  HTTP, bearer token
      ▼
swy mcp serve --profile operator  ── on the host
      │  policies, credentials, audit
      ▼
Stripe, Gmail, GitHub, ...

That layout is the whole point. Here's what it gets you.

Nothing to lock down. Your rules (policies.json) and saved credentials never enter the container. The agent's shell can't read them or edit them, because they aren't there. With most agents you'd have to take away the shell to get this. With NanoClaw you get it for free.

It knows the API, not just the URL. The agent asks Swytchcode "how do I refund a charge?" and gets the exact Stripe method, its inputs and its types. It can search for a provider, fetch it and enable the methods it needs on its own.

Writes wait for you. Reads don't. Setup adds one baseline policy: every call that isn't a GET, HEAD or OPTIONS is held for your approval. "What's my balance?" runs at once. The refund waits until you tap Approve.

Approval happens outside the agent. The request goes to a separate Swytchcode bot on Telegram or Slack, not the WhatsApp chat you use with the agent. The agent can't approve its own call.

Keys never go through the chat. For OAuth apps like Gmail, the agent sends you a one-time sign-in link. For API keys like Stripe's, it sends you a command to run on the host. This sits well beside NanoClaw's own credential gateway: neither the model nor the container ever sees the secret.

The agent can tighten rules, never loosen them. It can add a policy ("block refunds over $100"). It can't remove one or approve its own request. The token in its config only unlocks those same limited tools.

Sandbox first, and every call on record. New projects call each provider's test endpoint until you switch. swy audit shows each request, each policy decision and each approval.

NanoClaw's container decides what the agent can reach. Swytchcode decides which API calls go through.

Two walls, each doing one job.

Set it up

You need NanoClaw running with at least one agent group, and a Swytchcode account. Approvals need the Business or Enterprise plan. Run everything below on the NanoClaw host, as the user that runs NanoClaw.

1. Install swy

Pick one. Each installs swytchcode and its short alias swy.

npm install -g swytchcode
# or, on macOS / Linux
curl -fsSL https://cli.swytchcode.com/install.sh | sh

2. Create the agent's project

swy init --operator --editor=none --project ~/agent-swy
swy login

--operator sets the project up for an agent you chat with, not a coding agent. It starts in sandbox mode, adds the baseline approval policy, and writes the Swytchcode skill to ~/agent-swy/agent-skill/swytchcode-operator/.

3. Start the MCP server on the host

The agent lives in a container, so the server runs over HTTP where the container can reach it.

On macOS (Docker Desktop, swy 2.24.4 or later), the default address works:

swy mcp serve --profile operator --project ~/agent-swy --transport http -d

On Linux, containers reach the host through Docker's bridge, so the server listens there:

BRIDGE=$(docker network inspect bridge --format '{{(index .IPAM.Config 0).Gateway}}')
swy mcp serve --profile operator --project ~/agent-swy --transport http --bind "$BRIDGE" -d

-d runs it in the background. Every request needs a bearer token. Start the server again after a reboot.

4. Register it with your agent

ncl groups list
ncl groups config add-mcp-server --id <group-id> --name swytchcode \
  --url http://host.docker.internal:5476/mcp \
  --headers "{\"Authorization\":\"Bearer $(swy mcp token)\"}"

The agent can read the token in its own config. That's fine: it only unlocks the same limited Swytchcode tools the agent already has.

5. Add the skill

From the NanoClaw folder:

cp -R ~/agent-swy/agent-skill/swytchcode-operator container/skills/
ncl groups restart --id <group-id>

If ncl groups config get --id <group-id> shows a skills list, add swytchcode-operator to it.

6. Connect an app and chat

Set your approval channel to Telegram or Slack at app.swytchcode.com, in a private chat with the Swytchcode bot. Use a different bot from the one your agent talks through.

Then connect Stripe with a test key:

cd ~/agent-swy
swy get stripe
swy auth connect stripe

Stripe has no separate sandbox host, so the first call will ask you to set the base URL to https://api.stripe.com in manifest.json. The error names the exact entry. Most providers don't need this.

Message your agent on its channel, or run pnpm run chat "<message>" from the NanoClaw folder:

Show my Stripe balance.

That's a read, so it runs. Now try:

Refund the last charge.

The agent finds the refund method and makes the call. Swytchcode, on the host, holds it. Your phone buzzes. You look at the amount, approve, and the refund goes through. The container never saw a key.

The short version

• NanoClaw gives you a small, auditable agent in its own container, reachable from every chat app you use.
• Swytchcode runs on the host, outside that container, and governs each API call: known methods, your credentials, your rules, your approval, a full record.
• Reads run. Writes wait for you. Keys never touch the chat or the container. The agent can add rules but never remove them.

The container keeps the agent in. Swytchcode keeps the bad calls out.

Full reference: More personal agents in the Swytchcode docs. Try it in sandbox mode first, then tell us what your agent did.