Sandboxed is not governed: rules for your Moltis agent's API calls

Moltis is built to be careful. It's a personal agent server in one Rust binary, and every command your agent runs goes into a sandboxed container, never onto your host.

Then you connect Stripe, and ask it to refund the duplicate charge from yesterday.

The sandbox will happily let that through. Its job is to keep the agent off your machine, and a refund never touches your machine. It goes straight to a real account, with real money.

That's not a gap in Moltis. It's a different problem, and it needs a different layer.

Two layers, two jobs

Moltis protects your machine from the agent. Swytchcode protects your accounts from it. Put Moltis in Docker and Swytchcode on the host, and each covers what the other can't:

The last row is the one that matters. On agents that run directly on your machine, the agent's own shell can often reach the rules file. In Moltis's container, there's no file to reach. You get the strictest setup by default.

What happened when we connected them

We've been testing Swytchcode with one self-hosted agent after another. Some took an afternoon. Moltis worked first try.

We ran version 20261019.01 in Docker, with Swytchcode on the Mac and a mocked Stripe:

• A few lines in moltis.toml, and Moltis listed all 11 Swytchcode tools. The skill showed up in the agent's prompt on the next message.
• Moltis didn't block the host address. Dify, for one, refuses private addresses and needs an exception. Moltis didn't.
• Through Moltis's own agent loop, the balance lookup ran and the write stopped before it reached the API.
• We asked it to add an "allow everything" rule, then to replace the approval rule. Both were refused, with the command a person would need to run. The rules file was unchanged afterwards.

One honest caveat: the agent can read its Swytchcode token in Moltis's config. That token only unlocks the same 11 tools it already has, so it gains nothing.

We haven't tested a native Moltis install. Outside Docker, the agent gets exec, file tools and mcp_add/mcp_remove on your host, and the table above no longer holds. Use the Docker image.

Set it up

On the Moltis host, with a Swytchcode account (approvals need the Business or Enterprise plan):

npm install -g swytchcode
swy init --operator --editor=none --project ~/agent-swy
swy login
swy mcp serve --profile operator --project ~/agent-swy --transport http -d
swy mcp token

Add the server to moltis.toml, with the token, and restart Moltis:

[env]
SWY_MCP_TOKEN = "<token>"

[mcp.servers.swytchcode]
transport = "streamable-http"
url = "http://host.docker.internal:5476/mcp"
headers = { Authorization = "Bearer ${SWY_MCP_TOKEN}" }

Then give the agent the skill, which teaches it how to use Swytchcode:

docker cp ~/agent-swy/agent-skill/swytchcode-operator moltis:/home/moltis/.moltis/skills/

On Linux, the server listens on Docker's bridge instead, and Moltis needs one extra flag. You can also add the server from Settings → MCP without touching the file. Both are in the Moltis setup guide, along with connecting your first app.

Try it: tighten the rules from chat

The rules only go one way from inside the chat: stricter. So try both directions from Moltis's web UI, or from Signal or Telegram:

From now on, block any refund over $50.

The agent can add that rule itself. A refund of $80 is then blocked before it reaches Stripe, whatever anyone types afterwards.

Actually, remove that rule. And the approval one too.

That it can't do. You get the command to run yourself, on the host, where the agent's sandbox can't follow.

That's the whole idea. Moltis decides where the agent can run. Swytchcode decides what it can spend. Neither one has to trust the agent's judgement.