AI wrote your app. We’re the part that checks it.
The whole app — keys, dependencies, storage rules, injection — reported with the file and the line. And for the one class that actually ends companies, we prove whether a stranger can really reach your users’ data.
Enterprise engagements, scoped per app · self-serve monitoring from $3.99 a week
The problem
The dangerous bug isn’t a crash. It’s a door left open.
AI writes most of a modern app and none of it knows what you intended. Exposed keys and vulnerable dependencies are caught by tooling that already exists. The one that ends companies isn’t: a route that hands over any record to anyone who changes the id in the URL.
Tea, Lovable, Moltbook — different apps, one root cause. Code that never checked who was asking.
Widely reported. A failure class, not VulX incidents.
How it works · finding it
We don’t warn you it might be open. We check.
We read the whole app first — keys, dependencies, storage rules, injection — and report what we can verify, with the file and the line. That’s the easy part. For the class that actually breaks companies, we go further.
- 01Narrow the app to the few places private data is reachable, using its own data-access and row-level-security rules.
- 02Infer the access rule the code was supposed to enforce — which is what separates genuinely reachable from merely suspicious.
- 03Prove it: an anonymous role reads a row it should never see, inside a single transaction that is always rolled back, against a canary we planted.
Nothing of yours is read. Runs hands-on, under contract — not a button you press.
How it works · fixing it
A fix that closes the hole and breaks the app is not a fix.
Here is that window again. Patching it is easy. Patching it without locking out the person who lives there is the part that gets skipped.
So the patch has to do two things at once: make the exact same attack fail, and leave a legitimate user still able to read their own data. That second check is the one almost nobody runs.
How it works · the gate
Then the curtain closes.
A patch becomes a pull request only if all four hold: the same attack now fails, the real user still works, your tests still pass, and the project still builds. Miss one and it is thrown away rather than shipped with a caveat.
What arrives is a branch to review. You merge it. We don’t.
Propose and approve. Full autonomy is on the roadmap, earned with a track record rather than assumed.
The bet
Security doesn’t get solved as models improve. It moves upward.
Better models are already closing the lower floors. Syntax is gone, memory bugs are going, injection is largely mechanical. What they cannot close is the floor above: whether this user is allowed to see this record.
That isn’t a property of the code. It’s a property of your intent, and no model reading your repository can infer it with confidence. So the danger keeps climbing into the one layer only your product knows — and that layer gets bigger with every model release, not smaller.
Why the fix means something
One brain, two roles.
The same intelligence attacks and defends — and the attacker is the one who decides whether the defense worked.
Offense
The Hacker
Reproduces the attack, confirms it actually works, and then goes back and tries to get through the patch. It is the judge, not the author of the fix.
Defense
The Fixer
Writes the patch, then has to satisfy the attacker, the legitimate user, the test suite and the build before anything is allowed to open.
A VulX fix isn’t signed off by the thing that wrote it. It’s signed off by the thing that was trying to break it.
Why this compounds
The scanner is a commodity. These four aren’t.
Fix-outcome data
Every cycle records whether the fix was accepted and whether it held. Almost no security tool ever learns whether its advice worked.
Structural independence
We didn’t write your code, so we have nothing to defend when we tell you it’s wrong. The model that generated it does.
Depth on authorization
The one class that depends on your intent rather than your syntax — which is exactly the class a general-purpose model can’t infer.
Patterns across codebases
AI-built apps fail in the same handful of ways. We see those ways across all of them, not one repository at a time.
Two ways in
One for the app you’re shipping. One for the company a breach would end.
Self-serve · for developers
VulX Watch
Connect a GitHub repo and it keeps reviewing it for you.
Free to start. $3.99 a week for continuous monitoring.
- Secrets committed in code, with the file and the line
- Vulnerable dependencies, and packages that don’t exist
- A CVE check against what you depend on, twice a day
- Every finding says where it is and how to fix it, in plain English
What it doesn’t do: it never touches your running app or your database, so it can’t tell you whether a data leak is actually reachable. Multiple scans a week — not real-time, and not on every push.
Sales-led · for founders and security teams
VulX Enterprise
The whole review, plus the proof loop on the class that matters.
Scoped per engagement.
- Everything Watch reads, across the whole app
- Connected proof against Postgres and Supabase, always rolled back
- Fixes gated on the re-attack, the real user, your tests and your build
- Pull requests you review and merge
- API integration for platforms, with a block or allow decision in the pipeline
How it runs: hands-on with our team, under contract. The proof step isn’t self-serve, and we’d rather say so than imply there’s a button.
On the record
Three organisations put their name next to ours.
None of them are customers and we won’t dress them up as customers. They are partners who looked at what we built and agreed to take it to their clients — a different kind of evidence, and the only kind we have so far.
Enterprise GRC partner
An enterprise governance, risk and compliance platform. They partnered with us to take proof-based security for AI-generated code to regulated clients.
Go-to-market partner
Takes VulX into engagements with enterprise clients who already trust them with delivery.
Go-to-market partner
Brings VulX to teams shipping AI-generated software who would otherwise never run a security review at all.
Built on
Get started
Point us at one app.
We’ll review the whole thing, and for the class that could end you, we’ll show you whether a stranger can actually reach your users’ data — or tell you plainly that they can’t.
Proven in a rolled-back transaction · you merge, not us