Point Sentrint at the repo behind the app you built with Claude, Gemini or any of the 14 LLM platforms it supports. Its security engine reads every line for four things: hardcoded secrets, database access rules, dependencies and code paths. An AI layer then drops the results that are not really exploitable and writes the fix. Back comes a score out of 100 with a grade, every finding written in plain English, and a fix prompt rewritten for whichever of those platforms built the app. Paste the fix, scan again, and the grade climbs.
Built with Bolt, v0 or Cursor? You can't read every line it wrote. We scan for what's actually leaking (an open database, a live key, an unlocked admin page) and hand you a fix prompt for the same tool that wrote the bug.
Free · no card · code scans in ephemeral instance
D 29/100 on a real repo we scanned. 8 critical, 12 findings in all.
Every screenshot below is one real scan
A real scan of a real public repo, shown exactly as you would get it. The repo name, the paths and every key are starred out. Publishing a stranger's live credentials is not ours to do. Your own report names every file and every line.
A grade, the flaws, the fix.
And proof you fixed it.
01
The ledger. Every repo you own, as one number.
One score across everything you have scanned, what is still open, and what moved since last time. The point of scanning twice is the second number.
- Fixed versus new, every scan. The tile that tells you whether the work worked.
- A score with a trend, not a snapshot you have to remember to compare.
- Findings split by type, so leaked secrets and an old lockfile stop competing for the same attention.
- Only the repos you pointed us at. Nothing else appears here.
Security ledger · every repo, one score
02
The verdict. One number, and what it is made of.
A grade out of 100, split into the code you wrote and the packages you pulled in. No wall of CVE identifiers to triage before you know whether anything is actually wrong.
- Severity you can act on, counted separately, worst first.
- Code and dependencies graded apart, because a bad lockfile and a leaked key are not the same problem.
- The arithmetic is shown, so the score is checkable rather than asserted.
Report header · real scan, identity redacted
03
The findings. In English, not in CVE numbers.
What it is, where it lives, and what happens if somebody finds it first.
- Databases anyone can read, the usual way these apps leak.
- Leaked keys that still work. We test them, so you know which to rotate first.
- Pages with no lock, admin and billing, reachable by guessing.
- Code that trusts strangers, where a form field runs as code.
- Secrets in old commits. Deleting the file did not delete the key.
- Outdated packages with known holes already published in them.
- Server keys in the browser, shipped in what every visitor downloads.
- Doors left wide open, CORS and API settings that let any site call yours.
Each one is read a second time by an AI that says whether it is really exploitable, and why. When it downgrades one, it tells you what it decided and leaves the finding on the page.
Findings, critical group open
04
The fix. A prompt, not a to-do list.
Not a checklist to work through by hand. One prompt, ordered worst first, ready to paste back into whichever platform built the app.
- Rewritten per platform, for Claude, Cursor, Lovable, ChatGPT, Gemini and 14 in all.
- Says what an AI cannot do for you, because rotating a leaked key is your job, not the model's.
- Ordered by what is exploitable now, not by what is easiest to patch.
- Counts the leaked keys separately, because rotating one is a job no model can do for you.
Fix prompt · copy, paste, rescan
05
The badge. Earned, and impossible to fake.
Earned at grade C and up. It reads the live grade every time somebody loads your README, so it cannot go stale and it cannot be faked by pasting an image.
- Markdown and HTML embeds, ready for a README or a landing page.
- Live, not a snapshot. Let the grade slip and the badge says so.
Badge embed
You're handing us your code.
Here's what happens to it. And what you can take back.
From the founder
With experience in shipping production software, training ML models, and working in cybersecurity, Sentrint is the outcome. This combination of experience is the product: the security side decides what counts as a finding, and the ML side writes the fix you paste back in. We enforce all the rules below in the code very strictly. These are not just promises on a page.
Gourab · Sentrint
01
Read-only, on the repo you pick
No pushes, no pull requests, no reading repos you didn't choose. The scan only ever looks.
02
Scanned in isolation
Your code is cloned into a sealed, single-use job that exists just for your scan.
03
Wiped when the scan ends
No copy kept, no backups, nothing trained on it. The findings stay; the code is gone.
04
Secrets are never shown in full
A finding tells you where a leaked key lives. It never prints the key. A report shouldn't be a second leak.
05
Export or erase it yourself
Every record we hold, downloadable or deletable from Settings. No email, no waiting.
06
Rights with a name on them
DPDP data rights for every customer, wherever you are. A named person answers within 2-3 business days.
What a scan reads, and what we keep
Find out what your app is leaking.
Free to start. No card needed.