{"slug": "day-26-zero-trust-security-for-ai-sandboxing-ephemeral-execution-and-model", "title": "Day 26: Zero-Trust Security for AI — Sandboxing Ephemeral Execution and Model Egress", "summary": "A developer published a zero-trust design for sandboxing agent-generated code, arguing that once an AI agent can execute code, the model's output must be treated as untrusted. The approach layers a microVM or gVisor boundary, a read-only filesystem with a small in-memory scratch disk, cgroup limits on CPU, memory and I/O, no network access by default, and short-lived read-only credentials, with the whole environment destroyed after each task. The post includes a Python helper that runs untrusted code in a throwaway Docker container with --network none, --read-only, --cap-drop ALL and an unprivileged user.", "body_md": "Once an agent can **run code** (a Python script to analyse a dataset, a command on a server), the old network perimeter stops protecting you. The code was written by a model, and you cannot treat it as trusted. A zero-trust design starts from one assumption: **the model will eventually produce something buggy, unsafe or compromised**, so the system must stay safe anyway.\n\n**In plain terms:** Letting an agent run code on your server is like letting a stranger use your office computer. You would give them a locked guest room with no network cable, a time limit, and a visitor badge that opens nothing important.\n\n**Diagram:** Under zero-trust principles you assume the model will eventually produce buggy, unsafe or compromised code. Generated code must never run on a host or production container. It runs inside a sandbox that limits what it can steal, escalate or change. [See the animated version](https://sureshpallapothu.in/blog/day-26-zero-trust-ai).\n\nRunning generated code directly on a host or in a production container risks data theft, privilege escalation and damaging changes. Instead:\n\n**Diagram:** Agent-generated code runs inside layered isolation: a microVM or gVisor boundary, a read-only filesystem with a temporary in-memory disk, and kernel cgroup limits on CPU, memory and I/O. The whole environment is destroyed as soon as the task ends. [See the animated version](https://sureshpallapothu.in/blog/day-26-zero-trust-ai).\n\n**Diagram:** A code-execution sandbox should have no network access by default. If a task needs an external API, allow that single destination and keep everything else, including the local network and the internet, blocked so data cannot leak out. [See the animated version](https://sureshpallapothu.in/blog/day-26-zero-trust-ai).\n\n**Diagram:** Credentials given to an agent should be read-only, limited to non-sensitive schemas and short-lived. Administrative actions such as schema changes require an authenticated elevation step, and everything is logged. [See the animated version](https://sureshpallapothu.in/blog/day-26-zero-trust-ai).\n\nHere is a practical starting point: a Python helper that runs untrusted code in a locked-down throwaway container. It assumes Docker is installed. For stronger isolation, add `--runtime=runsc` if you have gVisor set up, or use a microVM platform.\n\n``` python\nimport subprocess, tempfile, pathlib\n\ndef run_untrusted(code: str, timeout_s: int = 10) -> str:\n    with tempfile.TemporaryDirectory() as d:\n        script = pathlib.Path(d, \"task.py\")\n        script.write_text(code)\n        cmd = [\n            \"docker\", \"run\", \"--rm\",\n            \"--network\", \"none\",                 # zero network access\n            \"--read-only\",                       # read-only root filesystem\n            \"--tmpfs\", \"/tmp:size=64m\",          # small in-memory scratch space\n            \"--memory\", \"256m\", \"--cpus\", \"0.5\", # cgroup limits\n            \"--pids-limit\", \"64\",                # no fork bombs\n            \"--cap-drop\", \"ALL\",                 # drop Linux capabilities\n            \"--security-opt\", \"no-new-privileges\",\n            \"--user\", \"65534:65534\",             # unprivileged user\n            \"-v\", f\"{script}:/task.py:ro\",\n            \"python:3.11-slim\", \"python\", \"/task.py\",\n        ]\n        try:\n            done = subprocess.run(cmd, capture_output=True, text=True, timeout=timeout_s)\n        except subprocess.TimeoutExpired:\n            return \"Stopped: time limit exceeded\"\n        return (done.stdout + done.stderr)[:4000]     # cap the output size too\n```\n\nTreat the agent's execution environment as an **untrusted runtime boundary**. That is what lets you give agents real capabilities without handing them the keys to the enterprise.\n\n**Day 27:** Observability and tracing for agentic systems: telemetry, logs and metrics.\n\n*Originally published at [https://sureshpallapothu.in/blog/day-26-zero-trust-ai](https://sureshpallapothu.in/blog/day-26-zero-trust-ai), where this post includes animated diagrams.*", "url": "https://wpnews.pro/news/day-26-zero-trust-security-for-ai-sandboxing-ephemeral-execution-and-model", "canonical_source": "https://dev.to/suresh_kumar_de3920bedd1c/day-26-zero-trust-security-for-ai-sandboxing-ephemeral-execution-and-model-egress-ilc", "published_at": "2026-10-26 19:31:01+00:00", "updated_at": "2026-10-26 19:42:28.500957+00:00", "lang": "en", "topics": ["ai-agents", "ai-safety", "ai-infrastructure", "ai-tools"], "entities": ["Docker", "gVisor", "Python"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/day-26-zero-trust-security-for-ai-sandboxing-ephemeral-execution-and-model", "markdown": "https://wpnews.pro/news/day-26-zero-trust-security-for-ai-sandboxing-ephemeral-execution-and-model.md", "text": "https://wpnews.pro/news/day-26-zero-trust-security-for-ai-sandboxing-ephemeral-execution-and-model.txt", "jsonld": "https://wpnews.pro/news/day-26-zero-trust-security-for-ai-sandboxing-ephemeral-execution-and-model.jsonld"}}