HeliosHELIOS DOCS

Sandboxes

Helios agents run in isolated E2B cloud sandboxes with a shell, a filesystem, code execution, web access, and a persistent workspace.

Sandboxes

Every Helios agent runs inside its own sandbox — an isolated cloud computer, provisioned per chat or per workflow run, powered by E2B. Nothing is shared between sandboxes.

This is what separates an agent from a chatbot. It doesn't describe the work; it does the work, on a machine, with tools.

What's inside

A shell and a filesystem. The agent can run commands, read, write, and edit files, and search across them.

Code execution. The image is Debian with a build toolchain, git, jq, and a JavaScript / TypeScript runtime. The agent installs what else it needs.

Web access. The agent can search the web and scrape a URL into clean markdown.

Your tools. Integrations (the full API of each connected service), databases, and any attached MCP servers.

The workspace

Each sandbox mounts a persistent workspace at ~/workspace, backed by durable object storage.

  • For a chat, the workspace belongs to that chat. Uploaded files land in ~/workspace/uploads/.
  • For a workflow, the workspace belongs to the workflow and is shared by every run of it. Files one run writes are there for the next.

Agents are instructed to write anything worth keeping under ~/workspace, and to use $TMPDIR for scratch work that should disappear when the run ends.

Deleting a chat or a workflow deletes its workspace.

Lifetime

A sandbox stays alive while the agent is active and shuts down after a period of inactivity, roughly fifteen minutes. Because the workspace lives in durable storage rather than in the sandbox, nothing is lost — the next message or the next run gets a fresh sandbox with the same files.

Workflow runs have a hard 30-minute execution limit. See runs and outputs.

Isolation and credentials

Sandboxes start with outbound network access closed. Helios opens access to specific hosts only as the agent's task requires, and injects the necessary authentication at the network layer.

This is the important part: the agent never holds your credentials. When it calls the GitHub API or clones a pinned repository, Helios attaches a short-lived, narrowly scoped token to the outbound request. Nothing readable as a secret exists inside the sandbox for a prompt injection to exfiltrate.

Your secrets are envelope-encrypted at rest and are never passed into the agent's context.

Database access is deliberately narrow

The agent reaches your databases through a dedicated tool, not through raw credentials. Queries run read-only, with a statement timeout and a row limit. See databases and database security for how to bound this further on your side.

Last updated on