-
-
Access Guard — one issue to an independently verified release.
-
Recorded final pipeline #2971862327: six successful jobs on the verified main commit.
-
Original issue #12: the passed controller receipt connects the complete recovery chain.
Inspiration
Restoring a backup should recover data while preserving the security decisions made since that backup was created. A revoked grant returning after restoration is a small-looking state inconsistency with a serious consequence: access that should remain denied becomes available again. We built Access Guard for the platform, DevOps and application-security teams responsible for that boundary.
The project's value is concentrated at a critical operational moment. It combines an executable recovery-security contract with an autonomous delivery loop, reducing the manual coordination between diagnosis, repair, verification, integration and release.
What it does
One human assigns a structured recovery issue to a dedicated GitLab Duo flow. Duo examines the failed seed pipeline, reads the application at the exact seed revision, diagnoses the behavioral regression and creates a bounded correction in a new branch and Draft MR.
Independent CI verifies that candidate. A protected controller then checks the issue, MR relationships, commit identities, allowed changes and structured receipts. It merges the correction into the seed, waits for the updated seed's checks, integrates the result into main, and follows package creation, GitLab Release and downloaded-package verification. A matching completion receipt is posted on the original issue only after those stages pass.
The application keeps revocation authority outside the restored snapshot. It preserves independent grant sources, organization boundaries, snapshot integrity and session invalidation. Access-grants and API-key adapters exercise the separation between a reusable controller and application-specific behavioral contracts.
How we built it
Access Guard uses Python and SQLite with the Python standard library. The GitLab implementation combines a native Duo custom flow and issue-assignment trigger with merge-request CI, structured test receipts, a protected default-branch controller, the GitLab SAST template, a generic package registry, commit-bound Releases and final adapter smoke checks.
The agent generates the repair; a separate verifier and controller decide whether delivery may proceed. The privileged merge credential is restricted to the protected controller environment and is absent from candidate jobs. Every downstream decision is bound to the specific commit and evidence being accepted.
Challenges we ran into
An agent reporting Finished proves that its repair phase ended. A green MR alone also leaves integration and delivery unproven. We connected the entire chain so that successful candidate checks hand off to a trusted controller and completion depends on the resulting main revision and the actual delivered package.
Recovery also needs source-aware authorization. Two independent sources can grant the same right; revoking one must not erase the other, and restoring an older snapshot must not revive the revoked source. Those distinctions are explicit in the behavioral tests.
Accomplishments that we are proud of
The recorded run generated a new correction, passed 69 unit tests, automatically completed both merges and finished all six final-pipeline jobs. Release v0.1.106, its package digest and the passed issue receipt connect the result to the exact main commit. There was no manual code change, merge or release action after the initial human assignment.
The video shows that real workflow in chronological order, with waiting periods accelerated and playback rates displayed. Main contains the corrected application; the deliberately faulty seed is the reproducible test input.
What we learned
Useful autonomy depends on clear division of responsibility. The agent needs enough freedom to diagnose and repair the defect; acceptance needs independent evidence, narrow authority and immutable identities. A completion claim should be the consequence of a verified delivered result.
What's next for Access Guard
The controller/adapter boundary provides a concrete route to more applications and recovery invariants. Additional languages and storage systems would need their own adapter contracts and verification evidence. The current working delivery is a Python command-line prototype released through GitLab; production identity-provider integration and operational hardening are future work.
Log in or sign up for Devpost to join the conversation.