DRAFT - requires attorney review. Not in effect.

Scan Authorization

By requesting a Scan, you confirm each statement below, and we rely on them. This Scan Authorization is part of the Terms of Service.

1. I own the target domain, application, repository, database and hosting project, or I have written authorization from the owner to request a security scan of each of them, and I will provide that authorization on request. If I am an agency, I hold that authorization from each client.
2. The target is not hosted on infrastructure whose terms forbid security scanning, or I have obtained any required permission.
3. I understand what each Scan does, as described below, and that it does not log in to my app, submit forms, send prompts to AI endpoints, try exploits, or change data in my app or database.
4. I understand the Scan is not a penetration test, audit or compliance certification, and is not a guarantee of security.
5. I will indemnify [OWNER LLC NAME] for any claim arising from a Scan I was not authorized to request.

Ownership verification

Before any active check (described below), and before every Launch Review and Guard scan, you must prove you control the domain by either:

• serving /.well-known/preship.txt containing your verification token, or
• adding <meta name="preship-verification" content="TOKEN"> to your homepage.

Guard re-checks verification before every weekly scan and pauses if it fails.

What each Scan does

Passive checks (Basic Scan without verification)

Rate-limited GET requests for your homepage and the resources it references (JavaScript files and the source maps they link to), exactly as a visitor's browser would load them. We read the response headers and look for secrets and Supabase/Firebase configuration in that public code. We make no other requests to your site or backend.

Active checks (Basic Scan and Launch Review, only after verification)

• Guessed paths: GET requests for well-known sensitive files that the homepage doesn't link to, such as /.env, /.env.local and /.git/config, plus one request to a made-up path to detect single-page-app fallbacks.
• Supabase: using only the public anon key your app already ships, a read of the PostgREST schema and at most one row per table (up to 15 tables) to see whether data is readable without a login. If the project URL isn't named in your code, we find it by requesting /rest/v1/ on up to 12 URLs your bundle references that are Supabase-hosted or under your own domain, plus your own origin. We never probe other third-party hosts. We record only whether a table is readable, never its contents.
• Firebase: one unauthenticated shallow read (/.json?shallow=true) of the Realtime Database URL your app ships. We record only whether it's readable and how many top-level keys exist, never values.
• Launch Review only: a deeper crawl of your own origin's JavaScript (including lazy-loaded chunks and build manifests), GET and OPTIONS requests to AI/chat routes to see whether they answer without authentication (we never send prompts), a re-scan after you apply fixes, and any connectors you choose (below).

Optional connectors (Launch Review and Guard)

• GitHub (GitHub App): we clone your repository into a temporary folder to scan it, then delete it. If you ask for a fix pull request, we push one new branch named preship/launch-fixes-… with the suggested changes and open a pull request from it. We never push to an existing branch, force-push, merge, or deploy. The app needs repository write permission to create that branch; you can uninstall it at any time.
• Supabase (OAuth, Management API): read-only catalog queries about your database's security settings (which tables have Row Level Security, which policies exist, and which storage buckets are public). We never SELECT from your tables through this connection and never change settings.
• Firebase / Google (OAuth or pasted rules): read-only access to your Security Rules to review them.
• Vercel (Integration): read-only access to project settings: environment-variable names and types (values are never decrypted), whether preview deployments are publicly reachable, and your vercel.json headers. After a one-time review we uninstall the integration ourselves.
• Zip upload: instead of connecting GitHub, you can upload a zip. It's held in a temporary folder and deleted after the job.

Unless you opt into Guard, connector tokens are discarded or revoked after your review. With Guard, they're stored encrypted and you can revoke them from your dashboard.

Limits on every Scan

An identifying User-Agent, a delay between requests, a cap of 400 requests per scan, per-domain daily limits, and a block on private, loopback and cloud-metadata addresses.