GitLab Guardian: Post-Code Incident Commander

Inspiration

Broken CI/CD pipelines, test regressions, security vulnerabilities, and leaked credentials create significant work after code is written. GitLab Guardian was created to explore a safer, reproducible approach to incident diagnosis and remediation, with human oversight.

What it does

GitLab Guardian is a reproducible proof-of-concept for post-code incident management.

It analyzes pipeline logs, identifies failure categories, checks for exposed credentials, generates reproduction tests and remediation proposals, and records decisions in a tamper-evident SHA-256 audit ledger.

The system operates in Assisted mode: human approval is required before changes can be applied. It generates structured Merge Request proposals but does not automatically create or merge real GitLab Merge Requests.

How we built it

We developed GitLab Guardian using Python 3.11+ and GitLab CI/CD, with configuration files prepared for GitLab Duo Agent Platform.

The implementation includes:

• Deterministic pipeline failure classification.
• Security checks and fail-closed controls.
• Reproducible test generation.
• Remediation patch proposals.
• Human approval gates.
• SHA-256 decision audit trails.
• Automated testing through GitLab CI/CD.

The project uses Python's standard library without requiring paid external APIs.

Challenges we ran into

The main challenges were preventing credential exposure, maintaining reproducible automated testing, and distinguishing actual platform execution from simulated behavior.

Hackathon subgroup provisioning and fail-closed cost governance: the hackathon-specific registration was approved on 2026-10-26T23:05Z, provisioning the gitlab-ai-hackathon/transcend-october-2026/43291390 subgroup and showcase project 88131246. Under a strict $0.00 USD free-first policy we ran exactly one authentic Duo session (#10098112, see the transparency section below), while the Guardian readiness gate itself stays fail-closed and the Guardian engine never invokes Duo remotely.

All demonstrated incident scenarios are synthetic. We do not claim that the local tests represent real GitLab Duo inference or production performance.

Accomplishments

• 42 automated tests passing.
• Four successful GitLab CI/CD jobs.
• Four validated synthetic incident scenarios.
• Security checks and mandatory human approval.
• Tamper-evident SHA-256 audit ledger.
• Reproducible benchmark covering 200 synthetic cases.
• Public GitLab repository with MIT License.
• Published demonstration video.

What we learned

Reliable automation requires more than generating recommendations. Security boundaries, reproducibility, traceability, and human approval are essential.

We also learned the importance of clearly separating local proof-of-concept functionality from native AI agent platform execution.

What's next

1. Live GitLab Duo Agent Platform cloud execution: one authentic Duo session has been verified (#10098112, Developer flow on a synthetic MR). Next, bind the declarative tool handlers in .gitlab/duo/agent.yml to live GitLab Duo Agent Platform workflow triggers so that Guardian itself drives flows, and capture remote execution traces for Guardian incidents (including code_review/v1 and fix_pipeline/v1, which are enabled but were not triggerable/used).

Future improvements include creating real Draft Merge Requests through GitLab APIs, integrating native security scan artifacts, and testing against real-world incident datasets.

Source Code and Evidence

Public GitLab Repository: https://gitlab.com/hg-stack-group/gitlab-guardian

Verified GitLab CI/CD Pipeline: https://gitlab.com/hg-stack-group/gitlab-guardian/-/pipelines/2991935711

Demo Video: https://youtu.be/_80GZfYpXew

Validated source branch: docs/devpost-final-alignment

Hackathon Track: Path A — Start Fresh

Autonomy Level: Assisted

Important disclosure: GitLab Guardian does not invoke GitLab Duo automatically; the Guardian-to-Duo binding remains declarative (.gitlab/duo/agent.yml). The Guardian workflows execute locally and through GitLab CI/CD using synthetic test cases. Separately, one authentic live GitLab Duo Agent Platform session was run on a synthetic MR in the hackathon showcase project (see below).

Transparency note for judges

1. Live GitLab Duo Agent Platform Cloud Execution (one authentic session, scope-limited, disclosed):
2. Verified authentic session: session 10098112, foundational Developer flow 3.0.0 (developer/v1), model claude_sonnet_5_5_vertex, CI job 17489077524, created -> running -> finished in ~45 s on 2026-10-27 01:33-01:34 UTC (2026-10-26 22:33 ART). Triggered by an @-mention of @duo-developer-gitlab-ai-hackathon on synthetic Draft MR !1 (branch duo-synthetic-review-20261027, commit b6270828041bb2257a21954b475501d1b080673f) in the Transcend showcase project 88131246: https://gitlab.com/gitlab-ai-hackathon/transcend-october-2026/43291390/showcase/-/merge_requests/1
3. Result: Duo identified the synthetic add() bug (subtracts instead of adds) and suggested "return a + b" in a comment. No commits, no merge, no proposal applied, no retries.
4. Exact scope (what this does NOT show): the session did not run the Guardian Python engine and did not process Guardian fixtures; Guardian does not invoke Duo automatically. It proves real use of GitLab Duo Agent Platform (a foundational flow running remotely in the hackathon project), while the Guardian-to-Duo binding remains declarative. The Code Review Flow (code_review/v1) is enabled but could not be triggered ("No triggers for this event"), so the Developer flow was used.
5. Entitlement and cost evidence (read-only GraphQL, before the run): gitlabCreditsAvailable=true, creditsUsage.enabled=true, creditsUsed=0, blockedStatus.blocked=false. Incremental cost: USD 0.
6. Note: the YouTube video narrates the target Duo Agent architecture while displaying the local deterministic run_demonstration.py simulation; the live Duo session is documented here and in the repository, not in the video.

Built With

• cybersecurity
• devsecops
• gitlab-ci
• gitlab-duo
• python