Let's protect Mini Me, part 2: `mm sbxinit`

Yesterday we saw how to protect Mini Me with Docker Compose in this blog post: Let's protect Mini Me, part 1: mm dockerinit. But if you need stronger protection, especially for your secrets, then Docker sbx is a perfect solution.

Quick reminder: what is sbx?

Docker sbx runs your agent in a micro-VM isolated by a hypervisor, with its own filesystem and its own private Docker Engine: from the host system, only the working directory is mounted (read-write), and the rest (the host's files, processes, Docker and network) is out of its reach. All outgoing traffic goes through a proxy that applies allow/deny policies (for example api.github.com allowed, bad.data.org denied), and this same proxy injects the secrets on the fly, so your credentials never enter the sandbox and the agent cannot read them. The result: you can run the agent in YOLO mode, without any permission prompt, because even if it runs anything at all, the damage stays confined to the VM.

So let's run Mini Me in sbx.

Mini Me in an sbx sandbox

Since version v1.0.5 of Mini Me, we have a new command, mm sbxinit, which generates the files needed to run Mini Me in sbx.

In the same folder as the agent.yaml file used yesterday (so in the previous blog post), you can remove the compose.yaml and Dockerfile files and type the following command:

mm sbxinit

A new file is generated in the folder: sbxenv.yaml

.
├── agent.yaml
└── sbxenv.yaml

Here is its content:

schemaVersion: "1"

name: bob-sbx

# The workload kit is the base "agent".
agent: mini-me-kit

kits:
  - docker.io/k33g/mini-me-kit:0.1.3

workspace: /Users/k33g/kDrive/Rickub/bots-garden/mini-me/blog/demos/bob

sandboxOptions:
  pullPolicy: always

All you have left to do is run the command:

sbx env run --force

Wait a few moments:

And you're done!

And if you ask for information about the operating system, you'll see that we are indeed in a Linux sandbox:

For more information on how sbx works and how to use it, you'll find the documentation here: Docker Sandboxes.

But now, let's talk about secrets.

Giving the agent an API key... without letting it read it

Let's take a concrete case: you want Bob to use the Context7 MCP server to look up technical documentation. Context7 requires an API key, CONTEXT7_API_KEY. If you put it in an environment variable of the sandbox, the agent can read it (a simple echo $CONTEXT7_API_KEY is enough), and therefore leak it.

With sbx, the real key stays on your machine. In the sandbox, the agent only has a decoy (a placeholder, like sbx-cs-…). When Mini Me calls Context7, it sends this decoy in the Authorization header, and it's the sbx proxy, on the way out of the sandbox, that replaces it with the real key:

Here is how to do it, in 3 steps.

1. Declare the MCP server in agent.yaml

Start by destroying your sandbox:

sbx env rm --force

Then, add the following section at the end of the agent.yaml file to give Mini Me access to the remote MCP server of Context7:

mcp:
  enabled: true
  # yolo: true, the Context7 tools run without asking
  permissions: auto
  servers:
    - name: context7
      transport: http
      url: https://mcp.context7.com/mcp
      auth:
        type: bearer
        # mm reads the token from this variable
        tokenEnv: CONTEXT7_API_KEY

Mini Me will read the CONTEXT7_API_KEY variable and send it in the Authorization: Bearer ... header of every request to Context7. It doesn't know (and doesn't need to know) that it's a "decoy".

2. Hand the key to sbx, on your machine

We will now create a "custom secret" for sbx: on your machine (not in the sandbox), with your key in the CONTEXT7_API_KEY variable:

printf '%s' "$CONTEXT7_API_KEY" | sbx secret set-custom \
  --host mcp.context7.com \
  --env CONTEXT7_API_KEY \
  --value-stdin

This command tells sbx three things:

• --env CONTEXT7_API_KEY: in the sandbox, the CONTEXT7_API_KEY variable will hold the decoy;
• --host mcp.context7.com: the proxy will replace the decoy with the real key only in requests to mcp.context7.com. Sent anywhere else, the decoy is worthless;
• --value-stdin: the key is read from standard input, so it shows up neither in the shell history nor in the process list.

Custom secrets are still experimental in sbx. They apply to all your sandboxes, unless you add --sandbox bob-sbx.

If your network policy blocks Context7, allow the domain:

sbx policy allow network mcp.context7.com

3. Restart the sandbox

The secret must exist before the sandbox is created. So restart it:

sbx env run --force

Let's check

Ask Bob to display the variable: it only sees the "decoy" sbx-cs-..., never the real key.

Then ask it a documentation question (for example "How do I clean up a useEffect in React?"): it calls context7_resolve_library_id then context7_query_docs, and Context7 answers, because the proxy added the real key along the way:

And our agent can build an answer from the documentation retrieved through Context7:

In short: the agent can use the key, but it cannot read it. Even in YOLO mode, even if someone pushes it to "leak" its secrets, it has nothing to give away.

That's it for this Sunday! You now know how to use agents in a fully secured mode and how to let them use your secrets "without seeing them".