Security for coding agents: remote, sandbox, and permissions

Now that we use local agents so much, you should know that they have access not only to your project’s code, but also to your environment variables, SSH keys, AWS configuration, and any other file your agent can read.

In the event of a supply chain attack —and there have been quite a few recently—or if your agent decides to read one of those files while exploring, your credentials may end up leaving your machine.

That is why I want to focus on the importance of establishing security limits and controls so that coding agents, such as Codex or Claude Code, cannot access files they should not, and our credentials do not end up on the internet.

In my case, I mostly use Codex and macOS, although this also applies to other harnesses such as Claude Code, OpenCode, or Pi, as well as to other operating systems.

I will walk you through three strategies you can use to improve security while developing, depending on your needs: remote development, virtualization, and permission restrictions.

flowchart LR
    agent[Coding agent] --> remote[Remote development]
    agent --> sandbox[Sandbox or virtual machine]
    agent --> permissions[Local with limited permissions]

Physical isolation with a VPS or homelab

The safest way to develop with agents is to use a remote machine (although it must be configured correctly, with least privilege, a firewall, etc.), whether that is a VPS or a homelab, partially isolated from the network.

This is the easiest option if you like tinkering, and it also allows you to keep agents running in the background and work remotely. For example, I can access them from my phone when I need to.

If you have an old computer at home, you can always set up a homelab with Ubuntu Server (or Proxmox, although I have not taken that step yet), or you can rent a Hetzner server for a few euros a month.

The important thing is to provide the agent with the minimum secrets it needs to work, and to protect the ones that must exist (GitHub, Codex, and so on). You can use the access policy described below to find a balance between convenience and security.

Outbound traffic filtering could also be useful, although that is a more advanced topic.

Using a virtual machine or sandbox

Another, more convenient option is to use a virtual machine on your computer, so that the agent has limited access to its resources. This is a middle ground between running it locally and having the protection of a VPS, as long as you configure the virtual machine securely.

There are many tools you can use to create virtual machines, for example:

  • On Mac, I use LimaVM to create a virtual machine and limit the agent’s access. I also use it to protect myself while developing, in case of a supply chain attack where the agent tries to access my data.
  • On Linux, you can use Incus, which has caught my attention, although I have not tried it yet.
  • You can also use a Docker (or Podman) container, although it is somewhat less secure because it shares the kernel with your computer. Docker Sandbox was launched recently; it requires you to sign in with an account, and the community is not very happy about it.

This is an example of a minimal Lima configuration, although I am still reviewing some settings that I have not fully figured out yet in order to make it properly robust.

Running the agent locally: access policy

Sometimes there is no other option, or it is simply more convenient, to investigate or run some commands locally. For this, Codex allows you to define a configuration file, usually ~/.codex/config.toml, which expresses your preferences, although the agent can bypass it. By contrast, ~/.codex/requirements.toml is a strict limit.

In my case, I restrict some permissions: I only allow the projects I authorize to be read, and prevent the agent from reading data in my user folders (.ssh, .config, and so on) or any .env files.

Finally, you can also configure what your agent should do when it encounters certain commands (prompt, allow, deny), allowing commands such as git add or git commit and adapting the policy to your needs.

Conclusion

My rule is simple: I work according to how much I trust the task. If I want to leave an agent working on long-running tasks, I usually do it in my remote homelab; if it is something I trust, I do it locally and supervise it; and if it raises doubts, I run it in a virtual machine.

Ultimately, the important thing is to be aware of the agent’s limits and the risks it may pose.