Allow Sandbox
allowSandbox generates the egress rules that let an agent create and reach one nested sandbox through the gateway, using a fixed config the agent cannot tamper with. It's the building block for agent swarms: an orchestrator agent spins up a worker, but you decide exactly what that worker is.
The rules do two things: allow the POST that creates the nested sandbox (with its request body replaced by your config, so the agent can't change what gets created), and allow the nested sandbox's proxy routes so the agent can talk to it.
Spread the result into the orchestrator's egress.
import { getOrCreateSandbox, allowSandbox } from "@hiver.sh/client";
const orchestrator = await getOrCreateSandbox("orchestrator", {
image: "claude",
egress: [
...allowSandbox("worker-1", { image: "my-agent:latest" }),
],
});The agent inside orchestrator can now create and reach a sandbox keyed worker-1, but only with the my-agent:latest config you pinned, it can't launch a different image or widen the worker's own policy.
Granting file access to the nested sandbox
Pass a list of directories to also open the nested sandbox's file API under those paths. Each entry allows the agent to POST/GET/DELETE files beneath that directory, enough to seed inputs and read back outputs, without touching the rest of the worker's filesystem.
const orchestrator = await getOrCreateSandbox("orchestrator", {
image: "claude",
egress: [
...allowSandbox(
"worker-1",
{ image: "my-agent:latest" },
["workspace/inputs", "workspace/outputs"],
),
],
});allowSandbox ships in all three clients. See Agent Swarm for the full orchestrator-and-workers pattern.Next: Agent Swarm