An autonomous security researcher for web apps and APIs.
It learns how an application is meant to work, forms ideas about where that logic could break, designs experiments to test those ideas, and proves a finding with hard evidence before reporting it.
Site · Security research · Free tools · Design partners
Most security tooling looks for patterns it already knows. Scanners fire a fixed list of payloads. A yearly pentest is a snapshot that ages the moment it ends.
The bugs that actually hurt are rarely a missing input filter. They are a line the application assumed would hold: one user reading another user's records, an endpoint that forgets to check who is really asking, a checkout flow that lets you skip a step. You cannot pattern match your way to those. You have to understand what the application is supposed to do.
The system is split in two, on purpose.
An AI proposes attacks and is allowed to be creative, speculative, and wrong. A separate deterministic checker then reproduces the exploit, and it is the only thing permitted to decide whether a finding is real.
That split is the whole design. It means the product cannot report something it has not proven. Every finding you receive is a recorded request, the response that should never have come back, and a replay your engineers can run themselves.
Understanding beats signatures. A finding worth your time comes from understanding features, roles, and trust boundaries, not from matching a template.
Proof, or it does not ship. Every reported crossing rests on a recorded request and a repeatable contradiction. If it cannot be proven, it is not a finding.
Permission is the first rule. Offensive work is only legitimate inside an authorized scope. That principle is built into how the product runs.
Findings should outlive the report. A confirmed crossing becomes a repeatable test, so a fix stays fixed instead of quietly regressing.
One system: an open substrate, with a hosted researcher on top. Each repo is a layer, not a side project.
security-agent-skills the method — how a security researcher thinks,
│ as portable skills any coding agent can run
▼
atropos ──▶ lachesis the model feeds the graph: atropos catalogs where
(sources, (compiler- untrusted data enters, must not land, and is made
sinks, precise safe again; lachesis parses real code into a graph
sanitizers) code graph) that follows how values actually move
│
▼
the autonomous researcher proposes hypotheses, designs tests, and proves
(hosted) findings with evidence over that substrate
- lachesis - a compiler-precise code property graph you can ask how data moves, who calls what, what reaches a sink. AGPL-3.0. The substrate.
- atropos - the taint-model knowledge base: sources, sinks, sanitizers, flow summaries. CC BY 4.0. The vocabulary.
- security-agent-skills - 33 tool-agnostic security-testing skills for AI coding agents. MIT. The method.
- free tools - 26 client-side security tools (CSP, JWT, CORS, headers…). No signup, nothing you paste is transmitted. The front door.
Everything runs in your browser. No signup, and whatever you paste in is never sent anywhere.
| CSP Evaluator | JWT Security Inspector |
| CORS Misconfiguration Checker | Secret Scanner |
| ReDoS Regex Analyzer | Subdomain Takeover Checker |
| MCP Server Security Auditor | OWASP LLM Top 10 Scorecard |
We write up the mechanisms behind real classes of bugs, in depth, at security.unboundcompute.com. Recent work covers prompt injection and agent tool abuse, MCP attack surface, TLS fingerprinting, ECDSA nonce reuse, and access control failures.
Lachesis is the code analysis layer we build on, released under AGPL 3.0. It parses a codebase into a code property graph that captures syntax, symbols, calls, and a full dataflow tier, then serves it to tools and AI agents through a navigation API and an MCP server. It is what lets a researcher ask precise questions about how data actually moves through source code, rather than guessing from text.
We are in private access, working with a small number of early teams as founding design partners who help shape what the researcher looks for and how the evidence reads.
Hiring: unboundcompute.com/careers.html Contact: riyan@unboundcompute.com