RestoreLab

RestoreLab breaks a safe copy of your app, has AI agents collaborate to restore it in parallel sandboxes, and independently verifies which fix actually works — so you know your disaster plan works before the real disaster.

Inspiration

In 2017, GitLab.com accidentally deleted production data — then discovered their backups didn't work. They had backups; nobody had ever proven the recovery worked until they urgently needed it. Every team has this blind spot: a disaster plan on paper that's never been run end-to-end against the real product. We wanted to catch that before the real disaster.

What it does

RestoreLab breaks a safe copy of your app, has AI agents collaborate to restore it in parallel sandboxes, and independently verifies which fix actually works — so you know your disaster plan works before the real disaster.

Our MVP scopes this to one authorized scenario: a BOLA flaw (OWASP API1:2023) in a team-owned, synthetic multi-tenant API where one tenant can read another's records.

A red-team agent proves the weakness on a running target with real HTTP evidence.
Recovery agents start from the same broken baseline and race two fix strategies in isolated sandboxes, sharing findings but never credentials.
An independent verifier tests the restored product: foreign-tenant read denied, owner's read preserved, admin behavior intact, data unchanged, exploit no longer reproduces.
Only fixes passing every gate are eligible; the fastest verified one wins. An over-restrictive "fix" that breaks legitimate access is correctly rejected.

The key idea: an agent cannot mark its own fix successful. Only the independent verifier can call a recovery proven.

How we built it

A TypeScript/Node monorepo with clear ownership boundaries:

API + collective intelligence — a Hono server that is the single source of truth for runs, approvals, evidence, findings, verdicts and a gap-free event feed. It enforces the rules: no writes until human scope approval, findings must cite stored evidence, credentials are rejected, verdicts are immutable and verifier-only. Backed by SurrealDB with a provenance graph.
Target + red team — VAmPI (an OWASP-catalogued vulnerable API) as primary target, scope-guarded to owned URLs.
Execution — Daytona sandboxes give each candidate an equivalent, isolated baseline.
Verification + observability — a deterministic verifier returns PASS/FAIL/UNKNOWN with evidence; Arize AX traces every step.

Challenges we ran into

Making agent collaboration real without being unsafe — share evidence, never credentials or blind "apply my fix" recipes.
Building a verifier that trusts nothing, and correctly rejects an over-restrictive fix that passes the exploit test but breaks legitimate access.
Separating the API's own SurrealDB from hosted Agent Memory (different auth, different endpoints).
Scope discipline: proving one verified remediation loop honestly, rather than claiming "full disaster recovery."

Accomplishments that we're proud of

A working end-to-end loop: proven weakness → competing fixes in sandboxes → independent verification → evidence-backed recommendation.
A verifier that rejects a bad fix — the thing that makes "proven recovery" mean something.
A real agent-to-agent handoff that changes another agent's plan, without sharing secrets.
Clean integration of Daytona, SurrealDB and Arize, each doing a real job.

What we learned

Verification is the product — the independent verifier is what turns a plausible fix into trustworthy evidence.
Shared knowledge needs provenance, and must be revalidated in each new run, never blindly trusted.
Guardrails made the demo more convincing, not less.
Narrow and real beats broad and hand-wavy.

What's next for RestoreLab

Expand beyond authorization flaws to database-loss restores, corrupt backups and full application recovery.
Add an Anchor Browser end-user journey so verification covers the real user experience.
Generate human-reviewable runbooks and suggested PRs, behind human approval.
Deepen cross-run recovery knowledge that future trials reuse and re-validate.