Start here

What this is

This is the Sentrint wiki. It explains what we check for, why those checks matter, and what to do with a report once you have one. You can read all of it without signing in. Nothing here is a sales pitch. It is the reference we wish existed when we watched app after app ship with the same holes.

Sentrint is an automated security check for apps built with tools like Lovable, Bolt, Cursor or v0. You sign in with GitHub, pick a repo, and the security engine reads the code and hands back a report: a score, a letter grade, findings sorted by how bad they are, and a fix prompt you can paste straight back into the tool that wrote the problem.

Two kinds of people land here, and they need different things first. One person built an app with a tool and has never read the code. The other can read the code and wants to know how the engine decides. The same wiki serves both, but the reading order is different. Pick the track that sounds like you.

I built my app with AI or no-code

You described what you wanted, a tool wrote the code, and it works. You have never read most of that code and you should not have to. The catch is that "it works" and "it is safe" are two different tests, and the tools optimize for the first one. That is the whole reason a security check exists.

Start with Why Sentrint exists. It lays out the pattern we keep seeing: a small set of the same serious holes, again and again, in apps built this way.

Then read Security for AI-built apps. It walks through the specific mistakes these tools tend to leave behind, in plain language, with what each one actually lets an attacker do.

When you have a report in front of you, The fix prompt explains the copy-paste instruction we generate. It is written for your AI builder, one small change at a time, so you can apply fixes without reading the code yourself.

If a word in a report is unfamiliar, FAQ and glossary has a plain-English table at the bottom. It also answers the questions people usually ask before running the first scan: what it costs, whether we keep the code, what it actually checks.

You do not need to read these in order or read all of them. Run a scan, and when a finding raises a question, come back and read the page that covers it.

I'm technical

You can read the code. What you want to know is what the engine looks for, how it decides, and whether it is going to bury you in noise.

Start with The security engine. It covers how a scan runs, the rule families it checks, and why the report groups findings by severity.

For developers goes into the parts you care about: what the scan reads, what it does not touch, and how rescans confirm a fix.

Common vulnerabilities is the reference list of the rule families, with the real-world impact of each. It covers leaked secrets, missing authentication, open CORS, injection and cross-site scripting, mass assignment, disabled row-level security, and vulnerable dependencies, among others. It is useful whether or not you ever run a scan.

What everyone should read

Your code and your data is the trust page. Your source code is never stored. It is read inside a single scan job and discarded when that job exits. That page spells out exactly what is kept, for how long, and the rights you have over it. If you are handing us read access to your repo, read that one.

Start free

You do not need to read any of this before you try it. Sign in with GitHub and run a scan free, one a month, no card needed. See for yourself what your app is leaking: start a scan.