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. Last updated August 16, 2026.
What a Ship Read is
A static read of the build you hand us, run at the moment that matters: right before the link goes out. In your agent (Cursor, Claude Code, Codex, or Antigravity), /seatbelt reads a project folder or a local ZIP export through MCP. At /app in the browser it runs fixture demos or an outside view read of a live URL. For GitHub, clone locally and scan the folder.
Serious findings are decided by rules rather than by a model, so the same input always gives the same result and a published finding can name the version that produced it. Judgment calls become a short checklist for the coding agent you already work with, instead of a second model run over your code. Every flag points at a file and a line with a plain English reason and a next step. Nothing is inferred from chat context.
What it checks, and what can hold a report
| Surface | What the engine reads | Can hold your report |
|---|---|---|
| Code execution | Request text reaching a shell command, attacker-controlled bytes handed to a deserializer, eval or new Function in app code, and user input in a server-side template. | Yes, for a shell or a deserializer. eval and templates are worth a look: finding the risky shape is not proof that user input reaches it. |
| Login and accounts | Identity routes, session wiring, and whether server-side checks actually guard the API. | Yes, for a privileged field the client can set on itself, or a lookup by id with no owner check. The rest is worth a look. |
| Payments and money | Checkout wiring, prices or amounts set in the browser, and whether webhooks are verified. | No. Worth a look, never a block. |
| Secret keys | Keys that landed in client-reachable code or the public build. | Yes, 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. | No. Worth a look if uploads are loose, or customer emails reach 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. | Yes, when private data is wide open. |
| Risky shortcuts | Leftover admin and debug routes, wide-open CORS, and HTML injected from user input. | Yes, if a route that can wipe real data is reachable. Otherwise worth a look. |
Three gate levels sit behind that column. Must fix holds the report until you fix it or explicitly accept it. Worth a look is a real finding that deserves your judgment and never blocks. Noted is context the report records so you ship with eyes open.
Two honesty rules ride along. Accepted is not fixed: accepting a risk instead of fixing it is recorded with a UTC timestamp, visible to anyone you share the link with. And any secret the engine finds is redacted in the report, so 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:
- 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 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. 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 a check earns its place
The clean half is the load-bearing half. A check that fires on the broken version proves nothing on its own, because a rule that flags everything would also pass that test. So a check ships alongside code it must stay silent on, and 297 of the 596 cases exist for no other reason. All 596 run on every change.
A fix has to be the thing that made the difference. Before it ships, the clean case is run against the previous engine. If it already passed, the fix was not what changed the outcome, and the case does not count.
An instrument that cannot fail is not an instrument. Each comparison we run is pointed at a known answer before it is pointed at anything real. A checker that reports zero because it is misconfigured looks exactly like a checker that reports zero because the code is clean, and we have published a wrong number that way before.
A number without its frame is not a number. Any rate we report names what was sampled, how many, and on what date. Two different sampling methods over the same population can differ by fourteen points, and both figures are true. Quoting either one bare would not be.
The corpus is authored, and that is its limit. These cases were written by us, which means they measure what we thought to check. A synthetic corpus tells you how well a detector finds what it already looks for. It cannot tell you what the detector never looks for, and those are different questions with only one number between them. We have scored well on one half of a class and missed the other half in real code, which is why findings from real repositories, not the corpus, decide what gets built next.
The engine is deterministic and public. The same input gives the same result, the package is on npm, and a published finding names the version that produced it. Anyone can re-run our numbers without asking us, which is the only version of a claim worth making.
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 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.
Verified by Seatbelt badge
After a cleared Ship Read, embed the badge on your site. Visitors who want their own check land on the app with ?ref=badge tracked.
Earned badges on cleared reports link to your live proof URL with ?ref=badge. See a sample report for the full pattern.
Why this page is public
A free scanner's grade is only worth citing if the method behind it is published. This is the contract behind every 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 your agent. Read the checklist worth doing by hand before you launch.
Common objections
Why not just ask your agent to audit the code?
Respect the instinct. Anthropic's Claude Code Security (Feb 20 2026, limited research preview for Enterprise and Team) reads and reasons about your code the way a human security researcher would, with multi-stage self-verification and nothing applied without human approval. Founders also shop claude code security audit skill and prompt recipes for the same job. Detection is not the wedge: a naive founder audit prompt on a frontier model already finds most planted flaws. Precision is. On our July 2026 agent-audit bench, that prompt wrongly blocked 27 to 33% of known-safe apps as ship-blocking. The Seatbelt engine blocked none of those same cases. Same thirty clean apps: the agent blocked ten, the engine blocked none. Limits on that number: one model (Gemini 3.6 Flash), Fable 5 not in the bench yet, our corpus, single-shot prompt. What still holds without leaning on catch-rate: Seatbelt is deterministic on the same artifact, independent of the model that wrote the code, automatic at git push via hooks, enforcing when you wire deny hooks, and provable with a shareable Ship Read link anyone can verify. Distinct from OpenAI's Codex Security CLI recipe in the FAQ below and from pasted checklist / SKILL prompts in the agent checklist FAQ, and from bundled scanner orchestration in the orchestration FAQ. Many teams want both.
I run a security checklist / SKILL in my agent. Why Ship Read?
Respect it. August 2026 brought three real in-harness layers builders paste or install:
- Vibesecurity (eticmedya, MIT, Aug 2026): a bilingual 40-check prompt repo (30 web · 10 mobile). Open it in Claude Code or ChatGPT Codex, let the agent walk the checklist, report
file:line, fix on approval, and teach manual retest. Their own disclaimer: not a pentest substitute. - Vibesec Auditor (softwareasg-tools, MIT, Aug 2026): a 12-phase AppSec
SKILL.md(secrets · auth · IDOR · API · injection · frontend · database · cloud · infra · logging · regression) you paste into.cursorrulesor Antigravity skills. - vibeward (npm 263 dl/wk, Aug 2026): prompt-time NL intent rules plus pre-write hooks that catch dangerous requests before the agent edits, with a read-only scanner lane. Distinct from a pasted checklist; see the PreToolUse hooks FAQ for session vs push boundary.
All three are genuine in-harness review. They run when you remember to open the repo, paste the SKILL, or wire the hook. Session-scoped LLM review is not the same layer as a deterministic seven-surface artifact read on what you export at git push, with a shareable Ship Read link at /r/:id anyone can verify at handoff without trusting your chat log. Seatbelt does not block prompts or replace your checklist. It reads the build you hand it, the same way every time, from outside your agent. Many teams want the in-harness checklist and the push-boundary proof. See the agent audit FAQ for false-alarm precision on pasted audit prompts, and a repo sample report for ship-moment proof. For bundled OSS scanner stacks, see the orchestration FAQ.
I already run a bundled security scanner stack. Why Ship Read?
Respect it. August 2026 brought two real orchestration kits that wrap the same OSS scanners many teams already run:
- vibe-code-guard (DOTfei, Apache-2.0, public beta Aug 2026): agent-installable, local-first workflow. Project-aware scanner selection, normalized findings, correlation, verification lifecycle, release gate, and a dashboard plus CLI/JSON for agents. Upstream tools include gitleaks, semgrep, trivy, and checkov. You paste a prompt and the agent installs from GitHub.
- vibe-check-security (jdj40211, MIT, Aug 2026): Spanish LATAM kit with
./scripts/auditoria.shto install and run gitleaks, trufflehog, semgrep, trivy, and osv-scanner in one command, plus Claude Code prompts for logic the scanners miss, securityCLAUDE.md, an anti-secret hook, and Anthropic's official PR review Action. Their own docs warn: DAST tools like ZAP or nuclei belong only on apps you own.
Both are genuine value. They bundle third-party scanners, print what files were read, and can score a release decision in terminal or dashboard. That layer is not the same as a deterministic seven-surface plain-English read on the artifact you export at git push, with a shareable Ship Read link at /r/:id anyone can verify at handoff without trusting your orchestration output. Seatbelt names what it read and what a static artifact read cannot see (no runtime attack traffic, no hosting dashboard settings, no registry malware lookup). It does not replace your scanner bundle. It reads the build you hand it at the push boundary, the same way every time, from outside your agent. Distinct from pasted checklists in the agent checklist FAQ and from session hooks in the PreToolUse hooks FAQ. Many teams want the orchestration stack and the push-boundary proof. See a repo sample report for ship-moment proof.
I already run OpenAI's Codex Security CLI (@openai/codex-security). Why Seatbelt?
Respect it. OpenAI's Codex Security CLI (npx @openai/codex-security, Jul 2026 research preview) is a real repo AppSec client: scan a folder or diff, CI and SARIF export, and install-hook can sit on pre-commit and block high findings. That packaging competes for the commit slot. Two limits stay load-bearing: the analysis still calls OpenAI (sign-in or API key; access grant, often Trusted Access), and the input is still a repository path or diff. No domain, no served-bytes read, no estate discovery, and no stranger-forwardable Proof of Read. Seatbelt is a different moment: a seven-surface plain-English read of what you export at git push, optional deny hooks, and a shareable Ship Read link anyone can verify at handoff. Distinct from REA's fleet Codex-review gate in fleet governance stacks. Many teams want both.
I keep seeing different npm packages called VibeGuard. Which one is which?
Two different npm packages share the name as of July 2026. @yagyeshvyas/vibeguard (MIT, Jul 2026) is the open-source package most builders mean: 764 rules, vibeguard scan, vibeguard guard, pre-commit blocks critical, vibeguard pre-deploy 13-gate check, PostToolUse hook, 463 npm dl/wk. @indicated/vibeguard is a different commercial package (ISC license key, 74 rules, 3 dl/wk). Builders searching npm often land on the wrong one. Respect what each does: local rules, hooks, and exit codes are real. Seatbelt is a different moment: seven-surface static artifact read at git push with shareable proof anyone can verify at handoff. Vendor guard exit codes are not push-boundary shareable proof.
I wired vibe-audit-security / an MCP security scan before push. Isn't that a gate?
Respect it. vibe-audit-security on npm (vibe-audit-security v0.1.0, Jul 2026) ships a local CLI + MCP with scan_code, scan_url, and scan_project, static and dynamic checks, a vendor 0-100 score, and optional exit 2 on critical when you wire CI yourself. Claude Code plugin marketplace install is real. That local MCP scan lane is genuine value. The vendor's default example CLAUDE.md is still advisory only: Do not block the push. Inform the user and let them decide. Optional exit codes you add in CI are not the same as fail-closed deny hooks on every push path. Contrast VibeGuard vibeguard guard pre-commit (blocks critical by default) and Seatbelt deny hooks (block --no-verify, core.hooksPath, and GitHub MCP writes, then gate open hard findings at git push). Seatbelt is a different moment: seven surfaces in plain English on your local artifact, fail-closed when wired, with a shareable Ship Read link anyone can verify at handoff. Session hooks and MCP scans catch in-editor mistakes; they do not replace artifact read on what leaves git (see the PreToolUse hooks FAQ). Many teams want the MCP scan and the push-boundary proof. Distinct from unrelated npm vibe-audit (agent session auditor).
I already have PreToolUse hooks or an agent-control IDE. Why Ship Read?
Respect it. PreToolUse hooks, Cursor beforeShellExecution denylists, and agent-control stacks like Aura (git-native IDE with proof-ledger commits via hooks, July 2026) are real for in-session catastrophic mistakes. Anthropic permissions docs say rules are enforced by the harness, not the model. Session hooks block commands at the harness layer. They do not read the seven-surface build you export. A documented gap: PreToolUse hooks silently skip Bash from subagents spawned via the Agent tool (anthropics/claude-code#43612, closed not_planned May 2026). Terminal commits, other agents, and human pushes can bypass session-only hooks. Seatbelt is a different moment: a cross-platform Ship Read on the artifact in git at the push boundary, with optional push gate and shareable proof anyone can verify at handoff. Many fleet stacks use both: session hooks for blast radius, artifact read for what leaves git. See a repo sample report for ship-moment proof.
I configured GitHub Copilot hooks in .github/hooks. Why Ship Read?
Respect it. Founders searching copilot hooks, copilot hooks.json, or github copilot hooks json are wiring real enforcement. GitHub's Copilot hooks configuration (Aug 2026) says that in a Copilot cloud agent job, the only hook configuration that exists by default is .github/hooks/*.json inside the cloned repository. A sessionStart hook with type: "prompt" can auto-submit text at session open. A preToolUse hook is the enforcement surface when tools are pre-granted. If your copilot hooks not working search landed here, start with the JSON schema, matcher names, and whether the cloud agent session loaded the repo default branch where those files live.
Committed hook JSON is genuine value. It governs what the agent harness may do in-session. It is not the same layer as a deterministic seven-surface artifact read on what you export at git push, with a shareable Ship Read link at /r/:id anyone can verify at handoff. Run /seatbelt init with install_hooks: true and Seatbelt writes .github/hooks/seatbelt-gate.json beside your other agent hook configs. npx withseatbelt --dry-run lists the paths without changing your tree. That wiring is the push-boundary gate, not a substitute for reading keys, database rules, auth, payments, customer data cues, and risky shortcuts in founder English on the artifact in git. Distinct from session governance in the PreToolUse hooks FAQ. Many teams want Copilot hook config and push-boundary proof. See a repo sample report for ship-moment proof.
I wired Claude Code hooks (SessionStart, Setup). Why Ship Read?
Respect it. Founders searching claude code hooks, claude code hooks examples, or session start hook claude code are configuring real harness behavior. Anthropic's Claude Code hooks docs (Aug 2026) let you run commands or MCP tools on events like SessionStart and Setup, plus mid-session enforcement on PreToolUse and Stop. Skills and subagents can declare hooks in YAML frontmatter that register when invoked. If you hit a claude code session start hook error or claude session start hook error, the fix is usually matcher syntax, handler type, or a command path the harness cannot execute, not a missing Ship Read.
Session hooks are genuine value. They run when the harness loads your settings and can block catastrophic commands before the model acts. They do not read the seven-surface build you export at git push, and they do not mint stranger-forwardable proof. Seatbelt is a different moment: a cross-platform artifact read at the push boundary, optional deny hooks on every push path, and a shareable Ship Read link anyone can verify at handoff. Distinct from pasted audit prompts in the agent audit FAQ and from session governance in the PreToolUse hooks FAQ. Many teams want Claude Code hook config and push-boundary proof. See a repo sample report for ship-moment proof.
I wired Cursor project hooks in .cursor/hooks.json. Why Ship Read?
Respect it. Founders searching cursor hooks, cursor hooks.json, or cursor project hooks are configuring real harness behavior. Cursor's project hooks docs (Aug 2026) let a repo ship .cursor/hooks.json with lowercase sessionStart handlers that run a command when the agent session opens. A shipped example: vibereview-cli writes .cursor/hooks.json with sessionStart command: "node .vibereview/hooks/context.cjs cursor SessionStart" on init, distinct from Claude Code's capitalized SessionStart on .claude/settings.json.
Committed hook JSON is genuine value. It governs what the Cursor harness may do when the session starts. Seatbelt walks .cursor/hooks.json as part of the artifact read. It does not flag lowercase sessionStart command hooks today, and we do not claim the engine reviews them as a ship-blocking finding until IMPROVE #313 lands. That is honest scope, not a missing wedge: session-start commands are not the same layer as a deterministic seven-surface artifact read on what you export at git push, with a shareable Ship Read link at /r/:id anyone can verify at handoff. Distinct from Copilot cloud hooks in the Copilot hooks FAQ, Claude Code SessionStart in the Claude Code hooks FAQ, and session governance in the PreToolUse hooks FAQ. Many teams want Cursor project hook config and push-boundary proof. See a repo sample report for ship-moment proof.
My URL scan at /app cleared. Do ship-blocking hard gates show up there?
Respect it. Paste-a-URL at /app is a real entry. The outside view reads what any visitor can see in the served page and scripts: exposed keys in bundles, some database rule leaks, and risky shortcuts that show up client-side. That lane is genuine signal before you share a link. Many URL scans read clear because login, payments, customer data cues, and code_execution paths (shell, deserializer, eval-shaped server code) live in your repo and backend, where a URL cannot reach.
Ship-blocking hard gates on those repo-lane surfaces require reading the artifact you export: scan a project folder, a local ZIP export, or wire MCP/repo scan via npx withseatbelt or /seatbelt init. The public URL lane does not surface repo-lane hard gates today. A cleared URL verdict is observation framing on what the outside view could see, not permission to skip the repo read. On our own dogfood fleet (August 2026), URL-lane scans overwhelmingly read cleared while repo-lane scans carry the code_execution hard-gate signal. Distinct from outside-view partial-read honesty in the advisory guard FAQ and from session hooks in the PreToolUse hooks FAQ. Many builders want the URL triage and the push-boundary proof. See a URL sample report for outside-view framing and a repo sample report for ship-moment proof.
I copied Supabase's hybrid search guide for RAG. Why Ship Read?
Respect it. Founders searching supabase hybrid search, supabase hybrid search docs, or supabase hybrid_search are wiring a real retrieval stack. Supabase's hybrid search guide (Aug 2026) ships a canonical hybrid_search SQL function over a shared documents table: semantic ranking over the full embedding index with no owner_id, user_id, or tenant column in the sample schema. The Edge Function example calls supabase.rpc('hybrid_search', …) with a client built from supabaseServiceRoleKey, which bypasses row level security. The inline comment says to swap in the user JWT when you use auth, but the published default is full-table hybrid retrieval with elevated credentials. That is a different RPC name from semantic-only match_documents (knowledge pass 161), but the leak class is the same: one shared index can serve every tenant's chunks if you copy the sample without scoping.
Seatbelt does not flag hybrid_search calls today (improve #167 is engine-blocked). Honest scope: we do not claim a detector caught your RAG wiring. What we do sell is a different moment: a deterministic seven-surface artifact read on what you export at git push, with npx withseatbelt or /seatbelt init on the repo folder, and a shareable Ship Read link at /r/:id anyone can verify at handoff. Paste-a-URL at /app is an outside view only; it cannot read your Edge Function or scoped SQL in git. Distinct from the URL lane vs repo hard gates FAQ. Many teams want RAG-with-permissions docs and push-boundary proof. See a repo sample report for ship-moment proof.
My UserPromptSubmit hook errors when I paste into Claude Code. Why Ship Read?
Respect it. Founders searching userpromptsubmit hook claude, claude code user prompt submit hook, userpromptsubmit hook error claude code, or userpromptsubmit operation blocked by hook claude are debugging real harness friction. Anthropic's Claude Code hooks docs (Aug 2026) let UserPromptSubmit handlers add context or block a submission before the model sees it. updatedInput belongs to PreToolUse for rewriting tool input; on Claude Code 2.1.246 it is silently ignored on UserPromptSubmit. Community hooks like oh-my-privacy (v0.3.0, Aug 2026) pivoted to block-never-mask: PreToolUse blocks secret-dumping commands, and UserPromptSubmit can set suppressOriginalPrompt or exit 2 to block a paste that contains secrets, rather than redacting it in flight. That session transcript hygiene is genuine value when you paste API keys into chat.
Session hooks govern what the harness does mid-chat. They do not read the seven-surface build you export at git push, and they do not mint stranger-forwardable proof. Seatbelt does not redact pasted prompts today, and we do not sell oh-my-privacy or any UserPromptSubmit hook as a Ship Read substitute. Seatbelt is a different moment: a cross-platform artifact read at the push boundary, optional deny hooks on every push path, and a shareable Ship Read link anyone can verify at handoff. Distinct from Claude Code SessionStart hooks and from session governance in the PreToolUse hooks FAQ. Many teams want prompt hygiene in chat and push-boundary proof on what leaves git. See a repo sample report for ship-moment proof.
What about slopsquatting or malicious npm packages?
Real risk, and the names matter. Four separate supply-chain shapes show up in builder conversations (July 2026):
- Typosquatting: you typo a real package name and install the wrong one.
- Slopsquatting: the model invents a package at codegen and you copy-paste the install. The Jan 2026
react-codeshifthallucination spread to 237 repos via agent skill files (Aikido). - HalluSquatting: the agent hallucinates a repo, skill, or MCP name at fetch with no human paste. Jul 2026 research reports hallucination rates up to 85% on repos and 100% on skills for trending names; tested agents include Cursor, Copilot, Cline, and Gemini CLI (arXiv, SecurityWeek).
- Dual-namespace collision: two legitimate packages share an unscoped name.
@yagyeshvyas/vibeguardand@indicated/vibeguardare different products (see the VibeGuard disambiguation FAQ). Confusion, not malware.
Run Socket or Snyk on your dependencies for registry lookup, malware signals, and install-time skill gates. Seatbelt reads your src/ artifact on the seven surfaces that hurt launches before you share. It is complementary, not a replacement: Seatbelt does not registry-lookup package names. Many teams run both.
npm audit or CodeRabbit already reviews my PRs. Why Seatbelt?
Respect it. npm audit catches dependency CVEs, not RLS-off migrations, client Stripe keys, or unsigned webhooks. Under agent-heavy PR volume, AI PR reviewers throttle in five different modes (Jul 2026), and none blocks merge on seven-surface artifact read at git push:
- CodeRabbit pass-check: CodeRabbit Pro fair-usage throttle degrades from 5 to as low as 1 review/hour at 60+ reviews in seven days. When rate-limited, it posts a Review rate limited check that passes by design (never blocks merge on protected branches).
- Greptile flex-skip: Greptile Starter Free includes 50 credits/mo. When projected flex spend hits the Flex Usage Limit, Greptile skips reviews that would incur flex usage until the next billing period (silent skip, merge ungated).
- Qodo credit exhaustion: Qodo Pro Team pools credits at $0.012/credit with headline "No rate limits", but reviews stop at zero credits.
- Macroscope spend-cap silence: Macroscope Code Review is $0.05/KB unified diff (10 KB minimum = $0.50/review; large refactor ~$35). Prepaid balance + auto-refill with monthly hard ceiling (cannot override), per-review cap, and per-PR cap. When a cap hits, reviews halt; commits/PRs during the pause are skipped, not retroactively processed. 1000 free Agent credits/mo (Jul 2026).
- Bugbot neutral-on-findings: Cursor Bugbot posts a neutral check by default when findings land (~$1-1.50/run); merge stays ungated unless you wire a custom block.
Probabilistic diff review on merged PRs is not a deterministic seven-surface artifact read at ship moment. Seatbelt reads keys, database rules, auth, payments, customer data cues, and risky shortcuts in founder English, with optional push gate and shareable proof anyone can verify at handoff. Many teams want both.
Git AutoReview already reviews my PRs for ~$15/mo. Why Seatbelt?
Respect it. Git AutoReview Team is a real flat-price PR-review lane: $12.49/mo annual ($149.90/yr) or $14.99/mo monthly for up to 10 members (not per-seat like CodeRabbit), with Free tier 10 AI reviews/day, BYOK, and a human-approval workflow where every AI comment stays a draft until you approve, edit, or reject before it posts to GitHub/GitLab/Bitbucket (Jul 2026). That flat team price and approval-before-publish motion is genuine value for eng teams. Seatbelt is a different moment: a deterministic seven-surface plain-English read of your local artifact at the git push boundary, with optional push gate and a shareable Ship Read link anyone can verify at handoff. Probabilistic diff review on merged PRs is not the same layer as ship-moment proof on what you export. Many teams want both.
My platform's built-in scanner already cleared me. Do I still need Seatbelt?
Respect it. Founders often search lovable security scan, replit security scanner, or vibe coded app security scanner and get a green in-platform result. Every vibe platform ships a real scanner tuned to what breaks most often on that stack. They are not interchangeable. July 2026 research pins a platform-skew pattern: each native scanner over-indexes on its home failure mode and under-checks the rest.
| Platform | What the built-in scanner emphasizes |
|---|---|
| Claude Code / Cursor agents | Missing auth rate limits (~80% of AI-built apps per vibe-eval pattern #10, Jul 2026; onout primary shows clean bcrypt/JWT login POST with zero throttling) |
| Lovable | Basic scan (fast config and dependency checks) vs Deep scan (on-demand agentic review; Lovable security docs, Aug 2026: does not run automatically as you work). Row-level security gaps, publish versus editor-private confusion, opt-in publish blocks (off by default, in-platform only), in-chat auto-fix (opt-in, credit-priced) and security memory |
| Replit | Always scans before publish; opt-in Block publishing of critical vulnerabilities (Deploy → Advanced, off by default; dismissed findings unblock publish; Replit Project Security Center, Jul 2026). Security Agent grades in-platform only |
| Bolt | Exposed keys in bundle and export paths, plus access control, cross-origin callers, and unverified input reaching the database. Opt-in from the Publish menu, full audit on paid plans, no deploy block |
| v0 / Vercel | Server actions and NEXT_PUBLIC_ misuse (default deploy block on the v0 lane; Vercel blog, August 2025) |
Each native scanner optimizes in-platform. None reads all seven surfaces at git handoff, gates cross-platform export from Cursor or GitHub sync, or returns shareable proof anyone can verify at handoff. For Lovable auto-fix and Deep scan limits, see the Lovable auto-fix FAQ. For Replit publish-scan limits, see the Replit scanner FAQ. Seatbelt gates your push wherever you build and returns the shareable Ship Read at freelancer handoff. See a repo sample report for ship-moment proof.
Lovable already auto-fixes security findings in chat. Do I still need Seatbelt?
Respect it. Lovable documents Basic scan (fast config and dependency checks) and Deep scan (on-demand agentic review; Lovable security docs, Aug 2026: does not run automatically as you work). Opt-in auto-fix during agent chat (Jul 2026) lets eligible Basic-scan error-level findings flow into chat context and the agent can patch in-platform. That motion consumes credits and does not apply to Deep scan. Lovable also ships security memory: dismiss, accept, and context edits persist so the scanner and coding agent stop re-flagging what you already judged. In Security view, Try to fix all on your current deep-scan filter is free; chat auto-fix consumes credits (Lovable security-view, Jul 2026). If Try to fix all is greyed out, Lovable usually means your Deep scan results are stale or out of date, not that you are cleared or that Lovable will not help. Security view requires Deep scan results to be up to date before remediation runs. Lovable's own docs also say that No issues found means the latest scan did not surface findings, but it does not guarantee the project has no security risk. A Basic-only green state can still miss code-level issues Deep scan covers. Real in-platform remediation. It still lives inside Lovable: no cross-platform git push gate, no seven-surface artifact read at handoff, no shareable Ship Read link anyone can verify when you export to Cursor or clone GitHub. Seatbelt reads the synced repo at the push boundary with proof you can forward.
Replit's publish scan cleared me. Do I still need Seatbelt?
Replit always runs a security scan before you publish. Respect it. Founders searching replit security scan or replit security scanner often land on that pre-publish check. Opt-in Block publishing of critical vulnerabilities (Deploy → Advanced, off by default) blocks on critical severity until you resolve or dismiss; dismissed findings unblock publish (Replit docs, Jul 2026). Security Agent grades in-platform only. No shareable plain-English cleared-report link at handoff. Sync to private GitHub, clone, and path-scan the checkout (never a Repl URL). That export path is still ungated. Seatbelt reads the artifact at the push boundary with proof you can forward.
Base44's Security tab already scans my app. Do I still need Seatbelt?
Base44's Security tab runs on all plans, including free: data permission gaps, exposed credentials, login gaps, package vulns, and security headers, with one-click Fix. The scan is manual (Run Security Scan in Dashboard → Security), not automatic on deploy, and it does not block publish. Ignore moves an issue to Ignored and it will not reappear on the next scan, so a green rescan can read false-clean after you dismissed a real gap. Base44's own application-security guide prescribes SafeVibes as step 1 of an external URL loop before the in-platform check. SafeVibes is their endorsed outside view; Seatbelt is cross-platform ship read plus shareable proof link anyone can verify when you export or clone and push from Cursor.
I ran Sable / a pre-launch security scan before launch. Why Seatbelt?
Respect it. Sable / SableOffensive (Jul 2026) ships a real pre-launch lane on two motions. Primary: credit-based agent pentest console with 150 free credits, five specialists (pen-scout through pen-compliance), credit packs from $9, and fixed-scope Pre-Launch $29 (promo from $39) through Scale Secure $199, plus monitoring $49 to $399/mo. Legacy: sable/agent scan in terminal (~60s headers) and the five-minute curl audit blog (API routes, cross-user access, headers, Supabase table probe). That automates curl recipes and sells a vendor pentest report or signed PDF before PH/HN. Distinct from VibeDoctor subscription Launch Audit and shipcheck-cli launch-readiness SARIF. Seatbelt is a different moment: seven surfaces in plain English on your local artifact at the git push boundary, optional deny hooks, and a shareable Ship Read link at /r/:id anyone can verify at handoff without trusting your scan vendor or a PDF only you have seen. Many teams want the pre-launch pentest and the push-boundary proof. See a repo sample report for ship-moment proof.