Your agents need a dynamic sandbox

In plain words

Imagine a very capable helper who is allowed to roam your house and get things done. The old way to keep them safe is a list written before they arrive: these rooms, these drawers, these doors, nothing else. But the helper doesn't follow a script. They figure out what to do as they go, and if a door is locked they look for a window. A dynamic sandbox is a chaperone who walks one step behind, watching each thing the helper actually does, and decides in the moment: that's fine, not that, do it this way instead. The chaperone has read your note about what you care about, so they judge why the helper is doing something, not just whether it's on a list.

The article in three lines

Most agent sandboxes are static: an access list written before the agent runs, which can say which files, commands and hosts are allowed but cannot judge why. Agents decide as they go and route around rules, so a blocked GitHub API call becomes curl, then a Python script the harness never sees. A dynamic sandbox sits underneath the process and above the operating system, sees every action including those from child processes, and allows, denies or rewrites each one in the moment, judging intent from a policy written in plain language.

The line that wants to be the picture: "A static rule covers the path you thought of. The agent has as many paths as it can come up with, and it's very good at coming up with them."

This is the first of three posts in a series (then The hidden agent surface, then Treat your agents like insiders). The three heroes will sit next to each other on the blog index, so they should read as a set without repeating one metaphor. That is the first thing to settle in Direction.

The author has already drawn four inline diagrams and put them in the article folder (static_vs_dynamic_sandbox, github_workaround, layer_stack, judge_rule_loop). Those are the explanatory figures; the hero and listing are the editorial image, and should not redraw a diagram.

Jargon

Term	What it means here	If you had to draw it
Agent	An AI program that takes a goal and works through it on its own, running commands and editing files as it goes. In this series, usually a coding assistant on a developer's laptop.	The capable helper
Harness	The app the agent lives in: Claude Code, Codex, Cursor. The agent's "body" with its own built-in settings.	The helper's uniform
Tool call	One request the agent makes through its harness: read this file, run this command. The part everybody can see.	A hand reaching for a drawer
Sandbox	The boundary of what a program is allowed to do. Static = written in advance as a list. Dynamic = decided per action, as it happens.	A fence (static) vs a chaperone (dynamic)
Allowlist / denylist	Lists of permitted or forbidden commands, files, and web addresses. The static sandbox's whole vocabulary.	A checklist on a clipboard
Credentials, `~/.aws/credentials`, `.env`, SSH keys	Files holding passwords and keys that unlock cloud accounts and servers. The things you least want sent anywhere.	A key ring
Python script	Code the agent writes itself and then runs. Once it runs, it's a separate program the harness no longer watches.	The helper building their own tool
Process, child process	A running program. A child is one started by another; the article's point is the children do the real work.	A figure with smaller figures trailing behind
Syscall (`exec`, `openat`, `read`, `write`, `connect`)	The handful of ways any program asks the operating system to do something: start a program, open a file, read, write, connect to the network. Everything an agent does passes through these.	A single doorway everything must use
Operating system	macOS, Windows, Linux. The floor the whole thing stands on.	The ground
"Underneath the process, above the OS"	Qpoint's position: between the program and the floor, where every request has to pass.	A layer between the figure and the ground
Plugin	A small separate program that gets each event and decides allow / deny / rewrite. Runs outside the agent so the agent can't touch it.	A separate figure holding the rulebook
LLM judge	A language model asked to decide whether an action matches a policy written in plain English. Only used when a rule can't decide.	A referee consulted on hard calls
Policy / intent	What you want in plain words ("agents can read internal APIs but can't send credentials to third parties").	A handwritten note on the fridge
eBPF	A Linux technology for watching programs from inside the operating system. Qpoint's earlier approach; it doesn't exist on Mac or Windows.	Background only; no need to draw
Hosted agent, CI runner, Kubernetes	Agents that run on servers rather than laptops, often in automated pipelines.	Helpers in a warehouse instead of a house
MDM (Jamf, Intune)	The tool a company uses to install software on every employee laptop.	Background only
Endpoint	A laptop or desktop, as opposed to a server.	The house
AI gateway / network controls	Tools that watch traffic leaving the machine but can't tell which program sent it.	A guard at the gate who can't see faces

Record

Shipped (2026-10-15): qpoint.io/blog/your-agents-need-a-dynamic-sandbox, byline The Qpoint Team. Hero hero.svg and listing listing.png under /images/2026.Q4/blog/dynamic-sandbox/, with the author's five inline figures (static-vs-dynamic, routing-static, routing-qpoint, qpoint-runtime, ai-judge) beside them.
Archived (2026-10-21): moved to Outcomes with the three sketch sheets, the hero and listing, and a screenshot of the live post (captured 2026-10-21, 1440 wide).

Your agents need a dynamic sandbox

Outcome

Sketches

In plain words

The article in three lines

Jargon

Record