Keybrum, from the first attack to every deploy.

Your first attack

1. Paste your app's address. Keybrum loads it like a visitor and tells you what any browser already sees: the builder, the backend, how many secret keys are readable. Nothing is attacked yet.
2. Unlock the attack: a one-time report for one app, or a plan that covers several apps and attacks every deploy again (see pricing).
3. Prove you own the app (below). It takes about two minutes, once per app.
4. Start the attack and watch it live. A full run takes about a minute and tries every attack in the library (112 kinds today) on each table, bucket, route and key it finds: with no account first, then as a brand-new account.

The report opens on the worst thing a stranger can do. Every finding has the proof, a command to replay it, and the fix.

Proving ownership

Pick whichever is easiest for your host. Your token is shown when you add the app, with copy buttons.

Tags, DNS records and files are checked again every 30 days. If the proof is gone, attacks pause until you put it back.

Reading a report

• Findings are ranked by what they expose. Each is one sentence about what a stranger can do, and says who can do it: anyone, or any signed-up user.
• Proof shows the request and the answer, with personal data redacted, and a command to replay it.
• Is it meant to be public? Tables that look public by design (reviews, products) are listed apart. Say no, and the next attack reports them as findings if strangers can still read them.
• Marked as intended removes a finding from the open list with your reason. You can reopen it.
• Not tested lists what the run could not try, and why. A clean run reads “none of the N attacks worked on this date”, never “secure”.

A finding closes only when the same attack fails on the live app. A leaked key closes only when it is gone from the code and no longer works.

Signed-in tests

Many leaks only show to signed-in users, such as “any user can read every booking”.

• Supabase and Firebase: when sign-up is open, Keybrum creates one throwaway account and reuses it. Confirmation emails are handled.
• Your own backend: a sandboxed browser finds the email sign-up or login form, handles confirmation links and email codes, and keeps only the first-party cookie or Authorization header. CAPTCHA, social-only login, passkeys and SMS codes are not bypassed; the report lists them as not tested.
• Closed sign-up: give Keybrum an ordinary (not admin) account in the app's Settings tab. It is stored encrypted.

Fix with your agent (MCP)

Every finding has a fix prompt for Lovable, Bolt, Cursor and Claude Code. With the MCP server, your agent reads the findings itself, applies the fix, and retests until the attack fails. Create an API key in Settings, then:

Claude Code

claude mcp add --transport http keybrum https://keybrum.com/api/mcp \
  --header "Authorization: Bearer kbk_…"

Cursor

In .cursor/mcp.json:

{
  "mcpServers": {
    "keybrum": {
      "url": "https://keybrum.com/api/mcp",
      "headers": {
        "Authorization": "Bearer kbk_…"
      }
    }
  }
}

Tools

A prompt that works

Use the keybrum MCP tools to list the open findings on my app, fix the most
severe one, deploy or apply the migration, and call retest_finding until it
says FIXED. Never disable Row Level Security to make a test pass.

Audit your code with your agent

Keybrum attacks the deployed app from the outside. To look at the code itself, your coding agent runs Cloudflare's open-source security-audit skill (MIT) on your machine, through the MCP server: it maps the code, hunts each class of weakness with separate agents, and has every candidate checked by an agent that tries to disprove it. Your code never reaches Keybrum; only the final records do.

1. Connect the MCP server as above.
2. In the app's repository, ask: “Run Keybrum's source audit on my app: call start_source_audit, follow it, then send the results with submit_source_findings.”
3. The records appear in the app's Code audit page. Each one the live attack also proves is linked to its live finding; the next full run tries to prove the others from outside.

A full audit takes a while and uses your agent's own model. Run it again after big changes: repeat audits update the same records.

Attack every deploy

On paid plans, each app has a deploy hook on its Deploy checks tab. Point your host's deployment webhook at it, and every successful deploy, previews included, is attacked again. You are alerted only when a new exposure is proven, or a fixed one comes back.

• Vercel: Team settings, Webhooks, event Deployment Succeeded.
• Netlify: Site configuration, Notifications, Deploy notifications, HTTP POST on Deploy succeeded.
• GitHub: Repository settings, Webhooks, content type application/json, event Deployment statuses.
• Lovable and Bolt don't send deploy events yet: keep the weekly retest on, or connect the GitHub repository they sync to.
• Anything else:

curl -X POST https://keybrum.com/api/hooks/deploy/HOOK_TOKEN \
  -H 'content-type: application/json' \
  -d '{"url":"https://your-deploy-url","commit":"abc123","environment":"preview"}'

Keybrum attacks a deploy only when it can tell the deploy is yours: the app's own address, any subdomain of your domain if you proved ownership with a DNS record, or any other address (a preview on *.vercel.app, *.netlify.app, *.lovable.app, *.lovableproject.com and the like) that carries the app's verification tag or file. Previews built from the same code carry them, so keep the tag or the file in your code.

CI check

Fail a pipeline when a deploy brings a new finding at or above the level set on the app's Deploy checks tab (high by default). Existing open findings never fail the check.

curl -fsS -X POST https://keybrum.com/api/ci/check \
  -H "Authorization: Bearer $KEYBRUM_KEY" \
  -H "content-type: application/json" \
  -d '{"app":"your-app","url":"https://preview-url","commit":"'$GITHUB_SHA'"}'

app is the app's name, id or trust page slug, and can be left out when the workspace has one app. url defaults to the app's address. The call waits for the attack (up to about 5 minutes) and answers:

A ready-made GitHub Action, with your app filled in, is on each app's Deploy checks tab.

Trust page and badge

On paid plans, each app can publish a trust page at https://keybrum.com/trust/your-app: when it was last attacked, how many attacks ran, how many findings are open and how fast fixes land. It never says what is vulnerable. The badge and a printable report (save it as PDF from the browser) come with it. Team and Business put your brand on all three.

Help

Use the contact page or write to [email protected]. For a vulnerability in Keybrum itself, see reporting a vulnerability.