Everyone is building AI agents right now. They are connecting them to APIs, giving them file system access, and letting them write code.
But almost nobody is talking about what happens when the agent hallucinates, gets prompt-injected, or decides to run an infinite loop.
If you give an AI agent the keys to your environment, you aren't just building a feature. You are building a security risk.
I’m 12 years old, and I’m building KODA, an AI coding ecosystem. Because I build entirely on a $150 Android phone on spotty 3G, I don't have the luxury of heavy, bloated security suites. Every millisecond of CPU and every megabyte of RAM counts.
Recently, I had a deep technical discussion with a senior engineer about Docker’s new agent architecture and the "two-writer rule" for AI isolation. It completely changed how I approach KODA’s secure JavaScript sandbox.
Here is the mental model I’m using to secure AI execution, and why I’m actively trying to break my own code before anyone else does.
The Core Problem: The "Black Box" Execution
When an AI generates JavaScript code and you run it in the browser, the default behavior is to give it full access to the DOM, window, localStorage, and the network.
If the AI is tricked by a malicious prompt injection, it can:
- Steal the user's session tokens from
localStorage. - Inject malicious scripts into the DOM.
- Spam API endpoints until your server crashes.
You cannot trust the AI's output. Therefore, the environment it runs in must assume hostility from line one.
The Philosophy: "Break Your Own Sandbox"
A senior engineer recently gave me the best piece of security advice I’ve ever received:
"Break your own sandbox before anyone else does, and write down what fell out. The failures you publish become the spec everyone else trusts."
Most developers build a sandbox, test it with "happy path" code (like console.log("Hello World")), and call it a day.
Instead, I am treating KODA’s sandbox like a Chaos Engineering target. Before I add a new feature, I write a script specifically designed to escape the sandbox. I try to access window.parent. I try to execute an infinite while loop. I try to bypass the JSON schema validation.
If my attack script succeeds, the feature doesn't ship. Period.
How KODA Handles AI Execution (The Architecture)
Building a secure JS sandbox on a low-end mobile device requires ruthless architectural discipline. Here are the three non-negotiable rules I enforce in KODA:
1. Strict DOM and Global Isolation
The AI-generated code never touches the real window or document objects. It runs in a heavily restricted Web Worker / iframe environment. I use a Proxy to intercept any attempts to access global variables. If the code tries to read window.location, the proxy returns undefined or throws a custom error. It doesn't just fail silently; it fails loudly.
2. The "Fail Closed" Schema Validation
Before the code is even executed, the AI's output is parsed against a strict JSON schema. If the AI is supposed to return a configuration object, but it returns a function or an unexpected string, the parser rejects it immediately. We don't try to "fix" the AI's output. We reject it and ask for a retry.
3. The "Two-Writer" Rule for State
This is the biggest takeaway from my recent discussions. An AI agent should never be allowed to both propose a state change and approve it.
In KODA, the AI can generate the code (Writer 1), but the execution engine and the strict sandbox boundaries (Writer 2) decide if it's allowed to run. Separation of duties prevents self-attestation loops.
The Constraint Advantage
People think building on a $150 phone is a disadvantage. In security, it’s an unfair advantage.
When you have 4GB of RAM and a mid-tier processor, you can't afford to run heavy, redundant security checks. Every single control has to earn its place. It forces you to write lean, deterministic, and highly optimized code. You can't hide bad architecture behind a massive cloud budget.
The Takeaway
If you are building AI agents, stop asking "What can this agent do?" and start asking "What is the worst thing this agent could do, and how do I make it physically impossible?"
Don't wait for a user to find the exploit. Break your own sandbox first. Publish the failures. Build the spec.
I’m still learning, and KODA is still in development. But treating security as a daily practice, rather than an afterthought, is the only way to build tools that people can actually trust.
How are you securing your AI agents? Are you using Web Workers, iframes, or server-side sandboxes? Let’s discuss in the comments! 🐯
