JoyStream Agent Sandbox: Code execution for Organizational Agents

Earlier this month, OpenAI shipped something special … for developers: the Agents API, which gives every agent an environment to work with files and run code. JoyStream has done something special as well … for developers and organizational agents. This post is about how ours is built, and why the one decision we made differently, where the secrets live, changes everything downstream.

What OpenAI built? Developers get an agent-specific environment for files and code

OpenAI hosts the harness. You choose the compute: their hosted sandbox, your own infrastructure running their exec server, or one of nine partners such as Vercel, Cloudflare, E2B, and Modal. The harness compacts context as a session grows, loads tool definitions on demand, and delegates work to parallel subagents.

It is a developer product. You write the task, pick the model, wire the tools, and get back a running agent.

JoyStream Sandboxes provides an agent-specific environment for files and code - for Developers and Business users

A JoyStream agent run is reproducible, auditable, and each leaves no secret behind in a VM.

When a compliance reviewer asks what the agent did on Tuesday at 6:03pm, the answer is in run ledger with the exact command, its size, and the artifact it produced.

That is what sandboxing looks like when it is built for a team that will hand the agent to someone else.

What the two have in common? Isolation and ephemerality

Isolation. Both run user code in a provider-operated microVM. JoyStream uses E2B directly. E2B is one of OpenAI's partners.
Files, code, artifacts. Both give the agent a filesystem, a shell, package installs, and a way to hand results back.
Skills mounted in. Both copy the skill's files into the VM so the model can read instructions and run scripts.
Ephemeral by default. Neither treats the VM as durable storage.

What is specific to JoyStream? A broker that keeps credentials out of the environment

The choice that shapes everything else is the credential boundary.

OpenAI's own security guide says to keep third-party credentials outside the environment and route requests through a broker.

We agree, and we built the broker: the JoyStream MCP gateway makes every outside call, and there is no option to put a connector secret in the VM.

The Agents API leaves that door open for developers who want it. If your agent is going to run for people who didn't build it, that door has to stay shut.

OpenAI Agents API and JoyStream Sandbox comparison

	OpenAI Agents API	JoyStream
Who it is for	Developers building an agent product	Teams building an agent by chat
Unit of work	A session, durable, can run for days	A run, bounded, written to a ledger
Where the model loop runs	Inside the OpenAI harness, next to the environment	In our worker, outside the VM
What the VM can see	A restricted executor key. Third-party secrets stay out only if the developer builds a broker	A JoyStream run token scoped to the tenant and agent run, and an API URL
Who picks the sandbox	From OpenAI's, your own, or a partner's	The platform, at build time, per skill
Model	OpenAI models	Any model, bring your own key
Cross-run state	Sessions persist and can be resumed	None. Artifacts carry state between steps only
Record of what ran	Session events	Every command, every artifact, in the run ledger

What the sandbox does in JoyStream? Run code, scripts, download/read/write files

How an Organizational Agent comes to life: describe it in the Agent Builder, get a locked build, deploy it to a workspace, and every execution after that is a run.

An agent run gets a sandbox if an agent requires it. This happens when a skill need to run code, or handle files: convert a markdown report to PDF, fill a .docx template, lint a repository.

The sandbox is a fresh Linux microVM on E2B. It belongs to exactly one run. It is created on the first step that needs it and destroyed when the run ends. Nothing survives from one run to the next.

The sandbox is an execution detail of a skill, not a place the agent lives.

Three properties follow from that.

The model loop stays outside the VM. The VM only runs code. If the VM dies, the run record still knows what happened.

Only two things enter the VM. A short-lived run token scoped to this workspace, agent, and run, and the URL of our API. No connector credential and no model key.

The platform decides when a sandbox is needed. At build time we inspect each skill bundle and decide which agent execution steps need to be executed in a sandbox.

JoyStream Agent Sandbox: the runtime sends commands to the sandbox VM and gets files back; the MCP gateway is the one door to every connected tool.

What's inside the sandbox? Anything a Linux shell can do

Basically, anything a Linux shell can do. The image ships Debian with Python, uv, pip, Node, pandoc, LibreOffice, poppler, git, curl, and jq, and the skill can install more.

There are two ways a skill uses it:

Declared script. The skill names an entry point in its SKILL.md. We run it with the step's inputs in the environment and read a JSON result from stdout.
Model-driven. The model gets three primitives, run a command, write a file, read a file, and works through the task itself. Commands are batched into one script per step so a task does not burn an iteration per line.

Either way, whatever lands in /workspace/out is collected, scrubbed of anything that looks like a secret, capped, and stored as an artifact the next step can use.

Inside a run: a small graph of steps. A connector call and a run-code step execute in parallel; the run-code step gets a sandbox VM that is fresh per run, commands in, files out.

Try it

Open Joyvis - our agent builder, use or describe a skill that needs code, say a weekly report rendered to PDF and dropped into a shared drive, and add a skill with a script in it. Build it. Run it. Then open the run record and read the sandbox commands next to the artifact they made.

If you have a workflow like that, try JoyStream and tell us what you built or send us your feedback.