# using an ordinary support agent's login GET /api/users/8814/pii Cookie: session=<support>
loading000
starting engine
01We map your appthe running app, plus your code in white-box mode
02We prove the way ina working exploit, not a warning
03We hand you the fixthe file, the line, the change
04We prove it is closedthe same attack, re-run, now blocked
We find the way in. Then hand you the receipts.
Cyberlop tests your live app and, in white-box mode, reads your code at the same time. Every bug comes with a working exploit, the exact line that caused it, and proof once it is actually fixed.
- $199 for thirty days, one application
- Bring your own AI key
- Private option: your code never leaves your network
Step 1 · Map the application
First we learn how your app
actually works.
A normal scanner guesses from the outside. We click through the running app and, in white-box mode, read your source at the same time. So before we test anything, we know what every page and API does and who is meant to be able to reach it.
Step 2 · Test who can see what
Who can see what?
Now you know.
We use a real login for each kind of account you have: admin, finance, support, partner and a total stranger, and check what each one can reach. Green means locked the way you meant. Pink means someone got somewhere they shouldn’t. Twenty-five attempts here. Two came back with data that user should never have seen.
what we tried
accountsupport
asked forGET /users/:id/pii
should return403 Forbidden
200 OK, data returned
Step 3 · Prove it
Exploited, not suspected.
{ "email": "a****@example.co",
"card": "4111 **** **** 9012",
"company": "not their company" }
212 const { orgId } = req.body
213 const user = await users.byId(id)
214 if (user.orgId !== orgId) throw 403
215 return res.json(user.pii)
exactly the request that worked before GET /api/users/8814/pii ← 403 Forbidden
Step 4 · Fix it
We tell you exactly what to change.
Not a page of general advice for your team to interpret. In white-box mode we read your codebase, so we can name the file, the line, and the change that closes the hole.
211 export async function getUserPii(req, res) {212 // who owns this is decided by whatever the caller sends213 const { orgId } = req.body214 if (user.orgId !== orgId) throw forbidden()212 // who owns this is decided by the session we issued213 const { orgId } = req.session214 if (user.orgId !== orgId) throw forbidden()215 return res.json(redact(user.pii))216 }
− 3+ 3
the check now trusts the signed-in session, not the request
Step 5 · Close it
200 OK
403
Then we run the exploit again, to prove the fix worked.
“Fixed” is a hypothesis until the same exploit fails. Rescanning is a new guess; re-exploiting is proof. You get the before, the after, and a report you can hand to a customer, a board or an auditor.
Why teams add us
Three things your scanner cannot do
“We already have a scanner.”
Who can see what.
Each account checked for what it should not reach. Green means locked the way you meant. Pink means someone got somewhere they shouldn’t. A scanner has one login. It has never been a partner, so it cannot know a partner should not read your invoices.
“Does AI not just invent findings?”
Exploited, not suspected.
If we didn’t break it, we don’t report it. Every confirmed finding carries the request, the response, a screenshot and the line of code that allowed it. Anything missing one of those is a suspicion, and we file it as one.
“We are not sending source to a vendor.”
Your code never leaves.
Run the agent inside your own network and nothing goes out but results. Four outbound calls, zero inbound ports. We port-scan our own agent container in CI on every release, so that is a test rather than a promise.
No hype
What’s ready, and what is still building
Counted from the actual codebase. We would rather you found the gaps here than three weeks into a pilot.
0Lines of codealready shipped
0Permission checksenforced at startup
0Bug classeswe hunt for
0Lines of your codethat leave your network
LiveSeparate vault per customerYour data sits in its own database schema, not behind a filter someone can forget.
LiveRun it on your own machineThe self-hosted agent works today. Source never leaves your perimeter.
LiveCross-account access testingWhat each signed-in account can reach, marked allowed, denied or leaked.
LiveLogins and rolesMulti-factor, single sign-on, API tokens, 43 permission checks.
LiveFindings and triageDuplicates merged, assign to people, tag, export.
LiveWhat changed since last timeNew, fixed and broken-again, side by side.
LiveBlock bad merges in CIFails the build when a scan finds something serious. GitHub Action included.
LiveBranded reportsHTML and PDF with your logo, secrets automatically blanked out.
19 OctConfirmed-only modeOne list, only the bugs we actually exploited. No maybes, no homework.
3 NovThe benchmarkJuice Shop, WebGoat, DVWA and real apps with known bugs. Misses included.
16 NovProve the fixWe re-run the exploit that worked. The finding closes only when it fails.
4 JanBusiness-logic abuseStacked discounts, negative quantities, quota resets, payment races.
LaterJira and GitHub Issues syncToday you paste the ticket reference in yourself.
LaterSelf-serve signup and billingNo payment system yet. We invoice you.
We have not published a detection rate, and we are not going to make one up. Here is why, and what we are doing instead →
Fit check
Who this is actually for
01
Security agencies and pentest shops
You already sell this work, and you are capped by hours in the day rather than demand. This is the console you would otherwise have to build yourself. Your pentester reviews and signs; your name goes on the report.
02
Product teams with 5–30 apps
You do one pentest a year and nothing in between. Keep the pentest. This covers the other eleven months: each account, each permission, each deploy. It also stops bad code at the pull request.
03
Honestly? Not everyone yet
If you need compliance certifications, a procurement pack and three reference customers today, we are not there. Telling you otherwise would waste your quarter. Come back when the benchmark is out.