End-to-end encryption

End-to-end encryption will encrypt sessions, files, and logs between the machine where you run the CLI bridge and your browser using keys you control.

Why use end-to-end encryption?

E2EE mode is for teams who need stronger protection of intellectual property and sensitive data. Session content is encrypted from your host running the CLI all the way to your browser, using certificate material only you hold.

This means only those who hold the ceritifcates can read the payload. It means that BuildAutomaton servers also cannot read that payload.

What it is

The CLI can load or generate certificates that will be used to encrypt data before it leaves the bridge host. The dashboard can import those same certificates into browser local storage so future encrypted session data can be decrypted in the browser.

Quick start

If you have not linked a workspace yet, complete Getting started first. To prepare a bridge host for E2EE, start the CLI with --e2ee-certificates-dir ~/.buildautomaton/e2ee. If that directory already contains a certificate bundle, the CLI uses it. If not, the CLI generates one there and reuses it on future runs.

npx @buildautomaton/cli@latest --e2ee-certificates-dir ~/.buildautomaton/e2ee

While the CLI is running, press c in the terminal to open the workspace end-to-end encryption settings page with the active certificate embedded in the URL for one-click browser import.

CLI flags

Flag	What it does
`--e2ee-certificates-dir`	Directory where the CLI loads an existing certificate bundle or generates one if none exists. You can also set `BUILDAUTOMATON_E2EE_CERTIFICATES_DIR`. Certificate bundles are stored as PEM files.
`c` while running	Opens the browser to the workspace end-to-end encryption settings page with the active certificate URL-encoded for import.

You still pass ordinary bridge options such as --workspace-id, --token, --headless, and --api-url (or their environment equivalents), which are covered on the Private & VPC agents page.

Individuals & teams

Individuals

Most people start by choosing a private directory such as ~/.buildautomaton/e2ee and passing it as --e2ee-certificates-dir. Store that directory securely. Private keys should stay on trusted machines unless your own policy says otherwise.

Teams

Teams can share a certificate bundle through their own secret distribution process, then place it in the configured certificate directory before starting the CLI. Each browser that needs to decrypt future encrypted payloads can import the same PEM bundle from the workspace end-to-end encryption settings page or from the CLI's c shortcut.

Limitations

E2EE generally encrypts most sensitive data from the CLI bridge to the browser but there are some exceptions.

Proxied HTTP requests for local previews are not encrypted.
User prompts are not encrypted because they may arrive from Slack and other integrations before reaching the bridge. In addition, user prompts are sent to an LLM for creating session titles.