know it’s safe to ship.
Audit is five checks that run before your code merges - on your data policies, your secrets, your dependencies, your licences and your overall readiness to ship. You don’t run them. Your AI editor calls them as part of shipping, every time, which is the only way a check gets run reliably. Audit is where Fizzgig started, and it’s still the pillar that stops the worst days from happening.
ai-written code fails in a particular way.
It isn’t that agent-written code is bad. It’s that when it’s wrong, it’s wrong plausibly. A hand-written security policy that’s broken usually looks broken. A generated one looks exactly like a working policy, because it was written by something that has read thousands of working policies. It has the right shape. It just doesn’t do what you assumed.
That’s a hard failure mode to catch by reading, and reading is the only thing standing between it and production if nothing else is checking. Meanwhile the volume has gone up - you’re shipping in an afternoon what used to take a fortnight, so there’s more surface and less time per unit of it.
The checks that would catch this are not difficult. They’re just not run. Nobody scans dependencies before a merge on a Thursday evening, or reads every licence, or tests each policy against the ways policies fail. It’s not a knowledge problem. It’s that the check has to happen at the moment of shipping, and at that moment you are thinking about shipping.
So the agent runs them. Every merge, without being asked.
five checks, called automatically.
rls_checkerReads every row-level security policy on your database and tests it against the patterns that make policies fail.
Pulled directly from your connected Supabase or Neon instance - the live policies, not the migration files you think are current.
The specific failures, not a score. Policies that reference a user column but never check auth.uid(), so any authenticated user reads every row. Tables with RLS enabled and no policy at all. USING clauses permissive enough to be decorative. Service-role keys reachable from client code. Each finding comes with the policy, the severity, a plain description of who can see what, and a suggested fix your agent can apply.
secret_leak_finderCatches keys, tokens and connection strings before they reach your git history, and maintains a register of every secret your product uses.
Scans the diff before commit, and cross-references the platforms your secrets belong to.
Two things, and the second is the unusual one. The catch is table stakes. The register is the differentiator: a provenance record of every secret in use, which platform it belongs to, where it’s referenced and when it was last rotated. That’s the thing you need when you rotate a key and want to know what breaks - and the thing you need when a security questionnaire asks how you manage credentials.
vuln_scannerChecks every dependency against current advisories and tells you which ones matter.
Your dependency tree from GitHub or GitLab, matched against advisory data, then analysed for reachability.
Findings ranked by whether the vulnerable code path is one your product actually calls. This is the difference between a usable scanner and an ignored one: an unranked vulnerability list on a modern dependency tree is forty items long, thirty-five of them in code you never execute, and the effect of sending it to a founder on a Thursday is that nobody looks at any of them.
data_licence_reviewReads the licence on every dependency and tells you what it obliges you to do.
Resolved across your full dependency tree, including transitive dependencies, which is where the surprises live.
Every licence, attribution requirement, commercial-use flag and share-alike obligation, filterable by risk shape. Copyleft in a commercial product. Attribution you’re required to display and don’t. A licence that changed between versions. These are all cheap to fix when you find them and expensive to find during diligence.
launch_checklistOne pre-ship sweep across all three pillars, returning a single verdict.
Runs the four audit checks, then adds architecture and operations state - outstanding advisors, undocumented stack entries, open critical plan cards, failed recent deploys.
An answer to “is this ready?” that isn’t a feeling. One call, one verdict, and a list of what’s blocking if the answer is no. This is the tool to call before a client demo, a launch, or handing a pilot over.
a bad policy, caught before it shipped.
This is the flow that started Fizzgig. You add a comments table with what looks like a reasonable select policy. It isn’t, and nothing about it looks wrong.
The policy was syntactically correct, passed review, and let every logged-in user read every comment in the database. Nine seconds, and nobody had to remember to check.
what audit gives you as you grow.
The checks that stop a weekend project becoming a story. Even with one platform and a daily refresh, a leaked key or an open policy gets caught before it’s public.
Real users means real data, and real data means a broken policy is a breach rather than a bug. Audit runs before every merge, and the launch checklist gives you a straight answer before each release.
The pillar that carries you through review. Licence obligations resolved, secrets registered, vulnerabilities triaged by reachability - so a security questionnaire is a retrieval task rather than a fortnight.
Supabase and Neon supply live policies and database advisors. GitHub and GitLab supply the dependency tree and the diffs. Your AI editor calls the checks at merge time.
Nothing runs in your infrastructure and nothing needs a CI step - the agent already has the code and now it has the tools.