Security

Last updated

Agents that write and run code need real access, so Build Depot is built around limiting what they can reach and keeping people in charge of what ships. This page describes how it works today. Build Depot does not yet hold third-party security audits or certifications.

Agents work in isolation

  • Every task gets its own Git worktree and branch. An agent edits only inside it, and changes meet your main branch only when they are merged, after conflict checks.
  • Tasks can run in a container sandbox: one container per task, with all Linux capabilities dropped, no privilege escalation, a non-root user, a read-only root file system and CPU, memory and process limits.
  • The sandbox network can be turned off, or restricted to an allow-list of hosts through an egress proxy.
  • Agents ask before risky actions such as pushing, publishing, deploying, using sudo or touching secrets. They never push or deploy on their own.

People decide what ships

  • Checks you configure run after every task, and a failing check blocks the merge.
  • Turn autopilot off and nothing merges until someone presses Merge. Any merge can be undone.
  • Deploys need a signed-in person with the deploy permission. Requests made by agents, or with personal API tokens, are refused.

Accounts and access

  • Passwords are hashed with scrypt. Repeated wrong passwords lock sign-in for a while.
  • Browser sessions use an HttpOnly, SameSite cookie. Changes made with it must come from Build Depot's own origin.
  • Four roles (owner, admin, member, viewer) decide who can run, merge, deploy and manage the team. Important actions are recorded in the team's audit log.
  • Personal API tokens act with your role and can be revoked at any time.

Secrets

  • Anthropic keys, GitHub tokens and deploy secrets are kept on the server and sealed with a server key when one is configured.
  • No API response, log line, audit entry or error message contains them. Deploy logs are scrubbed of every secret value they read.
  • Builds run with a minimal environment: the server's own keys are not passed to them.

Previews and hosted sites

  • Live previews and hosted sites run in a browser sandbox with an opaque origin, so their scripts cannot read the app or use anyone's session.
  • The preview proxy never forwards your session cookie or authorisation header to the app being previewed.

Known limits

We would rather you hear it from us:

  • There is no disk quota for a task's worktree yet.
  • A sandbox with an open network can reach the internet and, depending on the host, local services. Use the restricted network for untrusted work.
  • AI-generated code can contain bugs and security issues. Review changes before you merge and ship them.

Report a vulnerability

If you find a security issue, please tell us through the contact page with "Security" in the message, and include steps to reproduce it. Please give us a reasonable time to fix it before you share it, and do not access other people's data or disrupt the service while testing. We will reply, keep you updated and credit you if you would like.