Inspiration
Security has always been the awkward guest at the developer table — invited late, blamed early. The average time to detect a leaked secret in a public repository is four minutes. The average time to exploit it is even shorter. Yet most teams still rely on weekly SAST scans, manual PR reviews, and the hope that someone will notice a hardcoded API key before it ships to production.
We wanted to flip that model entirely. Instead of security as a post-commit audit, what if it behaved like a senior engineer sitting beside every developer — one who reads every diff, understands context, and speaks up the moment something looks wrong? That's the idea behind SecureFlow: not a scanner that produces reports nobody reads, but an agent that reacts, reasons, and acts.
What it does
How we built it
The agent is a Python service deployed on Google Cloud Run, exposed as a webhook endpoint. GitLab project webhooks send push, merge request, and pipeline events to this endpoint over HTTPS.
When an event arrives, the service calls the GitLab API to fetch the relevant diff or file tree. That content is structured into a prompt and sent to Claude Sonnet via the Anthropic API. Claude's response is parsed into structured findings — each with a file path, line number, category, severity, and explanation — and then written back to GitLab as inline MR comments or issues via the GitLab REST API.
API keys (Anthropic, GitLab personal access token) are stored in Google Cloud Secret Manager and injected into the Cloud Run service at runtime as environment variables — no secrets in source control.
For the auto-remediation flow, Claude also returns a suggested patch. If the confidence score is high and the issue is low-risk to auto-apply (dependency version bumps, removing a committed secret and replacing with a placeholder), the service creates a new branch via the GitLab API, commits the patch, and opens a merge request linking back to the original finding.
The scheduled compliance report is triggered by a Cloud Scheduler job that hits the same Cloud Run endpoint with a scan_type: scheduled payload. Claude synthesises findings from the past 30 days into a structured Markdown report, which is committed to the repository.
Challenges we ran into
Accomplishments that we're proud of
We're proud that SecureFlow actually works on real code. During testing against open-source repositories, it correctly identified a hardcoded Stripe test key, three dependency CVEs, and an overly permissive IAM role in a Terraform file — all without any false positives on the surrounding benign code.
The auto-remediation flow surprised us with its reliability. For dependency version bumps, Claude's patches were correct and mergeable in every test case we ran. Watching the agent open a branch, commit a fix, and link it back to the original finding with a plain-language explanation felt like the right version of what AI-assisted development should be.
We're also proud of the token efficiency work. By triaging files before sending them to Claude, the average cost per MR analysis is under $0.01 — well within the range where teams could run this on every single push without a meaningful infrastructure bill. That efficiency is also why we're entering the Green Agents track: the agent does the minimum work necessary to catch the maximum risk.
What we learned
Context is everything in security reasoning. The same line of code can be a critical vulnerability or a completely harmless test fixture depending on where it lives and what surrounds it. LLMs are uniquely good at this kind of contextual judgment — better, in our experience, than regex-based scanners that treat every match as equally alarming.
We also learned that the most valuable thing an AI agent can do in a developer workflow is explain itself clearly. Developers don't just want to know that something is wrong — they want to understand why, and they want a path forward. Structuring Claude's output as explanation + severity + fix, rather than just a finding ID and a link to a CVE database, made a significant difference in how actionable the results felt.
Building on Cloud Run taught us to design for cold starts. Webhook handlers need to respond quickly, and a service that takes three seconds to initialise before processing a request creates a poor experience. Keeping the handler lean and deferring heavy work to async tasks was the right architecture for this use case.
What's next for The Idea: SecureFlow — AI Security Agent for GitLab CI/CD
The immediate next step is a configurable severity policy — letting teams define which finding types block a merge request versus which ones post a warning and proceed. Right now the agent comments and flags; giving teams control over the gate condition makes it production-ready for real workflows.
We want to extend the triage layer with repository memory: tracking which files have historically introduced issues, and using that signal to prioritise analysis on future MRs. Claude already reasons well about individual diffs; giving it a longer memory of a codebase's risk profile would make it significantly more precise.
On the compliance side, we're planning SARIF output so SecureFlow's findings can be consumed by GitLab's native security dashboard alongside other scanners, making it a first-class citizen in an existing security workflow rather than a parallel one.
Finally, we want to open-source the prompt templates and triage scoring model so the broader community can improve them. Security is a domain where shared intelligence makes everyone safer, and the best version of SecureFlow is one that benefits from contributions across many teams and codebases.
Log in or sign up for Devpost to join the conversation.