In Cloudflare's sandbox demo, one outbound function decides what agent-written code can reach

When an AI agent runs code in a sandbox, the outbound handler is the control point. That is the argument in a recent episode of the Cloudflare Developers show, "Securely Run LLM Generated Code in Cloudflare Sandboxes," published on 4 November 2026. The handler is a function that sees every request leaving the sandbox and decides which ones go through. The speakers are not named in the source.

What was said

A speaker on the show walked through a demo that gives an agent three steps: set up a workspace, run code in it, and shut it down. Each workspace gets its own sandbox container. An agent can fetch a code repository, install packages and retry a failing script in the same place.

The risk is the code itself. A speaker on the show said it may "take secret credentials and send them to its own domain, for example."

The fix starts with cutting all internet access. The job still needs github.com, npm and api.github.com. So the policy lets those through and rejects everything else. It can also insist on secure HTTPS connections.

The speaker added that the approved list can change by phase. During setup, the container may reach some domains. Once it is ready to run code, a different list can apply.

The same handler also holds the keys. When a request is a pull request to GitHub, the handler adds the secret credential on the way out. So the agent's code "doesn't directly ever have access to environment variables." Those stay in the Worker, the developer's own Cloudflare program, outside the container.

Why it matters

Our reading: the speaker was solving a security problem, but the design also shows who holds power. Every request an agent makes passes through one function. Whoever writes that function decides which sites and services the agent can reach, and when.

For teams that build or buy agent tools, that raises practical questions. In this demo the keys stay in the Worker the developer controls. If you buy an agent tool, who holds them: you or the vendor?

For site owners, our reading is that an agent's visit may depend on a list someone else wrote.

The other side

The talk covers one setup, run by the developer who owns it, with a short list of known domains for a narrow job. The speaker showed a way to protect credentials and limit damage from untrusted code. The talk did not claim this decides how agents reach the web at large.

The speaker did not say how a policy would work for an agent that must browse widely. Nor did the talk say who should set the rules when many parties share the same agents.

The speaker likened the overall setup, with the platform running the agent loop and tools running in the customer's own environment, to Claude managed agents and Cursor cloud agents. He did not say whether they filter outbound traffic this way.