How much system access do 17 self-hosted AI agents get by default?
I work on agent tooling, so I installed 17 self-hosted agents back to back on my local Docker to see what each one can actually touch out of the box.
Test format
Each agent got an MCP server with read and write tools for a fake Stripe API, and a rule that writes need my approval. A scripted model (not a real LLM) then tried the same things on all of them: a write, deleting the rule from chat, editing the rule file with the agent's own shell, and reading the access token off disk. So this is about defaults and config, not how smart they are, and it's not a security audit. Versions are next to each name.
Here they are in alphabetical order.
AstrBot (4.29.1)
- Setup: Fine.
- Ease of use: It's a chat-app bot platform. One bug: an MCP tool argument named tool clashes with AstrBot's own arguments, so those tools fail on every call.
- Access: No shell or file tools at all until you turn on Computer Use, which I liked. Then members only get workspace files, but admins (you) get shell, Python and files on the whole host, so set the admin scope to Workspace.
Dify (1.17.1)
- Setup: Its outbound proxy blocks private addresses, including your own host, so connecting to a local MCP server needs an exception in .env (SSRF_PROXY_ALLOW_PRIVATE_DOMAINS).
- Ease of use: You build the agent in its web app and pick its tools there. Easy once connected.
- Access: Agents only get the tools you add to the app. There's no shell tool by default.
Hermes (0.18.2)
- Setup: Straightforward. Add the MCP server to its config and go.
- Ease of use: Chat in the terminal. It runs tools without asking, so it feels fast.
- Access: Terminal and code tools are on by default. I asked it to remove a rule I'd set up, and it opened its terminal and edited the file. Any agent with a shell can edit its own guardrails, so turn the terminal off or run it in a container.
Khoj (2.0.0-beta.28)
- Setup: The hardest one. The Docker latest tag is over a year old and has no MCP, so you need the 2.0 beta. Local MCP servers can't take arguments (you need a small wrapper script), and the image has no python command, so Python servers fail until you add a symlink.
- Ease of use: MCP tools only show up in research mode, not normal chat. Remote MCP servers are SSE only, and Khoj never sends the API key you give it, so servers that need a token don't work.
- Access: Tight, going by its code. Code runs in a separate sandbox (Terrarium or E2B), not on your host.
LangBot (4.11.1)
- Setup: The agent runner is a plugin, so you need the plugin runtime container and the LocalAgent plugin. After that it worked first try.
- Ease of use: A chat-app bot platform. No friction once running.
- Access: No shell or file tools unless you turn on its Box sandbox.
MARVIN (1.1.0 on Claude Code 2.1.306)
- Setup: It's a Claude Code workspace, so you add MCP servers the Claude Code way. Allow rules in the project settings are ignored until you trust the workspace.
- Ease of use: Claude Code asks before every tool, even read-only ones. Safe, a bit chatty. Its Telegram bot has no MCP, so your tools don't work from your phone.
- Access: No shell until you allow Bash. If you do, add deny rules and turn on Claude Code's sandbox.
Moltis (20261019.01)
- Setup: Just worked. A few lines of config and done.
- Ease of use: I used it from Telegram and it was smooth.
- Access: In Docker the agent can't touch your host. I didn't test a native install.
MyClaw (0.6.2)
- Setup: Local (stdio) MCP servers get killed right after connecting, so use HTTP. A plain http:// URL is treated as SSE.
- Ease of use: Ran every tool without asking in my tests. Smooth, but that's the risky part.
- Access: Bash, Read and Edit reach any file. restrictToWorkspace: true in its config isn't actually read (a bug). Deny rules work, but ~ isn't expanded, so Read(~/something/**) silently matches nothing. Use full paths.
NanoClaw (commit fb4797e)
- Setup: Smooth. The only catch: the agent runs in a container, so anything on your host has to listen on an address the container can reach, not just 127.0.0.1.
- Ease of use: Chat in the terminal. No friction.
- Access: Every agent runs in its own container and can't see anything on the host you don't give it. The strongest host isolation by default in my tests.
OpenClaw (2026.3.28)
- Setup: Straightforward.
- Ease of use: Chat in the terminal. No friction once set up.
- Access: File tools stay in its workspace, but it has runtime and automation tools, and its gateway tool can change its own config. Lock that down if you care what it's allowed to do.
PicoClaw (0.3.1)
- Setup: Smooth in Docker. MCP is off by default, so you have to turn it on in the config.
- Ease of use: A single small binary that runs on cheap boards. Worked first try.
- Access: restrict_to_workspace is on by default, and file tools held to the workspace. The shell tool is on by default too, so if you run it natively, I'd turn it off with tools.exec.enabled: false.
Picobot (0.3.0)
- Setup: The bearer token for an HTTP MCP server goes in headers.
- Ease of use: MCP servers only connect at startup, so restart after adding one.
- Access: The exec tool can't be turned off. It refuses absolute paths, but it runs from wherever you started it, so a relative path got through, and the deny list only checks the first word of a command. Both are already open issues on the repo. In Docker none of this reaches your host.
Rho (0.1.12)
- Setup: A fresh install didn't start. Pi (the agent it's built on) moved to a new npm name, Rho still pulls the old one, and the start command still said running. I pinned an older MCP adapter and turned off two modules.
- Ease of use: Once running, it stays up and remembers across sessions, which is the point of it.
- Access: Installed natively, shell, write and edit run without asking, and there's no setting to turn them off. A small Pi extension can block them. In Docker it's isolated.
Sentient (3.0.0b1)
- Setup: Smooth. It reviews every MCP tool before the agent can use it, and flagged some tool descriptions as high risk purely because of how they were worded. It was right. Very cool feature.
- Ease of use: Asks before every tool that isn't marked read-only.
- Access: Well thought out. File tools are confined to its own files folder, the terminal is off by default, and no tool can edit its own config. The one gap is code execution: it's on by default and runs Python on the host (after you approve it), so turn it off in Settings > Code execution if you don't need it.
Takopi (0.23.4) (a Telegram bridge for Claude Code and other coding CLIs)
- Setup: It runs Claude Code headless, so there's nobody to say yes, and any MCP tool fails until you add it to allowed_tools.
- Ease of use: You drive your coding agent from Telegram. Nice once the allowed list is right.
- Access: By default it pre-approves Bash, Read, Edit and Write. Setting allowed_tools to just your MCP tools both enables them and blocks the shell and file tools.
TinyAGI (v0.0.20) (formerly TinyClaw)
- Setup: The Dockerfile doesn't build on main right now (a bug). The release bundle works.
- Ease of use: It starts Claude Code with permissions skipped, so nothing asks. Smooth, and risky.
- Access: Bash and Edit reach everything out of the box. I locked it down with Claude Code's sandbox and deny rules, and the agent edited its own settings and turned the sandbox off. Deny edits to its own settings files too.
ZeroClaw (0.8.6)
- Setup: Straightforward.
- Ease of use: Asks yes or no before every tool unless you set auto_approve. Gets old fast, but safe.
- Access: It has a shell, limited to a default allowed_commands list, and it asks before every tool unless you turn on auto_approve. Tighten allowed_commands to what you actually need, and think twice before auto-approving.
My take: Don't judge an agent by what it asks permission for. Check what it can reach, run and change. Containers helped a lot, but only if you don't mount your keys and config into them. And test your restrictions, because a few of the ones I hit only looked like restrictions.
Which agent are you running, and how have you limited it?
19 comments
Mentions
🔥 [1 Repo Every Developer Should Know] zeroclaw: The Free Tool Taking Over GitHub! #shorts Discover zeroclaw-labs/zeroclaw: Fast, small, and fully autonomous AI personal assistant infrastructure, any OS, any platform deploy anywhere, swap anything 💬 Comment "ZEROCLAW" below for the direct link, or grab it from the links below: 👉 Interactive Star History & Live Analysis: githubrepo.cloud ⭐ Embed Live Verified Badges in your README: githubrepo.cloud 🔗 Direct GitHub Repository: zeroclaw-labs/zeroclaw 📊 Repository Specs: ⭐ Stars: 32,979 🍴 Forks: 4,975 💻 Language: Rust 📜 License: Apache-2.0 #shorts #zeroclaw #agent #agentic #ai #infra #artificialintelligence #machinelearning #deeplearning
How much system access do 17 self-hosted AI agents get by default? I work on agent tooling, so I installed 17 self-hosted agents back to back on my local Docker to see what each one can actually touch out of the box. Test format Each agent got an MCP server with read and write tools for a fake Stripe API, and a rule that writes need my approval. A scripted model (not a real LLM) then tried the same things on all of them: a write, deleting the rule from chat, editing the rule file with the agent's own shell, and reading the access token off disk. So this is about defaults and config, not how smart they are, and it's not a security audit. Versions are next to each name. Here they are in alphabetical order. AstrBot (4.29.1) - Setup: Fine. - Ease of use: It's a chat-app bot platform. One bug: an MCP tool argument named tool clashes with AstrBot's own arguments, so those tools fail on every call. - Access: No shell or file tools at all until you turn on Computer Use, which I liked. Then members only get workspace files, but admins (you) get shell, Python and files on the whole host, so set the admin scope to Workspace. Dify (1.17.1) - Setup: Its outbound proxy blocks private addresses, including your own host, so connecting to a local MCP server needs an exception in .env (SSRF_PROXY_ALLOW_PRIVATE_DOMAINS). - Ease of use: You build the agent in its web app and pick its tools there. Easy once connected. - Access: Agents only get the tools you add to the app. There's no shell tool by default. Hermes (0.18.2) - Setup: Straightforward. Add the MCP server to its config and go. - Ease of use: Chat in the terminal. It runs tools without asking, so it feels fast. - Access: Terminal and code tools are on by default. I asked it to remove a rule I'd set up, and it opened its terminal and edited the file. Any agent with a shell can edit its own guardrails, so turn the terminal off or run it in a container. Khoj (2.0.0-beta.28) - Setup: The hardest one. The Docker latest tag is over a year old and has no MCP, so you need the 2.0 beta. Local MCP servers can't take arguments (you need a small wrapper script), and the image has no python command, so Python servers fail until you add a symlink. - Ease of use: MCP tools only show up in research mode, not normal chat. Remote MCP servers are SSE only, and Khoj never sends the API key you give it, so servers that need a token don't work. - Access: Tight, going by its code. Code runs in a separate sandbox (Terrarium or E2B), not on your host. LangBot (4.11.1) - Setup: The agent runner is a plugin, so you need the plugin runtime container and the LocalAgent plugin. After that it worked first try. - Ease of use: A chat-app bot platform. No friction once running. - Access: No shell or file tools unless you turn on its Box sandbox. MARVIN (1.1.0 on Claude Code 2.1.306) - Setup: It's a Claude Code workspace, so you add MCP servers the Claude Code way. Allow rules in the project settings are ignored until you trust the workspace. - Ease of use: Claude Code asks before every tool, even read-only ones. Safe, a bit chatty. Its Telegram bot has no MCP, so your tools don't work from your phone. - Access: No shell until you allow Bash. If you do, add deny rules and turn on Claude Code's sandbox. Moltis (20261019.01) - Setup: Just worked. A few lines of config and done. - Ease of use: I used it from Telegram and it was smooth. - Access: In Docker the agent can't touch your host. I didn't test a native install. MyClaw (0.6.2) - Setup: Local (stdio) MCP servers get killed right after connecting, so use HTTP. A plain http:// URL is treated as SSE. - Ease of use: Ran every tool without asking in my tests. Smooth, but that's the risky part. - Access: Bash, Read and Edit reach any file. restrictToWorkspace: true in its config isn't actually read (a bug). Deny rules work, but ~ isn't expanded, so Read(~/something/**) silently matches nothing. Use full paths. NanoClaw (commit fb4797e) - Setup: Smooth. The only catch: the agent runs in a container, so anything on your host has to listen on an address the container can reach, not just 127.0.0.1. - Ease of use: Chat in the terminal. No friction. - Access: Every agent runs in its own container and can't see anything on the host you don't give it. The strongest host isolation by default in my tests. OpenClaw (2026.3.28) - Setup: Straightforward. - Ease of use: Chat in the terminal. No friction once set up. - Access: File tools stay in its workspace, but it has runtime and automation tools, and its gateway tool can change its own config. Lock that down if you care what it's allowed to do. PicoClaw (0.3.1) - Setup: Smooth in Docker. MCP is off by default, so you have to turn it on in the config. - Ease of use: A single small binary that runs on cheap boards. Worked first try. - Access: restrict_to_workspace is on by default, and file tools held to the workspace. The shell tool is on by default too, so if you run it natively, I'd turn it off with tools.exec.enabled: false. Picobot (0.3.0) - Setup: The bearer token for an HTTP MCP server goes in headers. - Ease of use: MCP servers only connect at startup, so restart after adding one. - Access: The exec tool can't be turned off. It refuses absolute paths, but it runs from wherever you started it, so a relative path got through, and the deny list only checks the first word of a command. Both are already open issues on the repo. In Docker none of this reaches your host. Rho (0.1.12) - Setup: A fresh install didn't start. Pi (the agent it's built on) moved to a new npm name, Rho still pulls the old one, and the start command still said running. I pinned an older MCP adapter and turned off two modules. - Ease of use: Once running, it stays up and remembers across sessions, which is the point of it. - Access: Installed natively, shell, write and edit run without asking, and there's no setting to turn them off. A small Pi extension can block them. In Docker it's isolated. Sentient (3.0.0b1) - Setup: Smooth. It reviews every MCP tool before the agent can use it, and flagged some tool descriptions as high risk purely because of how they were worded. It was right. Very cool feature. - Ease of use: Asks before every tool that isn't marked read-only. - Access: Well thought out. File tools are confined to its own files folder, the terminal is off by default, and no tool can edit its own config. The one gap is code execution: it's on by default and runs Python on the host (after you approve it), so turn it off in Settings > Code execution if you don't need it. Takopi (0.23.4) (a Telegram bridge for Claude Code and other coding CLIs) - Setup: It runs Claude Code headless, so there's nobody to say yes, and any MCP tool fails until you add it to allowed_tools. - Ease of use: You drive your coding agent from Telegram. Nice once the allowed list is right. - Access: By default it pre-approves Bash, Read, Edit and Write. Setting allowed_tools to just your MCP tools both enables them and blocks the shell and file tools. TinyAGI (v0.0.20) (formerly TinyClaw) - Setup: The Dockerfile doesn't build on main right now (a bug). The release bundle works. - Ease of use: It starts Claude Code with permissions skipped, so nothing asks. Smooth, and risky. - Access: Bash and Edit reach everything out of the box. I locked it down with Claude Code's sandbox and deny rules, and the agent edited its own settings and turned the sandbox off. Deny edits to its own settings files too. ZeroClaw (0.8.6) - Setup: Straightforward. - Ease of use: Asks yes or no before every tool unless you set auto_approve. Gets old fast, but safe. - Access: It has a shell, limited to a default allowed_commands list, and it asks before every tool unless you turn on auto_approve. Tighten allowed_commands to what you actually need, and think twice before auto-approving. My take: Don't judge an agent by what it asks permission for. Check what it can reach, run and change. Containers helped a lot, but only if you don't mount your keys and config into them. And test your restrictions, because a few of the ones I hit only looked like restrictions. Which agent are you running, and how have you limited it?
🦀 ZeroClaw v0.8.6 is out 🦀 🔌 Plugins in the stock CLI: install Discord, Telegram, Matrix and 10 more by name, no Rust toolchain 🔐 Groundwork for OIDC sign-in 💻 Multi-session ZeroCode 🧠 New providers + web search 573 commits, 74 contributors 🙏 github.com/zeroclaw-labs/zeroclaw/releases/tag/v0…
Alguno de ustedes está usando, o ha probado zeroclaw-labs/zeroclaw ?
ZeroClaw juga membawa sandbox OS bawaan dengan permission granular (read-only filesystem, network whitelist, human-in-the-loop approval). Dokumentasi dan repo open source: zeroclaw-labs/zeroclaw
3.3 万颗星。zeroclaw 是跑在自己机器上的自主助手底座：体积小、占用低，能长期挂在一台小机器上。 云端助手网络一断就没了，先想清楚让它替你盯哪件事再谈部署。 zeroclaw-labs/zeroclaw
I gave a GitHub star, did you? zeroclaw.com zeroclaw-labs/zeroclaw