Replace the single global admin allowlist with a per-customer concept

[JSONbored]

Decision (ratified 2026-07-21): live GitHub permission check, not a DB-backed allowlist. Query GitHub's real-time collaborator/permission API (is this login a repo owner or has admin/maintain permission on the specific repo) at each check site, mirroring the existing login === repoOwner pattern already used in src/review/linked-issue-label-propagation-fetch.ts and elsewhere. No new table, no admin UI to keep a list in sync.

Problem: A single global admin-login allowlist (ADMIN_GITHUB_LOGINS, src/auth/security.ts's parseGitHubLoginList) grants maintainer-equivalent trust across every repo in the deployment today — correctly representing "the one operator" for self-host, but there's no concept of a per-customer admin distinct from literal GitHub repo-owner permissions for a hosted model.

Area: ORB / Cloud. Confirmed live call sites of the allowlist check this replaces (for hosted deployments only — self-host keeps the simple global allowlist as its default): src/auth/security.ts (the parser itself), src/queue/processors.ts (6+ call sites), src/queue/review-evasion.ts (3 call sites), src/review/linked-issue-label-propagation-fetch.ts, src/review/visual/visual-followup.ts.

Deliverables:

• A isPerTenantAdmin(login, repoFullName)-shaped helper calling GitHub's real-time permission API (e.g. GET /repos/{owner}/{repo}/collaborators/{username}/permission), used in place of ADMIN_GITHUB_LOGINS membership at every hosted-deployment call site listed above.
• Self-host behavior (global ADMIN_GITHUB_LOGINS allowlist) completely unchanged — this only applies to the hosted path.
• Tests: a real repo owner/admin passes; a non-admin collaborator fails; a GitHub API error fails closed (denies, does not silently grant).

Resources

• src/auth/security.ts (parseGitHubLoginList, the pattern this replaces for hosted)
• Call sites above
• src/review/linked-issue-label-propagation-fetch.ts (existing login === repoOwner precedent this mirrors)

Contributor-eligible. Decision is ratified above; this is now mechanical application of a decided pattern across the listed call sites, with an explicit fail-closed test requirement as the safety guardrail.

[linear-code]

JSO-3549

[JSONbored]

Direction now decided for hosted ORB: multi-tenant on Cloudflare Workers, tenant data logically isolated via tenant-scoped D1 (not physical sharding, not per-tenant containers), free/beta launch first with billing deferred — CodeRabbit-style freemium target. This issue's scope reads as: add real tenant-id scoping to this table plus its resolver/read paths, consistent with that model. Moved to contributor-eligible — app-level code + a D1 migration, no infra credentials or business-judgment call involved.

[JSONbored]

Partially resolved by architecture, partially still real: the cross-tenant leak concern is gone — per-tenant Cloudflare Containers mean each tenant's admin allowlist only ever governs their own container, same as self-host today. No scoping code needed for that part.

What's still a genuine gap, unrelated to multi-tenancy: for a self-serve hosted signup, a new customer shouldn't have to manually hand-edit an allowlist file the way a self-host operator does today — admin rights should auto-derive from their real GitHub org/repo-owner permissions at provisioning time. Re-scoping this issue to just that: auto-derive admin rights from GitHub permissions during the self-serve provisioning flow (#4926/#4927), rather than requiring manual allowlist setup. Self-host keeps the simple manual allowlist as its default, unchanged.

[JSONbored]

Grounded in existing code: src/orb/oauth.ts's verifyInstallationAdmin already does exactly this check per-installation (org admin, or the account owner) for the self-enrollment flow. The global allowlist to replace is env.ADMIN_GITHUB_LOGINS (src/auth/security.ts). Proposal: for hosted-tenant admin actions, resolve admin status via verifyInstallationAdmin scoped to that tenant's installation, instead of the global env-var allowlist — self-host keeps ADMIN_GITHUB_LOGINS unchanged as its own simpler default. Concrete, buildable, no other blockers — ready for a contributor.

[JSONbored]

Correction to my earlier comment: on closer inspection this is bigger than 'ready for a contributor.' ADMIN_GITHUB_LOGINS is checked at 15+ call sites (src/queue/processors.ts, review-evasion.ts, linked-issue-label-propagation-fetch.ts, and more) as a fleet-operator identity concept with no per-request tenant context anywhere in that code today. A real per-tenant admin resolution needs a live tenant-request context to scope against, which only exists once #7180's provisioning/control-plane work lands. Marking blocked-by #7180, same as the rest of this cluster — not independently buildable yet.