<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Sandbox on AI + Quant Engineering</title><link>https://miasyster.github.io/en/tags/sandbox/</link><description>Recent content in Sandbox on AI + Quant Engineering</description><generator>Hugo</generator><language>en</language><lastBuildDate>Fri, 03 Apr 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://miasyster.github.io/en/tags/sandbox/index.xml" rel="self" type="application/rss+xml"/><item><title>Let AI's Code Run — But Don't Let It Run Away</title><link>https://miasyster.github.io/en/posts/sandbox-defense-in-depth/</link><pubDate>Fri, 03 Apr 2026 00:00:00 +0000</pubDate><guid>https://miasyster.github.io/en/posts/sandbox-defense-in-depth/</guid><description>AI-generated code must be executed — otherwise it&amp;rsquo;s just text. But execution means risk. I didn&amp;rsquo;t choose container isolation or RestrictedPython. Instead I designed a three-layer defense: reject dangerous structures at compile time via AST, replace the entire builtins at runtime, and enforce OS-level resource limits as a backstop. Each layer handles a different class of risk. Overlapping but not redundant.</description></item></channel></rss>