Security and data

Beaker processes the data you connect to it: the repositories you choose through the GitHub integration, and the samples and traces your .beaker folder points to. Whoever installs the GitHub App can see and change its permissions in GitHub.

We use it to run Beaker for you and to fix problems.

Beaker keeps a record of each run so you can review what it tried and create a pull request from the result. The record includes the before and after versions of the files Beaker is allowed to change, plus traces, evaluation results and the reports shown in the app.

Beaker only retains data processed through Beaker for the duration of the relationship with a given customer, unless otherwise specified by the customer.

Model calls from a run go through the Beaker gateway to the provider. We currently support OpenAI, Anthropic, Google and OpenRouter.

• The gateway doesn’t log or persist prompts, images, tool arguments or tool results by default.
• Beaker doesn’t ask providers to store your requests.
• If you bring your own provider key, calls to that provider go directly from the sandbox and use your key.
• The provider’s own data policy applies to what it receives. Check it for the models you use.

We may use your data to improve Beaker. If you’re on a paid plan, you can opt out at any time by contacting us. If you’re on an enterprise plan, we do not train on your data without your prior written consent.

Code and other work Beaker produces for you is yours, and you can use it commercially. The one exception: you can’t use it to train models that reverse engineer Beaker or compete with it.

You choose which repositories Beaker can access, and you can change them at any time. Beaker’s changes arrive as draft pull requests.

For the permissions Beaker requests and how to manage them, see the GitHub integration.

API keys and environment variable values you save in Beaker are encrypted at rest with AES-256-GCM. Run records are encrypted at rest and sent over TLS.

Each run executes your agent in an isolated hosted sandbox. The sandbox receives a scoped Beaker token and gateway URL for model calls. Beaker’s own provider keys stay on our servers.

Each user belongs to one Beaker organization and only sees that organization’s runs.

We don’t store your password. Sign-in goes through our identity provider.

The Beaker team uses multi-factor authentication and is trained in security best practices.

Access to production systems is granted as required, based on role, and only the relevant people have direct access.

Beaker removes credentials from the run reports and evidence you see in the app.

Beaker’s changes are proposals, so review its pull requests like any other contributor’s. We recommend branch protection on your main branch so required checks pass before anything is merged.

Your agent may need credentials and keys to run. Keep them out of your repository and add them as environment variables in your agent’s settings instead. They’re stored encrypted.