Use cases
Different starting points.
Same evidence.
Whether you are about to launch, inheriting someone else's code, or shipping every day, Sentrail runs the same seven checks and reports the same four verdicts.
Scenarios
What are the common Sentrail use cases?
Common Sentrail use cases include pre-launch security audits, monitoring AI-generated code, assessing inherited legacy codebases, and integrating directly into coding agents for continuous inline checks.
The app works. Nobody has checked whether the data is closed.
An LLM helped build the schema and the auth flow. It runs, the demo is convincing, and no one has looked at whether Row Level Security is actually on for every table the anon key can reach.
- Runs the RLS check across every non-system table and reports tables with RLS off, plus tables with RLS on and zero policies.
- Pulls Supabase's own advisor lints so exposed views and unsafe function search paths surface too.
- Returns a launch verdict, and says insufficient evidence rather than ready when a required check has not run.
"Ready" certifies required connectors are active, every required check has evidence from the last 24h (default), and there are zero open critical/high findings across code, database, Supabase advisors, dependencies, and deployment posture. It does not include the deep Semgrep/Gitleaks/OSV scanner, DAST-lite, the LLM-wiring audit, or a human review — those are separate, optional checks.
Constant across all of them
Three rules that never change.
Read first
Audits read your database, repositories and deployments. Nothing is written as part of a scan.
Approval gated
Fixes are proposals. A human on your side approves before anything is applied or opened.
Draft PRs only
Repository changes arrive as draft pull requests on their own branch. Sentrail never merges.
Get started
Start with the verdict you can defend.
Connect your stack, run the audit, and see which checks have evidence behind them.