If an AI model writes code and your system runs it, that code is untrusted, no matter how good the model is. Sandboxing means running it somewhere it can't touch your production data, secrets or network unless you explicitly allow it. With coding agents and "analyse my data" features everywhere, this has gone from a niche concern to a basic requirement.
Where AI-generated code runs today
- Coding agents running tests, installing packages and executing scripts in your repository.
- Data features, for example "upload a spreadsheet and ask questions", where the model writes Python to answer.
- Automation tools that generate and run scripts to transform files or call APIs.
Each one is a way for a confused model, or a malicious prompt hidden in a document, to do damage.
Sandboxing options, from light to strong
| Option | Isolation | Good for |
|---|---|---|
| JavaScript isolates (separate V8 contexts) | Moderate | Small, fast snippets |
| WebAssembly runtimes | Strong for compute | Plugin-style logic |
| Containers with strict limits | Good, if hardened | Most agent workloads |
| MicroVMs (Firecracker-style) | Strongest | Untrusted code at scale |
Rules that apply whatever you choose
- No secrets inside the sandbox. Pass only the data the task needs.
- Deny network by default. Allow-list specific domains if a task really needs them.
- Limit resources: CPU, memory, disk and a hard time limit.
- Throw it away. Use a fresh environment per task, never reused.
- Treat output as untrusted too. Validate files and results before they reach your app.
- Log everything the code did, for debugging and audit.
Prompt injection, where instructions are planted in content the model reads, is the main reason "the model wouldn't do that" isn't a security strategy. OWASP lists it first among LLM application risks.
Building safe AI features
At NextGen Fusion, our AI and software development company in Lucknow, AI features that execute code run in isolated, throwaway environments with no access to production secrets, by design.
