Can we please start sandboxing?

During the past few weeks I spent quite a bit of time researching how to properly secure coding agents. It's a challenging subject for sure. I also ran into some pretty interesting resistance from colleagues on the subject.

There are reasons why I think it important to start paying attention to agent security. Because agents are awesome, but without proper measures they're too dangerous to handle.

Agents can be very unsafe

Language models are awesome but also dangerous when you mix the right ingredients. For example, it's extremely easy for someone to abuse the LLMs through prompt injection.

If you have your agent use unsafe input, give it access to sensitive data, and mix in an outgoing channel or state manipulation, you end up with the lethal trifecta.

Don't think you're not affects: 26% of open-source skills contain some form of prompt injection. So there's roughly a 1 in 4 chance you're going to be hit. Roughly 80% of respondents on a recent enterprise survey said their agents carried out unintended actions. So your agent doesn't always like to follow your instructions.

There's not much you can do about prompt injection. The models are too powerful and flexible. You can easily fool them. I've seen people hack into systems with pretty poems for crying out loud!

The key here is to remove one of the elements of the trifecta to make it safer. Essentially, you need to apply the rule of two to your agent setup. It's a powerful concept, that leads to interesting patterns:

• You can let the agent access sensitive data and modify state, but you shouldn't allow it to process unsafe content.
• Also interesting, use the agent to process sensitive data, with unsafe content, but don't give access to internet or write access in your systems.
• Finally, use unsafe input for your agent, let it research the internet, but don't give it your code or secrets.

Note: I'm saying safer. There's nothing 100% safe in this world. And what you consider acceptable safety may not be acceptable to somebody else.

What's considered sensitive matters

Before you disconnect your computer from the internet, throw away all your secrets, and remove the skills, it's important to understand that context matters a lot here.

Your SSH private key and secrets to the production database are universally considered sensitive data. I think you should not have production accesss on your development laptop. There's not a lot of discussion about that. But your source code may not be that sensitive. For example, my sandboxing code is completely open-source. Not really a secret if you ask me.

For some organizations the source code can't be shared with the outside world. They consider the algorithm their trade secret. Some organizations cannot disclose source code because state actors may use it against them.

My message to you: consider your context before you use something like an agent sandbox.

Breaking the trifecta with a sandbox

After researching agent security I learned that one effective method to break the lethal trifecta is to use a sandbox. But you have to do this right, otherwise it doesn't help.

To break the trifecta, we need to take away one of three legs. However, removing unsafe content is the most difficult leg of the three you have, so not many people consider this a good strategy.

The alternative then, is to remove the agent's access to sensitive data and limit it's open communication channel to the outside world. Here's where a sandbox of some kind becomes useful. It helps you establish an integrity model like the Biba Model.

Place your agent on a separate machine. It's as simple as that. Don't code on the laptop you're using to access your email or maintain environments.

There's a downside to this: You're going to have to carry two laptops around and you need to pay for those laptops. And at today's prices that's not very cost effective. However, there's another way:

• You can use a virtual machine to run your agent. This is very effective, because it's extremely hard to escape. The virtual machine doesn't share anything with your host operating system.
• Alternatively, you can move your agent into a docker container. But this is the less safe option, as it can access other containers, and shares a kernel with your host if you're on Linux.

There are also other options like landlock and bubblewrap, but these are very brittle and I found Claude Code frequently successfully work around these tools.

My personal favorite tools to help me keep things safe are Docker Sandbox or my own Firebrick sandbox solution that I created recently as an alternative. You should also have a look at Huddle, a container based solution for the same purpose.

Firebrick and Docker Sandbox are based on virtual machine technology and offer the strongest isolation next to using a separate laptop. However, I must warn you that some sacrifices were made in the name of usability:

• You can copy/paste data between the host and the sandbox. This opens up a new attack vector. People have been known to abuse the clipboard.
• You share a directory from the host with the agent sandbox. The agent can drop files on your host through that directory. It's dangerous and one of the areas I'd like to improve upon in Firebrick.

As I mentioned earlier: No security solution is 100% because you need some access to do your job. It's up to you to keep things clean.

Tips for keeping things clean

Based on the Biba Model I learned some good tricks to keep things clean:

• Read up, write down: You can read from the host, but you shouldn't write to the host. In other words, clone the sources you work on into the sandbox. Let the agent submit diffs to your source tree that you can review.
• Open your IDE inside the sandbox and consider it dirty. Agents can modify your configuration, so opening that pull request on the host side is dangerous. Better do that in a sandbox.
• Use the secret management feature of the sandbox so you don't expose your secrets. Then configure a separate secret with limited permissions on GitHub/Azure DevOps so the agent can read, but never write to your GitHub/Azure DevOps environment. I also suggest limiting what the agent can read.

It's a lot of work, but with the right posture, you can have your agent work for you without sleepless nights for you or your system administrator!