What it looks for
- OpenAI, Anthropic, Google (Gemini, Maps), Groq, xAI, Replicate, Hugging Face tokens
- Stripe or Clerk secret and publishable keys, Stripe restricted keys, and Stripe or Clerk webhook signing secrets
- Supabase service role keys (legacy JWT with role service_role) and new sb_secret_ keys
- AWS access key IDs and secret keys, GitHub and GitLab tokens, Slack tokens and webhooks
- Twilio, SendGrid, Resend, Discord webhooks, private key blocks, and database URLs with a password
- Generic secret assignments, such as SECRET=, TOKEN=, or PASSWORD= with a long value
Publishable values like a Stripe pk_ key, a Supabase anon key, or a Firebase web config are reported as safe to ship, so you can tell them apart from real secrets. See anon key vs service role key.
If it finds a live secret
Rotate the key at the provider first, then remove it from code and git history. Deleting the line is not enough once it was pushed or deployed. Follow the first hour after an API key leaks and check your GitHub history.
A token in a committed .cursor/mcp.json or .mcp.json counts too. The MCP server security guide shows how to reference environment variables instead, and how to scope those tokens.
Limits
The repo scan reads the current branch only, not old commits, and stops at 150 files. Pattern matching misses keys with no fixed format and can flag test values. A clean result is not proof that a project is safe: a missing auth check, like an admin page guarded only in the browser, never shows up in a key scan (client-side auth is not security). For private repos and full history, run Gitleaks or TruffleHog on your own machine or in CI.
New checks and guides go out in the VibeLocked newsletter every week.