Inspiration
Companies are giving AI agents real tools and real credentials, and buying kill switches to feel safe about it. We kept asking one question, has anyone checked that the kill switch works? A fire alarm nobody has tested is just bad news waiting to pounch. Red teaming tools check what an agent says. Nobody was checking the containment around the agent: whether the sandbox actually holds, whether the kill switch fires, and whether anything keeps running afterward. So we built Ares.
What it does
Ares puts a real AI agent (Nemotron via NVIDIA NIM) inside a sealed copy of its environment. The copy has fake services, decoy credentials and planted bait. When the agent touches the bait, Ares pulls the kill switch and measures what happens:
Did the boundary hold? Every event after the kill counts as a breach. Only traffic that actually crossed the boundary counts as a leak. How fast was the agent stopped? Time to kill runs from the bait firing to the moment docker inspect confirms the agent is cut off, not to the moment we sent the command. Can we fix it? If the agent breaks out, Ares names the flaw that let it out, turns that flaw off, and reruns in a fresh lab. It then checks the fix against a held out variant with different paths, hostnames and wording, so a fix that blocks one path can't pass as a fix for the whole category. Finally it opens a GitHub PR with the fix. Results come with Clopper Pearson confidence intervals, not single percentages. A pixel art dashboard replays each drill beat by beat.
How we built it
Leakbox: a deliberately vulnerable sandbox, like DVWA but for agent containment. It runs on Docker Compose with three networks. Two are internal: true, and the only route out is an LLM gateway that swaps the agent's dummy key for the real one. Each flaw is a toggle in a YAML policy. Defender: three kill levers fired in order: gateway deny, then docker network disconnect, then docker pause/kill. Each one is verified before it counts. The first lever takes 3 to 5 ms. No model in the kill path. Bait detection is deterministic code, because a kill switch an LLM can argue with isn't a kill switch. Tamper evident evidence: the lab writes to an append only, hash chained JSONL log on a shared volume, and the final report is signed with ed25519. There is no network path from the lab to the control plane. Stack: Python and pydantic for contracts, scoring and the CLI (ares drill, ares trial, ares fix). The dashboard is React with no build step, so it runs on a conference network or with no network at all.
Challenges we ran into
Negative time to kill. Old sessions reused the same run ID, so we once paired a lever from 36 minutes earlier with a new bait event. The result was a negative time to kill, and a breakout scored as contained. We now key runs on directory plus run ID. The agent got stuck being too thorough. When our fake API answered every path, a 550B model probed it until it hit its step limit and never touched the bait. That looked like a perfect score for the wrong reason. Making unknown paths return 404 fixed it. The creation of the sandbox in the first place, dubbed LeakyBox, took way too much effort. The AI is obviously non deterministic and so we could never consistently get breakouts as we were stressing about the actual demo. We simply run multiple times now as the Nemotron model we use falls for the bait often enough to be consistent.
Accomplishments that we're proud of
We are very proud of Poyo and his bravery when facing these baits. Poyo is by far our proudest accomplishment to date! Once a model, Nemotron 30B for example, falls for our planted bait, we observe its path after terminating it and use another Nemotron model to find the vulnerability, patch it, and then create a informed and detailed PR to the repo that the environment was associated with. We also have a Slack Bot using Slack's public API to send the PR message to associated channels within invited workspaces.
What we learned
Given the option, an LLM does not hesitate to use a dangerous tool or API call that it probably shouldn't have to achieve something regardless of its knowledge of its sandbox. It took a lot of effort to build a good sandbox without an insane amount of vulnerabilities. We learned hat implementing an idea is much more than just implementing the idea. Oftentimes we were arguing different aspects of the idea to try and figure out if it was even worth pursuing as the problem was quite niche at first glance. Upon further research, the problem was far more widespread than we imagined even given the earliest case we could find was around 6 months ago.
What's next for Ares
DNS sinkhole and more Leakbox variants, plus a bait generator so the drills don't become predictable. Reports for people who never run the tool such as auditors, insurers and procurement teams answering security questionnaires. Plug in kill switches: levers already follow a protocol, so next is drilling real customer kill switches such as Okta session revoke, EDR isolation and E2B sandboxes. CI gate: run a drill on every PR that widens an agent's access (a new tool, a new MCP server, a broader allowlist).
