Auth finding · baseline
EXPLOITED
401 · “Account locked.
Try again later.”
Try again later.”
One automated loop · No human writes the fix
An evidence-based case study: the AI runs the whole loop on one real vulnerability, end to end — find, prove, fix, confirm, and the blast radius the fix reaches into — and refuses to certify a fix that doesn't hold.
Rohit Chaudhri·bringforth.ai·Live case study
Coverage is counted per operation — a test only counts when it exercises that exact entity and operation.
For weeks the work followed me into sleep. Half-dreaming through a bug, muttering to myself — or to the AI — and then it lands and I'm awake: the core architecture is wrong, damn. 3am. And with it, the question underneath all of it: how do you expedite AI-augmented coding and cut time to market — without shipping the mess the AI leaves behind?
The answer isn't a better scanner. Finding bugs stopped being the hard part the moment an AI could list every broken check in an afternoon. The hard part is trust — earning enough of it to let AI change production code with no human in the loop. And every step that makes autonomous fixing possible creates the next risk you have to close. By hand, this whole lifecycle is weeks of security-plus-dev work per finding.
So read this as a ladder, not a pipeline. Each rung earns a little more trust and hands you the next problem — run end to end, by the platform, on one real vulnerability in a rental-property manager built on a no-code platform. Where a rung is still hardening, I say so.
Four specialized scanners read the codebase in parallel, each tuned to one class of flaw. Every finding is checked back against the actual source before it persists — if the line doesn't say what the scanner claims, it's thrown out. What survives is anchored to a real location.
The finding is anchored on the form — the reachable entry point — but the leak happens elsewhere, and picking the exact snippet is the whole discipline. Two lines matter, in two different files.
172const handleSubmit = async (e) => { ... // name, email, phone, notes — the tenant's own PII 192 await onSubmit(submitData); // → Tenant.create, no request model 202};
The form ships arbitrary tenant fields straight to POST /api/rensure/entity/tenant with no schema, so a bad type or duplicate key becomes a database error.
A static finding is a guess. So the platform writes real exploit code, runs it against the live app, and captures the raw HTTP exchange — then renders an independent verdict: did protected data come back, true or false. The trace pins the leak to one server-side step; the exploit targets it.
Here is the exchange it captured on the tenant record, unedited. The attack is one malformed field — a landlord_id that points at no user, forcing a foreign-key error the server doesn't handle.
One bad request returns the constraint name, the entire tenant table schema, the exact INSERT, and a real account. That is the database boundary itself, handed to any logged-in caller.
And it isn't one endpoint. The leak lives in a handler every write funnels through, so the same exploit fires across entities and operations that have nothing to do with each other. Five scenarios, five fires:
Anything that doesn't fire is dropped here — no false positive reaches the fix stage.
The fix isn't a pull request waiting on a sprint. The platform generates a runtime filter, scoped to the exact request pattern that leaked, and hot-loads it at the gateway — one per scenario, surgical, no over-blocking. Here is the one it wrote, unedited:
This is where every "AI fixes your code" demo stops. Generating the fix is the easy part. Whether you can trust it is decided entirely by what happens next.
The filter loads and the exact exploit from Step 2 runs again. Nothing about the attack changes — same request, same malformed landlord_id. Only the response is allowed to differ. It does:
All five scenarios flipped the same way — every entity, every operation, exploited to blocked — each with the captured HTTP to show for it. The CWE-200 loop closed as completed.
remediation 97761074 · attempt 1 · 5/5 scenarios blocked · started 12:35:32 · completed 14:53:24
A confirm step that always rubber-stamps is theater. So here is the same step on a different finding in the same app — an auth endpoint that leaked account state. The platform generated a fix, re-ran the exact exploit, and captured the result. The response came back unchanged:
That is the difference between a report and a gate. A report tells you a fix was written. A gate re-runs the attack and tells you whether it actually worked — and this one can come back red.
The leak lived in a shared handler — the one every create, update and delete funnels through (that's the starburst at the top of this page). We proved it on the operations above; the platform walks the code knowledge graph outward from that unit to count the rest of the surface a fix there has to answer for. The answer isn't one endpoint. It's almost all of them.
Coverage is counted per operation — a test only counts when it exercises that exact entity and operation.
Green is what a test would catch if the fix broke it. Red is impacted but unverified. The gap is the risk — 148 of 165 flows the fix reaches have no test that would notice if it broke them. This is the reverse view: every unit that calls into the changed one.
Knowing what could break isn't the same as knowing it did.
Every scanner on the market can do the first rung. A growing number claim the third. What almost none of them do is the rungs in between and after — prove the bug fires, prove the AI's fix holds, and refuse to certify it when it doesn't. You saw the loop do exactly that: green for the tenant finding, red for the auth one, both on captured evidence.
That's the trust the whole thing is built to earn. No human wrote the fix — a human read the evidence and decided. And when a fix doesn't hold, the loop is the thing that says so, before production does.