Private preview · Invitation-only managed qualificationRequest access →

Trust & Privacy

What the app can and cannot do, how your code is handled, and who we share it with.

Architecture and data flowCurrent

Step 1
Private Golden Set
Frozen tasks paired with accepted pull requests
Step 2
Managed qualification
Ephemeral Fullbeam runners using customer-owned credentials
Step 3
Release decision
Paired evidence and workload-level recommendations
Step 4
Git-native gate
Exact-commit check, one explanatory comment, and rollout intent

Isolated Fullbeam execution · Ephemeral workspaces · Customer-owned provider credentials

Private qualification runs in isolated, ephemeral Fullbeam environments using customer-authorized repository access and customer-owned provider credentials. GitHub remains the source of truth for commits and pull requests; existing GitOps, MDM, vendor, and internal platforms remain responsible for deployment and rollback.

What Fullbeam can and cannot do

Can do

Derive private, versioned Harness Release evidence from Git-managed configuration artifacts, while preserving source coverage and unsupported components.
Run approved Golden Set tasks in fresh Fullbeam-managed ephemeral environments using customer-owned provider credentials.
Receive bounded runtime evidence with explicit source coverage after a user authorizes the agent connection.
Correlate an observed clean commit SHA only after complete GitHub pull-request membership confirms the relationship.
Read pull request diffs and metadata.
Read bounded repository context at the exact revision for dependency-impact analysis: up to 40 supported text blobs / 1 MiB after inventorying the tree.
Publish the exact-commit Fullbeam Qualification check and keep one aggregate-only explanatory PR comment up to date.
Show you a Story of the PR with chapters, risk tags, and cited evidence.
Show you a delta view when an agent pushes a new revision, scoped to what materially changed.

Cannot do

Deploy, synchronize, enforce, or roll back coding-agent configuration. Your GitOps, MDM, vendor, or internal platform remains the distribution system.
Merge, close, reopen, or approve pull requests autonomously.
Retain ephemeral qualification checkouts after an attempt completes.
Impersonate a user — all writes are bot-attributed, never user-attributed.
Approve on your behalf — the final review decision is always yours in GitHub.
Access repositories not selected during the GitHub App installation.
Claim that an agent authored an observed commit or that a Harness Release caused an outcome.
Treat missing runtime evidence as zero use, successful verification, or an unchanged configuration.

User identity versus installation accessCurrent

Signing in identifies a person; it does not grant repository access. An active GitHub App installation identifies the selected repositories, and Fullbeam separately maps the signed-in GitHub identity to current repository membership. A workspace role alone cannot bypass that repository entitlement. Installation owners control repository selection, while each reviewer owns only their own checkpoints.

App permissions and rationale

Permission	Why we need it	What it cannot do
`pull_requests: write`	Post review comments and check runs attributed to the App ("via Fullbeam on behalf of @you"). Required to submit chapter-level comments and the reviewer-checkpoint Check.	Cannot merge, close, or reopen pull requests. Cannot impersonate a user — every write is explicitly bot-attributed.
`checks: write`	Create the exact-commit Fullbeam Qualification check that enforces effective authorization and links to the authenticated Decision Report.	Cannot modify existing checks created by other apps or CI systems.
`contents: read`	Read pull request diffs and bounded repository context for review. During an authorized private qualification, Fullbeam also makes an ephemeral exact-commit checkout inside an isolated managed runner.	Cannot push repository changes. Cannot access repositories not selected during installation or retain the ephemeral qualification checkout after the attempt.
`metadata: read`	Required by GitHub for all App installations. Provides PR metadata (title, description, number, state) used to structure the Story.	Read-only; no write access to repository settings.
`members: read`	List organization members to compute repository-level access entitlements. Ensures only collaborators can view a Story — Fullbeam workspace membership alone is not sufficient.	Cannot invite, remove, or change roles for any organization member.

Webhooks received

pull_request
pull_request_review
pull_request_review_comment
check_suite
push (PR branches only)
Installation creation / update / deletion

All webhook deliveries are signature-verified, payload-size-limited, and idempotent by delivery GUID.

Coding-agent runtime evidenceCurrent

Claude Code, Codex, and OpenCode runtime evidence is connected separately and only after user authorization. Effective-runtime snapshots retain the observed Harness Release relationship and bounded session evidence. Missing or partial telemetry is shown as a provenance gap; it is never inferred from code or Git history. GitHub remains the source of truth for commits, pull requests, and review outcomes.

Runtime content boundaryCurrent

Focused runtime ingestion records bounded lifecycle, tool, capability, permission, verification, duration, and clean Git observations with explicit source coverage. Prompts, responses, source code, command text, and raw tool results are not part of the required telemetry contract. Missing evidence remains unavailable or partial rather than being inferred or rendered as zero.

Encryption and regional deploymentVerification required

Managed qualification is configured for private, ephemeral Daytona environments in the EU target. Customer-owned provider credentials remain encrypted behind the Fullbeam model gateway; the sandbox receives only a short-lived attempt token. Production admission still requires retained evidence for regional placement, egress enforcement, cleanup, and key rotation; Fullbeam does not claim customer-selectable regions.

Data collected for the control loopCurrent

Fullbeam stores Git-derived Harness Releases, externally observed assignment facts, bounded effective-runtime facts, exact Git and GitHub identities, pull-request revisions, checks, reviews, cited Story versions, and each reviewer's own checkpoint. Bounded dependency analysis may inventory the exact revision and read up to 40 supported text blobs / 1 MiB. It does not create a full repository clone.

Repository entitlement enforcementCurrent

Every Harness Release observation, runtime projection, Story, source, and write action is scoped by account and repository. Server-side checks require a current GitHub identity mapping plus repository membership; row-level security protects ordinary database reads, and installation lifecycle events revoke stale repository grants. Administrative clients bypass RLS only inside bounded services that perform the same account and repository validation explicitly.

Audit logsPlanned

The current transactional outbox records account-scoped GitHub actions, payloads, and dispatch state for operations and retry safety. A customer-visible audit log that also records the acting user and installation credential is planned and does not ship today.

Data handling & retention

Each claim below is labelled Current when repository evidence demonstrates the control, Verification requiredwhen deployed operational proof is still a release gate, or Planned when it is not yet implemented.

No training on your codeVerification required: The release contract is that customer code and generated Stories are not used to train models and that production model projects use the required data controls. Provider terms and the deployed project configuration must be verified before external access.
Minimal ingestionCurrent: Diffs, PR metadata, linked issues, and checks are read. Dependency-impact analysis may inventory bounded repository context. Private qualification creates an exact repository checkout inside a fresh managed environment; that workspace is destroyed after normalized evidence is packaged and is not retained as an application artifact.
RetentionVerification required: The intended policy is a 90-day default for raw diff content and deletion of stored organization code within 7 days after App uninstall, while generated Stories persist with the PR. A deployed deletion drill and retention audit remain release gates.
IsolationCurrent: Every repository read and write requires a current repository-level entitlement keyed by your GitHub identity and repository selection. Entitlements are checked server-side and refreshed on membership and repository lifecycle events.
TokensCurrent: No write-scoped user tokens are stored. App installation tokens are short-lived and never persisted beyond their TTL. Secrets are encrypted at rest and rotatable.
AuditPlanned: Today the transactional outbox records every action dispatched to GitHub — the topic, the payload, and when it was dispatched — scoped to an account. Recording the acting user and the specific installation credential behind each write, and exposing that as a customer-visible audit log, is planned and not yet shipped.

AI model providers

Fullbeam sends PR diffs and metadata to AI models to generate Story chapters, risk tags, and cited evidence. The providers below are used:

OpenAI — GPT-5.6 Luna through an API project configured for our required data controls. Final provider terms and deployed-project configuration must be verified before external access; this page does not treat repository code as proof of that external configuration.

This list is updated when providers are added or removed.

Analytics and AI observability

PostHog — optional product analytics starts only after consent. Fullbeam disables autocapture, session replay, surveys, and feature flags, and does not send prompts, code, repository or account names, email addresses, URL query strings, or raw user/account identifiers. Server actions and workers do not send product analytics to PostHog because browser consent cannot be verified there.
Langfuse — records the structure and health of AI runs, including agent role, model, latency, token usage, retries, and failure status. Prompt, diff, and generated-output bodies are excluded by default.

Sentry remains the error-monitoring provider. First-party funnel and operational telemetry remain in Fullbeam's own Supabase and ClickHouse systems.

Bot attribution

When Fullbeam posts a comment or check to GitHub on your behalf, it is explicitly labeled "via Fullbeam on behalf of @your-handle". This is an honest bot label, not a cryptographic proof of authorship. The final review decision — approve, request changes, merge — is always performed by you directly in GitHub, using your own credentials. Fullbeam never submits a GitHub review approval under your name.

Security review contactCurrent

Request the data-flow diagram, permission review, retention details, or a security questionnaire through the contact form. We will distinguish repository-demonstrable controls from deployment evidence and planned controls in the response.

Private-preview terms

Fullbeam is invitation-only in private preview. Admitted teams connect selected repositories and customer-owned provider credentials, then configure a bounded Stack Release qualification. Any Fullbeam plan limits, evidence scope, retention, and support terms are disclosed before a paid commitment.

Model usage remains on the customer's provider account. Workspace creation does not authorize Fullbeam to deploy or enforce the customer's coding-agent setup.