Block cross-tenant data leaks
before they reach main.
An org-scoped query with no org filter is the single most common SaaS breach — and AI writes it constantly, because the happy-path test still passes. SlopGrade catches the missing .eq(org_id) in CI, on every pull request, before the merge — deterministic, and only a {file · line · kind} fingerprint leaves your runner.
One missing filter, and tenant A reads tenant B's data.
The query returns rows scoped by id but never by org_id. Every test passes — the seed data has one org. In production, any authenticated user can read any tenant's invoices by changing an id. AI writes this constantly; a human reviewer skims past it. The gate doesn't.
What the AI shipped
What leaves your runner
Path, line, class. The file content never leaves. Audit it with --print-payload.
Detect → adapt → verify. Nothing else leaves.
In your runner, on the diff
The open-source client walks the pull request, resolves each org-scoped table access, and flags any query that reads by id without an org predicate — intra-function dataflow, no code leaves the machine.
Server verdict + gate
The fingerprint is classified server-side. A hard leak blocks the check on a paid private repo; public repos are gated free. The paywall fails open — never a build broken by mistake.
Fix computed in the runner
The finding is posted inline on line 44. The auto-fix — adding the missing org filter — is generated and verified locally: it's only offered once a re-scan proves the leak is gone.
Most scanners ingest your source. This one never does.
Block leaks on private repos. Per repo, never per seat.
Unlimited users. The per-repo price drops with volume. Advisory is free forever, and the blocking gate is free on public repos. Free 14-day trial — no card.
Public repos are gated free, forever. Blocking private repos starts at $11/repo/mo · 14-day trial, no card.
Ready to block the next tenant-isolation leak before merge?
Add it to one workflow file. The first AI pull request you scan will tell you what it was about to let through.
Cross-tenant leaks — the questions a security team asks.
What is a cross-tenant data leak?
In a multi-tenant SaaS, every row belongs to an organization. A cross-tenant leak is a query that filters by a record id but not by the caller's org — so an authenticated user of tenant A can read tenant B's data by changing an id. It's also called BOLA / IDOR (CWE-639) and is the most common serious SaaS vulnerability.
Why do tests miss it?
Because the happy-path test seeds a single org, so the missing org filter still returns the "right" row. The bug only appears with real multi-tenant data in production. A deterministic CI gate that reads the query shape catches it before it ever ships.
Does my source code leave the runner?
No. The client reads files locally and posts only a structural fingerprint — file paths plus {file, line, kind}. Run --print-payload to audit the exact bytes sent. The file content never leaves your CI.
Will it break my build with false positives?
Start in advisory mode — see every finding, block nothing — then switch to gate when you trust it. Calibrated to 0 false positives on 5,000+ real repos, and fail-open by default: an outage never breaks a build.
Which languages and frameworks?
JavaScript/TypeScript and Python today (Go and .NET cover the core subset), across common query builders and ORMs. The cross-tenant gate is one of the 10 free classes in the open-source client.