Real-time collaboration for Jupyter Notebooks, Linux Terminals, LaTeX, VS Code, R IDE, and more,
all in one place. Commercial Alternative to JupyterHub.
Real-time collaboration for Jupyter Notebooks, Linux Terminals, LaTeX, VS Code, R IDE, and more,
all in one place. Commercial Alternative to JupyterHub.
Path: blob/main/smolagents_doc/en/pytorch/secure_code_execution.ipynb
Views: 2935
Secure code execution
[!TIP] If you're new to building agents, make sure to first read the intro to agents and the guided tour of smolagents.
Code agents
Multiple research papers have shown that having the LLM write its actions (the tool calls) in code is much better than the current standard format for tool calling, which is across the industry different shades of "writing actions as a JSON of tools names and arguments to use".
Why is code better? Well, because we crafted our code languages specifically to be great at expressing actions performed by a computer. If JSON snippets were a better way, this package would have been written in JSON snippets and the devil would be laughing at us.
Code is just a better way to express actions on a computer. It has better:
Composability: could you nest JSON actions within each other, or define a set of JSON actions to re-use later, the same way you could just define a python function?
Object management: how do you store the output of an action like
generate_image
in JSON?Generality: code is built to express simply anything you can have a computer do.
Representation in LLM training corpus: why not leverage this benediction of the sky that plenty of quality actions have already been included in LLM training corpus?
This is illustrated on the figure below, taken from Executable Code Actions Elicit Better LLM Agents.
This is why we put emphasis on proposing code agents, in this case python agents, which meant putting higher effort on building secure python interpreters.
Local code execution??
By default, the CodeAgent
runs LLM-generated code in your environment.
This is inherently risky, LLM-generated code could be harmful to your environment. One could argue that on the spectrum of agency, code agents give much higher agency to the LLM on your system than other less agentic setups: this goes hand-in-hand with higher risk.
So you need to be mindful of security.
To add a first layer of security, code execution in smolagents
is not performed by the vanilla Python interpreter. We have re-built a more secure LocalPythonExecutor
from the ground up.
To be precise, this interpreter works by loading the Abstract Syntax Tree (AST) from your Code and executes it operation by operation, making sure to always follow certain rules:
By default, imports are disallowed unless they have been explicitly added to an authorization list by the user.
Even so, because some innocuous packages like
re
can give access to potentially harmful packages as inre.subprocess
, subpackages that match a list of dangerous patterns are not imported.
The total count of elementary operations processed is capped to prevent infinite loops and resource bloating.
Any operation that has not been explicitly defined in our custom interpreter will raise an error.
As a result, this interpreter is safer. We have used it on a diversity of use cases, without ever observing any damage to the environment.
However, this solution is certainly not watertight, as no local python sandbox can really be: one could imagine occasions where LLMs fine-tuned for malignant actions could still hurt your environment.
For instance, if you have allowed an innocuous package like Pillow
to process images, the LLM could generate thousands of image saves to bloat your hard drive. Other examples of attacks can be found here.
Running these targeted malicious code snippet require a supply chain attack, meaning the LLM you use has been intoxicated.
The likelihood of this happening is low when using well-known LLMs from trusted inference providers, but it is still non-zero.
[!WARNING] The only way to run LLM-generated code securely is to isolate the execution from your local environment.
So if you want to exercise caution, you should use a remote execution sandbox.
Here are examples of how to do it.
Sandbox setup for secure code execution
When working with AI agents that execute code, security is paramount. This guide describes how to set up and use secure sandboxes for your agent applications using either E2B cloud sandboxes or local Docker containers.
E2B setup
Installation
Create an E2B account at e2b.dev
Install the required packages:
Running your agent in E2B: mono agents
We provide a simple way to use an E2B Sandbox: simply add executor_type="e2b"
to the agent initialization, like:
However, this does not work (yet) with more complicated multi-agent setups.
Running your agent in E2B: multi-agents
To use multi-agents in an E2B sandbox, you need to run your agents completely from within E2B.
Here is how to do it:
Docker setup
Installation
Install the required packages:
Setting up the docker sandbox
Create a Dockerfile for your agent environment:
Create a sandbox manager to run code:
Best practices for sandboxes
These key practices apply to both E2B and Docker sandboxes:
Resource management
Set memory and CPU limits
Implement execution timeouts
Monitor resource usage
Security
Run with minimal privileges
Disable unnecessary network access
Use environment variables for secrets
Environment
Keep dependencies minimal
Use fixed package versions
If you use base images, update them regularly
Cleanup
Always ensure proper cleanup of resources, especially for Docker containers, to avoid having dangling containers eating up resources.
✨ By following these practices and implementing proper cleanup procedures, you can ensure your agent runs safely and efficiently in a sandboxed environment.