Lion Cipher Lab
Sandbox AI-generated code with a locked-down executor (contain the code your agent writes)
- AI Security
- Advanced
- ~90 min
- Free · no account required
Why it matters
Give an LLM a 'code interpreter' or 'run this code' tool and you have built the most dangerous endpoint in your stack: one where an attacker's goal (getting you to run their code) is the FEATURE, not the bug. The model writes Python; your harness runs it. If your harness runs it with `exec()` or `subprocess.run()`, you have wired a stranger's keyboard straight into your process — and the OWASP Top 10 for LLM Applications is explicit that model output must be treated as untrusted (Improper Output Handling: unvalidated output flows downstream into code execution; Excessive Agency: an agent with…
What you'll learn
- treating model/agent output as UNTRUSTED input (OWASP LLM Improper Output Handling & Excessive Agency)
- seeing exactly why a bare exec()/subprocess code-interpreter tool is RCE against your own host
- building a locked-down Docker executor from scratch: --network none, --read-only, --cap-drop ALL, no-new-privileges, --pids-limit, --memory, --tmpfs, non-root user, host wall-clock timeout
- proving four concrete escapes are each blocked, and naming WHICH control stopped WHICH escape
- a defense-in-depth setrlimit(2) pure-Python fallback for when Docker is absent — and an honest read on its weaker guarantees
Steps in this lab
- The threat model: model output is untrusted input
- Build the naive executor — the one you must never ship
- The four escapes the model's code might contain
- Watch the naive executor fail all four
- Build the locked-down executor (Docker: the primary path)
- Re-run all four escapes — and name what stopped each
- The fallback: pure-Python setrlimit — and where it stops
- Named failure modes — a sandbox is defense-in-depth, not one flag
- Wire it into the agent — and clean up