How Seatbelt scans
Every Ship Read follows the method on this page. If you are going to trust a report, or show one to someone else, you should be able to read exactly how it was produced.
Published July 19, 2026. Updated whenever the engine's checks or gates change.
What a Ship Read is
Seatbelt reads the build you hand it. In Cursor or Claude Code, /seatbelt scans a project folder or a local ZIP export through MCP. In the browser at /app, you can run fixture demos or an outside-view read on a live URL, not a folder, ZIP, or git URL paste. For GitHub, clone locally and scan the folder. It is a static read of the build, made for AI-built apps, run at the moment that matters: right before you share the link.
The read is deterministic where it must be. A fixed engine walks your files and decides the serious findings with rules, so the same input always gives the same result. For judgment calls, the report hands a short checklist to the coding agent you already work with instead of running another model over your code. Seatbelt never invents a finding from chat context: every flag points at a file and a line, with a plain-English reason and a next step.
The six surfaces
We check the six places AI-built apps actually get hurt. Each check reads specific things; here is what they are.
| Surface | What the engine reads | Gate |
|---|---|---|
| Login and accounts | Identity routes, session wiring, and whether server-side checks actually guard the API. | Noted. Worth a look if an identity API looks unguarded. |
| Payments and money | Checkout wiring, prices or amounts set in the browser, and whether webhooks are verified. | Worth a look. Never a hard block. |
| Secret keys | Keys that landed in client-reachable code or the public build. | Must fix if a secret key sits in the client. Publishable keys, like Stripe pk_, are expected there. Server-side .env hygiene is worth a look. |
| Customer data | Where emails, uploads, and logs handle personal information. | Noted. Worth a look if uploads are loose or customer emails show up in browser console logs. |
| Databases and storage | Admin-grade keys such as service_role in client code, open Firebase or Storage rules, database URLs in the build, raw SQL built by string concatenation, and public database files. | Must fix when private data is wide open. |
| Risky shortcuts | Leftover admin and debug routes, wide-open CORS, eval, and HTML injected from user input. | Worth a look. Must fix if a route that can wipe real data is reachable. |
Three gate levels, in plain English
- Must fix. The scary stuff: an exposed secret key, private data wide open, a destructive admin route. These hold the report until you fix them or explicitly accept them.
- Worth a look. Real findings that deserve your judgment before launch. They never block you.
- Noted. Context the report records so you ship with eyes open.
Two honesty rules ride along. Accepted is not fixed: if you accept a risk instead of fixing it, the report records that decision with a UTC timestamp, visible to anyone you share the link with. And any secret the engine finds is redacted in the report; the report proves the leak without repeating it.
What a scan cannot see
A Ship Read is one check before you ship, not a security audit. The limits are part of the method, so here they are in full:
- We do not touch your live site. No requests against production, no attack traffic, no exploit attempts. We read the artifact you hand us.
- We do not do runtime testing. Scanners that attack a running app (DAST) can find real access-control breaks by exercising the live system, and that layer has genuine value. It also sends real attack traffic at your app, and its findings arrive after deploy. We chose the other moment: read the build before the link goes out, with the human keeping structural judgment over every fix. If you want the runtime layer, run it in addition, not instead.
- We cannot read what is not in the artifact. Hosting dashboard settings, platform-managed server code you cannot export, and third-party service configuration live outside the files you hand us.
- We do not audit dependencies for known CVEs. Tools like Snyk own that lane.
- We are not a certification. No compliance stamp, no HIPAA or SOC 2 claim, ever.
- An empty result is not a security clearance. If your project is a brochure site with no login, payments, data, or secrets to check, the report says exactly that instead of pretending a clean bill of health.
How the badge is earned
The Verified by Seatbelt badge does not exist until a real scan has run. All of the following must be true:
- A real scan ran on your project folder or local ZIP export through
/seatbelt. Not a fixture demo at/app, not an agent's claim in chat. - There was something real to check. At least one app surface (login, payments, customer data, secrets, or risky shortcuts) was actually present. Brochure sites never earn the badge; an empty clear is not proof.
- Every must-fix gate is closed, either fixed and confirmed by a re-scan, or accepted with a recorded timestamp.
- The report exists. The badge always links to the live report it came from, never to a static sticker.
Worth-a-look findings alone never block the badge. That is deliberate: the badge means the scary stuff is handled and the decisions are on the record, not that the app is perfect.
Why this page is public
A free scanner's grade is only worth citing if the method behind it is published. This page is the contract behind every Seatbelt report: what was read, how it was judged, and where the edges are. When the engine's checks or gates change, this page changes with them, with the date at the top.
Want to see it on your own project? Try fixture demos or scan a live URL at /app, or install /seatbelt and scan your repo folder from Cursor. Read how Seatbelt compares to other tools and the checklist worth doing by hand before you launch.