The System
The platform serves local service businesses. Each tenant gets a marketing site, a CRM covering the full lead-to-invoice path, AI-generated marketing copy, and integrations for payments, accounting, business listings, and SEO data.
When we ran the audit, the platform was still sitting on a private staging environment with no paying tenants, and the founder was preparing to demo it to outside design partners. It's hard to find a cheaper moment for a production readiness review. No customer data was at risk yet, and every finding could go on a pre-launch checklist instead of turning up later as an incident.
The Engagement
We ran the system through our agentic audit pipeline, the same autonomous delivery tooling from our Lab, pointed at review instead of build. After the initial human-led intake of the project code, our senior engineers operate customized expert agent reviews in parallel, each with a specialized area of focus. Ambiguities and judgment calls are flagged for human engineer review to move the pipeline along. At the end of the pipeline another agent collects the findings and synthesizes them into a final report.
The economics are the point: the machine gathers evidence quickly, and the senior hours go where judgment is actually needed.
Inside the Pipeline
In the Lab, this tooling's day job is shipping software: requirements become issues, issues become pull requests, and nothing merges until CI is green and a human approves it. An audit is the same process run in reverse: instead of writing code to satisfy requirements, the agents read code and test it against production requirements it was never written to meet.
The flow is intake → parallel evidence passes → synthesis → report.
Intake takes more human attention than anything downstream. Pointing autonomous agents at a codebase you didn't write is a security decision, and vetting what's in the repository comes before any agent touches it. The evidence passes are the machine's strength: agents work through the codebase and infrastructure configuration and record what they find, citing the specific files and lines, which is what makes every finding auditable. Synthesis clusters the raw findings into root causes, so the report reads as six problems instead of thirty symptoms. The senior gate is where severity, priority, and the verdict get set. The machine collects evidence; it doesn't make the judgment calls.
What came out the other end was a 25-page branded report with thirty findings, each carrying a severity, a blast radius, a priority, an effort estimate, and evidence traced to specific files and lines. It included a hardening roadmap in three horizons (before the first demo, thirty days, ninety days), a quick-wins list the founder could act on within the week, and a plain-language glossary, written for a founder rather than an SRE.
What We Found
Thirty findings sounds like an indictment, and the report was explicit that it wasn't one. This was a competent build, not a rescue. Payment webhook verification, SSRF defenses, application-tier rollback, and per-request AI cost discipline all held up under examination. The real problem was the absence of a safety net around otherwise reasonable code.
The thirty findings collapsed into six root-cause themes, including:
- No safety net. No CI gate, no monitoring, no verified database restore. Roughly a third of the findings traced back to that missing layer.
- Public endpoints that bypassed row-level security. This included a denial-of-wallet exposure on an unauthenticated LLM endpoint.
- Fail-open authorization. A platform-admin check whose worst case was a full collapse of the tenant boundary.
- No technical operator. The one finding that wasn't a line of code: an AI-built system with nobody positioned to set spending limits, notice failures, or recover from them.
Four items were flagged P0, meaning they needed to close before the first outside user touched the system.
What We Told Them They Could Do Themselves
Several of the highest-priority fixes were dashboard settings: a hard LLM spend cap, database point-in-time recovery, and MFA on the admin accounts. We said so in the report instead of padding a scope with them. The work that warranted senior hands was the operational layer: the CI gate, the staging database, monitoring and alerting, and a tested restore drill. The audit also surfaced a standing question that no line of code answers: who runs this system once it's live.
AI code generation has made competent prototypes cheap. It hasn't done anything for the supply of people who can run them in production.
Outcome
The founder closed the self-serve P0 items on his own, working directly from the report: the provider-side spend cap, point-in-time recovery on the database, and MFA on the admin accounts, all before any outside user touched the system. He had been half-aware of some of these problems already but hadn't known what to do about them, which is exactly the situation the report format is built for. It turned a vague unease into a checklist he cleared in a couple of days.
He also agrees with the shape the report lays out for the deeper work, the safety net, and the eventual question of who operates the platform in production. That work will pace against his launch.
The larger change is harder to itemize. Before the audit, he had a working product and a set of worries he couldn't rank. After it, he knows which parts of his AI-built system held up, which ones would have failed him in front of a customer, and the exact order to fix them in. For a non-technical founder heading into first demos, that is the difference between launching on hope and launching on evidence.