Cyber: Proof Before the Fix
CloudThinker builds Frontier Investigation Agents. CloudThinker Cyber is our Frontier Security Agent.
Our line for Cyber is "Hacks you before hackers do." It tests your apps and APIs the way a hacker would, so your team catches critical issues first.
Here's the scene it's built for, illustrative but familiar. A scanner report lands with 140 items marked "possible". The team spends a week deciding which ones are real. Meanwhile the annual pentest PDF from March describes an app that has shipped forty times since.
The hard part of application security was never listing what might be wrong. It's proving what is wrong, and then fixing it.
Why the usual approach breaks
Scanners guess. They match patterns and report probabilities. Every "possible" finding costs an engineer time to confirm or dismiss, and the team pays that cost before anything gets fixed.
Pentests age. A consultant tests once a year and leaves a report. It starts going stale the day it arrives, because the app keeps changing and the report doesn't.
Nobody re-checks. A fix gets merged. Did it close the hole? Usually nobody tests that until the next engagement, months later.
We wanted a test that runs as often as you deploy, reports only what it can prove, and checks its own fixes.
What Cyber does
01Verify
Prove you own it
A DNS TXT record per domain. No pentest runs before it.
02Scope
Set the fence
Include and exclude paths, logins, repositories, intensity.
03Prove
Attack and confirm
Each finding carries an attack path and a safe proof you can replay.
04Fix
Pull request
Create PR with agent turns the remediation into a change to review.
05Re-check
Next scan
Old findings are replayed, and fixes are verified without asking.
You register an app with a name and a target: a domain or an API base URL. Then you prove you own the domain with a DNS TXT record. No pentest runs until you do.
Next you set the boundaries in the app's Settings tab. Scope takes include paths (like /api/**) and exclude paths (like /admin/**), and the agent never touches anything outside it. You can attach test identities, repositories and context files such as an API spec or a Postman collection.
Then it scans. A run maps everything reachable and tests inside your scope. Most runs finish in a few minutes, and every run has a three-hour deadline.
Each app is a living record. Every scan updates one picture of its security instead of producing another one-off report.
What "proven" means
A confirmed finding carries four things: a Summary of what's wrong, the Attack path showing exactly how the agent got in, a Safe PoC (the request you can replay yourself), and Remediation.
Anything short of proof is labelled. A Needs verification lead isn't a confirmed finding. You can Flag for retest so a later scan proves or rejects it.
Here's what proof looked like on our Juice Shop benchmark, a SQL injection in the login endpoint. One request:
curl -s -X POST https://<juice-shop-host>/rest/user/login \
-H "Content-Type: application/json" \
-d '{"email":"admin@juice-sh.op'\''--","password":"anything"}'
# if parameterized: 401, "Invalid email or password."
# observed: 200, with authentication.token for user id 1 (admin)
A valid admin token for a wrong password. That's a finding you don't need to debate.
How deep it goes
Depth depends on what you attach. Nothing means black-box: only what a stranger sees. A login means gray-box: what a signed-in user sees. A repository means white-box: the running app plus the code behind it, so findings point at the exact line that caused them.
Attach two logins, named something like victim and attacker, and describe what each may see. That description is how the agent knows which access is a bug, and it's how Cyber proves one customer can read another's data.
Intensity is separate. Safe only reads pages and data. Aggressive submits forms and creates test data, never deletes. Full may delete. You choose per run.
From proof to a fix
On a confirmed finding, Create PR with agent turns the remediation into a pull request against your code. Chat with finding opens a conversation with the finding already loaded, for when you want to understand it before you merge anything.
Your engineers review that pull request like any other. Changes go through Auto Mode, so you decide what runs on its own and what waits for approval.
The next scan re-checks
01The agent
Owns the verdict
- Real or notSettled with a replayed proof
- Still presentRe-tested on every scan
- Proven fixedOnly a scan can reopen it
Evidence decides
02Your team
Owns the workflow
- Triage stageNeeds triage, In progress, Awaiting retest
- DismissalsAlways with a reason on record
- The fixReviewed and merged by your engineers
People decide
Two kinds of ownership share each finding. The agent owns the verdict: whether the problem is real, still present, or proven fixed. You own the triage stage, from Needs triage to Verified fixed.
That last stage isn't yours to click. The next scan replays the proof and confirms the fix. A finding whose fix a scan proved can only be reopened by a scan that proves it's back.
Dismissals need a reason: False positive, Acceptable risk or Out of scope. A dismissed finding stays quiet on later scans. Reopen it and the agent starts testing for it again.
Design decisions
Ownership before the first packet. DNS verification is a hard gate. We only test what you can prove is yours.
A failed login fails the run. If a stored credential for a gray-box or white-box run fails, the run fails instead of quietly falling back to black-box. A clean report from the wrong depth would be worse than no report.
Proof belongs to the agent, workflow belongs to you. Splitting the verdict from the triage stage means a fixed finding can't be closed by a click, and a real one can't be argued away without a reason on record.
The evidence
01Confirmed
38 vs 23
CloudThinker Cyber against AWS Security Agent, black box, same target.
02Time
27 min vs 5 h 9 min
Wall-clock time from the start of the run to the completed report.
03Cost
About $57 vs $998
Billed usage of the run at list price, before trials or discounts.
We ran Cyber and AWS Security Agent side by side on OWASP Juice Shop, black box, one run each, default settings. Cyber reported 38 confirmed vulnerabilities in 27 minutes for about $57. AWS Security Agent reported 23 in 5 hours 9 minutes, about $998 at list price. Full method and raw results.
Honest limits
Cyber is in beta.
The benchmark is one target and one run each, two days apart. Juice Shop isn't your app.
Neither tool found everything. Juice Shop has well over 100 documented challenges. An AI pentest complements a human red team. It doesn't replace one.
Cyber tests one running app at a time. It can only find what your scope, identities and repositories let it reach.
Try it
Register a staging app, verify the domain, and run one Safe pentest. Then ask from a finding:
"Walk me through the attack path and tell me which line of code causes it."
"What would a fix look like that doesn't change the API response shape?"
"Which of our open findings can be reached without logging in?"
Run your first pentest or book a walkthrough.