This post is a deeper look at how UnboundCompute does ai penetration testing, walked through one step at a time with a concrete example. UnboundCompute is an autonomous security researcher for web apps and APIs. Instead of running a fixed list of payloads, it learns how an app is meant to work, forms an idea about where that logic could break, and proves a finding before it ever reports one.
To make the steps real, we will use an invented app called Acme Notes. It is a simple note taking SaaS where users sign up, create notes, and share them with teammates. No real system is being attacked here. Acme Notes exists only so we can show the method on something you can picture.
Why ai penetration testing starts with understanding, not payloads
Most scanners begin from a catalog of known attacks and fire them at every input. That finds the bugs everyone already knows to look for. It misses the bugs that come from a specific app making a specific assumption.
UnboundCompute starts somewhere else. Before it tests anything, it reads Acme Notes the way a careful new engineer would. It maps the routes, the request shapes, and the rules the app seems to enforce. For Acme Notes, that means noticing things like this:
- A note is fetched with
GET /api/notes/{id}. - Sharing a note is a
POST /api/notes/{id}/sharewith a teammate email in the body. - The app appears to assume that only a note owner can share that note.
That last line is the interesting one. It is not a payload. It is an assumption the app is making. The whole method points at assumptions like that, because the bugs with the most impact usually live there.
The highest impact bugs come from understanding the app, not from matching patterns. So the first job is to learn the app, then ask where its own rules might not hold.
Form an assumption about where it could break
Once the app is understood, the next step is a clear guess. Not a vague worry. A testable claim about one rule that might not be enforced everywhere.
For Acme Notes, here is the assumption to challenge:
- The app checks ownership when you read a note, but it may not recheck ownership when you share one.
This is a guess about how access control can quietly fail. The read path and the share path were probably written at different times by different people. It is common for one path to enforce a rule that the other forgot. The guess is specific, so we can design a test that either confirms it or kills it.
Design an experiment
A good experiment isolates one variable. We want to know whether a user who does not own a note can still act on it through the share endpoint.
So we set up two accounts in the test app, Alice and Bob. Alice owns a note. Bob does not. Bob has a valid session because he is a normal signed in user. The experiment is simple. Bob asks the share endpoint to operate on Alice’s note id.
The point is control. If Bob’s request needs Alice’s note id and Bob’s own token, and nothing else changes, then any result we see is caused by the one thing we are testing.
Verify with hard evidence
This is the step that separates a real finding from a maybe. We do not report a guess. We run the experiment and look at what the app actually does.
Here is the kind of request the experiment sends, using Bob’s session against Alice’s note:
POST /api/notes/9d2f/share HTTP/1.1
Host: acmenotes.test
Authorization: Bearer <bob_session_token>
Content-Type: application/json
{ "email": "bob@evil.test", "role": "editor" }
Note 9d2f belongs to Alice. The token belongs to Bob. If Acme Notes were enforcing ownership on this path, the right answer is 403 Forbidden and no change to the note.
Proof is what the response shows. If the app instead returns this:
HTTP/1.1 200 OK
Content-Type: application/json
{ "note_id": "9d2f", "shared_with": "bob@evil.test", "role": "editor" }
then the assumption was right and the bug is real. Bob, who never owned the note, just gave himself editor access to it. The evidence is concrete: a 200, the response naming Bob as an editor, and a follow up GET /api/notes/9d2f with Bob’s token now returning the note body. That follow up read is the part that turns a suspicious response into a proven one. We can see Bob holding access he should never have had.
What counts as proof
Proof is not a status code on its own. It is a short chain that any engineer can replay:
- The exact request that should have been denied.
- The response showing it was allowed.
- A second request that confirms the new access is real, not just an echo.
If any link is missing, the finding stays unproven and is not reported. No bug is reported until it is proven. That is the rule that keeps the output as signal instead of a stack of guesses someone else has to triage.
Chain a confirmed finding into the next
A proven finding is not the end. It is a new fact about the app, and facts open doors.
Now that Bob can grant himself editor access to any note id, the next question writes itself. What can an editor reach that a stranger cannot? If editors can read attachments, and attachments are served from a shared store, then the access control gap on sharing may lead to reading files that belong to other teams. So the next experiment targets that, using the access Bob just proved he can get.
This is the chaining step. Each confirmed finding becomes the starting point for the next assumption, so a single broken rule gets followed as far as it really goes, with evidence at every step.
A finding can become a repeatable check
Once the share endpoint bug is proven and fixed, the proof does not get thrown away. The exact request and the expected 403 become a check that runs again later. If a future change reintroduces the gap, the check catches it. A confirmed finding turns into a small guard that keeps watching for the bug coming back.
Where this stands today
We are early and honest about it. The product is being built. We are not claiming customers, benchmarks, or finished results.
What we can say is encouraging. A frontier model drove this full method on its own and identified and verified real access control and injection issues in test applications it had not seen before. We treat that as an early signal that the approach works, not as a final score.
The Acme Notes walkthrough is the whole idea in one example. Understand the app, assume where it could break, design a clean experiment, verify with evidence you can replay, then chain the result into the next finding. This is exactly the kind of logic bug an autonomous researcher that tests assumptions is built to find. If you want the fuller picture of who we are and where we are headed, read more on our about page.