Your backend was written by an AI. Who reviewed the tenant isolation?
A findings report covering the places generated and hand-written code most often get wrong: tenant isolation, storage bucket permissions, and privilege-escalation paths in access-control policies. In a recent audit of an AI-generated Supabase backend, this class of review found four critical issues in two days — including a path that let one tenant write into another tenant's data. Catching that before launch is a two-day review; catching it after launch is an incident. Findings come with remediation, either as pull requests I write directly or as prioritized task sheets your own team can execute from, depending on how you want to run the fix.
Audits run read-only against production wherever possible — scripts that pull state and check it against expected behavior without ever writing to the system being reviewed, so the audit itself introduces zero risk. For infrastructure audits, that extends to server configuration, SSL and certificate management, and monitoring setup. For application audits, it means checking access-control policies against the access patterns the application actually generates, not just the ones the documentation describes. The engagement ends with a report separated from remediation, so you see the risk clearly before anything gets changed.
Teams shipping a backend that was substantially AI-generated and hasn't had a systematic security review, teams that inherited infrastructure or an Odoo estate with unknown state, and anyone who wants a second set of eyes on tenant isolation before their first serious customer finds the gap for them.
Tell me what's breaking — or what you're building.