Warrant: Autonomy, Earned Per Change
Inspiration
AI coding agents can now generate code, write tests, and open merge requests at remarkable speed. But there is a fundamental problem: the agent writing the fix can also write the tests used to justify merging it.
A green CI pipeline does not necessarily mean a change is safe. Tests may be weakened, security vulnerabilities may remain, and an agent could even attempt to modify the pipeline responsible for checking its own work.
I built Warrant to explore a different approach: instead of trusting an AI agent by default, let every change earn its level of autonomy through independently checked evidence.
The principle is simple: trust should be earned per change, not granted per repository.
What it does
Warrant is an evidence-driven merge authorization and release system built around GitLab Duo and GitLab CI/CD. It evaluates proposed changes, determines whether they are ready to merge, and assigns an autonomy tier based on risk.
- Hands-off: Eligible application changes can be automatically merged and deployed after passing the required checks.
- Supervised: Higher-risk changes require human approval before merging.
- Assisted: Changes outside the automatic-authorization policy remain under human control.
Every change receives a deterministic verdict: READY, NEEDS_WORK, or HALTED.
How I built it
I developed Warrant as a solo project using Python, FastAPI, GitLab Duo flows, GitLab CI/CD, and a trusted verdict service.
The workflow begins when an issue triggers the build flow, which creates a merge request. An untrusted CI job then gathers evidence, including:
- Unit-test results and red/green testing against the base revision.
- Diff-scoped mutation testing to evaluate whether tests detect introduced faults.
- Tamper checks to detect weakened tests and unauthorized CI or governance changes.
- Static application security testing, secret detection, and dependency vulnerability auditing.
The trusted verdict service independently recomputes relevant change facts through the GitLab API, checks protected paths, applies deterministic policy rules, and publishes its decision. It does not execute agent-authored code.
When mutation testing identifies surviving mutants, a repair flow can generate additional tests and submit the change for another verification cycle.
Eligible changes proceed through a canary release workflow. Warrant can promote a healthy release or roll back a release that breaches its performance or error-rate limits. Verdicts and release events are recorded in a hash-chain ledger whose head is checked against a release anchor.
The system covers all nine DevSecOps lifecycle stages: Plan, Create, Verify, Package, Secure, Release, Configure, Monitor, and Govern.
What makes Warrant different
Traditional pipelines often produce a pass/fail result for an entire repository or merge request. Warrant combines evidence validation with change-specific risk classification.
A change to an ordinary application module can qualify for hands-off execution, while a new dependency, a large diff, or a sensitive file can require more oversight. Missing evidence, detected secrets, exhausted repair attempts, and agent-authored governance changes can halt automatic authorization.
This creates a practical path toward agentic software delivery without treating every AI-generated change as equally trustworthy.
Results and validation
I tested the implementation against a deliberately limited benchmark and exercised both successful and failed release scenarios.
- 9 of 10 seeded bugs caught by Warrant, compared with 0 of 10 caught by the baseline tests alone.
- 1 false merge occurred in the benchmark.
- 6 of 6 negative controls blocked.
- 10 of 10 known-good controls reached the hands-off tier.
- A real canary promotion and a rollback were recorded in GitLab evidence. The rollback triggered when p95 latency reached 803 ms against a 400 ms limit and completed in 1.2 seconds, within the configured 180-second deadline.
- The exported hash-chain ledger verifies against its anchor.
These are preliminary results, not proof of zero false merges. The benchmark contains 10 cases rather than the intended 30, and the surviving S05 bug exposes a limitation in the current mutation-testing threshold. The verification script correctly reports the 30-case benchmark and zero-false-merge targets as failing.
The rollback demonstration also uses a configurable delay to simulate a latency regression. The GCP deployment target is implemented but has not been validated on real Google Cloud infrastructure.
Challenges and lessons learned
The hardest problem was designing a trust boundary around an agentic workflow. Running tests is not enough if the same untrusted change can modify the tests, the CI configuration, or the policy that decides whether it should merge.
I addressed this by separating evidence collection from trusted verdict computation, keeping credentials out of merge-request pipelines, checking sensitive paths against the base revision, and recording decisions in an independently verifiable ledger.
Mutation testing also exposed a difficult trade-off: raising a threshold can reject faulty changes, but it can also reject legitimate changes with similar mutation scores. The S05 false merge demonstrates why a single threshold cannot replace broader benchmark coverage and stronger evidence.
Building Warrant solo also required balancing ambitious automation with verifiable functionality. I prioritized the core trust model, repair loop, release promotion and rollback, and audit trail over claiming integrations or deployment scenarios that have not been verified.
What's next
The next steps are to expand the benchmark to 30 independently sourced cases, eliminate the known false merge without blocking known-good changes, strengthen enforcement against manual merges of halted changes, and validate the deployment workflow on real cloud infrastructure.
I also want to integrate the verification MCP server more directly into supported agent workflows and measure how reliably the system handles diverse, previously unseen defects.
Conclusion
Warrant explores a future where AI agents can do more than generate code: they can participate in the complete software delivery lifecycle while being held to explicit, auditable evidence requirements.
The goal is not maximum autonomy at any cost. It is the maximum autonomy each change can justify.
Log in or sign up for Devpost to join the conversation.