second-brain

agent-sandbox

2 min read

Agent Sandbox

Isolated per-user execution environments that let agents run arbitrary code safely.

Last updated: 2026-04-12

Overview

Agents that handle multi-step tasks inevitably need to execute code — build spreadsheets, run scripts, install packages, manipulate files. Doing this on shared infrastructure is dangerous. The solution is a dedicated sandbox per user where the agent can do whatever it wants without affecting anyone else.

At Fintool, each user gets an isolated environment with three S3-backed mount points:

  • Private — read/write, scoped to that user
  • Shared — read-only, scoped to the organization
  • Public — read-only, available to all users

Access control is enforced at the credential level using AWS ABAC (Attribute-Based Access Control). Short-lived IAM credentials are scoped to specific S3 prefixes via ${aws:PrincipalTag/S3Prefix}. User A physically cannot access User B’s data — it’s enforced by IAM, not application logic.

Key Points

  • Sandbox pre-warming: when a user starts typing, the sandbox spins up in the background. By the time they submit, the environment is ready — no cold-start latency
  • Timeout management: 600-second base timeout, extended by 10 minutes on each tool usage. The sandbox stays warm across conversation turns
  • Agent freedom: inside the sandbox the agent can delete, install, script anything — blast radius is contained
  • The first lesson: “just running Python scripts” is never just running Python scripts. An LLM given shell access will eventually try rm -rf / while “cleaning up temp files”
  • Filesystem is the real payoff: the sandbox’s mount system enables the s3-first-architecture pattern — persistent user data, skills, and memories are just files the agent can read and write

Connections

Sources

Graph View

Backlinks