An AI sandbox is what makes it safe to let an AI agent actually do things: run commands, install packages, build your app, fetch documentation and connect to your servers. Without one, every command the AI types would run with real power over real systems. With one, the agent can work freely while the damage any single mistake can cause stays small and contained.
On AI Codes It, our agent writes code, runs it and fixes what breaks, often dozens of steps in a row. This article explains the guardrails around that work: what the AI sandbox allows, what it blocks, and why. We describe what each guardrail does for you. The exact internals stay private, because a detailed map of our defenses would mostly help people trying to get around them.
What is an AI sandbox?
In computer security, a sandbox is a restricted environment where untrusted code can run without affecting the system around it. Browsers sandbox every website you open. Phones sandbox every app. The idea is old and proven: assume the code inside might misbehave, and make sure it cannot reach anything important.
An AI sandbox applies the same idea to an AI agent. Large language models are powerful, but they are not perfect. They can misunderstand a request, copy a broken command from the web, or be manipulated by text they read. A good AI sandbox does not try to make the model flawless. It makes sure that when the model is wrong, the consequences stay inside the box.
Why agents need sandboxes more than chatbots
A chatbot only produces text. You read it and decide what to do. An agent acts on its own: it runs a command, reads the output, decides the next step and runs another. That loop is what makes agents useful, and it is also what makes guardrails essential. There is often no human between one step and the next.
The OWASP Top 10 for LLM Applications lists “excessive agency” and prompt injection among the biggest risks of AI systems. An AI sandbox is the most direct answer to both: limit what the agent can touch, and limit what a manipulated agent could do.
Guardrail 1: every command runs in a disposable AI sandbox
When our agent needs to run something, for example a test script, a build step or a quick check, the command does not run on the server directly. It runs inside an isolated, short-lived AI sandbox created for that job and thrown away afterwards.
- It only sees your project. The sandbox exposes your project folder and nothing else: no other users’ projects, no platform files.
- It has no administrator rights. Commands run as an unprivileged user and cannot change the system they run on.
- The system is read-only. Tools and libraries are available, but they cannot be modified or replaced.
- Dangerous operations are blocked. Low-level operations that sandboxed code has no business using are refused outright.
- It has strict limits. Processing time, memory, file sizes and the number of processes are capped, so a runaway loop or a fork bomb simply stops.
The result: even a completely wrong command can, at worst, affect files in your own project, and your project keeps a version history so those can be restored.
Guardrail 2: no secrets inside the AI sandbox
Every platform runs on keys: payment providers, email services, databases, AI models. If those keys were visible inside the environment where AI-driven commands run, a single printed variable could leak them.
That is why our AI sandbox follows a strict rule: commands receive an explicit, short list of harmless settings, and nothing else. Platform credentials are never passed in. The same rule applies to the in-editor terminal, to builds, to previews and to published sites.
Your own project secrets, such as your project’s database login, are scoped to your project only. And the AI’s database access goes through your project’s own login, which can only see your project’s data.
Guardrail 3: package installs and builds in throwaway environments
Modern apps depend on hundreds of open-source packages. Installing them means running install scripts written by strangers. Most are harmless, but supply-chain attacks, where a popular package is hijacked to run malicious code, are a real and growing problem.
On AI Codes It, installing packages and building your app happen in throwaway, isolated environments:
- They can download packages from the public internet, which builds need.
- They cannot reach the platform’s internal services.
- They run without administrator rights and with resource limits.
- They are deleted when the build finishes.
If a package ever did something nasty during installation, it would find itself in an empty room with only your project’s files and no keys, and the room would be gone minutes later.
Guardrail 4: previews and published sites are sandboxed too
An AI sandbox should not stop at the agent’s own commands. The code the agent writes eventually runs as your live preview and, once you publish, as your website. That code deserves the same caution.
- Live previews in the editor run in their own isolated containers, with only your project folder available.
- Published sites each run in their own isolated container, with an additional sandboxing layer between the site and the server’s operating system.
- Neither can see other projects or the platform’s internal network, and neither receives platform secrets.
We cover the hosting side in detail in our article on secure website hosting, including DDoS protection, encryption and how private files are kept private.
Guardrail 5: web access that can’t reach inside
Our agent can read web pages to look up documentation or check an API. That is useful, but it opens a classic attack called server-side request forgery (SSRF): tricking a server into requesting an internal address on the attacker’s behalf.
The agent’s fetch tool is built to refuse that:
- Public internet only. Every address a request would go to is checked, including disguised forms of internal addresses, and private or internal destinations are refused.
- No address switching. The connection goes to the exact address that was checked, so a domain cannot point somewhere safe during the check and somewhere internal a moment later.
- No surprise redirects. Redirects are not followed blindly.
- Size and time limits. Huge downloads and slow responses are cut off.
Curious how the agent works with real browsers too? See our post on the AI browser agent for live web browsing.
Guardrail 6: SSH to your servers, never to ours
Many users manage their own servers and want the AI to help: check logs, restart a service, deploy a fix. Our SSH tool gives the agent real shell access to your server, with a password or a key, whichever you prefer.
Because that tool runs inside our platform, it has its own AI sandbox rules:
- It cannot be pointed at the platform. Our own infrastructure and any internal or private address are refused, so the tool can never be turned into a back door.
- It remembers each server’s identity. The first time it connects, it records the server’s fingerprint. If that fingerprint ever changes, the connection is stopped and you get a clear warning, which protects you from someone impersonating your server.
- Credentials stay out of the output. Passwords and keys are redacted from anything the agent sees or shows.
Guardrail 7: you stay in control
The best AI sandbox is invisible when things go well and obvious when they do not. We designed the agent so you can always see what it is doing and stop it.
- Every tool call is visible. Commands, file edits and web requests show up in the chat as they happen. Our post on pipeline tool call transparency explains how.
- Budgets are enforced. The agent checks your balance before and during a reply and stops when the limit is reached, so a runaway loop cannot run up costs. See AI cost transparency and budget limits.
- History you can rewind. Your project keeps a version history, so any change the AI made can be reviewed and rolled back.
- Configurable agents. With the AI agent harness you decide which tools an agent may use at all.
Prompt injection: why the AI sandbox matters even for a perfect model
Prompt injection is one of the hardest problems in AI security. An attacker hides instructions inside content the AI reads, for example a web page, a code comment or a document, hoping the model will follow them instead of you.
No model today is fully immune. Security researchers such as Simon Willison have shown again and again that clever wording can steer even the best models. That is exactly why we do not rely on the model to behave. We rely on the AI sandbox to limit what a manipulated model could do:
- It cannot read platform secrets, because they are not there.
- It cannot reach internal services through the fetch tool or the SSH tool.
- It cannot touch other users’ projects, because it cannot see them.
- It cannot spend without limit, because budgets are enforced outside the model.
In short: the model might be fooled, but the sandbox is not a language model, and it does not take instructions from web pages.
A walkthrough: one request through the AI sandbox
Guardrails are easier to understand in action. Say you ask the agent: “Add a contact form that stores messages in my database and emails me a copy.” Here is roughly what happens, and where the AI sandbox comes in:
- Reading your project. The agent looks through your files to understand the structure. It can only read your project, nothing else on the platform.
- Looking things up. It may fetch the documentation of an email library. The fetch tool goes to the public site and refuses anything internal.
- Writing code. It creates the form, the server-side handler and a database table. Every file change appears in your chat.
- Installing a package. If it needs an email library, the install runs in a throwaway environment that can download from the public registry but cannot reach anything internal.
- Testing. It runs a quick check in a disposable sandbox with strict limits. If the test hangs or misbehaves, the limits stop it.
- Previewing. Your live preview updates in its own isolated container, so you can try the form right away.
- Storing secrets correctly. The email service key goes into your project secrets, not into page code, so visitors can never read it.
At no point does any step need access to other projects, platform keys or internal services, so none of them has it. That is the whole philosophy of the AI sandbox in one example.
What an AI sandbox does not do
Being honest about limits is part of good security. An AI sandbox contains the actions of the agent. It does not guarantee that every line of code the agent writes is correct or secure.
- It does not review your business logic. If you ask for a page that shows customer data to anyone, the sandbox will not stop the agent from building it. Think about who should see what.
- It does not replace testing. The agent tests as it goes, but try important flows yourself before you publish, especially payments and sign-ups.
- It does not protect secrets you paste into code. Anything inside your pages is readable by visitors. Use project secrets instead.
- It does not control third-party services. If your site connects to an outside API, that service’s own security still matters.
Put simply: the AI sandbox makes sure the agent cannot harm the platform, other users or your secrets. Building a good, safe product on top is still a partnership between you and the agent.
AI sandbox vs. running an agent on your own machine
Many developers run AI coding agents directly on their laptops. That can be convenient, but it is worth knowing what you give up.
| Aspect | Agent on your own machine | AI sandbox on AI Codes It |
|---|---|---|
| File access | Often your whole home folder | Only your project folder |
| Secrets | Whatever is in your shell and config files | None from the platform; only your project’s own |
| Package installs | Run directly on your computer | Run in throwaway, isolated environments |
| Internal network | Your home or office network is reachable | Internal destinations are refused |
| Runaway costs | Depends on your own limits | Budgets enforced on every reply |
| Rollback | Only if you committed in time | Built-in version history |
How to work safely with an AI agent: 6 practical tips
An AI sandbox removes most of the risk, but good habits still help. These apply to any AI agent, on any platform:
- Keep secrets in project secrets. Never paste API keys or passwords into the chat or into page code.
- Read the tool calls. Skim what the agent ran, especially before you publish.
- Be careful with untrusted content. If you ask the AI to read a random web page or document, remember it might contain hidden instructions.
- Give SSH access with care. Prefer a dedicated user on your server with only the rights the task needs, rather than full administrator access.
- Set a budget you are comfortable with. Limits protect you from surprises.
- Review before publishing. Remove test pages, sample data and admin screens you do not need.
The NIST AI Risk Management Framework is a good, vendor-neutral read if you want to go deeper into managing AI risks in your own organisation.
Why we explain the guardrails, but not the blueprints
We believe users deserve to know how their projects are protected, so we describe every guardrail and what it means for you. What we do not publish are exact limits, configurations, software choices or internal layouts. Those details help attackers far more than they help users.
If you are a security researcher and think you have found a way around one of these guardrails, please contact us privately before publishing. We take every report seriously and will work with you on a fix.
Frequently asked questions
Can the AI agent see other users’ projects?
No. Its AI sandbox only exposes your project, and it has no credentials that would let it reach anyone else’s.
Can the AI break my project?
It can change files in your project, that is its job. Every change is visible in the chat, and the version history lets you restore an earlier state at any time.
Does the AI sandbox slow things down?
Hardly. Sandboxes start in a fraction of a second, and most of the time is spent on the actual work, like installing packages or building.
Is an AI sandbox enough on its own?
It is the most important layer, but not the only one. It works together with budgets, transparency, version history and the protections on the hosting side. Together they form defense in depth.
Conclusion: freedom for the agent, boundaries for the risk
An AI agent is only as trustworthy as the box it runs in. On AI Codes It, the AI sandbox lets the agent run commands, install packages, browse documentation and work on your servers, while keeping secrets out of reach, other projects invisible and internal systems off-limits.
You get an agent that can really build, and the confidence that a mistake, a bad package or a cleverly worded web page stays contained. If you have not tried it yet, start a project and watch the agent work; every step it takes happens inside these guardrails.
Keep reading: Secure Website Hosting · AI Agent Harness · Pipeline Tool Call Transparency