Least-privilege tools and sandboxing

How it works: least-privilege tools

1. List each tool's worst case: if a hostile actor controlled the model, what could this tool do?
2. Make tools narrow: get_order_status(order_id) instead of run_sql(query); send_reply(ticket_id, text) instead of send_email(to, body). Narrow tools are also easier for the model to use correctly (tool calling).
3. Minimal permissions in the system itself: read-only database users or connections, API tokens with narrow scopes, file access limited to one folder.
4. Act as the user, not as a superuser: the agent's credentials carry the end user's identity and permissions, so it can never see more than the user could (agent authorization).
5. Short-lived credentials: tokens that expire in minutes, issued per task, never long-lived keys in the agent's context (secrets).
6. Validate arguments in code: IDs belong to the user, amounts within limits, paths inside allowed folders.
7. Remove what isn't used: review tool lists regularly; every tool is attack surface.

How it works: tool sandboxing

1. Anything that runs code or commands (code interpreters, coding agents, shell tools, browser automation) runs in a sandbox.
2. Isolation level: a separate process is the minimum; containers are common; microVMs (e.g. Firecracker, gVisor-style kernels) or hosted sandboxes give stronger isolation for untrusted code (Docker).
3. Nothing worth stealing: no production secrets or environment variables, a throwaway filesystem with only the files the task needs.
4. Network rules: no network, or an allow-list (e.g. a package mirror only), to stop data exfiltration.
5. Resource limits: CPU, memory, disk, process count and wall-clock time.
6. Destroy after use: a fresh sandbox per task or session; copy out only the results (a diff, a file) for review.
7. Log commands and outputs for audit.

import os, sqlite3, subprocess, sys, tempfile
 
# LEAST PRIVILEGE: the agent's "query orders" tool opens the database READ-ONLY.
db = os.path.join(tempfile.mkdtemp(), "shop.db")
with sqlite3.connect(db) as con:
    con.execute("CREATE TABLE orders (id INTEGER, status TEXT)")
    con.execute("INSERT INTO orders VALUES (1, 'shipped')")
 
def query_orders(sql: str):
    con = sqlite3.connect(f"file:{db}?mode=ro", uri=True)      # read-only connection, enforced by SQLite
    try:
        return con.execute(sql).fetchall()
    except sqlite3.OperationalError as e:
        return f"refused: {e}"
    finally:
        con.close()
 
print(query_orders("SELECT * FROM orders"))
print(query_orders("DELETE FROM orders"))                    # even if the model is tricked into this
 
# SANDBOXING (light version): run model-written code in a separate process with a timeout,
# an empty environment (no API keys) and a throwaway working directory.
code = "import os; print('keys visible:', [k for k in os.environ if 'KEY' in k]); print(sum(range(10)))"
os.environ["OPENAI_API_KEY"] = "dummy-not-a-real-key"
result = subprocess.run([sys.executable, "-I", "-c", code], capture_output=True, text=True,
                        timeout=5, env={"SYSTEMROOT": os.environ.get("SYSTEMROOT", "")},
                        cwd=tempfile.mkdtemp())
print(result.stdout.strip())

[(1, 'shipped')]
refused: attempt to write a readonly database
keys visible: []
45