# Isolation, plainly

Each run gets its own microVM, each org sees only its own resources, and secrets reach a run only in the form you chose. What that means in practice.

Rush runs work you did not watch being written, on code and credentials that matter to you. This
page states what keeps one run, one person and one org apart, in the terms you can check from the
API.

_Figure: one machine per run, on the page at /docs/concepts/isolation._
## One microVM per run

Every run gets its own E2B microVM: its own disk, memory, desktop and browser. Nothing is
shared with another run, including another run of yours. A follow-up wakes the same sandbox, so
the files from an earlier turn are still there; a new session starts a new one.

When a turn ends the sandbox parks with its disk and memory. It is removed when you cancel the
run, or after 7 idle days, when the session ends `expired`.

There is no local execution path. Every run happens in Rush Cloud, whether it was started from the
API, the console, the CLI or an automation.

## Orgs fail closed

Every path starts with an org, `/o/{org}/…`, and every request is checked against it before
anything else.

- A caller with no role in an org gets `404` on its paths.
- An API key works only in the org it was created in. Another org's paths answer `404`.
- Inside an org, a session, saved agent or file you may not read answers the same `404` as one
  that does not exist. A missing row and someone else's row look identical, so ids cannot be
  probed.
- A key reaches only the routes listed for it. Every other route answers a valid key `404`, as if
  it did not exist. An unknown, revoked or expired key is `401`.

A run's live surfaces (its display, its control and its terminal) go only to the run's owner or an
org admin. See [Watch and steer](/docs/concepts/watch-and-steer).

## Credentials

Rush never returns a credential once you have given it.

- **API keys.** The `rk_live_…` secret is in the create response only; it is never stored or shown
  again.
- **Secrets.** Sealed on save. Lists show names and kinds, never values. An `env` secret reaches
  a run as one environment variable. A `header` secret never enters the sandbox: the header is added
  to the run's HTTPS requests to the hosts you named, outside it. A `login` secret is typed into the
  run's browser on one origin, keeping it out of the transcript. See
  [Projects and secrets](/docs/concepts/projects).
- **Connections.** A token you sign in with, or send on an inline MCP server, is stored encrypted and
  never comes back in a response.

## What a run can reach

A run started with an API key gets only the connections it names in `connections`, plus those of
the saved agent it runs. It never picks up your other sign-ins. Project secrets reach only sessions
started in that Project. A repository is reached through your GitHub App installation, and only one
repository per run.

Text that arrives from outside, such as a GitHub comment or a webhook body that fires an
[automation](/docs/concepts/automations), reaches the agent marked as third-party data, after the
automation's own prompt. The saved prompt is the only instruction.

## Limits worth knowing

The sandbox is the boundary around the run, not around the agent's tools. The agent can read
anything placed inside its sandbox, including an `env` secret and the files you attach. A `login`
secret is kept out of the transcript, but the agent shares the browser it is typed into. Give a run
only what the work needs.