AI wrote your app.
Kelp finds the doors it left open.
Open-source security scanner for vibe-coded apps. Hardcoded secrets, permissive Supabase RLS, unauthenticated edge functions — Kelp probes the way an attacker would and hands you the fix, ready to paste back into whatever AI tool built the app.
An excerpt from an actual dispatch. Nothing invented, nothing dramatised.
Four specialists probe in parallel.
A reviewer keeps the honest ones.
Every finding is evidence-gated: Kelp’s reviewer re-runs the reproduction before it lands in your report. Nothing invented, nothing hand-waved. Hover a specialist to see its beat.
Small on purpose. Every finding is real.
Kelp covers the classes that actually breach vibe-coded apps, and it ships evidence for each. Everything else is honestly out of scope — see docs/SECURITY-MODEL.md for what Kelp explicitly won't verify.
Hardcoded secrets in source.
Service-role keys, Stripe secrets, and OpenAI tokens committed to the repo — including those bundled to the client. Kelp finds them with provider patterns plus entropy fallback, and never persists the raw value: only a masked preview reaches your report.
Row-Level Security, checked policy-by-policy.
Kelp reads your Supabase schema and finds the tables and columns anyone can read or write. The reviewer re-runs the check before it lands — if it doesn't reproduce, it doesn't ship.
Edge functions that skip the JWT.
verify_jwt=false in supabase/config.toml, unauthenticated replays, permissive CORS. Every finding comes with the exact curl the executor ran and the response it got.
One engine. Three surfaces. Pick what fits.
The detection engine is the same everywhere. Run it locally with the CLI, gate PRs with the GitHub Action, or connect a repo to the hosted app for continuous scanning. None of them require a Kelp account by default.
CLI — for local + CI shells
One command, no signup, no keys. Uses the same @kelp/core scanners as everything else.
$ npx kelp scan ./my-appGitHub Action — for pull-request gating
Fails the check when a PR introduces new critical or high findings against the base branch. Auto-comments the verdict, updated in place on each commit.
$ uses: kelp-security/kelp-action@v1Hosted app — for continuous scanning
Connect a repo once, get scans on every push, dashboards, agent chat per finding, and one-click fix PRs. Optional — the CLI and Action need nothing.
$ kelp.buildKelp's model never decides a finding is real.
Every agent-produced lead requires a reproduction — a probe with an expected observable, or a source citation. The executor re-runs it. Only findings that survive the re-run reach your report. Autonomy in reasoning, zero fabrication.
Agents reason, the executor proves.
Specialists form hypotheses freely; the executor accepts them only when the exploit reproduces against your actual endpoints, with real user context.
The reviewer only narrows.
A second pass reads each specialist's transcript, spawns targeted follow-ups, and drops the leads that don't reproduce. It never adds noise.
Full transcript per finding.
Every finding ships with the reasoning, the probe, and the response — the receipt for exactly how Kelp knows. Read the full principle in docs/EVIDENCE-GATING.md.
What people ask before they run Kelp.
Is Kelp actually free?
The engine, CLI, and GitHub Action are MIT-licensed and free to use forever — for any purpose, including commercial. The hosted app at kelp.build runs on infrastructure that costs money, so it may add a paid tier for high-usage workflows later, but the code itself stays open.
Do I need to sign up for anything?
No. `npx kelp scan ./my-app` works with zero configuration. `uses: kelp-security/kelp-action@v1` runs in CI without any Kelp-side account. Signup only matters if you want the hosted app's continuous scanning + history.
Does Kelp change my code without asking?
Never. Fixes are opened as PRs against a fresh kelp/… branch, never pushed to your default branch. Database fixes are proposed as migrations you review and run yourself. The CLI never touches your code at all — it only reads.
Does Kelp claim to find every vulnerability?
No. Kelp covers a small set of high-impact classes (secrets, RLS, edge-function auth, CORS) with high precision — the ones that actually breach AI-generated apps. Real fixes for those beats a forty-page report of maybes. See docs/SECURITY-MODEL.md for what's explicitly out of scope.
How do I extend Kelp — new secret pattern, new backend?
Open a PR against packages/core/src/scanners/ for a new pattern, or read docs/ADAPTERS.md for adding a whole new backend (Firebase, Convex, etc.). CONTRIBUTING.md has the full walkthrough.
Scan your app before your users do.
Two minutes with the CLI. Six lines of YAML for the Action. Kelp is MIT-licensed — clone it, fork it, or send a PR to add the vuln class you wish it caught.