Moltis: one binary at home, not a security guarantee
Moltis is an agent server written in Rust and shipped as one binary. It runs on your machine and talks to the messaging apps you connect. The homepage says the keys do not leave. The documentation says alpha software. A question sent to a remote model still leaves the machine.
Going deeper
Original AI-generated illustration · SecuFocus
At a glance
Key points
Take Moltis if you want an installed agent server, a sandbox chosen from the engines already present, and channels built into the binary. Do not take it because the site says secure. Without a container engine, the documented fallback does not isolate the file system. The default approval mode can be turned off. This reading describes the published documentation. It does not replace an installation.
Who it is for
Moltis fits if you administer the machine, and if you accept that an agent will run commands within what you have allowed. The distributed binary targets macOS and Linux. The published Docker image covers amd64 and arm64. The site also mentions a Mac mini, a Raspberry Pi or a server you own. That is not a run we performed.
It fits poorly if you want a chat window and nothing to install. It also fits poorly if nobody can approve a command, or if you mean to expose the service on the internet on the first evening. The introduction ranks it as alpha software: an isolated environment, tools reviewed, secrets scoped and rotated, and no public exposure without strong authentication and network controls.
What it is
Moltis presents itself as a personal, persistent agent server, written in Rust. The distributed binary includes the web interface, the model providers and the tools. You do not have a Node runtime to keep alive beside it, unlike an agent installed through npm. Building from source is a different job: the installation page asks for Rust 1.91 or later, a C compiler, the just tool, and Node to build the CSS.
The site says this is not a chatbot wrapper, and not a cloud service tied to one provider. The documentation lists remote providers, Anthropic, OpenAI, Google, DeepSeek, Mistral and others, and local models, Ollama, LM Studio, a GGUF file, an OpenAI-compatible endpoint. The server is at your place. The model is the one you choose.
The site also publishes a testimonial that compares Moltis with OpenClaw, and talks about guardrails missing or switched off elsewhere. A Discord message is not a measurement. The difference the two sets of documentation let you check is narrower: Moltis picks a sandbox if it finds one. OpenClaw leaves the sandbox off until you switch it on.
How it is installed
The documented quick path, on macOS or Linux, is a script from the site, which places the binary in ~/.local/bin. Homebrew has a formula, moltis-org/tap/moltis. The same script can install a Debian, RPM or Arch package, or an AppImage. Snap has its own command. Docker pulls ghcr.io/moltis-org/moltis:latest.
On first launch, moltis opens a local address. The installation page says a free port is chosen, then saved in the configuration, to avoid a conflict. The site and the Docker example publish port 13131, plus port 1455 in the Docker command. Those are not the same sentence. Keep the port printed in the terminal, not only the one on the homepage.
On localhost, the documentation says authentication is not required. As soon as access no longer comes from the machine, a setup code is printed in the terminal. Opening the port on the network without reading that line means discovering the service before authentication is in place.
Scroll the table sideways to read every column.
| Path | What the documentation says | What to know |
|---|---|---|
| Script or Homebrew | Binary in ~/.local/bin, or the tap formula | The script comes from the project site. You trust it when you run it. |
| deb, rpm, Arch, AppImage, Snap | The same installer, with a method, or snap install moltis | Versioned file names change. The page points to the script rather than a frozen URL. |
| Docker | Image ghcr.io/moltis-org/moltis, amd64 and arm64 | The site example publishes ports 13131 and 1455, and volumes for configuration and data. |
| Source | Rust 1.91, a C compiler, just, Node for the CSS | This is not the binary path. The sandbox WASM build is separate. |
- Pick the binary, Homebrew, a package, or the ghcr.io/moltis-org/moltis image.
- Run moltis and open the address it prints, not an address you guessed.
- Add a provider. An API key is pasted in the interface. OAuth access, such as GitHub Copilot, is presented without a key to paste.
- Check which sandbox was selected before you connect a messaging app.
- Expose the service only after the setup code has been used, and the network is limited.
The sandbox is not one promise
The homepage says the agent does not touch the file system until you say so. The sandbox page is more precise. The default setting is called auto. Moltis takes the strongest engine it finds, in a fixed order.
Apple Container comes first, on Mac only. It is a virtual machine: the container has its own kernel. Then Podman, then Docker. Both isolate through Linux namespaces. If none of that is present, the fallback is called restricted-host: cleared environment variables and resource limits, without file-system isolation. The last step is execution on the host, with no isolation.
The WASM sandbox is not in that chain. It cannot run an arbitrary shell command. You have to ask for it. Installing Moltis on a machine without Podman, Docker or Apple Container is therefore not the product described by the homepage sentence.
Scroll the table sideways to read every column.
| Priority | Engine | Where | Documented isolation |
|---|---|---|---|
| 1 | Apple Container | macOS | Virtual machine, separate kernel |
| 2 | Podman | Where it is installed | Namespaces, no daemon, rootless by default |
| 3 | Docker | Where it is installed | Namespaces, kernel shared with the host |
| 4 | Restricted host | Fallback | No file-system isolation |
| 5 | Host | Fallback | No isolation |
Who approves a command
By default, a command judged dangerous asks for approval. The mode is called smart. You can switch to always, so everything waits, or to never, which the security page calls dangerous. The setting lives in moltis.toml, under tools.exec.
Even on never, a hardcoded list blocks a few highly destructive patterns, such as a recursive delete of the root, a git reset --hard, a DROP TABLE, an mkfs or a terraform destroy. Those commands ask for approval again. You can remove a pattern by adding it to your allowlist. And that list applies only to host execution. A command already inside a sandbox is not caught by this net.
On a messaging app, the approval request is also supposed to arrive on the channel, so the run does not stall in silence. The documentation cites /approvals, then /approve or /deny, from Telegram or WhatsApp. An agent you can reach, with nobody to answer those messages, is not the deployment described.
Where it answers you
The channels are in the binary, not in a store you install one by one. That is not the same as an absence of third-party skills: the security page points to hardening for skills and plugins that come from elsewhere. The site, for its part, stresses the lack of a marketplace as an attack surface. The two sentences do not cover the same ground. Read the security page if you enable a skill that is not in the binary.
Not every channel asks for the same network opening. Telegram polls the platform. Discord, Matrix and WhatsApp open an outbound connection. Slack uses Socket Mode. None of those require a public URL. Microsoft Teams does: the platform calls a webhook on your side. Signal is documented, through signal-cli, for text, direct messages and groups. Nostr covers encrypted direct messages, not the same set of features.
The homepage also adds voice, memory, CalDAV calendar, web browsing and tasks in natural language. The channel page details what each platform can receive. An attachment or a thread is not guaranteed everywhere. Teams needs a public URL. Signal, in the table, does not take voice in.
Scroll the table sideways to read every column.
| Channel | How it receives | Public URL |
|---|---|---|
| Telegram | Polling | No |
| Discord, Matrix, WhatsApp | Outbound connection | No |
| Slack | Socket Mode | No |
| Signal | signal-cli | No |
| Nostr | Relay subscription | No |
| Microsoft Teams | Webhook | Yes |
What leaves, and what stays
Configuration lives in ~/.config/moltis. Sessions, databases and memory live in ~/.moltis. Removing them erases the agent, not only the binary. A shared Unix login leaves those folders readable by the same session.
The homepage says keys and private data never leave the machine. The installation page asks you to add a provider key, or OAuth access. The key can stay in the local configuration. The question sent to Anthropic, OpenAI, Google or another remote host leaves the machine. A local model, Ollama or a file on disk, is the case where that sentence holds. The project lists both. It does not mix them in the provider table. The homepage does.
Persistent memory, with vector search, keeps excerpts from one session to the next. That is not proof that what is retained is accurate, or that the model provider kept nothing on its side. Moltis does not become private because it runs at home. It is private to the extent that the model, the network and the tools are.
What not to ask of it
Do not ask it to be an audit. The project calls itself alpha. The default refusals and the sandbox order are documented settings. They do not say that your machine has Podman, or that nobody set approval_mode to never.
Do not ask it to be a public service either. Authentication is required only off localhost. Teams asks for a reachable URL. Exposing either without limiting who can write changes the product.
This reading follows the site and the installation, security, sandbox and channel pages. It did not install Moltis, measure a Raspberry Pi, or compare a speed with OpenClaw. The testimonial on the site remains a testimonial.
The decision
Choose Moltis if you want an agent server in one binary, a sandbox that attaches to the engine already present, and channels included. Check the selected engine before the first messaging app. Leave approvals on smart, or on always, until you have a reason to do otherwise. Prefer a local model if the sentence about data that does not leave has to be true.
Look elsewhere if you cannot take responsibility for a program that executes, or if the machine has no container engine and you were counting on file isolation. The wider frame is in the guide on generative AI. Hermes Agent is the other card in the same section, with a different deployment model.
Check and explore
Sources for this article
Numbers connect each reference to the passages that use it. Dates show when the documentation was consulted.
- Installation, Moltis ↗docs.moltis.org ·
- Security architecture, Moltis ↗docs.moltis.org ·
- Sandbox backends, Moltis ↗docs.moltis.org ·
This article draws on the sources above. The exercises are for you to try on your devices; SecuFocus does not present them as tests carried out by its editorial team. Interfaces and features can change. Method and corrections.
Cite this article
Keep this reference with the article when you save or share it.