Automating detection gap analysis with GitLab Duo Agent Platform

After an incident wraps up, every incident response or security operations center faces the same uncomfortable question: What did we miss, and why? Answering that question well takes real work — someone has to read through the incident timeline, map the attacker's actions to detection opportunities, identify the alerts that should have fired but didn't, and translate those findings into concrete improvements. Done manually, it's time-consuming, inconsistent, and easy to deprioritize when the next incident is already knocking.

At GitLab, our Signals Engineering team is responsible for building and maintaining the detections that protect the platform and the company. We deal with the same detection gap problem that every security team does so we’ve automated detection gap analysis with GitLab Duo Agent Platform to improve our assessment of those gaps and how we can close them.

In this article, you'll learn our strategy, which includes two AI agents you can use in your environment: the built-in Security Analyst Agent and a custom agent we built and named the Detection Engineering Assistant.

The detection gap problem

A detection gap is exactly what it sounds like: an attacker took an action, and your detections didn't catch it. Gap analysis is the process of systematically reviewing security incidents to identify those missed opportunities and determine what new or improved detections would close them.

The challenge isn't that gap analysis is conceptually hard. It's that it requires careful, methodical reading of incident data and mapping those events to your detection coverage. For a single incident, a skilled analyst can do it well. But across a steady stream of incidents, with multiple engineers contributing, it's difficult to maintain consistency and easy to let the review become shallow.

We wanted a process that was repeatable, thorough, and embedded directly in the workflow where our security incidents already live: GitLab issues.

What is GitLab Duo Agent Platform?

GitLab Duo Agent Platform is GitLab's framework for building and deploying agentic AI agents that can reason, take actions, and integrate natively with GitLab resources like issues, merge requests, and code. Unlike a simple chat interface, agents in Duo Agent Platform can be given specific roles, domain knowledge, and access to tools, making them effective for domain-specific workflows like security operations.

GitLab Duo Agent Platform gives you two practical paths:

1. Use a pre-built agent — GitLab ships several out-of-the-box agents, including a Security Analyst Agent designed for security-related tasks.
2. Build your own agent — You can create a custom agent in just a few minutes by giving it a name, a description, and a system prompt. The system prompt is where the real power lies.

Both paths are viable for detection gap analysis. Let's look at each.

1. Security Analyst Agent

The easiest way to get started is with Security Analyst Agent, which comes pre-configured with security domain knowledge and can be invoked directly from a GitLab issue.

To use the agent for gap analysis, we navigate to a closed incident issue and ask the agent to review the incident description, timeline, tasks, and comments to identify where detections were absent or insufficient. The agent reads the issue content — including comments, linked artifacts, and timeline details — and reasons over it to surface potential gaps. It can identify undetected tactics, techniques, and procedures (TTPs) mapped to MITRE ATT&CK and suggest areas where new detection rules could improve coverage.

This works well for a quick first pass, especially if your incident issues are well-documented. Security Analyst Agent is knowledgeable about general security concepts, common attacker behaviors, and detection principles. For teams just getting started with AI-assisted operations, it provides immediate value with no configuration required.

That said, the pre-built agent doesn't know your specific environment, including your SIEM, your log sources, your detection stack, or your team's detection engineering standards. For us, that meant the recommendations, while valid in general, sometimes missed the specific context we needed to translate them into actionable detections. That's what led us to build our own agent.

2. Building the Detection Engineering Assistant

Creating a custom agent in GitLab Duo Agent Platform is surprisingly straightforward. From the Duo Agent Platform interface, you give the agent a name (we called ours the Detection Engineering Assistant), a brief description, and a system prompt. That's it. The agent is ready to use.

The system prompt is the most important part. It's the agent's knowledge base: everything it knows about your team, your environment, your standards, and how it should reason about its work. A thin, vague system prompt produces thin, vague output. A verbose, carefully crafted system prompt produces an agent that behaves like a knowledgeable member of your team.

Here's the approach we took when writing our system prompt for the Detection Engineering Assistant:

Define the agent's role and scope clearly

We opened the system prompt by telling the agent exactly what it is and what it's responsible for. Not just "you are a security analyst." We specifically prompted: "You are a detection engineering assistant for GitLab's Signals Engineering team, responsible for analyzing security incidents and identifying gaps in our detection coverage." This framing anchors every response it produces.

Encode your detection philosophy

We wrote out what "a good detection" means to us: low false positive rates, high signal fidelity, and actionable alerts that provide responders with the context they need. We explained our preference for behavioral detections over IOC-based detections where possible, and described how we think about the tradeoff between coverage breadth and alert fatigue.

Give it context on your tech stack and log sources

An agent can only recommend what you can actually build. We told the agent which log sources we ingest, what our SIEM looks like, and what data is and isn't available to us. This means when it recommends a new detection, it does so in terms of what we can actually implement, not hypothetical telemetry we don't have.

Ground it in MITRE ATT&CK

We told the agent to organize its gap findings using ATT&CK tactics and techniques. This gives us consistent, structured output that maps directly to how we track coverage internally, and makes it easy to prioritize which gaps to address first.

Set expectations for output format

We specified exactly what we want the agent to produce: a structured list of detection gaps, each with the relevant ATT&CK technique, a description of what was missed, the log source or data that could support a detection, and a recommended approach. A consistent output format makes the findings easier to triage and turn into engineering work.

Example system prompt excerpt

Note: Our full Detection Engineering Assistant system prompt is 1,870 words and 337 lines. The example below is just a small example of what a full custom system prompt can be.

      You are the Detection Engineering Assistant for GitLab's Security Operations team. Your role is to analyze closed security incidents and identify gaps in our detection capabilities.

When reviewing an incident, you should:
1. Identify each distinct attacker action or technique described in the incident timeline
2. For each action, assess whether our existing detections would have caught it
3. For any action that would not have been detected, document it as a detection gap

For each gap, provide:
- MITRE ATT&CK Technique ID and name (e.g., T1078 - Valid Accounts)
- A plain-language description of what happened and why it wasn't detected
- The log source or telemetry that could support a detection (e.g., authentication logs, process execution events, network flow data)
- A recommended detection approach, written in terms our SIEM can implement

Our SIEM ingests [log sources]. Our detection standards prioritize behavioral patterns over static IOCs. Avoid recommending detections that would generate significant false positives without a high-confidence tuning path...

    

A system prompt this specific produces dramatically more useful output than a generic one. The agent stops giving you general security advice and starts giving you detection engineering recommendations.

Running gap analysis on incidents

With the Detection Engineering Assistant configured, the workflow is simple. At the close of an incident, we open the incident issue in GitLab and invoke the assistant. It reads the full issue — the incident summary, timeline, investigative notes, and any linked resources — and returns a structured gap analysis.

A typical output looks like this:

Gap: Lateral movement via valid credentials not detected

• ATT&CK: T1078.004 — Valid Accounts: Cloud Accounts
• What happened: An attacker used a valid access token to authenticate to an auxiliary GitLab instance. No alert fired because we lacked authentication baseline detections for that instance.
• Log source: Authentication logs from example.gitlab.com
• Recommended approach: Create a detection that alerts on first-time authentication from a user account to example.gitlab.com within a 90-day rolling window, with suppression for accounts with established access patterns.

This kind of structured output goes directly into our engineering backlog. We treat the agent's analysis as a high-quality first draft. It gets reviewed by a human engineer who validates the findings, checks whether gaps are already covered by detections we haven't documented, and adds context before it becomes an engineering issue. But the hard work of reading the incident and generating the initial findings is automated.

What we've learned

A few things stand out from building and iterating on this workflow:

The system prompt is a living document — Every time the agent produces an output that misses something obvious or gets the framing wrong, we update the prompt. The agent's quality is a direct reflection of how well we've encoded our domain knowledge into it.

Incident documentation quality matters — An agent can only reason over what's written down. Incidents with detailed, structured timelines produce much better gap analysis than sparse or informal ones. Building the gap analysis workflow created an unexpected second benefit: it gave us a concrete reason to improve our incident documentation standards.

This is a force multiplier, not a replacement — The Detection Engineering Assistant doesn't replace a skilled detection engineer, but it does amplify one. The engineer still reviews the findings, validates the recommendations, and makes the final call on what goes into the backlog. But the time spent on the initial analysis drops significantly, and the consistency across incidents improves.

Get started

If you want to build your own detection gap analysis agent, here's where to start:

1. Review your last three to five closed incidents and note what a good gap analysis would have surfaced for each.
2. Use those observations to draft a system prompt that encodes your environment, standards, and preferred output format.
3. Create a custom agent in GitLab Duo Agent Platform with your prompt.
4. Run it against one of your incidents and iterate on the prompt based on the output.

The detection gap problem isn't going away. But with GitLab Duo Agent Platform, you can make the analysis repeatable, consistent, and embedded directly in the place where your security work already happens.

Start a free trial of GitLab Duo Agent Platform today!