Security

Repo Bridge is a GitHub-integrated SaaS, so the trust model is the same as Dependabot, Renovate, Vercel, or CodeRabbit: you install our GitHub App on the repos you want to sync, and we use that installation to read source and write destination pull requests. We do not store source code at rest, and other customers cannot see your data — but operators of this service (the people running the infrastructure) have technical access to the metadata listed on the Privacy page. We disclose that openly below.

• Every workspace-scoped table is protected by Postgres Row-Level Security. A query from User A literally cannot return rows belonging to Workspace B — the database engine rejects it before our application code runs.
• GitHub App installations are bound to the workspace that installed them. Members of other workspaces cannot list, read, or use them.
• Server-side helpers that check workspace membership run as SECURITY DEFINER functions and have direct EXECUTE privileges revoked from authenticated and anonymous roles. They are only callable from inside RLS policy evaluation.
• Server functions that act on behalf of a user validate the user's Supabase JWT on every request and scope every query through RLS as that user. The browser never holds a service-role key.

• File bytes are fetched from GitHub by our edge worker, posted as blobs to the destination repo, and discarded. They are never written to our database or to any persistent disk.
• We persist Git blob SHAs and paths so we can compute drift and show file-level previews. SHAs are not the file contents — they are the same hashes GitHub itself stores.
• Sync runs open a fresh branch and a clean pull request on the destination. There is no shared Git history, no force-push, and no cross-repo remote linkage.

• GitHub App private key — stored as a Supabase secret, accessible only to server-side code. Used to mint short-lived installation tokens on demand.
• Service role key — server-only, never shipped to the browser, never passed as a caller token to edge functions.
• Webhook signatures — every GitHub webhook is verified with HMAC-SHA256 against GITHUB_WEBHOOK_SECRET before any handler logic runs. Invalid signatures are rejected.
• Cron endpoints — protected by a shared CRON_SECRET and timing-safe comparison.
• Transport — all traffic is HTTPS. Database connections use TLS. Data at rest is encrypted by the Supabase storage layer.

When the “AI comment” toggle is enabled on a sync profile, we send Anthropic's Claude API the diff for the commit being synced (file paths and patch text) so it can write the PR summary. We do not send credentials, secrets, environment variables, or unrelated repository content. The generated summary is stored in our database and posted into the PR body on GitHub.

You can disable this per profile. With AI off, the PR body falls back to a template that lists the changed paths and nothing leaves our infrastructure for Anthropic.

We believe in being upfront about this. The people operating Repo Bridge hold the service-role database key and the GitHub App private key. With those, the operator can:

• Read any row in the database, including sync history, repo names, PR records, AI summaries, and webhook payload summaries.
• Mint a GitHub installation token for any installation registered in the database, which would let them read the actual source code of those repos through GitHub. This is inherent to how GitHub Apps work — it is not a Repo Bridge bug, it is the trust requirement of installing any GitHub App.
• Read edge function logs, which include repo names, commit SHAs, file paths, and error messages.

We do not access customer data outside of the automated sync flow or on-request support. If you want a deployment where the operator cannot reach your code, the only honest answer today is to self-host — get in touch and we can discuss.

Please email security@gitsync.mikai.ai with details and steps to reproduce. We will respond within 3 business days. Please do not open public GitHub issues for security reports.