TIDE
Get started

Docs · Policies

Security and privacy

What keeps sandboxes apart, what we protect and how, and what we can see. Where something is not protected, this page says so.

Security and privacyMenu

Isolation between sandboxes

  • Each sandbox is its own Firecracker microVM, started under Firecracker's jailer, with its own kernel, memory and disk. Root inside a sandbox is root of that VM only.
  • Memory is never merged across sandboxes, because shared pages can leak data between tenants.
  • Whatever its network preset, a sandbox cannot reach other sandboxes, our hosts, private networks, loopback, or link-local and cloud metadata addresses.
  • Our machines talk to each other over an encrypted WireGuard network. Host agents listen only there, never on public interfaces, and hosts cannot reach each other.

Secrets

  • Brokered secrets never enter the sandbox. It holds a placeholder; the value is added on the host, only to HTTPS requests to the domains you bound it to.
  • Values are encrypted at rest with AES-256-GCM. Hosts hold them in memory only, for the sandboxes they are attached to.
  • The API never returns a value once it is set.
  • To add a value, the proxy decrypts HTTPS to bound domains, and only to them, and verifies the real server's certificate before sending anything.

See Brokered secrets for how it works and its limits.

Accounts and access

  • People sign in with GitHub or Google. Sessions last 7 days.
  • API keys are stored only as a hash. Each is shown once, when it is created, and can be revoked at once.
  • Shell, browser and preview links carry a single-use token valid for 60 seconds, so your API key or session never appears in a URL.
  • Previews are never public. Only a person signed in to the dashboard can open one, and signing out ends access.
  • Card details go to Stripe. We never see them.

What we can see

  • Connections. The egress log records the name and address of each connection a sandbox opens, and whether it was allowed. Not the contents. It is kept in the host's memory, the last 1000 per sandbox.
  • Resource use. We record each sandbox's CPU, memory, disk and network use and how long it sits idle, to run the fleet and to bill.
  • Command output. Output streams from the sandbox to you. The sandbox keeps the last 1 MiB of each command; our database does not store it.
  • Credential inventory. Runs only when you ask, and reports names and places, never values.
  • Email. We use the email from your sign-in only for account notices, such as quota and billing changes.

Abuse controls

Outbound mail on port 25 is blocked, new connections are rate-limited per sandbox, and a sandbox that looks like it is scanning is paused and held for review. Abuse reports against one sandbox can get a whole host taken offline, with every sandbox on it. See Abuse controls.

Durability

Deleting a sandbox deletes its files, saved memory and snapshots from its host. It cannot be undone.

Review status

No external security review or audit has been done yet.