AI wrote your app. We’re the part that checks it.
Building the thing is your job. Knowing what to look for never was. You point us at one app. We read the code, including the part that decides who’s allowed to see what, and hand what we found back to the thing that wrote it. The worrying stops being yours.
Free while we build it · never a patch · quiet is never a green light
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.
VulX Enterprise · finding it
Under contract, a human goes through the class that ends companies.
This is not VulX Watch. Watch reads the repo and emails you. Enterprise is hands-on, scoped per app. We read the committed code first: keys, dependencies, storage rules, injection, and the access rules as written. Then we name what we found, with the file and the line.
- 01Read the committed data-access and row-level-security rules, down to the places a wrong user could be in the code.
- 02Infer the access rule the code seemed to mean.
- 03Say it plainly: which role the code allows, where, and how sure we are. We do not log in and try it.
This is VulX Enterprise. It is not the self-serve product.
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 one is the half that gets skipped.
How it works · what you get
Then it’s your call, and it stays that way.
What arrives is a description of the change: the file it’s in, what’s wrong with it, and what it should say instead, in words you can hand straight to whatever wrote the code. Not a commit.
We don’t open pull requests and we don’t touch your code. The only thing we ever commit is the brief itself — AGENTS.md and CLAUDE.md, and only where you’ve allowed it. You apply the rest, or you decide it isn’t worth it. That is not a limitation we plan to remove quietly.
The gate that would let a change be sent automatically (the same attack fails, the real user still works, your tests pass, the build holds) is designed and not shipped. It earns autonomy with a track record or not at all.
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 a second reader
One brain can’t do both jobs.
The thing that wrote your app is the worst possible thing to ask whether it’s safe, not because it is bad at security, but because it is being asked to find its own mistakes.
The writer
Your AI
Made every call in the app, including the ones nobody asked it to make. Ask it to review its own work and it grades the intention it already had, not the code it actually shipped.
The reader
VulX
Comes to the repository cold, with nothing invested in it being fine. Three different models read it, and we don’t need them to agree before something reaches you.
Marking your own homework is not a review. That is the whole of it.
Why us
The scanner is a commodity. These two aren’t.
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.
We read where the rules live
The rules about who can see what sit in your migrations and policy files, not in the code that uses them. We read those first — and we tell you what the code allows, not that we got in.
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. We read it four times a week while you’re using it, email you what’s worth a second look, and brief your AI so it writes the next one differently.
Free while we build it. No card, nothing to cancel.
- Secrets committed in code, and the file they are in
- 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, in plain English, and where we can name the fix, it’s there to copy
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
Our team goes through your app by hand and walks you through what they found, on the class that matters.
Scoped per engagement.
- Everything Watch reads, across the whole app
- A human goes through the access-control findings with you, rather than handing you a list
- API integration for platforms, with a block or allow decision in the pipeline
How it runs: hands-on with our team, under contract. None of this is a button you press, and we’d rather say so than imply there is one.
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 authorization review 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 read the whole thing, including the part that decides who’s allowed to see what, and tell you in plain words what’s worth a second look, and how sure we are. Quiet is never a green light.
Already using Claude or Cursor? Paste
https://mcp.vulx.ai/mcp and ask your assistant what the last
review found, and which commit it read, without leaving your editor.
We read it and tell you · the only thing we ever write is our own brief