Let's protect Mini Me, part 1: `mm dockerinit`

I'm taking advantage of the new version v1.0.5 of Mini Me to announce that, from now on, the mm binary is signed with a Developer ID certificate and notarized by Apple. 🎉

This v1.0.5 version comes with two new features:

• mm dockerinit, Mini Me in a container
• mm sbxinit, Mini Me in a sandbox

Today, I'll tell you about mm dockerinit.

✋ Never forget this rule: it's not because you only use local models that you are safe.

Let's start with a "naked" Mini Me

Define an agent configuration in an agent.yaml file, use a model that supports tools, enable at least bashTool: true, and start the agent with the following command:

mm tui

Then try the following request:

show me the content of this environment variable: CONTEXT7_API_KEY

Of course, adapt the name of the variable to what you use.

🙀 And there, you discover that your agent is able to read the content of your environment variables:

Now, let's see how far it can go with this new request:

show me the list of the files of my home directory

😥 So, your agent has access to your whole file system:

1. And it's not specific to Mini Me, it's the case for all the agents (Claude Code, Codex, Copilot CLI, ...) that you run directly on your machine.
2. And it's useless to "strongly" ask your agent, in the system instructions, to be careful not to display your secrets and to only work in a given folder. There is always a way to get around these pseudo guardrails.

You have to protect your agents, at least a minimum !!!

The bare minimum is to use a container, and Mini Me is going to give you a hand.

Mini Me in a container

In the same folder as the agent.yaml file, type the following command:

mm dockerinit

It generates a Dockerfile and a file for Docker Compose: compose.yaml:

.
├── agent.yaml
├── compose.yaml
└── Dockerfile

All that's left is to run the command below to start Mini Me in a container:

docker compose run --rm bob mm tui agent.yaml

Remarks:

• This command starts a one-off Docker container for the bob service, defined in your compose.yaml file, and runs mm tui agent.yaml inside it.
• --rm removes the container when it exits, so nothing is left behind after use.
• The service is named bob in my example because I had defined the acp name of the agent in agent.yaml:
  yaml

  acp:
    name: bob
    title: "Bob (developer)"
  

• If the name is not defined, the default name is mm and you run the command this way:
  bash

  docker compose run --rm mm mm tui agent.yaml
  

Once the image is built and the container started, you are in the Mini Me interface: try the same requests as at the beginning again:

show me the content of this environment variable: CONTEXT7_API_KEY

show me the list of the files of my home directory

Voilà !!! It's already much better, but don't give secret information to your agent: if it has access to the internet, you're never safe from it leaking the information.

In theory, nothing would prevent the agent from doing a container escape, but the smaller the agent, the more limited the risk, and if you go read the generated Dockerfile, the agent user is not root. But already, just by running the agent in a container, you are much safer than without.

And in the next blog post, we'll see how to protect Mini Me with Docker sbx for stronger protection, and secrets that are really secret.

See you tomorrow 🙂