Every gate, shown.
In 2025, security researchers found more than 170 apps built on vibe-coding platforms leaking customer data. There was no sophisticated attack. The tables holding the data had no access rules at all.
CVE-2025-48757. A missing or overly permissive row-level-security policy let an anonymous request read other customers' records. It is the single most common way an AI-generated app leaks, and it is what the rls and rls-enforce gates below exist to catch.
The model never grades its own work.
The model writes the code and has no say in whether it ships. That decision belongs to twelve deterministic checks, run in a fixed order on every build. They fail closed: a gate that fails, or crashes mid-run, ends the run with the same verdict — BLOCK. There is no override.
The verdict board, as the dashboard shows it mid-build.
The code, read for attack patterns
Static analysis of every line of authored source — semgrep at a pinned version, with a purpose-built SQL-injection rule on top of the standard ruleset. Injection sinks and other dangerous constructs block the build.
No committed credentials
A scan of the whole build for committed credentials — API keys, tokens, connection strings, passwords (gitleaks, pinned version). Any one found blocks; there is no severity threshold.
Dependencies against the CVE record
Every dependency in the lockfile is checked against the public CVE record (trivy, pinned version). Known vulnerabilities block. If the scanner itself cannot run, the gate blocks on its own — a missing scan never passes.
Every table has an access policy
Modeled on CVE-2025-48757. Every table a migration creates must carry row-level security and a policy with real conditions, and every table the app queries must be covered by one. A table without a policy blocks.
Migrations run for real
The build's database migrations are executed against a real embedded Postgres, with no LLM in the loop. SQL that would fail on deploy day fails here, with the exact file and the exact database error in the findings.
The live two-tenant attack
The gate stands up a live database, applies the build's migrations, seeds two tenants, and tries to reach one tenant's rows from the other's session and from an anonymous one. A single leaked row blocks. The full walkthrough is below.
Controls to match the data
Reads the sensitivity classification from your intake interview and checks for the controls that class of data requires — authentication in front of it, a working hard-delete path. The classification is verified independently: declare no sensitive data while the schema stores diagnoses, and the mismatch blocks.
Personal data out of logs and URLs
Personal data has two common ways out: written into logs, which routinely ship to third parties, and carried in URLs, which every server along the way records. This gate traces both. console.log("email sent") passes; console.log(user.email) blocks.
Operational hygiene
The basics that break real handoffs: unpinned dependency ranges, a missing README, containers running as root, base images not pinned by digest, type-checking turned off. These block at production rigor and warn at prototype — the standard follows what the spec declared.
Acceptance criteria, run as tests
Each acceptance criterion in the spec is generated into a property test and run against the app over a full range of inputs, from a fixed seed so the result is deterministic. A fix round that breaks a criterion the app previously satisfied blocks, with the requirement named. The tests are read-only for fixes — one that has been skipped or neutered is itself a blocking finding.
Built clean and booted
The app is copied to a clean directory, built from scratch, and booted several times; every run has to come up healthy. A build that reports success without producing artifacts also blocks.
Everything promised is present
The code is held against the spec's feature list, one feature at a time. A promised feature that is missing blocks the release, and the next fix round generates it. If the reviewer itself fails to run, that blocks too.
The signed sentinel
When all twelve gates pass — with at least one doing substantive work, since twelve "not applicable" verdicts do not count — a cryptographically signed sentinel is written, bound to that exact build in that exact directory. The deploy will not run without it, a copy will not validate anywhere else, and it is deleted the moment a later run fails.
Why it attacks a real database.
Access-control code can look correct and still leak — a typo in a condition, a policy that checks the wrong column, a table nobody covered. Reading that code and concluding it is fine is how CVE-2025-48757 happened; the code looked fine to the people who shipped it, too.
So the rls-enforce gate runs the attack itself. It stands up a real Postgres database, applies the exact migrations the build produced, and seeds two separate tenants with real rows. Signed in as tenant A, and again as an anonymous session, it attempts to read, update, delete, and insert tenant B's data across every table the spec marked as isolated. If a single row comes back, the build is held. If the attack harness itself errors, the build is held.
Both attempts, on every build. A single returned row holds the release.
Receipts, not badges.
You will not find a compliance badge on this site. The compliance gate is forbidden, by written policy, from claiming any certification — it checks controls, and "helps toward" is the strongest thing it will ever say. What you get is the verdict board: every gate's result on your build, every finding in plain English, and the signed sentinel tied to the exact code that shipped. If a claim on this page ever drifts from what the gates actually do, the gates win.
- fail-closed everywhere — a crashed gate is a BLOCK
- no LLM has authority over a deploy verdict
- anti-tamper — a fix round cannot weaken the check it answers
- tenant isolation proven by live attack, on every build
- a held build never ships, and there is no switch to make it
Put a build through it.
Describe the app you need in plain language. Every build, on every plan, runs the full line.