How Open-Source AI Agents Handle Permissions and Sandboxing

Aug 12, 2026

Problem

When I started running open-source AI agents, I assumed they were safe by default. The agent asks before it runs a tool, right? That must mean it is sandboxed.

It is not the same thing. A Reddit post about Pi made the point I had missed: “Pi is explicit about permissions. If you need stronger filesystem, process, network, or credential boundaries, you need to provide a container or sandbox layer yourself.”

Prompt-gated access          Sandboxed execution
---------------------------  ---------------------------
Agent asks "can I do X?"     Agent runs inside a boundary
Consent controls approval    Boundary controls blast radius
Files/network/creds open     Files/network/creds restricted

What “explicit about permissions” really means

Being explicit about permissions means the tool tells you what it is about to do and asks for consent. That controls approval. It does not control the blast radius.

A prompt-gated agent that already holds your full shell, your network, and your credentials can still read, write, and execute anything. The prompt is just a warning light, not a wall.

The permission checklist

Before I trust any agent tool with real work, I audit it against this list:

[ ] Filesystem reads    which paths can the agent read
[ ] Filesystem writes   can it overwrite config or code
[ ] Process execution   can it run arbitrary shell commands
[ ] Network access      can it reach the internet or internal services
[ ] Credentials         can it read ~/.ssh, ~/.aws, env vars

Ask the same questions for Pi, Goose, and OpenCode. Each tool answers differently, and none should be assumed isolated by default.

Adding a sandbox layer yourself

For strong boundaries, I run the agent inside a container with a restricted volume and network:

# Don't: run the agent with your full shell and all credentials
# Do: run inside a container with a restricted volume and network
docker run --rm -it \
  -v "$PWD:/workspace" \
  --network none \
  --cap-drop ALL \
  my-agent-image run --tool-calls

A container is not the only option. A lightweight sandbox such as bubblewrap, or a least-privilege OS user with restricted network and credential access, also works. The point is to add a real boundary instead of relying on prompts.

What this means for each tool

Pi (harness): the permission model is explicit, but strong isolation is expected to be your layer. Plan to supply a container or sandbox.
Goose (workbench): verify whether its default execution path is isolated or just prompt-gated.
OpenCode (coding agent): the same check applies, do not assume its default mode is sandboxed.

Summary

In this post, I explained the difference between explicit permissions and real sandboxing for open-source AI agents. The key point is that a permission prompt controls consent while a sandbox controls blast radius, so audit each tool’s permission model and add a container or sandbox layer yourself when you need strong boundaries.

Final Words + More Resources

My intention with this article was to help others share my knowledge and experience. If you want to contact me, you can contact by email: Email me

Here are also the most important links from this article along with some further resources that will help you in this scope:

👨‍💻 OpenCode
👨‍💻 Goose
👨‍💻 Docker Docs

Oh, and if you found these resources useful, don’t forget to support me by starring the repo on GitHub!