The method we automate
UnboundCompute runs the loop a strong human tester uses, continuously and without supervision. Each step exists to turn an assumption about the application into a provable contradiction.
Explore the live application 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.
Writing, soon
We are putting together longer pieces on reasoning about trust boundaries, designing crossings against a baseline, and turning findings into regression tests. We would rather publish something worth reading than something on a schedule.
Want the first posts when they land? The fastest way in is the access list.
Request access →