Scan a repo

Docs

Audit AI is built for one job: prove whether an AI-generated Next.js + Supabase app lets one customer read or change another customer's data, then fix it and prove the fix. This page is the map — what gets checked, the three ways to run it, what the statuses mean, and where the honest limits are.

What it checks

Version 0 goes deep on one vulnerability class instead of wide on ten: broken object-level authorization and tenant isolation in Next.js (App Router) + Supabase apps, in TypeScript. That is where AI coding tools — Lovable, Bolt, v0, Cursor, Claude Code — consistently leak. Concretely, the rule pack looks for:

  • Service-role key reaching the browser bundle
  • Object access by id (IDOR/BOLA) with no tenant or owner scope, across route handlers, server actions, Drizzle and Prisma
  • Tenant id taken from the request instead of the session
  • Privileged routes or server actions with no caller authentication
  • Whole request bodies written to a table with no allow-list (mass assignment)
  • Roles or permissions read from user-editable metadata
  • Tables reachable by the anon key with Row Level Security disabled
  • RLS policies that grant rows without tying them to the caller

Full list with vulnerable/fix snippets, severity and CWE →

Every result carries an honest coverage line instead of a pass/fail score, for example:

Checked 12 risks in class authorization/RLS. Verified: 2. Confirmed (no sandbox): 1. Unverified: 0.

What it doesn't

  • It never claims "no vulnerabilities". Coverage is always shown next to the result; silence about a risk class means it wasn't checked, not that it's safe.
  • One stack, deep rather than wide: Next.js + TypeScript, with Supabase clients, Drizzle or Prisma on Postgres. No Python, Java, Go, C#, mobile, Kubernetes security, CSPM, or general dependency/secrets scanning.
  • The free scanner (npx auditai-scan) never calls a model and never reaches the network — it only ever reports likely. Turning a finding into confirmed or verified needs reasoning and sandbox verification, described below.
  • The GitHub Check runs the deterministic scan only — no model, no sandbox, serverless time limits (see /docs/security). Repositories without supabase/migrations at the root lose every RLS-aware rule; the summary says so.
  • Sandbox verification in v0 covers one scenario shape: a cross-tenant read reproduced with two synthetic tenants. See /docs/verification for exactly what "verified" requires and what it doesn't cover yet.

Three ways to run it

Paste a repo on auditai.sh

Zero install. Works on any public GitHub repository. Runs the deterministic scan on our servers and gives you a report page.

Go to auditai.sh
Paste github.com/owner/repo
Read the report at /r/<id>

CLI, open source

Local, deterministic, no account, no model, no network call. Good for CI.

npx auditai-scan .
Reads findings + coverage line
Exit code for CI gating

GitHub App

A Check on every pull request, with annotations on the exact lines that triggered a rule.

Install github.com/apps/auditai-sh
Pick a repository
Open a PR, watch the Audit AI check

MCP, in your own agent

Claude Code or Cursor calls the tools directly. Full setup on the MCP page.

claude mcp add auditai -- auditai-mcp
"scan this repo and explain AUDIT-001"
See /docs/mcp

The web scan and the GitHub App never touch anything beyond a deterministic scan by themselves; MCP hands reasoning to your own agent. Details for each: /docs/security.

What the statuses mean

  • candidate

    A rule fired. Not yet reviewed for false positives.

  • likely

    The deterministic pass found nothing that contradicts the rule. Default output of the free scanner.

  • confirmed

    A reasoning pass (model or your own coding agent) looked at the evidence and agrees it's real.

  • unverified

    Reviewed but not reproduced — sandbox verification wasn't run, or couldn't reach a verdict.

  • fix_proposed

    A minimal patch and a regression test exist as a diff. Nothing has been applied to your repo.

  • fix_applied

    The patch was applied (only ever with explicit confirmation, never automatically).

  • verified

    Proved end to end in the sandbox: see /docs/verification for exactly what that requires.

  • suppressed

    Ignored on purpose, with a reason: // auditai:ignore <rule> -- reason in the code.

likely never silently becomes confirmed: that transition needs evidence, either a reasoning pass or your own agent's verdict through MCP. Full protocol: /docs/verification.

Honest limits. No tool proves an app has zero vulnerabilities, and Audit AI will not pretend otherwise. If you want the specifics — what data leaves your machine in each mode, how the sandbox is isolated, and where the MCP server can and can't reach — see /docs/security.