foldrun.

Security

Isolation you can explain in a sentence per layer.

The platform runs code it did not write, on behalf of people who may be wrong about what it will do, next to other people's data. Everything in its design follows from taking that seriously.

One step, one sandbox

Every step executes in a container created for it and destroyed after it — a gVisor pod on a cluster. It holds a copy of the agent's folder and nothing else: not the platform's filesystem, not the vault, not another workspace. Startup is under a second, so this is not a trade against latency.

The public internet, and only that

A run may reach the internet as itself. Every private network range and the cloud metadata endpoint are denied by network policy, and so is the platform's own API and database. Workspace files move through presigned URLs; no bucket credential is ever in a sandbox.

File tools that cannot leave the workspace

An agent's Read, Write, Edit, Glob and Grep are confined to its workspace and the account library (read-only). A path outside is refused with a message naming the path the agent probably meant, and refusals are counted per step on the run page.

Secrets the model never sees

A secret is named in the agent's file and handed to its scripts as an environment variable. It is never in a prompt, never in a workspace file, never in git. Each account has its own encryption key, wrapped by a root key that no data backup contains.

Capability is structural

A step can do only what its file grants. An agent with no tool that writes cannot write, whatever it is told or tricked into. The reference pattern: the tool that proposes a change and the tool that applies it are two tools, and only the step after a human gate holds the second.

Everything on the record

Every write to a workspace is a revision with an author. Every sign-in, key use and role change is in the audit log. Every step's tool calls, script runs and refusals are in the run's events. A run can be reconstructed from its record.

People and roles

Four roles — viewer, editor, admin, owner — and every write route asks for the least role that may take that action. Reads are open to every role, because supervisors who cannot see what agents did are not supervising. Members can be scoped to some workspaces. API keys carry a role and can never act as a named person.

What is still yours to think about

  • A model reading a web page reads whatever is on it. Give an agent the narrowest tools its job needs; put a gate before anything irreversible.
  • A tool with write access to a third party is a write. Scope the credential to what the tool must do.
  • Bring-your-own-key credentials are yours; the platform stores them sealed and never sees the bill.
The full model, with what each layer does and does not allow, is in the docs:Security. To report a vulnerability, write to [email protected].