RepairGate

One detected defect. One proposed repair. Reproducible checks. A recorded human decision.

RepairGate helps a developer evaluate an agent-proposed security repair by connecting the defect, exact candidate bytes, regression results and an authorized outcome decision. It demonstrates a synthetic multi-tenant SQLite order lookup; it records acceptance rather than deploying an application.

What it does

A custom GitLab Duo Agent Platform flow reads the lookup, writes a data-only JSON query proposal and runs scan/verification commands. A deterministic verifier reproduces the baseline injection and tests that proposal in fresh Python processes. CI retains snapshots, JUnit results, code/evidence hashes and a hash-chained audit. Approval reruns the checks and records the decision for that exact run.

The unchanged genuine proposal has SHA-256 a39dba8b8032de7b26fa0e6839df38c15c38067a05e0e28f70ec01a3ca9a54d3.

Security protections now adopted

Adversarial review found that a hidden-trigger query could pass the old finite test suite. Current main closes that boundary: the lookup accepts only two equivalent tenant-and-order equality forms, then executes the recognized canonical query with bound parameters. Arbitrary predicates, OR triggers, UNIONs, subqueries and comments are rejected before execution. The tests supplement this policy; passing tests alone is not the isolation mechanism.

A separately protected verifier now fetches only the bounded proposal at an explicit full Showcase commit SHA. It never clones or imports candidate Python, executes candidate CI, or accepts candidate-authored reports. Manual external approval re-fetches the bytes, checks source/root/pipeline bindings, reruns the trusted verification and records the GitLab-authenticated actor. The private verifier's protected branches and approval environment were verified as Maintainer-only, while proposer bots are Developers.

Both hardening MRs are merged. Adopted verifier root d3ea6d47576984787e4527ff4b1adb1b47074f5d accepted exact public source de7faff0b3bf9e2517933de101978fba3f0d2e91, with successful manual approval. The same root rejected a hostile candidate whose own CI was green, and skipped approval. A missing-candidate-input control also failed closed.

Judge inspection: no private access needed

The security archive is a byte-for-byte operator export of synthetic artifacts. Judges can inspect and hash it anonymously; copied JSON is not a signature or independent proof of a private job's authenticity. Authorized reviewers must inspect the originating GitLab jobs against the adopted full verifier SHA for trusted acceptance. The archive approves the recorded source revision, not future documentation or code commits.

How we used AI

The genuine custom Duo flow ran in the private development project (session9868050, job17372153956). It read source and the public fixture, wrote the proposal and invoked scan/verification tools. Because it saw the fixture and produced matching SQL, no novel SQL invention or blind evaluation is claimed. Public excerpts preserve the original null commit context and non-attested provenance. They are not a new Showcase Duo execution.

The category is Start Fresh Supervised. The flow executes multiple steps before a human outcome decision. Operator transfer to an MR and publication/merge remain manual orchestration; this is not hands-off deployment.

Codex built and tested the prototype, reconciled review findings, operated GitLab under Roy's authorization, and verified downloaded artifacts. Roy approved adoption, manual decisions and merge; Codex executed those actions under his signed-in account. This is not a second independent human approval. Grok Bot independently reviewed an earlier local snapshot without private GitLab access. GitLab Duo reviewed and approved the final verifier correction.

Reproduce locally

Python3.12+ and standard library only; no credentials, paid services or package installation.

git clone https://gitlab.com/gitlab-ai-hackathon/transcend-october-2026/21511976/showcase.git repairgate
cd repairgate
python3 -m unittest discover -s tests -v
python3 -m repairgate scan
python3 -m repairgate verify --proposal proposals/duo.json --out artifacts/judge-run-01
python3 -m repairgate audit --run artifacts/judge-run-01

Expected: 34 tests pass; candidate31/31; vulnerable baseline11/31 and fails overall; state awaiting-human; one evaluation audit event. Use a new output directory each time. Open artifacts/judge-run-01/review.html. This fresh local run is not already human-approved. The evidence archive includes a hostile proposal that must fail verification.

Demo and architecture

Watch the captioned 2:35 demo. Its private-origin execution and approval captures are historical; the new protections above were adopted afterward.

The dashboard source and instructions reproduce the filming wrapper: run python3 demo/server.py and open localhost:8767. Its first two controls run real synthetic code; the third displays a bundled historical public approval. It cannot issue a new approval or approve the current security release.

Operator trigger → Duo query proposal → closed query policy → independent verification → retained evidence → authorized manual outcome decision. Lifecycle stages: Create, Verify, Secure, Govern.

What we learned and remaining limits

Finite public tests can miss malicious triggers. Enforcing a narrow policy at the query sink and moving verification outside candidate control are different, complementary protections. Exact revision and evidence bindings matter more than a green candidate-owned badge.

This remains a synthetic query-only prototype. Local actor names are self-asserted; hashes cannot authenticate an entirely rewritten archive. Trusted-root administrators, runners and reviewer accounts remain trusted. There is no cryptographic signing, automatic Showcase merge-policy enforcement, production deployment or universal security guarantee. Exclusive approver settings in Showcase were not independently inspectable; the separate verifier's controls are described separately.

The project is submitted, not a claimed judging result. Customer impact, labor savings, revenue, Google Cloud and sustainability outcomes are unverified. Next work is validation in a real developer workflow.

GITLAB is a trademark of GitLab Inc. in the United States and other countries and regions. RepairGate is independent; no endorsement is claimed.

Built With

Share this project:

Updates

Submission history