Every release ships a clearance report
One release pipeline, every stage
The triage agent writes the plan
The permission slip.yml: what each agent may do, in which folders, until when. Pipeline, slip and infra are off limits. Read from main only.
Only the story’s owner can say go
Vague story: go signal refused
A drill breaks staging on purpose. The watch spots it, rolls back, and opens a story about it. Production is never touched.
Hotfix shipped without waiting for the train
On staging, a browser runs the story's own test IDs and posts the results on the story. Only then is it marked shipped.
Asked to change files outside its slip, the coding agent stops and says why, instead of trying anyway.
When the checks and review are done, the decider, plain code with no model, hands the MR to a person and says why.
Duo Code Review leaves a comment, the agent answers it and pushes one fix. Three rounds at most, then a person.
The agent touched a file outside its folders. The slip check names the grant it broke, and the merge is blocked.
The agent edited requirements.txt, a file only people may change. The slip check says ambiguous: a person must decide.

Slipstream lets AI agents ship code with permission and proof. Every agent holds a permission slip: what it may change, in which folders, and until when. Plain code checks it on every change, people approve the go signal and production, and every release ships with a clearance report. To prove it on real work, we ran it on Consentinel, an AI app of ours that is live on Google Cloud.

Inspiration

AI agents can now open a merge request at 3 a.m. Nobody can say afterwards what the agent was allowed to do, whether it stayed inside that, or who signed off. Teams either keep agents on a short leash and do the work themselves, or let them loose and hope.

We wanted a third option: give each agent written permission, like a signed slip, that is scoped, expires, and is checked by plain code, never by the agent itself. The idea came from our own app, which tracks exactly this kind of permission for people.

What it does

Slipstream takes a story from a GitLab issue to production:

Triage. When a story is opened, a custom GitLab Duo flow reads it and the code, then posts a plan (files, acceptance checks, the browser test that proves it) or up to five questions. It can only comment.
Go signal. The story's owner says go. Only the owner can; anyone else is refused.
Coding. GitLab Duo's Developer flow builds it on an agent/ branch, following AGENTS.md. Every commit names the agent and the model.
Gates. Tests, an eval gate, SAST, secret detection, a planted attack set, and the slip check: was this agent allowed to touch these files? It answers authorized, unauthorized or ambiguous (ask a person), and an error always means doubt, never permission.
Review. Duo Code Review tags each comment critical, warning or info, plus a risk level. The coding agent answers, at most three rounds. A plain-code decider, never a model, picks the next step: another round, hand to the owner, or escalate to a draft marked needs-human.
Merge. A person merges.
Release. A release train (or an immediate hotfix) builds the image, deploys to staging and runs QA in a real browser, with results and screenshots posted on the story. Only the owner can approve production; it is a protected environment.
Watch and roll back. After the deploy, the watch checks the live site and Cloud Monitoring (5xx rate and p95 latency against the previous version) and moves traffic back if the new version is worse, opening a story.
Clearance report. Every GitLab release carries a report: for each change, who or which agent made it, the model, every check, who reviewed and merged, and a state of cleared, blocked or unverified. Anything that didn't run is unverified, never cleared. It ends with a carbon estimate.

Proof it ran

Story #9, end to end: triage plan, go signal, agent MR !14, two Duo review comments, the agent's fix, Duo's approval, a person's merge, QA on staging, production. Its row in release v2026.10.27-485 is the first change marked cleared.
Story #7: the real coding agent stopped itself before writing anything, because the fix needed files outside its slip, and said so on the story.
MRs !19 and !20: rule-breaking gate tests. One changes a file outside the agent's slip (verdict unauthorized), one edits requirements.txt (verdict ambiguous, ask a person). Every test passed; the slip check refused both, and the decider turned them into drafts for a person.
Story #10: a vague story. Triage asked five questions, and the router refused the go signal until they were answered.
Story #11: the go signal from someone who isn't the story's owner was refused, and triage wasn't taken in by instructions planted in the story.
Story #12: a hotfix. The agent's MR !21 was titled "Hotfix:", shipped without waiting for the train, and the story was told it was live in production.
Release v2026.10.27-763: six of eight changes cleared, including changes written by people, with Cloud Monitoring numbers in the production-watch line.
Story #13: a rollback drill. Staging was broken on purpose, failed 25 of 25 checks, and traffic went back to the healthy version on its own.

Before and after (Path B)

The app Slipstream runs on is Consentinel, an AI app we built earlier and keep live on Google Cloud Run. Everything in the "after" column is new work for this hackathon: the agents, gates, pipelines, reports and deploys.

Before (GitHub, by hand)	After (GitLab, with Slipstream)
One person deployed from a laptop	Pipeline deploys with keyless Google Cloud login; only protected `main` can deploy
No record of who or what changed a line	Every change carries agent, model, checks, reviewer and merger in a release report
GitHub Actions ran tests and evalsets, and nothing after that	Tests, eval gate, SAST, secret detection and the slip check on every merge request, then a release pipeline to production
No staging, no browser checks	Staging with seeded demo data; Playwright QA posts results on the story
A bad deploy stayed until someone noticed	Production watch with Cloud Monitoring and automatic rollback
Stories closed when someone remembered	Stories close only when they ship

How we built it

GitLab Duo Agent Platform. A custom flow (triage) defined in YAML and registered in the AI Catalog, triggered when a story is created or the agent is mentioned. The foundational Developer flow as the coding agent, triggered by assignment. Duo Code Review with custom review instructions for severity and risk lines.
The glue is plain code. GitLab doesn't let a bot fire a flow trigger, so a project webhook starts a small "route" pipeline that reads the event and moves the story along with scoped labels (slipstream::triage, ready, in-progress, needs-review, shipped). The decider, slip checker, QA runner, release notes, clearance report and production watch are Python modules, covered by the repo's 1,108 tests.
Trust boundaries. The slip and the checker are always read from main, so a merge request can't change its own verdict. Agent branches get no cloud credentials. Issue and comment text is treated as data, never as instructions. A person is recognised from an allowlist in slip.yml, not from anything a commit author can set.
Google Cloud. Cloud Build and Artifact Registry for the image, Cloud Run for staging and production, Workload Identity Federation so GitLab never holds a key, Cloud Monitoring for the watch.

Challenges we ran into

Bots can't trigger Duo flows, so every agent hand-off had to come from a person's action or a webhook pipeline.
GitLab refuses HTML comments inside flow prompts, and the trigger passed only an issue number, so the triage agent's first run couldn't find the issue.
Our agent image had no git, which silently broke every Duo session for an hour.
Running real stories end to end found bugs no unit test had: a late triage comment could wipe a go signal that was already given, a later merge auto-canceled a hotfix pipeline, stories closed at merge instead of when they shipped, and earned autonomy was built but never scheduled. Each got a fix and a test.
We ran out of CI minutes the night before the deadline.
Our own reviewer kept us honest: Duo Code Review caught a fail-open identity check, a drill pipeline that would have offered a production button, and a cleanup that could leave staging broken. We fixed each before merging.

Accomplishments that we're proud of

A real agent-made change, cleared in a real release report, with every check visible.
Agents that are refused by plain code, not by politeness: !19 and !20 were stopped with every test green.
A rollback that we proved by breaking staging on purpose.

What we learned

The model is rarely the risky part. The risky parts are the hand-offs: who may say go, who may merge, what an agent may touch, and what counts as done. Writing those down as a slip, and letting plain code enforce it, made the agents easier to trust and easier to audit.

What's next for Slipstream

Close the gaps we know about: apply the reviewer's risk level as a label that picks the pipeline profile, have triage flag planted instructions as suspicious instead of only ignoring them, and build hotfixes from the last release tag instead of shipping main as it is.
Earned autonomy: a clean record in a folder proposes a wider slip; a rollback narrows it. A person approves every change to the slip.
One-command setup: a Claude Code plugin that installs Slipstream on any GitLab project or group (labels, slip, CI jobs, triage flow, webhook) and walks the person through the steps only they can do.