Teaching AI Agents to YOLO Responsibly

tl;dr: I created llm-rustyolo, a Rust+Docker security wrapper that lets AI coding agents run with elevated permissions without accidentally becoming your worst employee.

---

The Problem: AI Agents Want Superpowers

AI coding agents like Claude Code are legitimately impressive. They can write code, run tests, debug issues, and even refactor entire codebases. But here’s the thing: to do their job well, they need permissions. Real permissions. The kind that make security professionals break out in hives.

Want the agent to install dependencies? It needs filesystem access. Want it to run your test suite? It needs to execute commands. Want it to deploy your app? Well, now we’re talking about network access and potentially root privileges.

This creates what software engineer Simon Willison has dubbed the Lethal Trifecta of AI Agent Security Concerns:

The traditional solution? Run the agent in “sandboxed mode” where it can’t do anything dangerous. Which is great, except now it also can’t do anything useful. It’s like hiring a chef but not allowing them near the stove. In the parlance of the youths:

---

The Solution: llm-rustyolo

So I built llm-rustyolo: a security wrapper that lets AI agents run with elevated permissions inside Docker containers while systematically addressing each element of the Lethal Trifecta.

The name? LLM (Large Language Model) + YOLO (You Only Live Once) + Rust (the language it’s written in). Because sometimes you need to let AI agents YOLO, but responsibly.

How It Works

The architecture is relatively simple: a two-component design that separates concerns between the host and the container.

Component 1: The Rust CLI (rustyolo)

A host-side binary that constructs secure Docker commands. Think of it as a very paranoid bouncer checking IDs at the container entrance. It:

• Mounts only your project directory (no sneaky access to /etc/passwd)
• Passes through environment variables you explicitly approve
• Handles volume mounting for things like authentication directories
• Builds a whitelist of network domains the agent can talk to

# Example: Run Claude Code with access to only the current directory
# and permission to talk to bubbabrooks.info
rustyolo --workspace . --allowed-domain "bubbabrooks.info"

Component 2: The Container Entrypoint

Once inside the container, a shell script entrypoint enforces the security policies:

• Sets up iptables firewall rules blocking all outbound traffic except DNS and whitelisted domains
• Creates a non-root user with UID/GID matching your host user (so file permissions don’t become a nightmare)
• Drops privileges before handing control to the AI agent

The result? The agent runs in a locked-down environment where it can only:

• Access files you explicitly mounted
• Make network requests to domains you approved
• Write files with your user’s permissions (not root’s)

It’s like a playground with guardrails. The agent can run around and have fun, but it can’t wander into traffic.

---

The Lethal Trifecta: Solved

Let’s revisit our security concerns:

✅ Filesystem Isolation

Docker bind mounts mean the agent sees only your project directory. Want to give it access to a credentials file? You mount it explicitly. Otherwise, it doesn’t exist to the agent.

✅ Privilege Isolation

The entrypoint creates a non-root user with permissions matching your host user. Files created by the agent are owned by you, not root. No more sudo chown -R cleanup sessions after the agent is done.

✅ Network Isolation

Dynamic iptables rules block all outbound traffic except:

• DNS (because the agent needs to resolve hostnames)
• Domains you explicitly whitelist

The agent can talk to the Anthropic API to think, but it can’t phone home to sketchy domains or exfiltrate data.

---

The Tech Stack

• Rust: For the CLI wrapper. Because if I’m building security tooling, I want the compiler yelling at me about memory safety.
• Shell: For the container entrypoint script. Sometimes bash is just the right tool.
• Dockerfile: For packaging the secure agent environment.

---

Inspiration and The “Why”

I didn’t invent this concept. This project was born from a very practical itch:

• Anthropic’s sandbox-runtime: It’s the “official” tool, but I found it clunky and hit a wall trying to get it running on my Mac.

• deva: A great, simple shell-based approach, but it lacked the granular, outbound network firewall I needed. It’s not enough to just block all network access; I need to control it.

• Simon Willison’s work: He’s been writing extensively—and scaring me sufficiently—about the security considerations of AI agents, which helped frame the exact problems to solve.

llm-rustyolo is my answer. It’s an attempt to take the security-first mindset of Willison, add the iptables networking that deva was missing, and wrap it all in a Rust CLI that’s (hopefully) easier to get running than the official sandbox.

---

Should You Use It?

If you’re:

• Running AI coding agents on production machines
• Working with sensitive codebases
• Generally concerned about giving AI agents root access to your computer

Then yes, you should probably use something like llm-rustyolo. Or deva. Or whatever security wrapper makes sense for your threat model.

If you’re just experimenting with AI agents on a VM you can nuke from orbit if things go sideways? Maybe this is overkill.

But remember: the best time to implement security is before you need it. The second best time is now, before your AI agent accidentally commits your .env file to a public GitHub repo, just to be slurped up by crypto miners to drain your coffers!

---

Get Started

The project is open source on GitHub under the MIT license. Contributions, issues, and feedback are welcome.

Installation is straightforward:

# Clone and build
git clone https://github.com/brooksomics/llm-rustyolo
cd llm-rustyolo
cargo build --release

Now go forth and let your AI agents YOLO responsibly.

---