Security and access

What it covers

This page explains how Fullbeam limits access to your repositories, how benchmark runs are isolated, and what data Fullbeam keeps. For the public summary, see the Security page.

Repository access

• The GitHub App can only reach the repositories selected in its installation.
• Signing in to Fullbeam does not grant repository access. Fullbeam checks that your GitHub account can currently access each repository before it shows its tasks, results or PR Stories.
• A copied link does not grant access to someone who can't see the repository.
• Removing a repository from the installation, or uninstalling the app, removes Fullbeam's access to it.
• Every GitHub webhook is checked with GitHub's signature before Fullbeam processes it. Oversized payloads are rejected.

Workspace roles

• Member: reads results and can ask an owner to install the GitHub App.
• Owner: sees setup controls, installs the GitHub App, and imports and approves specs.
• Primary owner: adds provider keys, authorizes task validation, creates and freezes suites, prepares and starts comparisons, and changes security roles and data policy.

The primary owner is labelled Primary Owner on the Members page.

Where runs happen

• Each attempt runs in its own private, short-lived sandbox managed by Fullbeam. Sandboxes are configured for Daytona's EU target. No customer runner installation is required.
• The agent sees the repository at the task's starting commit and the approved spec. It never sees the pull request's solution or its tests.
• Grading runs after the agent finishes, in a separate sandbox that gets no model keys. The hidden tests are added only for grading. In the Compare your current and proposed setup preview, the app notes that the independent hidden-input verification boundary is not yet available.
• Sandboxes are destroyed after the run. The Audit trail page shows the cleanup receipt.

Provider keys

• Your provider key is added by the primary owner in Provider credentials. It is encrypted and never shown again.
• The sandbox never receives your provider key. It gets a short-lived gateway token for that one attempt. The provider credential remains encrypted behind the Fullbeam model gateway and is used only for that attempt's model requests.
• Keys never appear in setups, reports, GitHub output or stored evidence.
• Spec writing uses Fullbeam's own AI provider and budget, not your key.
• The Harness evaluations preview uses Fullbeam's hosted runner account for model calls, not your key.

What Fullbeam stores

• Digests and metadata of your setups, tasks and results, not full copies of your repository.
• Task specs and hidden grading material, encrypted and scoped to your workspace, so a task can be run again the same way.
• Attempt files from Harness evaluations only if you choose to keep them. They are encrypted and deleted after seven days.
• Usage, cost, outcomes and the exact commits involved.

The Audit trail page lists each kind of data with its retention period, and lets the primary owner change the data policy.

Audit trail

Open Audit trail in the sidebar to see:

• security and data boundaries;
• data classes and how long each is kept;
• managed execution environments;
• organization roles;
• Immutable security audit, a log of security-control changes that you can download with Export signed JSONL.

Not available today

• SSO or SAML sign-in.
• Choosing a hosting region.
• SOC 2 or ISO 27001 reports.
• A customer-visible log of the actions Fullbeam takes on GitHub. The audit trail records security-control changes, not GitHub actions.

The region, network, cleanup and key-rotation controls still need recorded proof from the deployed system before production use.