The method we automate
UnboundCompute runs the loop a strong human tester uses across authorized research runs. It reads your source and probes your running app, and each step exists to turn an assumption about the system into a provable contradiction.
Read the source and explore the running app the way a person would: features, roles, objects, workflows, state, and the trust boundaries between them.
For each feature, work out the rule the app is meant to enforce. Only the owner can refund. An invite works once. Each rule is a boundary to test.
Turn each assumption into the exact request that should be blocked, always measured against a normal, authorized baseline.
Confirm a crossing with hard evidence, a real and repeatable difference between what should happen and what did. Otherwise, drop it.
Feed every confirmed result into the next idea, following the thread the way an attacker would instead of stopping at the first crossing.
Research notes
What we are actually learning while we build the researcher, including the parts that did not work. We would rather write down a result that surprised us than post on a schedule.
We expected our dataflow and taint layer to carry most of memory-safety analysis. It does not. A whole class of bug, an integer that wraps and then narrows into a smaller signed type, is a local property: the dangerous value is computed and used inside one function, with nothing flowing in from outside. Taint, reachability, and points-to add nothing there. The lesson we keep relearning is that no single technique covers memory safety, and the honest move is to add a model for the class you are missing, not to stretch the one you have.
We optimize for precision, not coverage. A finding only ships with repeatable evidence, and anything ambiguous is suppressed with a written reason instead of presented as a finding. Much of the engine's work is proving code safe, ruling out cases that cannot matter so a person only looks at the few that can. Five findings you can ground beat a hundred you have to triage. A tool that cries wolf gets turned off in a week.
How do you know the finder is any good? Re-finding a known bug proves little if you told it where to look. Name the function in the prompt and you have measured recall of a hint, not discovery. So we separate the two: rediscovery on public, already-fixed bugs to check the mechanism, and blind runs with no hints to measure real discovery. When a result is not clean, we say so. Most of what we learn comes from the runs that fail.
Want the first posts when they land? The fastest way in is the access list.
Become a design partner →