Stack
The problem with running code an AI wrote
The moment you let an AI generate code and then run it, you have a security problem. The code might be fine, or it might delete files, leak secrets, or hammer the network. CodeCourier was my answer: a service that takes a snippet, runs it somewhere it can do no harm, and returns the result.
Sandboxes are the whole point
The core idea is that the code runs in a disposable, isolated environment, a sandbox, that has no access to anything I care about. If a snippet tries something nasty, the worst case is that the sandbox gets thrown away. I leaned on existing sandbox infrastructure rather than rolling my own isolation, because getting isolation subtly wrong is how you get owned.
- Each run gets a fresh, throwaway environment with no host access and no real secrets.
- Network and filesystem are locked down by default; you grant access deliberately, never accidentally.
- Timeouts and resource limits stop a runaway snippet from costing you money or hanging forever.
Why I did not build my own isolation
My instinct was to clever my way to a homemade sandbox. I am glad I did not. Isolation is a domain where the failure mode is silent and catastrophic: you think you are safe until you are very much not. Using purpose-built sandbox tooling meant the hard, security-critical part was handled by people who specialise in it, and I got to focus on the orchestration around it. That is the same instinct as using an auth provider instead of rolling your own login: some problems are too sharp to solve from scratch.
Lessons learned
- Never run untrusted or AI-generated code on a machine you care about. Always sandbox it.
- Default to locked-down. Grant network and filesystem access deliberately, never by accident.
- Do not roll your own isolation. Security-critical primitives are where you stand on the shoulders of specialists.
- Timeouts and resource caps are not optional. A sandbox without limits is just a slower way to get hurt.