VerdantFlow — Carbon-Aware DevSecOps for GitLab

Carbon-aware CI/CD meets smart vulnerability triage. VerdantFlow uses live grid data to cut pipeline emissions and reachability analysis to silence false security alerts.

Comment

Inspiration

I kept seeing the same two problems at every company I worked at. First, our CI/CD pipelines ran around the clock with zero awareness of where or when the electricity was cleanest. A pipeline running at 2am in a coal-heavy grid region produces 5-10x more CO2 than the same pipeline in a wind-powered region an hour later. Nobody tracked this. Nobody even thought about it.

Second, our dependency scanners were crying wolf. We'd get 15-20 vulnerability alerts per sprint, and after manually checking, maybe 3-4 were actually exploitable. The rest flagged functions we never called. After a while, developers just stopped looking at the alerts entirely, which meant the real threats got buried too.

When GitLab announced this hackathon with a Green Agent category, it clicked. What if one agent could tell you the carbon cost of your pipeline before it runs, and another could tell you which vulnerability alerts actually matter?

What it does

VerdantFlow has two agents and a shared MCP server:

The Carbon Advisor sits in GitLab Duo Chat. You ask it things like "which region should I run my pipeline in?" and it pulls live carbon intensity data from two free APIs (UK Carbon Intensity for 14 UK regions in actual gCO2/kWh, and WattTime for global coverage). It compares regions, calculates CO2 savings using the SCI formula, and recommends the greenest option. It also checks 24-48 hour forecasts so you can time-shift non-urgent jobs to greener windows.

The Supply Chain Sentinel is a flow you trigger by @mentioning it in an issue or MR. It reads your dependency files, identifies CVEs, then does something most scanners skip entirely: it reads your actual source code to check whether the vulnerable function is imported and called. If lodash has a template injection CVE but you only use _.merge, that's a false positive. The Sentinel filters it out and only creates issues for vulnerabilities where the code path is actually reachable.

The CI/CD pipeline itself queries live carbon data on every push. The first stage checks current grid intensity across regions, the last stage calculates your pipeline's carbon footprint using the SCI formula.

How we built it

The MCP server is Python with FastMCP, deployed on Google Cloud Run. It wraps two carbon APIs: the UK Carbon Intensity API (completely free, no auth, 14 regions with half-hourly data) and WattTime (free tier after registration, global coverage via a 0-100 relative index). The tricky part was normalizing data across sources since one gives absolute gCO2/kWh and the other gives a relative score. We built a cross-source normalization layer that scales everything to 0-100 for comparison, but preserves the original units when both sources are from the same system.

The agent and flow are YAML configs for GitLab's Duo Agent Platform. The agent uses Anthropic Claude through GitLab's managed credentials. The flow runs in GitLab Runner inside a sandboxed environment.

For the demo, we built a Node.js Express app with 6 intentionally vulnerable packages. Three have reachable code paths (express, axios, node-fetch are all actively used for carbon API endpoints). Three are false positives (lodash is imported but _.template() is never called, minimist is imported but parse() never runs, jsonwebtoken is imported but neither sign() nor verify() are invoked). This gives us a clean 50% noise reduction to demonstrate.

The whole thing costs nothing to run. Cloud Run scales to zero. Both carbon APIs are free. Anthropic runs through GitLab's managed tokens.

Challenges we ran into

I'll be honest, the flow sandbox nearly killed this project. Flows run inside a sandboxed container that blocks all outbound connections to external servers. We had a perfectly working MCP server on Cloud Run, and the flow just... couldn't reach it. The line Sandbox mode detected (GITLAB_WORKFLOW_SANDBOX=true) - skipping external MCP servers showed up in the session logs, but we only found it after hours of thinking the problem was tool authorization. That was frustrating.

The flow YAML schema was a guessing game. The template had toolset: [] and no docs explaining the correct format for actually adding tools. We went through maybe five or six validation failures. At one point I was convinced tools needed tool_name objects. Then plain strings. Then it turned out inputs needed from/as keys, except sometimes plain strings also passed. Basically: read the CI error, tweak the YAML, push, wait for the pipeline, repeat.

Electricity Maps was supposed to be our carbon data source. Signed up, got an API key, and then discovered the free tier only works for a single hardcoded zone. Multi-region comparison, which was the whole point, was paywalled. We switched to the UK Carbon Intensity API plus WattTime, and honestly it worked out better.

WattTime's v3 registration endpoint returned 403 errors from CloudFront for reasons I still don't fully understand. Their v2 API worked fine. Also, there's no web signup for WattTime. You register by sending a raw POST request to their API. Took me a minute to figure that out.

Accomplishments that we're proud of

The thing I keep going back to is that the pipeline carbon check uses real data. Not a mockup, not hardcoded numbers. When you push to this repo, the CI job queries the actual UK electricity grid and tells you which region is cleanest right now. It's maybe 20 lines of shell, but seeing real gCO2/kWh numbers show up in a pipeline log felt like a small proof that carbon-aware CI is actually doable today, not some future aspiration.

The demo app's vulnerability mapping is also tight. Each of the 6 packages has a specific CVE tied to a specific function, and we wrote the source code so that some of those functions get called and some don't. It's a clean ground truth for testing reachability. You can verify every classification by reading demo-app/src/index.js.

And the cost. The whole system runs on free-tier everything. No paid APIs, no always-on servers, nothing that expires. Someone could fork this, deploy the MCP server in 5 minutes on Cloud Run's free tier, and have it working.

What we learned

GitLab's agent platform is still early. The docs, the schema validation, and the sandbox restrictions all have rough edges. But the core idea is strong. Being able to define an agent in a YAML file and have it show up in Duo Chat is genuinely useful.

Carbon-aware computing is more accessible than I expected. I assumed you'd need expensive API subscriptions or complex integrations. The UK Carbon Intensity API is completely open, no auth, well-documented, and gives you half-hourly data for 14 regions with 48-hour forecasts. You can add carbon awareness to a CI pipeline in about 20 lines of shell.

The gap between "demo works" and "production ready" in AI agents is mostly about tool authorization and sandboxing. The prompts work, the logic works, but getting the platform to let the agent actually do things (read files, create issues) in a sandboxed environment is where most of the debugging time goes.

What's next for VerdantFlow

The first thing I want to fix is the sandbox problem. The Discord community pointed me toward bundling the MCP server locally into the project instead of hosting it on Cloud Run. That way the flow can talk to it without hitting the network sandbox. Should have done this from the start, but I didn't realize the sandbox was that strict until the flow sessions kept dying.

Beyond that, the piece that's missing is tracking trends over time. Right now each pipeline run is a snapshot: here's the carbon intensity, here's your footprint, done. Showing a chart of "your pipelines got 12% greener this month because you shifted nightly builds to off-peak" would make the data actually useful at a team level.

I also want to make the reachability analysis less reliant on the LLM's judgment. Plugging in Semgrep or CodeQL as additional data sources for call graph analysis would make the REACHABLE/NOT REACHABLE classifications more trustworthy. Right now it works, but I wouldn't bet production security decisions on it without that extra verification layer.

Built With

Share this project:

Updates