Blast Radius Guardian

A blast radius guardian that analyzes the downstream impact of a merge request and posts a structured blast-radius report directly on the merge request.

Comment

Inspiration

Code reviewers focus on what changed — but rarely on what breaks downstream. Every day, engineers merge code without knowing which sibling projects import their modules, whether those projects have failing pipelines, or who the right people to notify are. Production incidents caused by invisible cross-project dependencies are a well-known but unsolved pain point in large monorepo and multi-repo organizations. We wanted to make hidden blast radius visible before the merge button is clicked, not after an on-call alert fires at 2 AM.

What it does

Blast Radius Guardian is a GitLab Duo agent that answers one question with evidence: "If this merge request is merged, what else breaks and who needs to know?"

When invoked on a merge request, it:

  • Reads the MR diff and classifies changed source files
  • Queries GitLab Orbit's knowledge graph to discover same-project and cross-project dependents
  • Checks pipeline health for every impacted downstream project
  • Identifies the top contributors to those projects as suggested reviewers
  • Surfaces open critical and high security vulnerabilities in impacted projects
  • Computes a transparent, heuristic risk score (0–100) with full arithmetic shown
  • Posts exactly one structured report as an MR comment — never partial, never fabricated

Risk levels range from NO BLAST RADIUS through LOW, MODERATE, HIGH, and CRITICAL.

How we built it

Blast Radius Guardian is a GitLab Duo agent defined in a single blast-radius-guardian.yaml file using the GitLab AI Catalog agent format.

The agent operates in two strict phases:

  1. Evidence Collection — all Orbit graph queries, diff analysis, pipeline checks, reviewer discovery, and vulnerability lookups are completed before any output is produced.
  2. Report Generation — a single, fully-formed MR comment is posted using create_merge_request_note.

The core toolset is:

  • get_merge_request + list_merge_request_diffs — read MR context
  • query_graph — traverse GitLab Orbit for dependents, pipelines, contributors, and vulnerabilities
  • get_graph_status / get_graph_schema — validate Orbit availability
  • gitlab_search — supplementary project discovery
  • create_merge_request_note — post the final report

Supporting Python services (MRAnalyzer, PipelineAnalyzer) handle risk context building, payload classification, and score computation.

Challenges we ran into

  • Scoping Orbit queries correctly. Cross-project dependency graphs can be enormous. We had to enforce strict top-level group scoping on every query to prevent unrelated projects from polluting results.
  • Preventing hallucinations. LLM agents tend to fill gaps with plausible but invented data. We enforced a hard rule: zero Orbit rows means "None found" in the report — never a fabricated result.
  • Single-comment discipline. Ensuring the agent never posts intermediate or partial findings required explicit two-phase separation in the prompt architecture.
  • Graceful Orbit degradation. Orbit may be unavailable. The agent must still produce a useful diff-only report rather than failing silently or crashing.

Accomplishments that we're proud of

  • A fully auditable report where every risk conclusion is traceable to a specific Orbit query result
  • A transparent risk score formula with every line of arithmetic shown in the MR comment — no black-box AI scores
  • Zero-hallucination enforcement baked into the agent prompt as a hard rule
  • Graceful fallback when Orbit is unavailable, so the agent is always useful
  • A clean two-phase architecture that separates evidence collection from reporting — making the agent deterministic and testable

What we learned

  • GitLab Orbit's knowledge graph is a powerful primitive for cross-project impact analysis that is largely untapped in day-to-day code review workflows
  • Prompt architecture matters as much as model capability — strict phase separation and explicit rules dramatically reduce non-deterministic behavior
  • Heuristic risk scores are more trustworthy when the formula is fully transparent and shown to the reviewer, rather than hidden inside a model
  • Agents that produce a single, structured artifact are far easier to validate than agents that produce conversational output

What's next for Blast Radius Guardian

  • Automatic MR trigger — invoke the agent automatically on every MR open event, not just on-demand
  • Richer dependency signals — extend Orbit queries to cover runtime dependencies, shared database schemas, and API contracts
  • Reviewer auto-assignment — use suggested reviewers to automatically assign MR reviewers via the GitLab API
  • Risk trend tracking — store scores over time to identify projects that are consistently high blast-radius and flag them for architectural review
  • Merge gate integration — optionally block merges above a configurable risk threshold via GitLab merge request approval rules
  • Multi-language module extraction — improve module name extraction beyond filename-based heuristics using AST parsing per language

Built With

Share this project:

Updates