GitLab Duo Sentinel

GitLab Duo reviews code. Sentinel audits measured CI evidence and produces a traceable report for human review before approving a change.

Comment

Inspiration

Writing code is fast. Deciding whether a change is ready still requires a reviewer to connect several different signals: the intended scope, the actual diff, test results, security findings and policy checks.

We built Sentinel for small development teams that want a clearer review checkpoint. Its goal is to make the evidence inspectable before a person approves the outcome.

What it does

The workflow pairs real GitLab Duo Code Review flow sessions with a deterministic Sentinel audit in GitLab CI/CD. Duo reviews the code; Sentinel independently audits the execution evidence. The demo does not establish a native Duo-to-Sentinel MCP call.

The demonstrated pricing merge request contains Duo findings about non-finite inputs, monetary rounding and missing boundary tests, followed by reviews of corrections. These are real historical reviews of the revisions shown.

On a committed revision, Sentinel runs tests under coverage.py, reads the Git diff, compares changed files with a versioned scope policy, inventories imports and screens secrets and dependency license metadata. It records test output, coverage, source identity, findings and a scorecard as CI job artifacts.

The gate reloads those reports and verifies their commit and pipeline identity. Acceptable evidence produces AWAITING_HUMAN_SIGN_OFF; blocking findings produce REJECT_AND_BLOCK. The demonstrated clean main revision passes 28 tests with 83.20% measured engine line coverage. A separate, deliberately faulty merge request demonstrates a real rejected audit. This fault is isolated from main.

A reviewer inspects the outcome in GitLab. Sentinel does not merge or deploy the change.

Evidence in the final demo

The successful recorded revision changes .gitignore; it demonstrates the audit on that revision, not a new pricing-feature change. The report screens are labeled local read-only views of the original GitLab job artifacts. The French generated comment is shown with an explicitly labeled English translation; the original artifact is preserved.

How we built it

Four Python engines handle reconciliation, secret/license screening, carbon estimation and decision logic. GitLab CI executes the measured audit and retains its reports. The declared intent is a repository scope policy, not an automatically fetched issue.

Six tools expose the engines through a JSON-RPC stdio MCP server. Local subprocess tests cover protocol initialization, tool discovery, a tool call and error handling. A native Duo-to-Sentinel MCP connection remains unverified. The demonstrated sponsor integration is GitLab Duo Code Review flow together with GitLab CI; we do not claim that Duo invokes our MCP tools.

Engine coverage includes core and mcp_server, excluding the CI measurement harness, which has separate regression tests. Executed function lines are useful evidence, but they do not prove assertion quality. Commit/pipeline identity checks reduce revision mix-ups; they are not a tamper-proof signature of the entire evidence bundle.

Challenges we ran into

We had to distinguish a successful example from evidence generated by the actual revision. The audit now executes the tests, retains their reports and consumes the saved evidence at the gate.

The slim CI image needed Git installed before it could inspect repository changes. We also made merge-request pipelines read their complete base diff and replaced a known token signing default with a random process-local key. Cross-process token use requires an explicitly configured key; the token helpers are not an authenticated approval service.

Another challenge was presenting the integration honestly: local MCP protocol tests and historical Duo reviews prove different things. We keep that boundary visible in both the video and documentation.

Accomplishments that we're proud of

The demonstration connects concrete Duo review findings, measured CI artifacts and two distinct audit outcomes. Every displayed audit outcome is associated with its source revision and pipeline. Human responsibility remains explicit.

What we learned

Missing evidence should remain visible. A test name is not proof of execution, and a calculated decision is not an executed deployment. A useful audit gives reviewers enough context to understand both its result and its limits.

What's next for GitLab Duo Sentinel

Verify a native Duo MCP session, add a coverage-regression baseline and an actual SAST integration, and strengthen authenticated approvals. For environmental comparisons, replace static assumptions with measured inputs and establish a defensible baseline before claiming savings.

Current scope and limits

Carbon values model measured test duration using static resource and regional assumptions. They are not measured electricity use, whole-pipeline emissions, certified SCI compliance or demonstrated savings. Secret/license screening is heuristic; SAST and baseline coverage regression remain unverified.

Built with

Python, Git, GitLab CI/CD, GitLab Duo Code Review flow, coverage.py, Model Context Protocol (MCP).

Built With

Share this project:

Updates

Submission history