7 Safety and Isolation: Sandboxes and Permissions
Coding agents are incredibly powerful—they can delete files, run commands, and access the internet. This power comes with significant security risks. To mitigate these risks, agents operate within Sandboxes and under strict Permission systems.
7.1 Sanboxing and Containerization
A Sandbox is an isolated environment where the agent can work without affecting your main computer. Usually, you would like the agent to have access to its own folders (with systemp prompt, settings and skills) and to your specific project folder, but not anywhere else on your computer. This way, if the agent makes a mistake or runs a malicious command, it only affects the sandbox and possible files in your project, but not your entire system.
In this workshop, your entire environment is inside a Docker container. If the agent makes a mistake or runs a malicious command, it only affects the container, not your laptop.
All operating systems provide different ways of sandboxing or containerization, and many agent harnesses have built-in sandboxing features (but they still depend on your operating system). For example, there is well written concise documentation for Gemini CLI on the ways it supports sandboxing, also see Claude Code sandboxing, Codex Sandboxing. For other agents, you might need a more custom setup, for example using Docker Sandboxes or Virtual Machines (e.g. VirtualBox) to create a isolated environment for the agent to run in and only connect your project folder to that environment. For most of these tools you have to have administrative access to your computer to set up the sandbox, there for for your work computer, ask your IT team if they can set up a sandboxed environment for you to run agents in.
Sandboxing also allows to allow the agent to be more autonomous and possibly also run in the so called ‘YOLO’ (‘you only look onece’) or ‘dangerously skip permissions’ mode, where the agent essentially can do whatver it decides to do without asking for permissions. That allows you to stop babysitting the agent and let it do its work without interruptions, but it also means that if the agent makes a mistake or is tricked into doing something malicious, it can cause a lot of damage. So be very careful with this mode.
In this workshop in the provided Codespace Docker container you can feel, free to run the agents in this mode.
To run agents in ‘YOLO’ mode, you can either start them in this mode:
gemini -y
agy --dangerously-skip-permissions
# opencode does not have this mode yet, but it can be configured to just skip all permissions in its settings file, ask the agent how to do itGemini CLI also allows swithing it on while running with Ctrl+Y hotkey.
7.2 Ignore files
When working on your tasks, agents often scan and read full files or parts of files in your projects. This data is of course then sent over to the model provider along with your prompt and chat history. This data may (and with free models we use in the workshop will) be used in future model and agent training. Therefore, you might want to exclude certain files from being read by the agent.
You can instruct the agent to ignore certain files with .gitignore file in the project root, or with a custom AGENTS.md file with instructions for the agent (e.g. “never read .env files”). The exact way to do this depends on the agent harness you are using, so ask your agent how to exclude certain files from being read by the agent.
Very often agents will use the default .gitignore file to exclude files from being read. But many have their custom special files such as .ignore (OpenCode), .geminiignore (Gemini CLI), Codex does not have such special file yet, read the documentation of your agent harness to see if it has such special file and how to use it.
But this is not a guarantee that the agent will not read these files, as there are many hacks that a rouge agent might use to bypass these ignore files. Also remember, that agents generally (at least by default) have write permissions to their own setttings files, so there is also no guarantee that the agent will not change its settings to remove the ignore files or edit them.
7.3 Permission Systems
Even inside a sandbox, we may not want the agent to have “God Mode.” Permission systems act as a gatekeeper for sensitive actions. They can also act as a safety net in case you cannot setup a proper sandbox (e.g. you don’t have sufficient permissions to set up a sandbox on your work computer).
Human-in-the-Loop: For high-risk actions (like deleting a directory or pushing to GitHub), the agent should ask for your permission first.
Rule-Based Blocking: Harnesses can be configured to automatically block access to certain folders or commands. For example, an agent might be allowed to edit your code but forbidden from reading your
.sshkeys or.envfiles with passwords (e.g. credentials you may be using to access external services or databases). Also you might configure the agent harness to never execute file deletion commands, or commands that result in git commites or your prjoect data upload to a remote git repository or other backup locaiton (which may lead to data loss or corruption if agent messed something up locally).
7.4 Bottom line
It is very likely that even most sandboxed isolated agent customized with strict permissions will make a mistake at some point and do something you did not want it to do, such as deleting a file or installing a package that breaks your project. This is just the nature of current generation of agents, they are not perfect and they will make mistakes. So always make sure to have proper backups of your work, and if possible use version control (e.g. Git) so you can easily revert any unwanted changes.
For git, consider using authenticaiton that requires user interaction for any changes done in your project locally to be pushed to your remote git repository or backup. Such precations could be a password required for every access to ssh key for sending the data to the remote repository, or a biometric authentication (supported on some laptops and operating systems).