Author: UnboundCompute

If you search for an ai vulnerability scanner, you will find a lot of tools that promise to find every bug in your app. Most of them work the same way underneath: they match your app against a list of known patterns and hand you back a long report of maybes. UnboundCompute is a different kind of tool, and this post is an honest look at how it differs and where it stands today.

We are early. The product is being built. So this is not a sales pitch. It is a comparison of two ways of looking for bugs, and an explanation of why we chose the harder one.

What a traditional vulnerability scanner actually does

A classic scanner crawls your app, collects every URL, form, and parameter it can reach, then fires a fixed set of test payloads at each one. It watches the response for signs that something went wrong. A reflected string here, a database error message there, a slow response that hints at a sleep command.

This works for whole classes of well known bugs. If a field echoes back <script>alert(1)</script> without encoding, a scanner will catch it. If a search box passes ' OR '1'='1 straight into a query, it will often catch that too. That is real value, and pattern matching is good at finding the obvious mistakes quickly.

The trouble starts past the obvious. A scanner does not know what your app is for. It does not know that a user on a free plan should never reach /api/v1/exports/full, or that order id=1043 belongs to a different account. It sees a request that returns 200 OK and moves on. To the scanner, a working feature and a broken access control check look identical.

Why the report is full of maybes

Because a scanner guesses from surface signals, it has to play it safe. If a payload causes any change at all, it tends to flag it so it does not miss a real bug. The result is a report with many items marked “possible” or “medium confidence,” and a real chance that most of them are false positives. Someone on your team then spends a day or two checking each one by hand to find the few that are real.

That is the core problem. The scanner did the easy part and left the hard part, proving the bug, to you.

A scanner tells you where something might be wrong. The expensive work, proving whether it really is, still lands on a human.

How an ai vulnerability scanner that reasons is different

UnboundCompute is built around a different loop. Instead of matching payloads against a list, it tries to understand the app first, then form ideas about where the logic could break, then run experiments to test those ideas, and only report a finding once it has proof. Understand, assume, experiment, verify, chain.

Here is what that looks like in practice on an invented example. Say a typical SaaS app called Acme Notes lets users share a note by id:

GET /api/notes/4471
Authorization: Bearer <user A token>

A pattern matcher checks that the response is valid and moves on. A researcher that reasons about the app notices the id is a plain number and forms an assumption: the server might be trusting the id in the URL without checking who owns the note. So it designs an experiment. It logs in as a second user, takes that user’s token, and asks for a note id that belongs to user A:

GET /api/notes/4471
Authorization: Bearer <user B token>

If user B gets back user A’s private note, that assumption was correct. The tool does not stop at a hunch. It confirms the note content belongs to a different account, records the exact request and response as evidence, and only then reports it. That is an access control bug a payload list would never spot, because nothing in the request looks malicious. The request is perfectly well formed. The problem is what the app assumed.

Proof before report

The rule that changes the output is simple: a finding is only reported when it is proven with concrete evidence. No proof, no report. This flips the work. Instead of handing you candidates to verify, the tool does the verification itself and hands you the ones that survived. The output is signal rather than a stack of maybes.

A confirmed finding can also be turned into a repeatable check, so the same test keeps running and tells you if the bug ever comes back after a fix or a refactor.

A short comparison

• How it finds bugs. A scanner matches known patterns. UnboundCompute forms an idea about the app’s logic and tests it.
• What it understands. A scanner sees URLs and parameters. The researcher tries to learn what the app is meant to do and where that intent could break.
• What it reports. A scanner reports candidates, many of them false positives. UnboundCompute reports findings it has already proven.
• Who proves the bug. With a scanner, a human triages the list. Here, the tool runs the experiment and keeps the evidence.
• The kind of bug it catches. Scanners are strong on known payload bugs. The researcher reaches logic and access control flaws that have no fixed payload.
• After the fix. A proven finding becomes a repeatable check that watches for the bug returning.

We go deeper on this split in scanners vs research, since it is the line that matters most when you are choosing a tool.

Where we are honest about the limits

None of this means scanners are useless. They are fast, cheap, and good at sweeping for the common, known issues. If you have never run one, run one. The point is that pattern matching has a ceiling, and the highest impact bugs usually live above it, in the assumptions an app makes about who you are and what you are allowed to do.

It also does not mean UnboundCompute is finished. It is not. We are building it, and we are not going to dress that up with customer counts or benchmark charts we do not have. What we can say is an early, encouraging signal: a frontier model drove the full methodology on its own and identified and verified real access control and injection issues in test applications it had not seen before. That is a hint that the approach works, not a promise of a result on your app.

Which one should you use

Think of them as different jobs. A vulnerability scanner is a smoke detector for the known stuff, cheap to run and worth keeping on. An autonomous researcher is closer to a person who reads your app, asks “what if the server trusts this id,” and goes and checks. They answer different questions.

If you take one thing from this, take the difference between a maybe and a proof. A maybe costs you time. A proof saves it. That gap is exactly what an autonomous researcher that tests assumptions is built to close. You can read more about who we are and where we are headed on our about page.

Frequently asked questions

How is UnboundCompute different from a vulnerability scanner?

A scanner crawls your app and fires a fixed set of known payloads at every input, then flags anything that looks suspicious. UnboundCompute instead tries to understand the app, forms ideas about where its logic could break, runs experiments, and reports a finding only once it has proof.

Why do scanner reports contain so many false positives?

A scanner guesses from surface signals, so it plays it safe and flags anything that changes, which produces a report full of items marked possible or medium confidence. Someone on your team then spends a day or two checking each one by hand, because the scanner did the easy part and left the proof to you.

Should I stop using vulnerability scanners?

No. Scanners are fast, cheap, and good at sweeping for common, known issues, and if you have never run one, you should. The point is that pattern matching has a ceiling, and the highest impact bugs usually live above it, in the assumptions an app makes about who you are and what you are allowed to do.

Can I buy or try UnboundCompute today?

Not yet. It is still being built, and we are not going to dress that up with customer counts or benchmark charts we do not have. You can read about who we are and where we are headed on our about page.

Put an autonomous researcher on your own systems

UnboundCompute is an autonomous security researcher that reasons about how an application fits together and proves the access control and injection bugs it finds. We are opening a small number of founding design partner seats: private early access pointed at a staging target you choose, a say in what it looks for, and founding pricing. If your team ships software worth pressure testing, apply to the design partner program.

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}/share with 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.

Frequently asked questions

How does UnboundCompute actually find a bug?

It works in a loop: understand, assume, experiment, verify, chain. It reads how the app is meant to behave, forms a testable guess about a rule that might not hold, designs an experiment that isolates one variable, and confirms the result with evidence before reporting anything.

What counts as proof before something is reported?

Proof is a short chain any engineer can replay: the exact request that should have been denied, the response showing it was allowed, and a second request that confirms the new access is real rather than just an echo. If any link is missing, the finding stays unproven and is not reported.

What does chaining mean here?

A proven finding is a new fact about the app, and facts open doors. Once one rule is shown to be broken, UnboundCompute uses that access as the starting point for the next assumption and experiment, so a single gap gets followed as far as it really goes, with evidence at every step.

Is UnboundCompute finished and ready to use?

No. We are early and the product is being built, and we are not claiming customers, benchmarks, or finished results. You can read more about where we are headed on our about page.

Put an autonomous researcher on your own systems

UnboundCompute is an autonomous security researcher that reasons about how an application fits together and proves the access control and injection bugs it finds. We are opening a small number of founding design partner seats: private early access pointed at a staging target you choose, a say in what it looks for, and founding pricing. If your team ships software worth pressure testing, apply to the design partner program.

We started UnboundCompute because of a gap we kept running into. Most automated security testing checks a fixed list of known bugs and stops there. That misses the flaws that hurt most, the ones that need a real understanding of how an app works, like broken access control and business logic abuse. This post explains the gap, why we think it matters, and what we are betting on.

We are early. The product is being built. We would rather tell you what we believe and why than sell you on results we have not earned yet. So this is a point of view, written plainly.

What most automated security testing actually checks

A normal scanner works from a catalogue. It knows what a reflected script looks like, what a classic injection string returns, what an outdated library version means. It sends those patterns at every endpoint it can find and reports the matches. This is genuinely useful. It catches the well understood bugs fast, on a schedule no human could keep, and it never gets tired.

But notice what that approach assumes. It assumes the dangerous bugs all look like something the tool has seen before. Many do not. Consider a request like this:

GET /api/orders/8841
Authorization: Bearer trial-user-token

HTTP/1.1 200 OK
{ "id": 8841, "owner": "another-account", "total": 1290 }

There is no malformed payload here. No quote to break a query, no script tag, no signature to match. Yet the trial user just read an order that belongs to someone else. That is broken access control, and a pattern matcher has nothing to match against, because the request looks perfectly ordinary. The bug lives in the rule the app forgot to enforce, not in the shape of the input.

Why automated security testing misses the bugs that matter

The highest impact flaws come from understanding what an app is trying to do, then asking what happens when you bend one of its rules. Two examples make the point.

Broken access control

An app decides who is allowed to see or change what. When a check is missing, one user can reach another user’s data by changing an id in a URL, or reach an admin route that was never linked from the menu. To find this, you have to know who the current user is supposed to be and what they should not be able to touch. A fixed payload list does not carry that idea.

Business logic abuse

Logic bugs are worse to automate, because the app is behaving exactly as written. The code is just wrong about its own rules. Picture a checkout that takes a discount code. A tool sending known strings will never think to apply the same code three times, or set the quantity to a negative number so the total drops below zero:

POST /api/cart/apply
{ "code": "SAVE20", "quantity": -4 }

Nothing about that request is malformed. It is a valid call that exploits a rule the app assumed no one would break. You only find it by understanding the flow first, then probing the assumption underneath it.

The bugs that hurt most are not strange inputs to known holes. They are ordinary requests that break a rule the app forgot to enforce.

Why skilled humans cannot cover the gap alone

Human testers find these bugs. A good one reads the screen, guesses the business rules, and chases behavior no rulebook predicted. That is exactly the kind of judgment a payload catalogue lacks. The problem is supply.

• They are scarce. The people who are genuinely good at this work are few, and demand far outruns them.
• They are expensive. A deep manual test is a serious cost, so most teams can only afford it once or twice a year.
• They cannot keep up with shipping. Teams deploy many times a week. A test run once a year cannot see the code that shipped last Tuesday.

So you end up with two options that each fall short. Scanners run constantly but miss the bugs that need understanding. Humans understand but cannot run constantly. The deeper version of this comparison lives in our scanners vs research category, which goes through where each one earns its keep and where it does not.

Our bet: an autonomous researcher that tests assumptions

Here is what we are building toward. Instead of a tool that matches known payloads, an autonomous researcher that works the way a thoughtful human tester does. It learns how the application is meant to behave. It forms ideas about where that logic could break. It designs experiments to test those ideas. Then it proves a finding before it ever reports it. Understand, assume, experiment, verify, chain.

The order of those words matters. Understanding comes first, because the bugs we care about only appear once you know what the app expects. The verify step matters just as much. A finding is only reported when it is backed by concrete evidence, so the output is signal, not a pile of maybes. Take the order example above. The researcher would not flag a “possible” issue. It would replay the request, show the other account’s data coming back, and hand you a result you can reproduce.

That last step changes the cost of reading a report. Every false alarm costs someone an hour of triage, and after enough of them people stop reading. Proof cuts the noise. And once a finding is confirmed, it can become a repeatable check that keeps watching for the same bug coming back after a future deploy.

Where we are, honestly

We will not pretend we are finished. We are early, and the product is being built. We have no customers to name, no benchmark to wave around, and we are not going to invent one.

What we can share is an early signal that keeps us going. A frontier model drove the full methodology on its own and identified and verified real access control and injection issues in test applications it had not seen before. We frame that as encouraging, not as proof. It is enough to tell us the bet is worth making, and not enough to claim the work is done.

Why this is worth building

The pattern is hard to ignore. Software ships faster every year. The bugs that cause the worst days, the leaked records and the abused workflows, are the ones that need understanding, not pattern matching. Scanners cannot supply that understanding, and skilled humans cannot supply enough of their time. Something has to test the assumptions an app makes, at the speed teams now ship, and prove what it finds before it interrupts anyone.

That is the thing we are trying to build. An autonomous researcher that tests the assumptions your app makes and reports a bug only once it is proven. We are early and we know it, but this is the gap worth closing, and it is why UnboundCompute exists. If you want to follow along or tell us where we are wrong, read more on our about page.

Frequently asked questions

Why is UnboundCompute being built at all?

Most automated security testing checks a fixed list of known bugs and stops, which misses the flaws that hurt most, like broken access control and business logic abuse. Those bugs need a real understanding of how an app works, and we are building an autonomous researcher to test the assumptions an app makes rather than match known payloads.

Why can’t existing scanners or human testers cover this gap?

Scanners run constantly but only catch bugs that look like patterns they already know. Skilled human testers understand an app and find logic bugs, but they are scarce and expensive, so most teams can only afford a deep manual test once or twice a year, which cannot keep up with code that ships every week.

Do you have customers or proof it works?

No. We are early and the product is being built, so we are not claiming customers, revenue, funding, or benchmarks. We share a point of view here rather than results we have not earned yet.

What kind of bugs does this approach target?

It targets bugs that come from understanding what an app is trying to do, then asking what happens when one of its rules is bent. Common examples are broken access control, where a user reaches data they should not, and business logic abuse, where a perfectly valid request exploits a rule the app assumed nobody would break.

Put an autonomous researcher on your own systems

UnboundCompute is an autonomous security researcher that reasons about how an application fits together and proves the access control and injection bugs it finds. We are opening a small number of founding design partner seats: private early access pointed at a staging target you choose, a say in what it looks for, and founding pricing. If your team ships software worth pressure testing, apply to the design partner program.

UnboundCompute is an autonomous security researcher for web apps and APIs. It reads an application the way a careful person would, builds a picture of how the app is meant to behave, then goes looking for the places where that intent quietly falls apart. This post explains who it is, what it does, and where it fits in the wider story of autonomous penetration testing.

What UnboundCompute actually is

Think of it as a researcher that never gets bored and never stops reading. You point it at a web app or an API. It studies the routes, the parameters, the responses, and the rules the app seems to enforce. From that it forms a working model of the system: who is supposed to do what, which actions need permission, and which inputs the app trusts.

That model is the whole point. Most bugs that matter are not missing patches. They are gaps between what the app intends and what it allows. A user who can read another user’s invoice by changing one number in a URL. An endpoint that checks your login but forgets to check whether the record belongs to you. These are logic gaps, and you only see them once you understand the logic.

The loop: understand, assume, experiment, verify, chain

UnboundCompute works in a loop. Each step feeds the next, and the loop keeps tightening until there is either a proven finding or nothing left to test.

Understand

First it learns how the app is meant to work. It maps the surface and reads the behavior. If GET /api/orders/1042 returns your order, the researcher notes that orders are addressed by a simple number and asks the obvious follow up: what enforces that 1042 is yours?

Assume

Next it forms ideas about where the logic could break. This is the part a fixed checklist cannot do. The researcher reasons about the app in front of it, not a generic template. For an orders endpoint it might assume that ownership is checked at login but not at the record level. For a password reset flow it might assume the token is predictable or reusable.

Experiment

Then it designs a test for each idea and runs it. One assumption, one experiment. For the ownership idea, it requests a record it should not own:

GET /api/orders/1043
Authorization: Bearer <a different user's session>

If that returns someone else’s order, the assumption held and there is a real access control bug to confirm.

Verify

This is the step that separates a researcher from a noise machine. A guess is not a finding. UnboundCompute only reports something when it can prove it with concrete evidence, the request that triggered the behavior and the response that shows the impact. The output is signal, not a pile of maybes you have to sort through by hand.

A finding is only worth reporting when you can show the exact request that proves it. Everything else is a guess wearing a confident face.

Chain

Single bugs are useful. Chained bugs are how real damage happens. Once a finding is verified, the researcher asks what it opens up. A leaked email here, a guessable identifier there, an endpoint that trusts a value it should not. On their own each looks minor. Together they can add up to a full account takeover. Because UnboundCompute carries its model of the app through the whole loop, it can connect one verified result to the next instead of treating every test as a fresh start.

Why this beats a scanner that checks a known list

A traditional scanner is a list reader. It carries a set of known signatures and fires them at every input it finds. That has real value for catching the obvious and the already known. It also has a hard ceiling. A scanner that only checks a known list cannot find a bug that is not on the list, and the bugs that hurt most are almost never on any list.

Here is the difference in one example. A scanner sends a SQL injection string at /search?q= and checks whether the response looks like a database error. Useful. But it will happily pass an endpoint like this:

POST /api/account/transfer
{ "from": "acct_self", "to": "acct_other", "amount": 500 }

There is no payload to match here. The bug, if there is one, is that the server never checks whether you own acct_self. No signature catches that. You catch it by understanding what the endpoint is for and testing the assumption it makes about who is calling it. We write more about this split between checking and researching in our scanners versus research category.

• A scanner asks: does this input match a known bad pattern?
• A researcher asks: what does this app assume, and what happens when that assumption is false?

Both questions are fair. The second one is where the high impact findings live, and it is the question UnboundCompute is built around.

Where this sits in autonomous penetration testing

Autonomous penetration testing is the idea that a system can plan and run its own security tests, not just replay a script. UnboundCompute fits there, but with a specific stance: the value is not in running more checks faster. It is in reasoning about the target, testing assumptions, and proving impact before saying a word.

Verification also pays off after the first run. Once a finding is confirmed, it can become a repeatable check that keeps watching for the same bug coming back. So the work is not throwaway. A proven issue today becomes a guard against regressions tomorrow.

Where we are right now: honest version

We are early. The product is being built, and we are not going to dress that up. We have no customer numbers to share, no benchmark to wave around, and we are not promising results we cannot back.

What we will say is this. In our own testing, a frontier model drove the full methodology on its own and identified and verified real access control and injection issues in test applications it had not seen before. We read that as an early, encouraging signal that the approach holds, not as a benchmark and not as proof. There is a long way to go from a good signal to a tool you can rely on every day, and that gap is the work in front of us.

The short version

UnboundCompute is a security researcher that runs on its own. It learns how an app is meant to work, guesses where the logic breaks, tests those guesses, and only reports what it can prove. That is a different job from a scanner reading a list of known payloads, and it is the job we think matters most. If you want to know who is building this and why, read more on our about page.

Frequently asked questions

What is UnboundCompute?

UnboundCompute is an autonomous security researcher for web apps and APIs. It learns how an application is meant to behave, forms ideas about where that logic could break, runs experiments to test those ideas, and only reports a finding once it is proven with concrete evidence.

Is UnboundCompute available to use yet?

Not yet. We are early and the product is still being built, so we have no customers, revenue, or benchmarks to share and we will not invent any. If you want to follow the work, read more on our about page.

How is this different from a vulnerability scanner?

A scanner reads a fixed list of known payloads and fires them at every input, which catches obvious and already known issues. UnboundCompute instead reasons about what the app assumes and tests those assumptions, so it can reach access control and logic gaps that no fixed signature would match.

Why does it report only proven findings?

A guess is not a finding. UnboundCompute reports something only when it can show the exact request that triggered the behavior and the response that proves the impact, so the output is signal rather than a pile of maybes you have to triage by hand.

Put an autonomous researcher on your own systems

UnboundCompute is an autonomous security researcher that reasons about how an application fits together and proves the access control and injection bugs it finds. We are opening a small number of founding design partner seats: private early access pointed at a staging target you choose, a say in what it looks for, and founding pricing. If your team ships software worth pressure testing, apply to the design partner program.