Clearance

Inspiration

Every team adopting coding agents hits the same wall after the code is written. Either a human approves every agent change, so the agent is only as fast as the slowest reviewer and reviews turn into rubber stamps, or agents are kept away from production and nothing after the code gets automated.

This hackathon asks teams to pick a level of autonomy. On a real team, nobody picks a new engineer's autonomy once: they earn it, area by area, from a track record, and lose it when they break production. We wanted AI agents to work the same way.

What it does

Clearance gives every AI-authored change a lane:

• 🟢 GREEN (Hands-off): issue → merge request → independent AI review → merge → staging → production canary → promote → watch, with no human involved.
• 🟡 AMBER (Supervised): the same, but a human approves the outcome with one click after a healthy canary.
• 🔴 RED (Assisted): a human approves the merge and every delivery step.

The codebase is split into zones (menu, orders, payments, auth, platform, governance). For every change, Clearance combines:

• the trust agents have earned in the weakest zone the change touches
• risk signals: size, untested code, dependency changes
• security findings in the changed files (GitLab SAST, secret detection, bandit, pip-audit)
• an independent AI reviewer that can only add caution, never remove it

Trust comes from production, not opinions:

• Earned: a change that survives in production credits its zones. 3 survivors take a zone RED → AMBER, 5 more AMBER → GREEN.
• Lost: a change caught by the canary costs one level; one that reaches users costs two.
• Capped: payments and auth can never go hands-off, and the agents' own rules can never leave RED.

Every promotion, demotion and incident is a commit on a ledger branch, so GitLab's history is the audit log. When a change breaks, Clearance rolls back, opens an incident, demotes the zone and hands it to a Responder flow that writes a regression test, a fix and a postmortem. The fix travels in a stricter lane.

What ran live on GitLab

• Hands-off, zero clicks: "add opening hours to the shop" went from issue → plan → code → review → 🟢 GREEN → auto-merge → canary → promote → live, with no human action after the issue.
• Trust earned: an orders change shipped AMBER (one click), survived, and the watchtower promoted the zone AMBER → GREEN.
• Risk stays human: a one-line wallet fee in payments shipped RED. The planner predicted it: "RED because of earned trust in the payments zone, not because of size." The reviewer rated it medium: "the 1% rate is a business decision; a human should confirm." Payments then earned its ceiling, AMBER.
• Bad changes stopped: a "sort specials by price" change would crash on an item priced "at the counter". It was blocked before merge by tests earlier agents wrote on production data, and the reviewer named the exact None < int bug. A checkout panel that showed customers less than they'd be charged was rated high by the reviewer and pulled out of hands-off, even in a trusted zone.
• The full failure loop (canary catch → rollback → demotion → Responder fix → stricter lane) runs against the real app in make simulate, which runs in every pipeline.

How we built it

• GitLab Duo Agent Platform:
  • Builder flow (Assign/Mention): planner → implementer → reviewer. The planner checks its own clearance before writing code.
  • Reviewer flow (MR created / Assign reviewer / Mention): an independent risk verdict on any MR.
  • Responder flow (pipeline failed): triage → fixer → reviewer.
  • Clearance Officer: a custom chat agent that explains lanes and trust from the live ledger.
  • An MCP server so any agent can ask for its clearance before acting.
• The Clearance engine (Python standard library) in GitLab CI: gate on merge requests (Clearance card, lane label, auto-merge or approval rule), route generating a dynamic child pipeline per lane, record / incident on delivery, and an hourly watchtower schedule for survival and promotions.
• Delivery: container registry, staging, a zero-traffic production canary with synthetic user journeys, lane-gated promotion, automatic rollback, GitLab Releases with evidence.
• All nine DevSecOps stages: Plan, Create, Verify, Package, Secure, Release, Configure, Monitor, Govern.

Challenges we ran into

• Composite identity: Duo flows act on behalf of the human who triggered them, so agent MRs showed a human author. Clearance now also recognises agent work by the branches the flows push to.
• Prompt security: GitLab rejects HTML comments in flow prompts, so the reviewer's machine-readable verdict became a plain-text marker.
• Lanes are decided at run time, pipeline rules at creation time: solved with a generated child pipeline per lane.
• Restricted permissions: without pipeline variables or trigger tokens, any scheduled pipeline runs as the watchtower.
• Spam protection blocked API edits to issues, so trust is shown from the ledger branch and the Officer agent.

What we learned

Autonomy isn't a property of an agent. It's a property of an agent in a part of your system, and the only honest way to measure it is what happens in production. And the AI reviewer is most valuable when it can only add caution: it caught two real bugs that a "trusted" lane would otherwise have shipped.

Built With

• ai-agents
• ci/cd
• docker
• gitlab
• gitlab-ci
• gitlab-duo
• gitlab-duo-agent-platform
• mcp
• python