The setup
A thousand sandboxes walk into a folder. The first one says it is only here to read. The second says it needs to write a report. The third has been alive for four seconds and already wants to know who is in charge of AGENTS.md.
The folder, being a folder, does not mind. It has a bigger problem, which is that somebody handed all thousand of them the same API key.
That is the joke, and I am afraid it is a documentary. Almost everyone who runs agents in cloud sandboxes has, at some point, pasted a real key into an environment variable and moved on. I have done it. It works, right up until you think about what you just did.
Why the API key is the wrong thing to hand over
An API key is for a person, or for a service you run and trust. It can reach everything that person can reach, and it does not expire on a schedule. A sandbox is the opposite of all that. It is a temporary computer, running code you may not have read very carefully, often written by a model a few minutes earlier.
Put a long-lived key in there and every one of its habits becomes a risk. The job prints its environment into a log, and the key is in the log. A dependency you have never heard of reads the variable. The sandbox is paused, snapshotted, and forgotten, and the key goes with it. If the key leaks, you rotate it, and the other nine hundred jobs that were using it fall over.
There is also the plain matter of blast radius. A sandbox with your key can read your whole workspace, including the folders it has no business with. A job whose only task is to resize images has no reason to be able to read the board papers, and you should not have to trust it not to.
What you actually want to say to a sandbox is something narrower: you may use this folder, for this long, to do this kind of thing, and then you are done.
Giving anything temporary a temporary pass is an old habit. It is why a building hands a courier a visitor badge and keeps the master key in a drawer.
What a sandbox token is
That sentence is more or less a sandbox token. You make one from an API key, and it reaches one drive, or one folder of a drive and the folders inside it. A request for any other drive, folder or file is refused.
It has one access level. `read` lets the job list, read and grep files. `read_write` adds uploading, editing, writing bytes, deleting, and making folders, all inside the token's own scope. There is no in-between and no hidden third level, so what a token can do is easy to say out loud.
Making one takes a single command, and the token is shown only once. The Python SDK can make them too, and so can a connected assistant if you ask.
It also has a lifetime: anywhere from 5 minutes to 12 hours, and an hour if you do not say. It can never outlive the key that made it. Once a job is running, you can extend the token, and when the job is done, or the moment you doubt it, you can revoke it.
A job per task, one folder for all of them
Now the part the joke was about. Say you have a folder of a thousand support transcripts, and you want each one summarised. You start a sandbox per transcript. Each one gets its own token, scoped to the same folder, and each does its small piece of work.
They are all in the same files. A job that finishes writes its result, and the jobs that start later can see it. The one doing a final tidy-up sees what the others produced a moment ago. There is no staging area to merge and no copy of the folder per job to reconcile, because there is only one folder.
I like this for a dull reason. The natural design used to be one copy of the data per job, because shared files with many writers sounded like trouble. Copies are their own trouble: they drift, they need cleaning up, and somebody has to merge the results at the end. With one folder, the results are simply there.
That is also what makes it safe to run this many at once. Every write names the revision it was based on, so if two jobs touch the same file, the second is told the file has changed, reads the new version, and redoes its edit. Nobody overwrites anybody.
A practical footnote, since the joke says a thousand: a workspace can hold at most 500 live tokens at a time. For a very large batch, hand one token to a group of related jobs instead of one each, or start them in waves. Keeping each token short-lived means the waves tidy themselves.
The rule about instruction files
There is one rule I like more than the others, and it surprises people. A sandbox token can never write agent instruction files. That covers AGENTS.md, CLAUDE.md, GEMINI.md, SKILL.md, copilot-instructions.md, .cursorrules and .windsurfrules, and the folders .github, .claude, .codex, .cursor, .vscode and .agents. Even with read_write, those stay read-only to the token.
Think about what those files are. They are the standing orders that every agent reads before it does anything. If one sandbox, running some task with some untrusted text in front of it, could rewrite them, then a single poisoned document could change what the other nine hundred and ninety-nine do next. The attack would not even need to be clever. It would only need a write.
So a job can be wrong, or confused, or hijacked, and the worst it can do is bad work inside its own folder. It cannot change the instructions of everything else. Changing the standing orders stays a job for people, which is where I would want it.
Patterns that work
Read-only for analysis. If a job is going to look at data, summarise it, or answer a question, give it `read`. It can grep the whole drive and still cannot break anything. Most jobs, honestly, are in this group.
Write access to an output folder. When a job has to produce something, make a folder for its results and scope the token to that folder. It can write what it likes there and nowhere else. If you also want it to read the inputs, run it with a second, read-only token for the source folder, or have a person look over the output folder afterwards.
Short lives, extended while running. Start with 5 or 15 minutes, and have whatever launches the job extend the token while the job is still healthy. If the job dies or the launcher does, the token expires on its own a few minutes later. Think of it like a hotel key card for a stay that keeps being renewed, rather than a copy of the front door key.
A small tip on handing the token over: pass it to the sandbox as a secret, never on a command line or in a prompt, and where your sandbox provider can inject it for you, let it. If a token ever lands in a log, treat it as leaked and revoke it. With a token per job, one revocation never takes the other jobs down.
And revoke when you are done. It takes effect for new requests within a minute, and it is one command.
The punchline
I said it was a documentary, so here is the ending. A thousand sandboxes walk into a folder, and not one of them is carrying your key.
Each has a token for one folder, for an hour, for reading or writing and not both. They do their jobs, write their results, and at the end the tokens run out and there is nothing left to clean up. The folder stays open all day for the people who actually work there.
The bartender, if you were wondering, is a person with a laptop and a very short list of things to approve. I would like to keep it that way.