Inspiration
AI can propose a useful incident diagnostic, but reaching a machine and trusting its answer are separate problems. Dropline makes that boundary explicit: one policy-checked command, a signed request, an operator-controlled host step, and verification before the planner consumes the result.
What it does
Dropline is a signed, policy-gated request/result channel implemented in Rust with zero external Rust crates. It checks the command and intent against an argv-aware policy, authenticates requests and results with HMAC, and pins the exact request bytes. The local MCP tools expose the request, host result, and a strict verification verdict to GitLab Duo.
Real GitLab Duo demo
The 2:45 video shows a freshly captured run on merged main commit 501806bebf93d7bc7a823c4db8b8738933c7620e. The incident and host fixture are synthetic; the Duo sessions and tool responses are real.
Duo session 10016502 received a release-artifact mismatch incident with competing hypotheses and no prescribed diagnostic. It chose the read-only command sha256sum out/incident-host/release.txt, checked the policy, and filed a signed request. A separate operator host step executed that exact request. Duo session 10016506 called trusted verification before reading the result, then compared the observed checksum with the expected release checksum.
All six verification checks passed and execution_ok was true. Duo correctly concluded that the bytes differed while qualifying that a checksum mismatch alone does not prove the artifact's age or a cache-related cause. It did not perform remediation.
The video is an edited rendering of captured terminal output, with waits condensed, offline synthetic narration, and captions. Tool responses are not fabricated. Private signing keys are excluded.
How we built it
The Rust workspace contains the CLI and local MCP server. A Python standard-library rehearsal wrapper prepares isolated keys and runs the request, host, verification, and evidence checks. Keys stay outside the shared drop directory. Verification checks the pinned proposal bytes, command and intent, request authentication, result binding and integrity, result authentication, and freshness ordering before the planner reads stdout.
Public source and MIT license: https://gitlab.com/athulpsudheer/dropline Documentation and explainer: https://dropline-staging-f13e2d.gitlab.io Merged implementation MR !7: https://gitlab.com/athulpsudheer/dropline/-/merge_requests/7
Verified results
Main pipeline 2986449518 passed 20 jobs, including the signed incident-loop coverage and Pages publishing; the failure-only incident job was skipped. The real Duo rehearsal is separate evidence from the automated CI tests.
Pipeline: https://gitlab.com/athulpsudheer/dropline/-/pipelines/2986449518
Challenges and honest limits
This entry uses the Start Fresh: Assisted workflow: two real Duo sessions with an explicit operator host step. The ambient YAML flow is a draft and is not presented as an unattended working deployment. The demo validates a synthetic local incident, not a production environment. Dropline is not a sandbox. HMAC establishes possession of a shared key; filesystem freshness ordering is not an independent trusted clock or host identity.
What we learned and what's next
A trustworthy diagnostic needs evidence about both what was authorized and what actually ran. Separating execution success from verification success also prevents an authenticated failure from being mistaken for a successful diagnostic. Next we want deployment-specific integration and stronger independent host identity and time evidence, while retaining the explicit execution boundary. Outside the demo, those are future work.
Built With
- devsecops
- gitlab
- gitlab-ci
- gitlab-duo
- mcp
- rust
- security
