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.

Read in this order:

1. Why Sentrint exists lays out the pattern we keep seeing: a small set of the same serious holes, again and again, in vibe-coded apps.
2. Security for AI-built apps walks through the specific mistakes these tools leave behind, in plain language, with what each one actually lets an attacker do.
3. The fix prompt explains the copy-paste instruction we generate once you have a report in front of you. It is written for your AI builder, one small change at a time, so you can apply fixes without reading the code.
4. FAQ and glossary has a plain-English table of every term a report uses, and answers what people ask before their first scan: what it costs, whether we keep the code, what it actually checks.

You do not have to read them in order, or read all of them. Run a scan, and when a finding raises a question, come back to 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.

1. Inside the security engine covers the static analysis pass, the rule families it runs across code, config and dependency manifests, and the AI review layer that filters what they catch.
2. Sentrint for developers goes into the severity model, the fix-and-rescan workflow, and where a code scan stops being useful.
3. Common vulnerabilities is the reference list: leaked secrets, missing authentication, open CORS, injection and cross-site scripting, mass assignment, Supabase tables with Row Level Security disabled, and vulnerable dependencies, among others. 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.