Walk through AutoGen local code-execution pattern and its sandboxing risk

AutoGen models a task as a conversation between agents. Two are involved here: an AssistantAgent backed by an LLM, and a UserProxyAgent that stands in for the human. The assistant's job is to think. When it decides the next step needs code, it writes a fenced Markdown block, `python` or `sh`, inside its message. The user proxy reads incoming messages and looks for those fences. If `code_execution_config` is set, the proxy extracts the code and runs it. By default the proxy runs the code as a local subprocess in the working directory, with the same permissions as the Python process hosting AutoGen. The standard output and standard error are captured and posted back as the proxy's next message. The assistant reads that output and either declares the task done or writes the next block. The risk is that the assistant can be steered by attacker text. A poisoned web page, a prompt injection in a document, a hostile user turn. Once steered, the code it writes runs on your host.

AutoGen's local code-execution pattern is a two-agent loop. The AssistantAgent's LLM emits Markdown code fences inside its reply. The UserProxyAgent owns a reply hook that scans incoming messages for those fences and, if `code_execution_config` is set, hands the extracted code to an executor. The default executor is local. It writes the code to a file in the working directory, runs it as a subprocess with the host process's permissions, captures stdout and stderr, and posts the captured output back as the proxy's next message. The assistant reads the output on the next turn and decides whether to emit more code or finish. The production risk is direct: whoever steers the assistant chooses what runs on the host. The assistant has no built-in distinction between code it wrote on its own initiative and code it was tricked into writing by a poisoned document, a hostile tool response, or a prompt injection in a user message. The blast radius is the host's filesystem, network, and credentials. The mitigation is to swap the executor. Setting `code_execution_config={'executor': DockerCommandLineCodeExecutor(...)}` runs code inside a disposable container with no host mounts, capped CPU and memory, and an execution timeout. The Jupyter executor offers a similar isolation surface. The cost is a small per-invocation latency hit; the benefit is that an attacker who hijacks the assistant can only damage the container.