Skip to content

Sandboxing

AutoGen Docker Executor vs a Hardened Agent Sandbox

If you are evaluating autogen docker code executor isolation for running model-written code, start with the good news: AutoGen genuinely ships DockerCommandLineCodeExecutor, and it really does put generated code in a Docker container instead of your Python process. That is a meaningful boundary and a real step up from executing code in-process. This post credits that up front, then draws the honest line between "a container" and a hardened agent code sandbox — the difference between Docker's defaults and a profile purpose-built for untrusted model code, plus the piece AutoGen's executor does not do at all: bridging each tool call back through host governance.

Give a Code-Interpreter Agent Your Tools, Keep Approval Gates

Building a code interpreter agent with approval gates means letting the model write and run one program over your tools while every mutating call it makes still stops at a human — and gets counted against a hard per-run budget. That combination is the whole point of this guide. The code-interpreter (codeact) pattern itself is easy; the interesting engineering is the governance you refuse to give up when you hand a model an execution surface. This post is scoped to exactly that: enable agent_pattern="code-action", wrap the tools that change state with an approval gate, keep a hard max_tool_calls cap on the generated program, and pick the gVisor backend when the input is untrusted.

Hot-Reload an Agent's Instructions Without Losing State

You can hot-reload agent instructions without losing state — rewrite a running agent's system prompt mid-conversation, let its graph rebuild around the new prompt, and keep every message the agent has already exchanged — and then undo the whole thing with a single rollback() call. This post is deliberately narrow. It isn't a tour of open mode's fourteen meta-tools; it's about the one mechanic that decides whether a self-modifying agent is safe to run in production: when the agent changes itself, does the live conversation survive, and can you get back? In Promptise Foundry the answer is yes on both counts, and the machinery that guarantees it — a preserved conversation buffer, a max_rebuilds cap, and one-call rollback — is what this article walks through.

The Hidden Risk of Letting an Agent Write Its Own Tools

To let an agent write its own tools safely you have to accept an uncomfortable fact first: the moment an agent authors a Python function and you add it to its toolset, you are running model-written code — and the function it wrote is one string away from open("/etc/passwd") or an outbound socket to an address you never approved. The Voyager-style dream, where an agent grows its own skill library as it explores, is genuinely powerful. It is also the exact point where "the agent got smarter" and "the agent got a shell on my box" become the same event. This post is a threat-model deep dive on Promptise Foundry's create_tool meta-tool specifically — attack by attack — and on the two guardrails that are on by default so self-authored tools stay tools instead of turning into a breach.

The Real Risks of Running AI-Generated Code In-Process

The risks of running AI-generated code are easy to underestimate, because the failure mode is invisible right up until the day it isn't: the program runs, prints a plausible answer, and only later do you notice it also read your .env, listed /, and made an outbound request you never authorized. This post is a threat-model walkthrough rather than another isolation-layer reference. We are going to trace exactly what a model-written Python snippet can reach when it executes inside your process — the working directory and everything around it, environment-variable secrets, and the open network — using LangChain's PythonREPLTool as the worked example, and then show why Promptise Foundry treats a hardened container as the default path instead of something you remember to bolt on.

How to Run AI-Generated Code Safely: The 2026 Field Guide

To run AI-generated code safely you have to satisfy two requirements at once, and most stacks only meet one of them: can the model's code escape the box? and is every tool that code reaches inside the box still governed the way the rest of your agent is? Containment answers the first. Almost nothing answers the second. This field guide contrasts the three ways teams actually run model-written code today — an in-process REPL, a bolt-on third-party sandbox, and a hardened first-party sandbox with a governed tool bridge — and shows why Promptise Foundry treats both containment and per-call tool governance as first-class parts of one layer instead of two separate integrations you assemble yourself.

Can Your Agent Exfiltrate Data? Sandboxing Code With No Network

To sandbox agent code with no network is the single highest-leverage control you can put between a code-writing agent and a data breach — because a program with an open socket doesn't need a bug to exfiltrate your data, it just needs a plausible-looking line the model was talked into writing. A code interpreter that "does some math" also has your process's network stack, and one urllib.request.urlopen turns a local read into a POST to attacker.example. Cutting the egress is obvious. The reason teams don't is subtler, and it's the honest problem this post is about: for most sandboxes, cutting the network also cuts the program off from the very tools it exists to use. This is how Promptise Foundry breaks that trade-off — NetworkMode.NONE, auto-set for the code-action pattern, where the isolated program's only reach to the outside world is your tools, invoked over a filesystem bridge that needs no network at all.

Smolagents CodeAgent vs Promptise: Where Do Tool Calls Run?

The smolagents codeagent vs promptise code-action question is not "who lets the model write one program over your tools" — both frameworks do, and both do it well. It is a narrower, more consequential question: when that program calls issue_refund() or delete_customer(), where does that call execute, and what governs it? This is a precise-delta piece, not a "they have nothing" one. By the end you will know exactly what smolagents' CodeAgent does today, where Promptise's bridge draws a different line, and how a sandboxed program can still trip your approval gate and a hard call cap.