Sandboxing Tool Calls

The model can call tools; tools can do real things

Once tools have side effects (send email, run code, fetch URLs), the runtime around them needs sandboxing — limits on what each call can do, regardless of how confidently the model called it.

Sandboxing patterns

Resource limits — tools that fetch URLs hit a network policy that blocks internal IP ranges, file:// URLs, and metadata endpoints.
Process isolation — code-execution tools run in containers / VMs / WASM; no host filesystem or env access.
Rate limits per tool — caps on how many times an agent can call a sensitive tool in one session.
Allow-listing — sensitive tools (charge_card, send_email_external) require a confirmed allow-list; otherwise refuse.
Dry-run modes — agent's first call is a 'plan,' not an 'execute.' Human or downstream check before commit.

The runtime owns the limits, not the prompt

Telling the prompt "do not call charge_card on amounts over $1000" is a guideline. The tool implementation rejecting calls over $1000 is a guarantee.

Code

URL fetcher with SSRF defense·python

import ipaddress
import socket

DENY_NETS = [
    ipaddress.ip_network(n) for n in [
        "127.0.0.0/8", "10.0.0.0/8", "172.16.0.0/12", "192.168.0.0/16",
        "169.254.0.0/16",  # link-local + cloud metadata
    ]
]

def fetch(url: str) -> str:
    if not url.startswith(("http://", "https://")):
        raise ValueError("only http(s)")
    host = urlparse(url).hostname
    addr = ipaddress.ip_address(socket.gethostbyname(host))
    if any(addr in net for net in DENY_NETS):
        raise ValueError("blocked target")
    return httpx.get(url, timeout=10).text

The model can call tools; tools can do real things

Sandboxing patterns

The runtime owns the limits, not the prompt

Code

External links

Exercise

Progress

Comments 0