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
Harness Registry
Versioned Packs, assignments, and rollout policy
Step 2
Provider runtime
Claude Code and Codex sync plus bounded evidence
Step 3
GitHub correlation
Exact commits, pull requests, and review outcomes
Step 4
Review and improve
PR Story, continuity, and successor Pack evidence

One immutable Harness Pack identity follows assignment, provider installation, runtime evidence, exact GitHub pull-request membership, review, and the observed outcome used to inform a successor Pack. GitHub remains the source of truth for commits, pull requests, and review outcomes.

What Fullbeam can and cannot do

Can do

Manage private, versioned Harness Packs and compile their supported configuration for Claude Code and Codex.
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.
Post review comments and a Check run, explicitly attributed as via Fullbeam on behalf of @you.
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

Merge, close, reopen, or approve pull requests autonomously.
Store full repository clones.
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 Pack 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 revision-aware GitHub Check that links to the Fullbeam Story. The Check appears in the PR timeline and triggers the reviewer deep link.	Cannot modify existing checks created by other apps or CI systems.
`contents: read`	Read pull request diffs and bounded repository context at the exact revision when dependency-impact analysis needs it. Fullbeam may inventory the repository tree and read up to 40 supported text blobs / 1 MiB; it never creates a full repository clone.	Cannot write, delete, or modify any file. Cannot access repositories not selected during installation or retain a full repository clone.
`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 and Codex runtime evidence is connected separately and only after user authorization. Accepted installation receipts bind the exact Harness Pack identity to 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

Application secrets and stored data use the encryption controls provided by the configured infrastructure, and credentials are designed to be rotatable. A documented EU deployment, customer-selectable region, and production evidence for key rotation are release gates; they are not represented here as deployed controls.

Data collected for the control loopCurrent

The control plane stores versioned Harness Packs, assignments, provider installation receipts, bounded 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 assignment, 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 also inventory the repository tree and read bounded context at the exact revision, capped at 40 supported text blobs / 1 MiB. Full repository clones are never created or stored.
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.

Pricing hypothesis & design-partner terms

There is no public launch today. After the release gates pass, selected design partners may join a founder-led alpha at no charge. The later pricing hypothesis is $30 per reviewer seat per month; repositories, authors, and read-only evaluators would not be billed. This is research, not a live paid plan.

Alpha participants would receive bounded early access and direct influence on the product roadmap in exchange for regular feedback. We would give at least 30 days notice before any transition to a paid plan.