A release decision with evidence attached.
Extension stores and users judge the bundle that was uploaded, not the promise made weeks earlier. Preflight makes that decision legible: it inventories the build, exposes what changed from the baseline, applies policy, and preserves the resulting verdict.
From artifact to an accountable decision.
Bring the bundle
Upload a .zip or .crx with its claims.json, from the Console, CLI, or CI.
Inspect deterministically
Five Rust agents hash, extract evidence, diff the baseline, evaluate policy, and issue a verdict.
Sign off consciously
Clear safe changes, hold unclear ones, or reject the build. The decision is appended to the review record.
The same review, in the right place for the job.
These are product-surface illustrations of the actual UI, not a claim that a browser is executing extension code. The scanner inspects artifacts out of process.
Rules are versioned, visible, and reproducible.
Preflight ships with a Chromium Web Store pack and a project-claims pack. A review records the selected pack versions so a verdict can be understood later instead of being recreated from a moving checklist.
| Control | What it checks | Outcome |
|---|---|---|
CWS-01 | Manifest V3 is required. | Blocker |
CWS-03 / 07 | Broad hosts, cleartext endpoints, and host declarations are constrained. | Blocker / high |
CWS-08 | eval, remote script imports, and unsafe CSP patterns are rejected. | Blocker |
NODE-01 / 02 | Manifest and discovered network destinations match claims.json. | Blocker |
NODE-03 / 04 | Consent and a kill switch are required where the policy calls for them. | High |
Automation moves work forward. People own the release decision.
Workspaces use scoped keys and separation of duties. An organization can have multiple isolated projects and baselines; an independent developer gets a personal workspace with the same review workflow.
| Role | Can do | Cannot do |
|---|---|---|
admin | Manage projects, keys, members, and sign-off. | Bypass the recorded decision trail. |
reviewer | Inspect findings and sign off a review. | Manage the whole workspace. |
ci | Submit builds and read their verdicts. | Sign off, hold, or ship a release. |
Browser access: optional WorkOS AuthKit sessions are sealed in HttpOnly cookies and linked to a known workspace member. API keys remain the explicit credential for the Rust CLI and CI; a browser session never exposes or replaces them.
One key across local review, CI, and the control plane.
# Inspect locally with the same deterministic scanner
preflight review ./build.zip \
--claims ./claims.json \
--pack cws-2026.1 \
--key $PREFLIGHT_KEY
# Push a review record to a workspace project
preflight push ./build.zip \
--project <PROJECT_ID> \
--claims ./claims.json \
--key $PREFLIGHT_KEY \
--api https://preflight.aetherhost.com.ngA GitHub Action can upload the real release artifact, wait for the verdict, add it to the workflow summary, and fail a pipeline for block or needs_human. Keep a CI key in the repository’s encrypted secrets; it remains unable to approve a release.
A small API around the release workflow.
POST /v1/signupCreate an individual or organization workspace and initial admin key.
POST /v1/sandbox/evaluateRun an ephemeral review against public Harbor Node fixtures.
GET /v1/meRead the active workspace, actor key, projects, and roles.
GET /v1/auth/workos/loginStart optional hosted browser sign-in with PKCE.
POST /v1/projects/:id/reviewsUpload a release artifact and optional claims document.
POST /v1/reviews/:id/sign-offRecord a reviewer or admin decision.
POST /v1/members/inviteInvite an organization member with a scoped role.
What Preflight does well—and what it intentionally does not claim.
Preflight does not execute an extension. That limits runtime risk during review and makes scans repeatable, but it cannot prove every behavior that only appears after live configuration, remote data, or user interaction.
Requiring a reviewer for uncertain or blocked builds is slower than automatic promotion. It is deliberate: a policy violation should be understood, not merely acknowledged by a CI token.
A diff is only as meaningful as the last known good baseline. Teams need to establish a cleared first release and keep claims accurate as capabilities evolve.
Versioned rules are auditable and stable. They still need ownership: teams must decide which controls are appropriate and update policy as store guidance changes.