Relay Desk

A separate protected build passed; candidate repair and release build are distinct records.
GitLab MR !4 changes cache scope from the organization to the individual actor.
Collaborator searches the shared invoice ticket; synthetic private notes stay out of this view.

Why I built Relay Desk

Sharing a support ticket is a small, ordinary action with an awkward question behind it: which parts should the next person see? A colleague may need the invoice conversation, while the support team's private notes should stay inside the team. I wanted to make that boundary visible in a working product, including the less obvious places where information can escape.

Relay Desk is a new support application built for this event. Its sample workspace has internal users, collaborators and people from another organization. The demo follows an invoice search through those different roles. The useful public subject and excerpt remain available to a collaborator, while internal context stays with the team. Exports and notification data are part of the same question, so the walkthrough continues beyond the first search.

What GitLab does after the code

I deliberately introduced a cache bug that remembered the organization but failed to distinguish the people inside it. The first request could look correct while a later person received somebody else's cached result. That gave the project a concrete failure to investigate and a clear way to judge a proposed repair.

A registered GitLab Duo Agent Platform flow received the relevant source and failure information. The successful investigation proposed adding the person's identity to the cache key. The controller checked the complete proposed edit, created a merge request and followed the candidate through GitLab CI. A separate protected release project built the full application, staged the resulting image, checked the actual responses, promoted it and observed production.

This is an Assisted workflow. The recorded release had eight separately approved operator decisions, exercised through authenticated automation. Those approvals are visible parts of the design. The model's contribution is the proposed source change, and the surrounding software carries out the reviewed release operations.

The difficult part

A privacy fix can appear successful simply because it refuses every request. I needed checks for legitimate sharing as well as checks for unwanted access. The evaluator therefore looks at complete responses and the actor making each request. A subject that remains useful to a collaborator matters just as much as a private field that stays hidden.

An earlier genuine proposal changed a deliberate fault control and was stopped before candidate creation. Keeping that rejection helped me make the review stricter. The later completed run passed the protected release chain and merged the checked change in merge request 4 on October 22. Earlier failures remain available in the evidence.

What I learned and what comes next

The project made me treat a cache entry as a permissions decision. I also learned to keep a repair proposal, a green pipeline and a verified application response connected to the same version.

Relay is aimed at teams building shared support tools and the developers maintaining their access rules. The demo uses synthetic support tickets, so the permissions can be inspected without exposing a real conversation. Next I would add more policy changes during active sessions and invite support teams to try the sharing workflow. The public walkthrough, MIT source, visible CI and short film let judges inspect the current result without private operator credentials.

Try the project | MIT source and CI | Watch the demo