RSS Feeds

GitLab is not affected by PHP2Shell (CVE-2026-109618 and CVE-2026-109619). The GitLab application is not written in PHP and does not run it to serve web requests, and our Security team has found no evidence of impact to GitLab-managed infrastructure. GitLab.com, GitLab Self-Managed, and GitLab Dedicated are not impacted.

PHP is a widely used programming language that runs on web servers and powers popular platforms like WordPress, Drupal, and Magento, so a flaw in PHP itself can affect many websites and applications. On October 21, 2026, the PHP project fixed two critical remote code execution flaws in PHP, together known as PHP2Shell (CVE-2026-109618 and CVE-2026-109619). PHP rates both 9.2 on CVSS v4.0. The flaws are in the PHP engine, not in any framework, library, or application code, so there is no application-level fix. Any web server that runs PHP is affected, including NGINX and Apache. The PHP project confirmed the vulnerability on Apache with mod_php, where an unauthenticated request can achieve remote code execution before any application code runs.

Upgrade every server and container that runs PHP to serve web requests to PHP 8.5.12, 8.4.27, 8.3.36, or 8.2.35, or to your distribution’s patched package now.

This guide is for security and platform teams with PHP projects on GitLab. It covers the fixed version for each PHP branch and distribution, how to use GitLab features to locate PHP projects across your groups, how to track remediation, and how to check for signs of compromise.

Upgrade PHP to a fixed version now

Upgrade the PHP runtime on every host and in every container image to a fixed version. Framework updates, Composer updates, input validation, and authentication don’t help, because PHP handles the request before application code runs.

If your PHP comes from a distribution package, upgrade that package. Fixed package versions as of October 22:

Sources: Ubuntu, Debian, Alpine, and Red Hat security trackers, as of October 22, 2026.

Ubuntu, and Red Hat for its 7.4 and 8.0 packages, keep the old upstream version number and backport the fix. Compare the package versions rather than php -v. Restart every process that runs PHP after upgrading.

Rebuild your container images. If your image uses a floating tag of the official php image, such as php:8, php:8.3, php:8.3-apache or php:latest, rebuild it with docker build --pull and redeploy it. Images that pin a patch version, such as php:8.3.35-apache, need the tag changed to the fixed version first. Images built on derivatives such as wordpress or drupal get the fix only after their maintainers publish an updated image, so check the upstream image before you rebuild.

Locate PHP projects across your GitLab groups

Any project that runs PHP to serve web requests needs a fixed version, including the ones that are easy to forget, such as an internal dashboard, a marketing site, or a CI job image. Finding them takes two views: a static search of what your repositories declare and your images contain, and a runtime inventory of what actually runs. GitLab covers the static view with two features. Use both, in this order.

1. Container scanning

Container scanning reports vulnerabilities in operating system packages, so it finds PHP installed with apt, apk, or dnf, and it reports the two CVEs once they reach the scanner’s vulnerability database. To turn it on for a project, add the template to .gitlab-ci.yml:

include:
  - template: Security/Container-Scanning.gitlab-ci.yml

You can also use a group-level scan execution policy to turn container scanning on for every project in a group at once. When a policy is enabled, the next time a pipeline is run, it will be run with container scanning. Container scanning results for the default branch can be reviewed in the Vulnerability Report after the scanner completes.

Additionally, you can set up Merge Request Approval policies with container scanning. With merge request approvals in play, if a code change contains PHP2Shell, the policy will block a merge without approval from the selected parties.

Container scanning detects only PHP installed as a package. PHP compiled from source, including the official php images, has no package record, so a project can pass container scanning and still run a vulnerable PHP. Code search covers that gap.

2. Code search

Exact code search can find the two types of files that indicate a PHP project. Run these at the top-level group with regular expression mode enabled (the .* toggle at the right of the search box):

• Container base images: This query searches for every file GitLab detects as a Dockerfile. The pattern matches any image whose name or tag contains php, so it also finds derivatives such as wordpress, frankenphp, or bitnami/php-fpm. Expect a few false positives that you can rule out by reading the result: lang:Dockerfile ^FROM.*php
• Composer projects: This query finds projects that use PHP even when they have no Dockerfile, or when the Dockerfile takes its image from a build argument such as FROM $BASE_IMAGE:

file:composer\.json$

Exact code search covers the default branch only. On GitLab.com it is on by default for paid plans. On GitLab Self-Managed instances an administrator must install Zoekt first. GitLab Dedicated doesn’t support exact code search.

For each result, confirm the version. You can check the FROM php:<tag> line, or run php -v in the running container, and compare it with the table above. The group dependency list shows Composer packages and framework versions but not the PHP runtime version.

3. Compare with your runtime inventory

Container scanning and code search show what your projects declare and build, not what runs. PHP can run outside your GitLab projects, for example on web servers with mod_php or PHP-FPM enabled only in their configuration, on hosts configured by hand, or in containers that still run in clusters without an active pipeline. Compare the static results with an inventory of your running workloads from your configuration management (Ansible, Puppet, Chef, etc.), cloud, or VM inventory tools. For Kubernetes, operational container scanning scans the images that run in your clusters, with the same package-only detection as container scanning. Treat every PHP runtime that appears in only one of the two views as a gap to investigate.

Remediate at scale with GitLab Duo Agent Platform

Start with asking GitLab Duo Agentic Chat to:

• collect every container scanning finding for CVE-2026-109618 and CVE-2026-109619 across the group from the vulnerability report (requires an Ultimate subscription)
• run the code search queries above across the group, review each hit and read the PHP version from the Dockerfile or the Composer files
• open a merge request per affected project that bumps the base image tag or the package to the fixed version, and assign it to the right maintainer
• track the whole effort in an epic with one issue per project, and is closed when the fixed version is deployed and confirmed

From each issue, the Developer Flow can open a merge request that updates the base image tag or package to a fixed version. Turn on automatic reviews with the Code Review Flow to get a first review that follows your custom review instructions. Review and merge each merge request, then close the issue once the fixed version is deployed.

Searches find candidates, but a security or platform engineer still has to review each match, resolve CI includes, and tell what the code declares apart from what actually runs. An example agent skill from the GitLab Developer Advocacy team handles this work. It runs on GitLab Duo Agent Platform and with agents that use GitLab MCP server or the glab CLI, such as Claude Code, Codex, and Cursor.

The skill checks container images, CI jobs, OS packages, configuration management variables, Composer pins, and environments. It returns a cited findings table with deployment evidence, and open gaps. The skill is read-only: It makes no changes, and remediation merge requests remain a separate, reviewed step. It cannot confirm what is running on hosts it cannot access, so verify those directly. Adapt the skill to your own environment before you use it.

Check for compromise

Reports of exploitation differ. Security researchers reported an exploit attempt on October 17, 2026, before public disclosure, and further reports of exploitation followed the release. The PHP project identified no functional exploits at the time of release. If an internet-facing server ran a vulnerable PHP version, review its logs from October 17, 2026, onward for:

• Multipart requests followed by memory-limit errors or repeated HTTP 500 responses
• Unusually large or malformed PHPSESSID response cookies
• Unexplained PHP worker restarts, or shell processes started by PHP workers
• Unexpected files on the PHP web server, outbound connections from PHP workers, or unexpected cron entries

A successful exploit can return HTTP 200 and leave the worker running, so an absence of errors doesn’t rule out compromise. If you find signs of exploitation, isolate the server and start an incident investigation. Where possible, capture memory, disk, and logs before patching and restarting. Restarting PHP workers may erase evidence. CVE-2026-109619 can also expose process memory, even when an attacker doesn’t achieve code execution. Rotate any credentials, tokens, or keys the PHP process could read.

Note: Scanners may flag the Gemnasium dependency scanning image (gemnasium:6), deprecated since GitLab 17.9, for its bundled PHP. It is used only as a command-line tool and never handles HTTP requests, so it is not exploitable, and a fixed version has already shipped under the same tag.

Timeline

Broken object-level authorization ranks first on the OWASP API Security Top 10, and OWASP says that traditional static application security testing (SAST) tools struggle to find access control flaws. A missing authorization check is an absence of code, so a scanner that matches patterns has nothing to match. You can find the gap only if you already know what the endpoint is meant to enforce.

We're building Business Logic Security Analyzer in GitLab Duo Agent Platform to catch business logic vulnerabilities that pattern-based scanners miss. It is now in early access for GitLab Ultimate customers on GitLab.com.

Valid code, wrong intent

Any application security team will recognize these three findings:

1. An endpoint takes an order ID from the request and returns the order without checking who owns it.
2. A role field on a user profile accepts whatever JSON the client sends.
3. A user ID is a sequential integer.

Each one is valid code that slips past most taint and pattern rules in a conventional SAST engine, because no untrusted data reaches a dangerous sink, and no known-bad signature appears. Chained together, they hand an attacker every customer's order and an administrator role.

Across GitLab's customer base, codebase size has grown as much as 500% as agents write code. CVE disclosures through April ran 46% above the February forecast from the Forum of Incident Response and Security Teams. The same AI models that generate code also make existing weaknesses less expensive to discover and chain. Authorization logic is where that pressure lands: Developers and agents write a check in a line or two, but when one is missing, the gap often goes unnoticed. As Omer Azaria, vice president of Product Management at GitLab, put it at GitLab Transcend, "We're caught in the middle: more code, faster attacks, same teams."

Why whole-repository scanning starts here

GitLab Duo Security Review looks for authorization flaws in merge requests, but many business logic flaws aren't visible in a diff. Whether an endpoint should check ownership depends on the data model, the roles the application defines, and how other endpoints treat the same records. Judging one handler means reading the application around it.

That is why Business Logic Security Analyzer scans the whole repository, and why GitLab is the platform to do it on. The source code, the pipelines that build it, the security findings attached to it, and the policies that gate it all live in one system. An agent that scans here sees the full application and writes its findings where the security team already works.

At Transcend, we introduced the GitLab Security Standard: five stages each agent must clear to earn more autonomy, built on the premise that code is now abundant and trust is scarce. Its Verify stage requires every change, whether written by a person or agent, to pass controls the author cannot touch. Business Logic Security Analyzer runs outside the author's hands, and its findings persist in the same report and dashboards that govern the rest of the codebase.

How the analyzer works

Business Logic Security Analyzer is a foundational flow on GitLab Duo Agent Platform that targets business logic flaws, starting with broken object-level authorization, missing or improper authorization, and mass assignment. A practitioner can run a whole-repository scan, and scan each merge request automatically after its pipeline passes.

Detecting any of these flaws requires a model of what the application is meant to do. Pattern scanners have none, but an agent that reads the repository can build one. The analyzer starts by enumerating the application’s entry points and mapping who should be allowed to do what: which records belong to which user, and which actions are administrative. It then reads each handler in scope and checks whether the handler enforces that rule before touching the record. Findings land in the Vulnerability Report and the merge request security widget as first-class SAST results, to support triage, remediation, and auditing.

In the demo application below, refund_order accepts an order_id from the request and sets refunded=1 without checking that the caller owns the order or is an administrator. Taint rules stay silent because the query is parameterized. The analyzer reports it as CWE-639, Critical, at app/orders.py:17, and its explanation names the missing ownership check.

The models behind the analyzer

Business Logic Security Analyzer is the first GitLab capability supporting Anthropic's Claude Mythos 5.1, and is available in early access to customers in approved environments. The model sees only GitLab's prompts and the customer's repository, which holds the context the analyzer needs: the data model, roles, and rules each endpoint enforces. As Rajat Pandit, Head of Applied AI, Anthropic India, said at Transcend, "When defenders have more context than attackers, advanced models change the math in their favor."

Alongside Mythos, the analyzer supports Anthropic’s Claude Opus 5.5, Sonnet 5.5, Sonnet 5, and Sonnet 4.6, with more models planned for future releases. All of them run as GitLab-managed models through GitLab’s AI gateway, under the same data handling terms as the rest of GitLab Duo Agent Platform.

Request early access

Business Logic Security Analyzer is in early access for a small group of GitLab Ultimate customers on GitLab.com. Participants run the analyzer on their codebases to find true positives their security teams didn’t already know about. We will work with each team to learn where the analyzer is correct, wrong, or silent. Each scan consumes GitLab Credits, and cost scales with the size of the application's attack surface.

To be considered, contact your account team, or, if you are not yet a GitLab customer, contact our sales team. Once your group is enabled, start a whole-repository scan from GitLab Duo Chat or through the API, and attach the Business Logic scan profile to a project to scan its merge requests. The Business Logic Security Analyzer documentation covers prerequisites and setup.

AI coding agents are writing and changing code, from GitLab Duo Agent Platform agents to externally connected agents like Claude Code, Cursor, and Codex. You are accountable for what those agents do, yet most of their activity stays invisible: which agents ran, who used them, and what they touched. Teams often struggle with understanding whether a developer used a tool or model that is approved or not.

The AI Governance Dashboard, now in beta, gives you one place to see agent activity across your top-level group. It brings GitLab Duo Agent Platform agents and the external agents your developers connect into one view, showing which agents ran, who used them, and which projects they touched. The dashboard also shows the tools and sessions associated with each agent.

With that audit trail in place, you can answer the questions auditors and risk owners ask: who ran this agent, what did it do, and who is accountable for it. Every agent action gets recorded in one audit trail, detailing the model it used, the tools it called, and the project it ran in. You can now investigate a session or hand an auditor evidence without stitching together multiple sources of data.

Watch a demo of the AI Governance Dashboard:

Gain visibility into AI agent activity

More AI agents are running across your organization than you can track by hand. GitLab Duo Agent Platform agents run inside GitLab, while externally connected agents like Claude Code, Cursor, and Codex run on developers' own machines.

The result is the shadow AI problem: real work happening in your projects, from many tools, that no one accountable can see in one place or tie to a team member.

The AI Governance Dashboard brings that activity into view and connects each agent to the developer behind it. To turn it on in your top-level group, go to AI > Governance. GitLab Duo Agent Platform agents and externally connected agents appear together, and you can toggle between the views to see all agents, just Duo Agent Platform Agents or just externally connected agents. Three tiles at the top give you a baseline: how many agents ran, how many sessions they started, and how many tool calls they made over the past seven or 30 days. Each tile shows the daily trend and the change from the previous period, so a spike, like a new tool your team started using last week, stands out. The cards below tell you where to act. You can check whether the agents your developers rely on match the ones you approved, see which projects carry the most agent activity and need closer review, and know who to talk to when usage shifts.

Prove what every agent did

Managing AI risk starts with knowing what every agent did and who prompted it. Traditional audit trails were built for human changes, so that record is often scattered across tools or missing. GitLab records every agent action as an audit event, so you can investigate an incident or answer an auditor from one place.

Open any GitLab Duo Agent Platform session to see the prompt the developer sent, the tools the agent called, the MCP servers it used, the model that ran, and the project it changed. From there, you can download an immutable copy of the session as evidence, or stream the events to your security information and event management (SIEM) system.

Set up your dashboard today

It only takes a few steps to set up the AI Governance Dashboard:

1. Check access. The dashboard needs the Owner role on the top-level group, or a custom role with the read_agent_artifacts ability. If the people who should watch agent activity don’t have Owner access, create that custom role first.
2. Turn on AI audit event storage. Storage is off by default, and events are only recorded after you turn it on. In your top-level group, go to Settings > GitLab Duo, select Change configuration, and then Store AI audit events in the Data and privacy section. You need to have an Owner or Security Manager role to have access.
3. Open the dashboard. In your top-level group, go to AI > Governance, and select the Dashboard tab to see your GitLab Duo Agent Platform activity.
4. Connect your externally connected agents. Sign in with GitLab CLI (glab) 1.122.0 or later on macOS or Linux. To capture Claude Code sessions, run glab govern setup, which installs the Claude Code hooks. To also capture Cursor and Codex sessions, run glab govern setup --agents codex,cursor, which adds a background job that sends those sessions every 30 minutes. Run glab govern doctor to confirm the setup works.

The AI Governance Dashboard is in beta for GitLab Premium and Ultimate customers. Turn it on for your top-level group to keep oversight of AI usage as fast as your teams adopt it.

Not on GitLab yet? Try GitLab Ultimate for free and use the AI Governance Dashboard to get started.

AI agents are sending more and more code into review queues built for human-paced work. A coding assistant can speed up code writing, but it can’t show you whether review, security checks, and release approvals can keep pace with all that extra code. AI-native engineering — the practice of intentionally designing the engineering process so people and agents each do what they are best suited to — starts with identifying delivery bottlenecks, then deciding how much autonomy agents should have and how to maintain control as you scale.

The AI-Native Engineering Playbook, launching this week, helps teams turn faster coding into faster delivery by redesigning how they ship software with agents. Every practice in the playbook is grounded in insights from engineering leaders at GitLab, our customers, and members of our Software Engineering Leadership Forum (SELF) community. We also partnered with IT Revolution to incorporate findings from a diverse group of practitioners looking at AI-native software development from a number of different angles, from code review to agent autonomy.

Below are a few of the questions we sought to answer in the process of creating the playbook.

Where does the bottleneck go when coding gets faster?

Coding used to be the slowest, most expensive part of building software. Agents removed the bottleneck on coding, and the constraint moved to everything around the code: waiting for clarifications, environments, approvals, and other teams. GitLab’s AI Accountability Report, based on an April 2026 survey of 1,528 DevSecOps professionals, found that 79% of respondents agreed that individual developer productivity has improved with AI, but the overall software delivery process has not accelerated at the same pace.

Large enterprises typically have software delivery lead times of well over 200 days, with active development taking only 10% to 20% of that time. The numbers explain why a faster coding step is often disappointing in the long run. For example, imagine a 281-day delivery cycle that involves about 32 days spent on coding. Make coding 50% faster, and you save about 16 days, a 6% improvement. But if you take coding all the way to zero, around 88% of the lead time stays untouched. [1]

GitLab’s research similarly found that DevSecOps professionals reported spending only 16% of their time writing new code, and 85% agreed AI has shifted the bottleneck from writing code to reviewing and validating it.

That means your first job is diagnosis. Take one small, real change and trace it from request to production, marking every wait and every handoff. The longest waits show where your next improvement is, and it's rarely in the code. Watch where an agent stalls on a small task, too. The stall usually points to a standard nobody documented, an environment that’s hard to start, or context that lived in a single person’s head.

How much autonomy should agents have?

Agent autonomy should depend on how well you can verify the agent output. Imagine a ladder with four stages, ranging from semi-manual (a person approving every step) to fully autonomous (a zero-touch workflow). In this framework, there are clear rules for advancing up the ladder: no rungs can be skipped, and each step up needs to be backed with evidence from the rung below. [2]

1. Stage 1: Humans are in the loop at every step
2. Stage 2: Humans are still in the loop, but the agent executes within set bounds
3. Stage 3: Humans are out of the loop for normal operation and handle only exceptions
4. Stage 4: A zero-touch workflow, where the agent manages itself end to end, calling in a human only when predefined thresholds are met [2]

It’s also important for a named human to stay accountable for every AI-enabled workflow, and the line between a human reviewing and a human monitoring should be explicitly defined, since loose or arbitrary definitions tend to erode under time pressure. [3]

That erosion is the trap. A person who is nominally in the loop but approves everything gives the appearance of control without the benefits, and habit and volume can easily turn review into mindless rubber-stamping. A checkpoint nobody actually exercises is worse than none, because it creates confidence where the system needs scrutiny.

The way up is to earn each step on evidence. Set an explicit accuracy or success threshold before you widen a step, then move people from reviewing each step to monitoring the whole. An agent that stops more often to ask for help is a healthy sign, since the system is refusing to outrun its own evidence. [2]

How do you review code at agent volume?

Widening autonomy depends on catching mistakes, and that puts pressure on code review. Review at merge time was built for human-paced output. Agents raise the rate of change, and manual review of every change set has become unsustainable. GitLab’s research also highlighted this strain: 78% of respondents agreed existing code review processes were not designed for the scale of code AI tools enable, and 80% agreed their organization has adopted AI coding tools faster than it has developed policies to govern them.

The answer is a layered verification system in which each layer does the part it does best. Humans are only removed from the loop when the risk level and evidence justify that design choice — it’s never a default. [4]

1. Move objective checks, such as formatting, types, and dependency policy, as close to authoring as possible.
2. Keep changes small so every later layer works faster.
3. Define the expected behavior up front so there is something concrete to check.
4. Use an independent reviewer.
5. Match review depth to the risk of the change.
6. Record every agentic review decision in a form someone can inspect later.

The organizations that have been most successful here have already invested heavily in automated testing, static analysis, and small change sets, so the layers work best on a foundation you already have. [4]

Dive into the playbook, or contribute your own insights

Becoming AI-native is a practice that leaders will continue to refine with their teams as tools and understanding evolve. To get started, read the entire playbook, or begin with the part that matches where your team runs into the most friction:

• Redesigning the work so agents fit the flow of delivery instead of attaching to steps built for people alone
• Working with agents by deciding where human judgment and accountability stay and how engineers keep growing as the coding shifts
• Governing and scaling from one workflow to many with the context, verification, and measurement that let you move faster without losing control of quality or risk

If you lead an engineering team and want to contribute your own insights to the playbook, join SELF, the community for engineering leaders navigating the AI era.

Papers cited in this article

1. Cochran, Timothy, and Bryan Finster, Tim Ottersburg, Scott Prugh, and Amy Willard. "When Coding Is Free, Where Is the Bottleneck? A Guide for Leaders Building Agent-Ready Delivery Systems." Enterprise Technology Leadership Journal 3, no. 2 (Fall 2026). https://itrevolution.com/product/when-coding-is-free/.
2. Cockcroft, Adrian, and Jeremy Eder, Joseph Enochs, Jenn Spykerman, and Brian Wald. "When Agents Decide: Continuous Decision Intelligence and the Substrate Beneath It." Enterprise Technology Leadership Journal 3, no. 2 (Fall 2026). https://itrevolution.com/product/when-agents-decide/.
3. Eslick, Ian, and Collin Fox, Amanda Graham, Suzette Johnson, Chuck Lafferty, Tom Kilcommons, Rosalind Radcliffe, Cat Swetel, Annie Vella, Sam Yeats, and Robin Yeman. "The Sociotechnical Architecture of AI-Enabled Enterprises: Principles, Patterns, and Practices for Human-Governed AI." Enterprise Technology Leadership Journal 3, no. 2 (Fall 2026). https://itrevolution.com/product/sociotechnical-architecture-of-ai-enabled-enterprises/.
4. Davis, Zach, and Michelle Gill, Elisabeth Hendrickson, Angie Jones, Sha Ma, Randy Shoup, and James Wickett. "Agentic AI and Code Reviews: Toward a Pattern Language for Code Reviews in the Age of Agentic AI." Enterprise Technology Leadership Journal 3, no. 2 (Fall 2026). https://itrevolution.com/product/agentic-ai-and-code-reviews/.

When code becomes abundant trust becomes scarce.

That is the argument GitLab CEO Bill Staples made in his recent essay: AI is collapsing the cost of producing software, and everything around production, including context, verification, governance, and evidence, becomes proportionally more important. Both security and collaboration are key elements to producing trust. AI widens what has to be trusted to include the agents that now write software along with the software that gets written.

That is why GitLab is joining the Open Secure AI Alliance, which brings together organizations to develop and share open technologies, techniques, and tools that help safeguard software and agents in the age of AI. We joined because we believe AI security is strongest when it can be inspected, tested, adapted, and improved by a broad community of defenders.

This is an extension of work GitLab is already doing in the open.

GitLab’s AI Gateway is a standalone service that provides access to AI features across GitLab.com, GitLab Dedicated, and self-managed instances. Its source code is public, and so are the agent workflow configurations running on AI Gateway, including configurations for code creation, code review, secrets false-positive detection, and security review.

• Developer Flow configuration
• Code Review Flow configuration
• Security Review Flow

These examples reflect an important principle: An AI system is more than the model behind it. Trust depends on the surrounding harness, workflows, controls, context, and evaluation. Open tooling makes it easier for defenders to understand how those pieces work, test them against real risks, and improve them over time.

We also believe enterprises need choice. Organizations should be able to use proprietary and secure open weight models, select the right model for the job, and make decisions about where and how AI systems operate. Model and cloud agnosticism helps preserve that flexibility, while an open ecosystem gives customers more options for building, governing, and securing AI.

Transparency also has to cover the risks. Our documentation on security threats in agentic systems sets out the attack paths that apply to our own agents and the controls that apply in each environment. We treat our agents as privileged actors: Each one runs with an explicit identity, constrained tools and permissions, and actions that can be audited. We share how this works through our documentation for composite identity, sandboxed execution, per-flow tool restrictions, and agent tool governance.

Through our participation in the Open Secure AI Alliance, GitLab has an opportunity to share practical work already underway across our AI and security teams and learn from the broader community. Our goal is not to position open weight and closed models as opposites. It is to help ensure that defenders have the transparency, control, and flexibility they need to build trustworthy AI systems.

AI security should be built in the open. Learn more about the Open Secure AI Alliance.

You already have an AI assistant. It completes your code, explains code you didn’t write, and maybe even drafts a whole feature while you sip your coffee. An agent on GitLab picks up where your editor stops.

The AI in your editor only knows what's open in your editor. It doesn't know that your merge request has been sitting in the queue for two days, or that your pipeline failed for the third time this week. Without your pipeline logs, it can’t offer a fix.

GitLab Duo Agent Platform works within the project and across your software delivery workflow, taking into account merge requests, issues, pipelines, and repositories your whole team shares. This context makes all the difference.

Here are three ways to try out GitLab’s agentic features today, and you don't need a paid GitLab plan to do it.

Set up your group

On GitLab.com, a group Owner sets up your top-level group:

• Purchase GitLab Credits.
  • Go to Settings > Billing and select Purchase credits.
• Turn on GitLab Duo Agent Platform.
• Turn on foundational flows.
  • Go to Settings > GitLab Duo.
    • Select Change configuration.
    • Under Flow execution, select Allow flow execution and Allow foundational flows.
    • Select Code Review and Fix CI/CD Pipeline.
    • Select Save changes.

1. Hand off the first pass on reviews

Code Review Flow reads a merge request's diff, description, and related files (like tests and dependencies), then posts detailed review comments directly on the merge request. The flow catches small issues, missed edge cases, and inconsistent patterns on your merge requests, so you can save your judgment for the critical details.

Try it on your project:

1. On a merge request, assign @GitLabDuo as a reviewer, or comment /assign_reviewer @GitLabDuo.
2. Watch the review comments appear on the merge request itself, the same place your teammates will see them. Code Review Flow checks the diff, the description, and related files like tests and dependencies before it comments.

To hand off the first pass on every new merge request, turn on automatic reviews.

Watch how merge requests can speed up with Code Review Flow:

2. Send a failed pipeline to an agent to investigate

Have Fix CI/CD Pipeline Flow diagnose your failed pipeline and propose a fix, so you spend your time applying it instead of hunting for the cause.

This flow investigates logs, error messages, the merge request changes that likely caused it, and the repository contents. Depending on the failure, it either proposes an inline code suggestion on your merge request or opens a new merge request with a fix.

Try it on your project:

1. On a merge request with a failing pipeline, select Fix pipeline with Duo from the Overview or Pipelines tab. The flow reads the pipeline logs and your merge request changes to find the cause.
2. Select AI > Sessions to follow along, then review the result on your merge request. Depending on the failure, you get inline code suggestions you can apply, a new merge request if the fix touches files outside your diff, or a comment with next steps when a failure needs a person.

For pipelines that aren't tied to a merge request, you can trigger the same flow: go to Build > Pipelines, select the failing pipeline, and select Fix pipeline with Duo. You get a new merge request with the fix.

Follow along with this demo:

3. Get answers from across your project

Ask Agentic Chat what changed in a merge request or why last night's pipeline failed, and get one answer that pulls from your project's merge requests, issues, and pipelines. This is where most editor-based AI assistants fall short. Your IDE's assistant can tell you what a function does, but it can't tell you which issue introduced it or why last night's pipeline failed.

Try it on your project:

1. In the GitLab UI, open your project. In the GitLab Duo sidebar, select Add new chat, then select an agent. You can also use Agentic Chat in VS Code, JetBrains IDEs, and Visual Studio.
2. Make sure the Agentic toggle is turned on.
3. Ask what you'd normally dig for by hand. Agentic Chat searches your project's issues and merge requests by keyword and retrieves pipelines to build its answer. For ready-made prompts, browse the AI Resource Library, for example Summarize Recent Changes to MR/Issue or Debug Failing Pipeline.

You can also ask Agentic Chat to run either flow above on a merge request. Each chat message you send uses GitLab Credits.

Watch the demo:

What these agentic features cost

On GitLab Free, you can use a set of GitLab Duo Agent Platform agents and flows, including all three above, without upgrading to Premium or Ultimate. Your group buys a monthly commitment pool of GitLab Credits that every group member draws from, so you pay for the work agents and flows do instead of paying per seat. The pool refreshes each month on an annual term. You can increase it at any time and decrease it at renewal.

Each feature uses credits at its own rate. For Agentic Chat and Fix CI/CD Pipeline Flow, usage depends on the model and on how much back-and-forth a request needs. The credit multiplier tables list current rates. Buying the pool also turns on on-demand billing for usage beyond it, so set usage caps to control spend.

Where to start

If you only try one this week, make it the Code Review Flow. Assign @GitLabDuo as a reviewer on your next merge request and see what it comes up with. From there, Agentic Chat and Fix CI/CD Pipeline Flow are ready to be deployed when you are.

Ready to get started? You can purchase GitLab Credits for your monthly commitment pool in your Customer Portal.

AI agents have changed how much code a team can produce in a day. Review queues haven’t kept up, and delivery stalls while changes wait for a closer look. The usual workarounds (reminders, reviewer rotations, assigning a team) buy a little time and then burn people out.

Client-side review with AI helps the author by catching issues as the code is being written, before a merge request even opens. But it only goes so far. A review that only checks quality still leaves the organization without enforceable policy on the way to production, since comments on a diff do not decide whether a change can merge or reach production.

Every merge request still needs a consistent certification step tied to pipelines, security findings, code owners, approval rules, and audits. Review in the author’s environment cannot standardize that work across all your projects, route policy-bound changes to the right person, or show leaders what the agent did before the change merges. As agents write more of the code, automated reviews need to happen in the platform that already tracks each change from plan to production, and where identity, policy, and oversight controls are already in place.

Earlier this year, we made Code Review Flow generally available on GitLab Duo Agent Platform, bringing that sign-off to the merge request and making agentic review part of the same platform where code ships. Teams can turn it on so every change is automatically addressed under rules you set once, at $0.25 per review, delivering an estimated 100x ROI. That predictable unit cost is low enough to leave automatic review on for every merge request, which is how reviews move at machine speed while staying cost-efficient at organizational scale.

Agentic reviews, built for how you ship

Code Review Flow is native to GitLab merge requests, so it covers your whole environment. It runs as a CI/CD job on your runners, whether GitLab-hosted or your own, so review executes in the same environment as the rest of delivery. It works the same way on GitLab.com, GitLab Dedicated, and GitLab Self-Managed, keeping inference under your control with self-hosted models when air-gapped or regulated environments require it. You also have the flexibility to choose which model acts as the foundation for agentic code review: GitLab-managed or your own self-hosted models.

When certification is the default on the merge request, teams get coverage, control, and follow-through in one place. Here are the key highlights for agentic code review with GitLab Duo Agent Platform:

Every merge request is reviewed, without anyone having to ask. Turn on automatic reviews at the project, group, or instance level and settings cascade. Authors don’t have to remember to request a first pass.

Standards you set once for how the group ships. Custom review instructions capture language conventions, security practices, and path-specific rules. A group can point the Code Review Flow at a template project so those standards travel with the work. Pair guidance with GitLab’s enforced security and compliance controls when a requirement must always hold.

Follow-through on every finding. Follow-up review rechecks what GitLab Duo Agent Platform already flagged, verifies fixes, and avoids repeating the same points. At that price, you can leave automatic reviews everywhere.

The right human, when policy requires one. Code owners and relevant approval rules still apply. Recommend Reviewers Flow suggests the smallest group that can satisfy those rules based on their level of expertise, workload, availability, and timezone.

How agentic code review works in GitLab

Within GitLab, code review happens on the merge request, next to your pipelines, security findings, and approvals.

1. A merge request opens (or becomes ready). Automatic review can start the Code Review Flow, or an author assigns GitLab Duo.
2. The flow runs as a CI/CD job on your runners, analyzes the change with repository and merge request context, guided by your custom review instructions and the models your group selected, and comments on the diff.
3. Authors and their coding agents push fixes. Follow-up review verifies Duo’s prior findings and carries context forward from the earlier pass.
4. When a human must approve, Recommend Reviewers Flow proposes who should take the request; you assign from the merge request.
5. Pipelines, security findings, approval rules, and the session record stay in the same place, so “reviewed” means certified on the path to production.

Watch agentic code review in GitLab in action:

What’s ahead

Our platform roadmap for agentic code review includes:

Deeper review when the change warrants it. An extended analysis pass will pull in calling code and tests for high-complexity merge requests, under your model-selection controls.

Clearer decisions on the merge request. GitLab Duo will be able to approve or request changes under settings you control.

Focus on risk. Risk assessment on the merge request will help teams see which changes deserve more attention.

Review before the merge request opens. Local review in Duo CLI will let developers run project review guidance against working-tree changes before the merge request runs the organization’s official check.

As agents write more of your code, you need reviewed code reaching production, with every change held to your standards and your reviewers focused on the changes that need a person. Every improvement on this roadmap is built to help you get there.

Getting started

If you are new to GitLab Duo Agent Platform, you can get access with a free trial. If you already are a GitLab Premium or Ultimate customer, you can simply turn on Duo Agent Platform and use the GitLab Credits included with your subscription.

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 these statements are reasonable, they are subject to known and unknown risks, uncertainties, assumptions and other factors that may cause actual results or outcomes to differ materially. Further information on these risks and other factors is included under the caption "Risk Factors" in our filings with the SEC. We do not undertake any obligation to update or revise these statements after the date of this blog post, except as required by law.

Agents are working across your team's software development lifecycle, but most still operate as separate tools, leaving the context, handoffs, and permissions for your team to stitch together. When your agents use APIs for these disparate tools, they often guess at endpoints and use up their context window on extra calls. The GitLab MCP server, now generally available with GitLab 19.5, connects your team’s external agents to your entire software lifecycle — from planning through production.

The GitLab MCP server enables any MCP-compatible agent to run GitLab workflows from the client your team already works in, getting what it needs in fewer calls and with less context bloat. Agents can work across code, merge requests, work items, and pipelines, and hand work to agentic flows within GitLab Duo Agent Platform. Each action runs under your existing GitLab permissions.

Built for how agents work

APIs are built for developers writing code. An agent that uses one has to work out which endpoints to call and make several calls to assemble one answer. Model Context Protocol (MCP) is an open standard built for agents. An MCP server tells an agent what it can do and offers a curated set of tools designed around real workflows. Agents get the tools they need with more focused context, in fewer calls, and needing less data to carry through each task.

The GitLab MCP server applies that approach to your workflows across your projects, supporting all your team members within the GitLab permissions you already set.

Whether you're a developer handing a task to an agent or a team deciding how agents should work across your organization, your agents get tool coverage broad enough to complete the work, with access that follows each user’s GitLab permissions. Developers can even start GitLab Duo Agent Platform flows from the MCP-compatible coding agent they already use.

Here is Claude Code using the GitLab MCP server to start the Fix Pipeline flow in Duo Agent Platform:

More of your workflow, within reach of an agent

In addition to the tools announced in 19.4, the GitLab MCP server now includes more tools for working with code and pipelines, and for finding the right group or doc.

• Code: add_branch starts a feature branch, get_repository_file reads a file at any ref, and semantic_search finds code by meaning, answering "where is this implemented?" without knowing the file or symbol name.
• Pipelines: get_pipeline shows why a pipeline is red, with its jobs, downstream pipelines, and artifacts on request. list_pipelines surfaces patterns across recent runs, and get_artifact_file reads a single file from a job's artifacts, such as a log, report, or test fixture, without downloading the whole archive.
• Orientation: list_groups lets an agent browse your group hierarchy to find the right group instead of guessing at identifiers, and list_wiki_pages, an opt-in tool, surfaces runbooks and docs before it answers a how-to question.

In 19.5, the MCP server tool catalog is also simpler to work with. Related tools are now consolidated, with fewer tools doing more. get_merge_request lets you ask your agent for a merge request’s commits, diffs, pipelines, conflicts, or notes. get_pipeline now includes get_pipeline_jobs, so you can ask for a pipeline’s jobs along with the pipeline itself. Your agents spend less time choosing the right tool and pull in only the details a task needs.

Toolsets let you choose which groups of tools the server returns. Each agent works from a focused set of tools that fits your team’s workflow instead of everything the server offers. A smaller set makes it less likely that an agent picks the wrong tool and has to retry. Most groups are on by default, and code security and wikis are available as opt-in groups. Browse the full catalog in the tools reference.

Start GitLab flows without leaving your client

Calling tools is one way an agent works with GitLab. Now, an agent can also hand a job to GitLab Duo Agent Platform and follow that job to the result without leaving your client. It can find the flows a project offers with list_duo_agents_and_flows, start a new flow from a goal in plain language with start_duo_session, and check progress with get_duo_session and list_duo_sessions. The work runs in a CI job inside GitLab, under the same context layer, policy checks, and audit trail as any other Duo Agent Platform session.

When a session needs a decision, it pauses for your input. With send_duo_session_input, you approve or reject the agent’s proposed action, or answer its question, and the session picks back up, keeping you in the loop. The duo_agent_platform toolset is included by default alongside the rest of the GitLab MCP server's tools.

Connect your agents to GitLab today

The agents supporting your software lifecycle will continue evolving. As your team adopts new agents, the GitLab MCP server connects each one to GitLab’s tools and flows, so they’re productive from day one.

You can connect the agents your team already uses by following the MCP server documentation, which includes setup instructions for Claude Code, Claude Desktop, Cursor, GitHub Copilot, OpenAI Codex, Gemini, Kiro, Zed, and other MCP-compatible clients. The GitLab MCP server is available on the Free, Premium, and Ultimate tiers, on GitLab.com, GitLab Self-Managed, and GitLab Dedicated. On GitLab.com, per-user rate limits are set at 60 calls per minute on Free and 600 on Premium and Ultimate.

If you’re new to Duo Agent Platform, start a free trial. Already on Premium or Ultimate? Turn on Duo Agent Platform and use the GitLab Credits included with your subscription.

The code is written. Now who reviews it?

The volume of code has never been greater, but delivery hasn’t kept pace. At Meta, code changes on internal platforms grew 220% year over year, while changes that reached users as new features grew only 36% (Reuters, August 2026). Every one of those changes has to clear review before it reaches users.

Automated review absorbs much of that load. Code Review Flow in GitLab Duo Agent Platform reviews merge requests as they arrive, follows custom review instructions you define per project, and costs a flat 0.25 GitLab Credits per review ($0.25 at list price). If a manual review takes about 15 minutes of a senior engineer’s time, that’s roughly $25 per review, so automated review cuts per-review cost by 99% (GitLab).

Automated review doesn’t take people out of the loop. Approval rules, CODEOWNERS, and compliance policies still require a person to sign off on many changes. For those merge requests, the first slowdown is often finding the right reviewer, and it happens before anyone reads a line. The right reviewer needs expertise in the code being changed, room in their queue, and availability in a time zone where they can respond quickly. When authors can’t see those factors, a few senior engineers carry most of the reviews while other qualified reviewers sit idle.

GitLab 19.5 removes that step with Recommend Reviewers Flow. When you create a merge request, GitLab recommends the best individual reviewer based on workload, time zone, availability, and expertise defined by approval rules and CODEOWNERS. The flow explains why it chose that reviewer and lets you assign them in one click. Across your engineering organization, reviews start sooner, review load spreads across every qualified engineer, and more of the code your team writes reaches users.

Watch Recommend Reviewers Flow in action:

Review is a routing problem, not a headcount problem

Teams often treat slow reviews as a people problem. They add reminders, review rotations, extended time zone coverage, and escalations. Those workarounds cost people time and can lead to burnout, and they leave the real cause untouched: routing. The expertise and capacity already exist; there’s just nothing to match them to each merge request as it arrives.

Without that match, the author has to answer questions GitLab already can. Who knows this part of the codebase? Who has room in their queue? Who is online right now? Authors fall back on habits that slow everyone down:

• Assigning a whole group. Everyone gets notified, nobody feels responsible, and the merge request waits for a volunteer.
• Defaulting to the same trusted reviewer. That person becomes a bottleneck, and their own work stalls.
• Guessing across time zones. The reviewer you picked just signed off for the day, so your feedback arrives tomorrow.

Reviewers pay a price, too. Group assignments flood their notifications with merge requests they will never review, which makes the ones that need them easier to miss. And the reviewers everyone defaults to absorb a growing share of the queue on top of their own work, which wears them down faster.

How intelligent reviewer suggestions work

GitLab Duo Agent Platform runs Recommend Reviewers Flow on your merge request and does the research for you:

1. You create your merge request. A trigger starts the flow automatically when a merge request is created, whether in draft or ready state, so suggestions arrive from the start.
2. The flow evaluates eligible reviewers. It weighs each candidate’s workload, time zone, availability, and expertise as defined by approval rules and CODEOWNERS, to find the person best suited and positioned to respond.
3. You see the recommendation and the reasoning. The flow explains why it chose each reviewer, so you can approve the suggestion based on that context.
4. You assign with one click. Suggestions appear in a dedicated panel on the merge request. You decide who reviews and when.

This design keeps you in control of timing. You can finish iterating or address automated code review feedback first, then bring in a human reviewer when the change is truly ready. You set it up as a flow trigger in your project rather than a project setting, so it fits alongside the other agentic workflows your team already runs.

What your team gains

The right reviewer match means faster feedback, clearer accountability, and a more balanced workload. Recommend Reviewers Flow makes that call consistently, at scale, and with reasoning you can see and override.

Recommend Reviewers Flow also works alongside the other foundational flows in GitLab Duo Agent Platform that handle the work around a merge request:

• Run Code Review Flow first, so automated feedback lands before a person is brought in.
• Add Security Review Flow to check merge request changes for business logic vulnerabilities before they merge.
• Use Fix CI/CD Pipeline Flow to diagnose and repair failed jobs, so a broken pipeline doesn’t hold up an approved change.
• Use Custom Flows to build Recommend Reviewers Flow into the process your team already follows.

Each step from merge request to merge runs on the same platform, under the same policies, so more of the code your team writes actually reaches users.

Get started

Intelligent reviewer suggestions are generally available in GitLab 19.5 for GitLab.com, GitLab Self-Managed, and GitLab Dedicated. To try them, add the Recommend Reviewers Flow trigger to your project, then create your next merge request. Learn more in our documentation.

New to GitLab Duo Agent Platform? Start a free trial today. Already a GitLab Premium or Ultimate subscriber? Turn on Duo Agent Platform and use the GitLab Credits included with your subscription.

Credentials often start in an engineer's local dev environments, then get copied into unscoped CI/CD variables to keep pipelines running. Stored there as a raw value rather than a reference to a scoped secret, a signing key reaches every job in the pipeline — compromised or not.

Standing up a standalone vault narrows that exposure but requires mirroring every change to project membership, protected branches, and production environments. When the vault falls out of sync, a pipeline breaks or an agent’s service account keeps access it no longer needs.

GitLab Secrets Manager tightens credential security without a second permission model. It is now generally available in GitLab 19.5 for Premium and Ultimate on GitLab.com and GitLab Self-Managed, with GitLab Dedicated coming soon. Built on OpenBao, it stores build-time and runtime credentials under the same permissions and audit trail as your code. Platform teams can offer developers self-service secrets, and security teams get credentials scoped to the jobs that use them, plus the pipeline and job ID on every CI/CD read.

"GitLab Secrets Manager lets us centralize secrets across CI/CD, Kubernetes, and infrastructure as code without standing up multiple vaults or maintaining separate integration points. It also strengthens our supply chain security by tightening which users and pipelines can access a given credential." - Jeremy Nauta, Software Architect, OneTrust

How Secrets Manager scopes build-time secrets to each job

Agents can take actions no one anticipated, so security teams need to regard every job as if its agents will use any credential it can reach. Secrets Manager narrows what agents can reach with the context GitLab already holds about each job: its project, the branch it runs on, whether that branch is protected, and the environment it targets.

A developer declares the secret a job needs with the secrets: keyword in .gitlab-ci.yml, and GitLab injects the value only into jobs that declare it and fall within its scope. Scope conditions accept wildcards on branch and environment, and they combine, so one rule can require a protected branch and a production/* environment before a job receives the credential.

Inside the job, GitLab writes the value to a temporary file and exposes only its path, which limits exposure in subprocesses, crash dumps, and telemetry. GitLab masks the value in job logs and discards it when the job ends. Unlike a CI/CD variable, a secret is never readable in your project configuration. OpenBao encrypts secrets at rest with AES-256-GCM, so a copy of the secrets database holds only ciphertext. Jobs fetch values straight from OpenBao with short-lived tokens bound to each job’s identity, which keeps plaintext secrets out of the GitLab application.

See how to get started with Secrets Manager:

Revoke and trace an exposed credential

When the axios npm package was compromised, a SANS advisory warned teams to "assume all environment variables on affected systems were exfiltrated" and extend investigations to CI/CD runners and build infrastructure. Responders had to work out which credentials each affected job could read, how to cut off access, and which runs read them.

With Secrets Manager, when a job runs a poisoned dependency, the exposure stops at the secrets that job declared and was authorized to read. To clean up, revoke and replace the leaked credential, update the value in Secrets Manager, and audit that one job while other pipelines keep running. Secrets Manager prompts you to set a rotation reminder when you create a secret. Dynamic credentials are coming soon and will provide ephemeral access without manual rotation.

GitLab streams every secret create, read, update, and delete event to your audit event destinations and records changes in the audit trail. Each pipeline read carries the pipeline and job IDs, which tie to the commit, the triggering user, and the merge request, when there is one. Incident responders and auditors can trace a read to the change behind it without correlating logs from a CI system, a vault, and an identity provider. Audit events never contain secret values.

Govern secrets with the permissions that govern your code

As agents take on more work, platform teams field more requests for pipelines and service accounts that need credentials. When those requests queue, teams fall back on broad grants and shared secrets.

Secrets Manager uses the GitLab namespace as its isolation boundary. Projects inherit secrets defined in the groups above them, so you define a shared credential once. Owners grant read, write, and delete permissions to specific users or default roles, using the same membership model that governs the code. Remove a person or an agent's service account from a project, and that identity's access to the project's secrets ends.

Developers reference secrets through the project access they already hold. When a secret reference breaks, they fix it in the same merge request as the code, with no second repository, approver, or access ticket. With a governed credential one line away, fewer secrets end up in over-scoped CI/CD variables, local files, or the repository.

One store for pipelines and runtime workloads

Kubernetes, Terraform, and scripts often get separate secret stores, each with its own access model and logs. Secrets Manager serves runtime tools from the same store as pipelines, under the same permissions and audit trail:

• Kubernetes, through External Secrets Operator. ESO re-fetches the secret on a set interval and updates the Kubernetes Secret in place, so a rotated value reaches the cluster without a pipeline run.
• Terraform and OpenTofu. They read a secret as a data source at plan or apply time and keep credentials out of .tfvars files and CI/CD variables.
• OpenBao and Vault CLIs, through the Vault-compatible API. Teams keep their existing scripts and point them at Secrets Manager.
• Other runtime tools, through the Secrets Manager API.

Each runtime tool authenticates with a service account or an access token, and that identity needs project membership and explicit read permission for the secret. GitLab then issues a separate token, valid for five minutes, that the tool uses to fetch it.

How Secrets Manager fits with GitLab's supply chain controls

GitLab’s governed software factory connects code, pipelines, packages, and secrets on one platform, with one identity model and one record of how a change reached production. Dependency Firewall decides which packages enter a pipeline, Secrets Manager limits which credentials the pipeline can reach, and Artifact Central governs what you ship.

Secrets Manager supports two of the five stages in the GitLab Security Standard, GitLab's framework for letting agents earn autonomy: For Authorize, it binds each job to the secrets its identity and scope allow, and for Respond, it streams every CRUD event.

Secret push protection blocks commits containing credentials before they reach the repository, and Secret detection finds the ones already in your code and history. GitLab Duo Agent Platform triages what those scans find and flags likely false positives, so your team revokes, rotates, and audits only real leaks.

GitLab's existing integrations for HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, and Google Cloud Secret Manager keep working alongside Secrets Manager, so you can migrate at your own pace.

Get started

GitLab Secrets Manager is a paid add-on for Premium and Ultimate, billed through GitLab Credits: 1 credit per secret stored per month, and 1 credit per 2,500 read operations. An enterprise license agreement is available for air-gapped environments.

• On GitLab.com, top-level group Owners can try GitLab Secrets Manager free for 30 days or 500 evaluation credits, whichever ends first. Go to your top-level group, select Secure > Secrets Manager, then Start 30-day trial.
• On GitLab Self-Managed, your administrator must install and enable Secrets Manager, following the documented sizing and high-availability guidance.
• GitLab Dedicated support is coming soon.

To find the first credentials to move, run the secret audit tool for CI/CD variables, which flags variables likely to hold credentials. A migration workflow for CI/CD variables is in development.

Have suggestions or feedback? Share them in the Secrets Manager feedback issue.

As AI models take on longer, multi-step work, the challenge is putting that power to use across the software lifecycle without adding risk or cost. Teams need to be able to move faster, within enterprise controls and guardrails.

Google's Gemini 4 Argon, now available on GitLab Duo Agent Platform, was built for that kind of work. With Argon, your team can delegate long, multi-step actions and receive outputs for review. In GitLab's internal evaluation, Gemini 4 Argon completed 93.3% of GitLab’s software engineering benchmark tasks.

Reliable execution for long-horizon tasks

Work across the software lifecycle demands persistence and steady attention. Argon sustains its reasoning across the many steps of a task, reading files, running commands, and editing code through to completion. Your engineers can delegate to GitLab Duo agents powered by Argon with confidence and spend their time reviewing results instead of monitoring runs.

Google trained Argon to respect system boundaries, tell you when it couldn't find something or finish a task, and pause for confirmation before an irreversible step. Teams can hand off complex tasks and stay in control of the important decisions.

In internal evaluations, Argon resolved 73.3% of GitLab’s benchmark tasks, with each change passing the benchmark’s tests across multiple programming languages. Of the runs that hit a tool error or timeout, Argon still completed 93.8% of them, so a single failure mid-run won’t force your team to start over. Agent output lands in a merge request, where your team reviews the result with the full context of the change.

Argon works through problems thoroughly, making it a strong model choice when finishing correctly matters more than finishing fast.

Choose the Gemini model that fits your workload

Gemini 4 Argon is Google's newest frontier model and the most performant Gemini model on GitLab Duo Agent Platform. It handles long-horizon agentic actions especially well, including tasks that begin loosely defined. It pairs with the Flash models, which offer a lower-cost option for high-volume work, so you can match each workload to the best Gemini model. Whichever Gemini model you choose, it runs inside the same context layer, policy checks, and audit trail that cover every agentic action across your software lifecycle.

Try Argon on GitLab Duo Agent Platform

Gemini 4 Argon is available now on GitLab Duo Agent Platform. Like other models, it runs on GitLab Credits. Argon is available at promotional pricing of 2.86 calls per credit, through November 30, 2026. Starting December 1, standard pricing applies at 1.33 calls per credit.

If you already use GitLab Duo Agent Platform, you can try Argon today by choosing Gemini 4 Argon in model selection. GitLab Premium and Ultimate customers can turn on Duo Agent Platform and try Argon using the GitLab Credits included with your subscription. New to Duo Agent Platform? Start a free trial today.

AI agents are fundamentally changing the economics of software development. As the cost of producing code falls, the volume of changes moving through the software factory is accelerating beyond what infrastructure designed for human developers was built to handle.

GitLab anticipated this shift and began developing next-generation source code management (SCM) to support thousands of concurrent agents working against large repositories. In June, we announced next-gen SCM at GitLab Transcend, joined on stage by Nick G. from Anthropic's source control team. We've continued collaborating on the technical challenges of agent-scale development, and in August we shared more of our architecture and early performance results.

This week, Anthropic provided a compelling demonstration of why this work is so important. As daily merges to its monorepo grew from approximately 2,500 in May to more than 30,000 in September, its engineers built Scion, a specialized source control system designed for their environment.

Anthropic's experience reinforces the architectural direction we've been pursuing. Scion is purpose-built for enormous monorepos where nearly all clients are agents that are always online. Anthropic acknowledges that its approach isn't a general-purpose replacement for Git and requires its own code review, search, and CI infrastructure.

GitLab is building for the broader enterprise market: delivering agent-scale performance while preserving Git compatibility, infrastructure choice, and integration with the software development lifecycle.

"Scaling our monorepo for agentic development has changed how we think about Git server architecture. We see room to expand what Git servers can do for these workloads without departing from the overall Git model."

— Nick G., Source Control, Anthropic

Built on Git. Designed for agents.

Traditional Git workflows require clients to download substantial repository data, even when an agent needs only a small portion. A single agent invocation can involve 5–10 GB of data transfer and more than 30 seconds of setup, just to answer one question. Multiply that overhead across thousands of agents and source control becomes a bottleneck.

Most enterprises can't move source control onto new infrastructure just to scale it. Next-gen SCM preserves the Git protocol while modernizing the architecture underneath. Stateless compute scales horizontally against shared object storage, while agent-native interfaces let agents request the files and history they need without repeatedly cloning entire repositories.

In early internal tests, workloads completed up to 50x faster, used up to 2x fewer tokens, and generated up to 1,000x less network traffic compared with conventional workflows. These are peak improvements under specific test conditions, and we're continuing to validate performance under sustained, concurrent load.

The same architecture is designed to run on GitLab.com and on S3-compatible storage that customers control, including in air-gapped data centers. Repository data stays within the customer's infrastructure, preserving data sovereignty and existing investments while delivering the scalability agentic development demands.

For a closer look at the architecture and what we're building, watch Mark and Kranthi's latest next-gen SCM update:

Source control is only the first bottleneck

Speeding up source control alone moves the bottleneck downstream. An agent that writes code in seconds creates little value if the resulting changes spend hours waiting for validation, security review, or deployment.

Traditional merge queues and CI workflows face growing pressure when agents generate changes faster than validation can complete. We're seeing this pressure across GitLab.com. Over the past year, customers created 40% more CI/CD pipelines, while code pushes increased 50%. Agent-scale CI will need to validate more changes with less compute per change while preserving evidence of what was tested and verified.

This is why next-gen SCM is part of GitLab's broader vision for a governed software factory. As agents accelerate software production, source control, context, orchestration, CI, security, and governance must evolve together.

We're designing next-gen SCM to let thousands of agents work in parallel in isolated sessions, where unsuccessful experiments can be discarded without disrupting shared code. Successful changes can flow into GitLab's existing merge requests, pipelines, security checks, and governance controls on their path to production.

GitLab Orbit is being developed to provide a context graph of the entire software lifecycle, while GitLab Duo Agent Platform orchestrates agent work across stages. We're also advancing capabilities to make agents accountable for their work, including attribution and authorization of agent actions, preserving the instructions and decisions behind code changes, and giving reviewers the context needed to focus human judgment where it matters.

The goal is to reduce the time and total cost of moving software from intent to production, even as the number of agents and changes grows dramatically.

We believe a governed software factory offers the best economics for agentic development: more software delivered at lower cost per change, with the security and control enterprises require.

Advancing Git through open collaboration

Git's open ecosystem has been foundational to modern software development, and we believe it will remain essential in the agentic era. GitLab has long been an active contributor to Git, and we'll continue working with the community to advance the standard that millions of developers and tools depend on.

Our next-gen SCM architecture builds on that foundation, combining Git compatibility with a redesigned backend and agent-native interfaces designed to deliver the performance and scalability these new workloads demand.

This approach preserves the investments customers have made in Git while allowing GitLab to innovate rapidly across the broader software lifecycle. Our differentiation is the governed software factory: bringing source control, context, orchestration, security, and governance together on one platform.

What's next

Next-gen SCM is in private beta, and we're working with customers to validate performance against their own repositories and workloads.

As agents dramatically increase software production, the entire software factory must operate at machine scale. GitLab is building that foundation.

Request early access to next-gen SCM and evaluate it against your own repositories.

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 these statements are reasonable, they are subject to known and unknown risks, uncertainties, assumptions and other factors that may cause actual results or outcomes to differ materially. Further information on these risks and other factors is included under the caption "Risk Factors" in our filings with the SEC. We do not undertake any obligation to update or revise these statements after the date of this blog post, except as required by law.

In a recent engineering blog post, Anthropic described how agentic coding pushed its source control past what Git was designed for: Merges to its monorepo grew from around 2,500 a day in May to more than 30,000 a day by September. Its team built an in-house system, Scion, around the assumption that nearly all clients are agents that are always online.

Anthropic is clear that Scion isn't meant to be a replacement for Git and has not been designed with Git compatibility in mind. Instead, it has been aimed at resolving the scaling problems that could become common over the next six to 12 months. The article suggests Git platforms can evolve and implement richer server-side operations, while maintaining Git compatibility. That's the problem space our next-gen source code management (SCM) work is aimed at.

"Scaling our monorepo for agentic development has changed how we think about Git server architecture. We see room to expand what Git servers can do for these workloads without departing from the overall Git model."
— Nick G., Source Control, Anthropic

GitLab’s next-gen SCM design pairs agent-facing interfaces with a horizontally scalable backend, using the Git protocol to address the same infrastructure pressures.

This work supports the DevOps infrastructure layer in GitLab’s broader vision for a governed software factory. At Transcend, our global customer event, GitLab described the factory as a connected system that helps teams move software from idea to production under their own policies and standards. Teams need to trace changes, understand their context, and apply policy as work moves through the software lifecycle.

Serving large repositories

We use the Git protocol developers and their tools already rely on as the foundation of our next-gen SCM. Its backend can scale across many compute nodes, and its interfaces let agents request the files and history needed for each task. This can reduce repeated full repository clones.

The architecture separates compute from repository storage. Object storage holds repository data. Stateless compute nodes serve requests from local caches. You can expand compute resources by adding nodes, and the components communicate through the standard S3 API. You can run it on GitLab.com and self-managed environments, including air-gapped environments where repository data never leaves your infrastructure.

This design aims to reduce bottlenecks from heavy read and write activity. In early internal tests, workloads completed up to 50x faster, used half the tokens, and generated up to 1,000x less network traffic.

What we’re building next

The backend is one part of preparing source control for coding agents. You also need to know what instructions shaped a change, which commits and merge requests were affected, and which policies applied. The roadmap includes these capabilities.

• GitLab plans to capture the instructions and decisions behind an agent session as the work happens, giving teams a record of the context that shaped a change.
• Each session will remain linked to the commits and merge requests it produces, including after a squash or rebase, so teams can trace agent work to the code it changed.
• Reviewers will see changes alongside relevant context so they can focus on the work that needs human judgment.
• Branch policies will apply to agent identities, allowing teams to control which agents can change specific code.

These capabilities on the roadmap are designed to give you a clearer record of how agent work was produced, reviewed, and governed. They build on the platform’s orchestration, lifecycle context, governance, and security.

Together with the community

Scaling improvements in Git helps each client and host, and you don’t have to depend on a fork for your source control. That's why much of our Git work happens upstream. Git remains a collaborative project and GitLab has been the largest corporate contributor to Git in recent releases. Git contributions from many companies and the wider community shape every release, continuously iterating and evolving Git.

GitLab delivered a pluggable interface for Git's object storage in Git 2.54 and has been moving more of Git's object database subsystems behind it. And in Git 2.56, consistency checks, housekeeping, and packfile generation moved behind the interface, and that work continues. The interface belongs to the Git project and serves clients as well as servers. GitLab’s next generation of SCM will run as our own fast, scalable implementation of it with agent-facing interfaces. Also, we intend to extend the same abstraction to upstream Git, improving how Git handles large binary files. GitLab will continue working with the Git community on how capabilities like these can serve every Git client.

Evaluate next-gen SCM with your own repositories

You can request early access to GitLab’s next-gen source code management solution, and test it against the repositories that strain your Git backend today.

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 these statements are reasonable, they are subject to known and unknown risks, uncertainties, assumptions and other factors that may cause actual results or outcomes to differ materially. Further information on these risks and other factors is included under the caption "Risk Factors" in our filings with the SEC. We do not undertake any obligation to update or revise these statements after the date of this blog post, except as required by law.

Read more about next-gen SCM

• What is next-gen SCM?
• Git was built for humans — agents need an upgrade
• Transcend: Speed you can trust all the way to production

Costs multiply with every task you hand to an agent. Each task consumes tokens and credits, and as agents spread across your teams and automations, consumption can grow faster than usage. If you run the platform, you own that growth, including which teams and workflows drive it and whether the usage ships work.

At GitLab Transcend, we introduced the governed software factory, our architecture for agentic software engineering, and new capabilities in GitLab Duo Agent Platform that bring that growth under control. GitLab-managed open-weight models matched frontier-model task completion at a fraction of the cost in GitLab's benchmark, so you can align your model to the task to improve your team’s cost efficiency. GitLab Orbit gives agents lifecycle context so they retry less. Duo Agent Platform Impact Analytics and credit caps show where credits go and put a limit on them.

Control costs in the governed software factory

A usage total tells you what you consumed, and leaves hard questions open: how much routine work sat on an expensive model, how many agent runs were wasted retries, and which users and teams burned through the credits. When the dashboard only shows tokens, platform and engineering leaders end up debating a number neither side can stand behind. If you can't attribute the usage, set a limit, and cut the waste, you can’t optimize or justify your spend.

Breaking that pattern starts with the architecture. The governed software factory is built in layers, and cost grows where those layers don't connect. Two of those layers matter most for cost. The first is agent orchestration, where open weight models put routine work on lower-cost models. The other is data and context, where Orbit, Duo Agent Platform Impact Analytics, and credit and usage controls give humans and agents the context to produce high-quality outcomes at the lowest possible cost.

You can see the problem in a shadow software factory, where each stage has its own tool, with no shared policy or context between them. Agents spend tokens searching for context across systems that were never built to integrate. A governed software factory gives agents shared context, shared policy, and one place to measure what they cost. When every AI credit counts, you can:

• Spend fewer credits for the same work: Match models to the task at hand with open weight models, and ground agents in lifecycle context with GitLab Orbit so they retry less.
• Trace spend to its source: See credits by user, team, task, and model in Duo Agent Platform Impact Analytics and the GitLab Credits dashboard so you can point to what drove the growth.
• Set a ceiling before the next spike: Cap usage per user with credit caps, with overrides where needed, so agent loops stay inside the limits you set.

Match the model to the task

Agent cost starts with the price of each model call. GitLab Duo Agent Platform lets you pin a default per feature and control what your teams can use: your own model, self-hosted or from your provider, GitLab-managed frontier models, or GitLab-managed open-weight models, new in GitLab 19.4.

Three open-weight models are now hosted in GitLab Duo Agent Platform: GLM 5.3, Kimi K3, and MiniMax M3. In GitLab's internal benchmark with Duo agents, GLM 5.3 matched Claude Opus 5's task completion at approximately one-fifth the cost, Kimi K3 matched Claude Fable 5.1 at one-third the cost, and MiniMax M3 matched GPT-5.5 at one-eighth the cost. Model choice is an admin setting. In your top-level group's GitLab Duo settings, open Model Selection, select Manage Models, and pin a model to each feature. For example, pin Kimi K3 to Agentic Chat and MiniMax M3 to agents and flows, so routine work does not default to a frontier model. Group Owners also choose which models their teams can use.

Cut retries with the right context

Model choice sets the price of each call, and retries multiply the number of calls. Gartner found that a team of 40 developers spent 23 times more on AI because agents kept retrying without the right rules and context. Agents retry when they lack context. Across a monorepo or several repositories, an agent spends its first stretch crawling files to work out what connects to what, and every retry resends the full context window.

GitLab Orbit maps your code, work items, merge requests, pipelines, deployments, and security findings into a single graph that stays current as your teams ship. Agents in GitLab Duo Agent Platform query it natively. External agents like Claude Code and Codex connect through Model Context Protocol (MCP), and custom tooling connects through the REST API. Every agent sees exactly what its user can see in GitLab.

With that context, an agent asks the graph and gets a precise answer faster and more efficiently. In GitLab testing, the same task in Claude Code needed up to 45x fewer retries with Orbit and, separately, used 4.5x fewer tokens to get the right context the first time. Orbit is in free beta on GitLab.com today and reaches general availability next month across all deployment options.

Manage what you can measure

Models and context lower the cost of each task. Impact data shows whether it worked. Duo Agent Platform Impact Analytics answers the two questions platform leaders ask: how much are we spending, and where is that spend concentrated? It breaks spend down by team, task, and model for the teams and date range you choose, and it shows how an open weight model stacks up against your current model mix, so you compare with data instead of guessing. The GitLab Credits dashboard adds detail below the team level, tracing usage to the user and session behind it.

Visibility pairs with limits. Without a limit, the only lever left is asking everyone to use less. Credit and usage controls set caps at the subscription, group, or user level, with alerts at 50%, 80%, and 100% of spend and an automatic pause once usage reaches the cap. A flat per-user cap, such as 1,000 credits per user/per month, applies to every team member, and an individual override, such as 500 additional credits, gives an engineer who is experimenting room to work without asking for more. Per-user caps apply once a user has consumed their included credits, and only the capped user loses access to credit-consuming features, until the next billing period or until an administrator raises the cap.

Duo Agent Platform Impact Analytics shows credit consumption alongside the work that reaches production, so you can see whether usage is turning into delivered work.

See Duo Agent Platform Impact Analytics in action in this demo from our Transcend global event:

Put agent cost control to work

Start your agent cost control journey with the model. GitLab-managed open-weight models are generally available. In Model Selection pin GLM 5.3, Kimi K3, or MiniMax M3 to a routine workload, such as a flow that runs on every merge request.

Next, cut retries. GitLab Orbit is in free beta on GitLab.com today. Turn it on for the group that runs the most agent sessions. Orbit reaches general availability next month across all deployment options.

Then, measure and set limits. Duo Agent Platform Impact Analytics is in early access, so you can see spend by team, task, and model. Credit and usage controls are generally available. Set a per-user cap for GitLab Credits with overrides for your heavy users. After a few weeks, compare usage by team and model against the previous period.

Design the foundation for your software factory with GitLab Duo Agent Platform. If you're new to GitLab, start a free trial of GitLab Duo Agent Platform. If you're on Premium or Ultimate, turn on GitLab Duo Agent Platform and use the GitLab Credits included with your subscription.

AI coding tools have changed how fast software gets written, but not how fast it ships. As code generation accelerates, the bottleneck moves downstream into verify, review, and ship. Those stages still run on human time. While agents write fixes in minutes, delivery slows on constant wait times and manual handoffs. Reviewer signoffs, pipeline alerts, scan triage, and step-by-step prompting are examples of obstacles DevOps teams face in maintaining on-time delivery.

At GitLab Transcend, we announced new agent orchestration capabilities in GitLab Duo Agent Platform to eliminate that delay. Goal-driven flows take the outcome you define and run it end to end, through review, tests, security scans, and approvals from Duo CLI, headless mode, or Agentic Chat. GitLab for Slack starts work from the conversation where it was requested, like turning a thread into an issue or kicking off a flow to fix a failing pipeline. Custom Flows let you define your own multi-step sequences and start them from GitLab events like a mention, an assignment, or a pipeline. All three run under your identity, policy, and evidence chain.

How agentic orchestration speeds up delivery

Faster coding, process checklists, and single-chat coding agents all contribute to delays in software delivery. With agentic orchestration capabilities, you can accelerate each stage and reclaim time for your development team.

Fewer handoffs. You name the goal, and the flow keeps working across review, tests, scans, and approvals instead of stopping between each step.

Start work where the request already is. A Slack thread becomes an issue or a flow immediately from where you’re already discussing the work.

Automate the process your team already follows. Custom Flows let you define your own multi-step sequences and start them from a mention, an assignment, or a pipeline.

Stay in control. Flows run under the same identity, policy, and evidence chain as the rest of GitLab, so governance stays with the work. Foundational agents and flows already cover plan through analyze stages in the GitLab UI, your IDE, and Duo CLI, and you can enable more from the AI Catalog, bring in external agents, and connect tools through the MCP client and the MCP server.

Goal-driven flows: Set your objective

Goal-driven flows give agents the finish line instead of the next step. You describe the objective and what done looks like, and the flow keeps working until it gets there. Goal-driven flows automate handoffs, so review, tests, security scans, and approvals run as one connected sequence.

You start one with the /goal command, for example:

/goal Fix the checkout timeout. Continue until tests pass and CI is green.

A separate model checks the work against your goal at each step, and you can stop or redirect a run at any point. You can start a goal-driven flow in Duo CLI, in headless mode with duo run --goal, and in Agentic Chat.

GitLab for Slack: Start where the work gets discussed

GitLab for Slack lets you start work in GitLab without leaving Slack. Mention @GitLab in any channel or thread and describe what you need, such as "fix the failing pipeline," and a flow starts. Duo streams its progress back into the thread, so your team follows the work where the conversation is already happening. The flow runs under the same identity and policy as any other GitLab flow, so governance stays in GitLab. You can also use @GitLab to ask questions about your codebase or create an issue from the conversation.

Custom Flows: Turn your process into a flow

Custom Flows chain agents together to match the process your team already follows. You define a flow once, start it from GitLab events like a mention, an assignment, or a pipeline, and run it in CI/CD pipelines. A self-healing pipeline, for example, can analyze a failed test, generate a fix, commit it, and notify your team, with human-in-the-loop checkpoints at sensitive steps. Each flow runs under the same identity, policy, and evidence chain as every other flow, so governance stays in GitLab.

Put agent orchestration to work

To achieve the benefits of agent orchestration, start with goal-driven flows. The documentation for Duo CLI slash commands walks you through /goal. Goal-driven flows are available on GitLab.com, GitLab Self-Managed, and GitLab Dedicated, on the Premium and Ultimate tiers, and require GitLab 19.3 or later and Duo CLI 9.17.0 or later.

Then extend that orchestration to your team's processes and channels with Custom Flows, which are generally available, and the MCP server and GitLab for Slack, which will be generally available later this month.

To design the foundation for your software factory, check out GitLab Duo Agent Platform. New to GitLab? Start a free trial of GitLab Duo Agent Platform. Already on Premium or Ultimate? Turn on GitLab Duo Agent Platform and use the GitLab Credits included with your subscription.

If you run application security across more than one top-level group, getting a single organization-wide view of your risk has meant manually pulling together data. That is operational work rebuilt in spreadsheets and one-off scripts every time someone asks. This manual work is easy to get wrong, and is often out of date the moment it is published. Every hour spent assembling that view is an hour your security team is not spending on strategic work to drive down risk.

With GitLab 19.4, the security dashboard now gives you a consolidated view of risk at the organization level. Across every top-level group and every scanner your teams run, you can see how your whole application security program is doing, find where the real risk is concentrated, and act on it, without stitching anything together by hand. Your team spends its time remediating vulnerabilities instead of assembling reports, and when leadership or an auditor asks where the organization stands, you have a current, defensible answer on one screen. The organizational level security dashboard is available in beta for GitLab.com users.

Watch the demo:

See total risk, then triage down to the project

The risk score quantifies the risk level across the entire organization. This score is calculated based on the severity and age of your open vulnerabilities, whether each one appears on the Known Exploited Vulnerabilities (KEV) list, and its Exploit Prediction Scoring System (EPSS) score. The risk score helps security leaders prioritize what area of the organization is most susceptible to threats, rather than a raw count that treats every finding as equal.

The charts around the risk score also proactively answer follow-up questions. The Vulnerabilities over time view shows whether risk is trending up or down across the organization over 30, 60, or 90 days. Vulnerabilities by age shows what is going stale and slipping past your remediation targets. Open vulnerabilities by severity and the top 10 Common Weakness Enumeration (CWE) show the shape of the risk, so a weakness that recurs across the whole organization gets interpreted as a training or policy gap rather than a series of bugs. Filter the entire dashboard by project or by report type to focus on static application security testing (SAST) or dependency scanning vulnerability types.

Consolidate every scanner into one view

The organization dashboard isn’t limited to GitLab's own scanners. Any third-party scanner that outputs Static Analysis Results Interchange Format (SARIF) reports can feed its findings into GitLab. These become vulnerability records like any native finding and roll up into the same risk score, charts, and per-project view. For a security team running multiple tools across the organization, you get one consolidated read on risk, including GitLab's scanners and those you already run, rather than a separate dashboard per tool and manual efforts to combine them.

Turn on the organization security dashboard

The organization security dashboard is available in beta on GitLab.com for Ultimate. It reads the data your projects already produce, so switching it on depends on having the right pieces in place.

Before the dashboard can display your org-level risk, confirm four things:

• You have created an Organization with multiple top-level groups using the Organizations (Beta) feature. To do this, Owners can Create Organizations under Settings > General > Advanced.
• You have Owner role access to the Organization-level in GitLab.
• Advanced search and advanced vulnerability management are active. These power the rollup across top-level groups, and on GitLab.com they are on by default.
• Your projects run at least one security scanner and have a completed scan on their default branch, so there are vulnerabilities to aggregate.

With that in place, go to the top bar, select Search or Go to, and choose your Organization. In the left sidebar, select Secure, then Security dashboard. The organization view opens with the risk score and the charts across every top-level group in the organization.

Not on GitLab Ultimate yet? Start a free trial today to get organization-level visibility into your risk posture.

At Transcend, we made over a dozen announcements across all four layers of our architecture for agentic software engineering: agent orchestration, data and context, DevOps workflows, and governance and security. Watch the replay, or read on for what shipped and how to turn on the new capabilities.

At a glance

Agent orchestration across the software lifecycle

Today, each step in your agentic workflow still waits for a person to approve it before the next one starts. With new capabilities in GitLab Duo Agent Platform, you can eliminate the wait between your development stages.

Goal-driven flows take a stated objective and run it end to end, through review, tests, security scans, and approvals from the Duo CLI, headless mode, or Agentic Chat. Custom Flows let you chain agents together to match the process your team already follows. GitLab for Slack starts a flow from the channel where the conversation is already happening. The MCP Server enables external AI applications and coding agents to securely access your GitLab instance under the same policy your own agents follow.

GitLab-hosted open-weight models, including GLM 5.3, Kimi K3, and MiniMax 3, give you a lower-cost option when a workload doesn't need a frontier model. At similar task-completion rates, some open weight pairings deliver up to 8x more model calls per GitLab Credit than their frontier counterparts.

Data and context to power human and agent reasoning

Every agent task starts by re-deriving the same context, which drives up retries and token use. And without coherent visibility into AI costs and ROI, there's no way to tell whether your investment is paying off.

GitLab Orbit, the context graph of your entire software lifecycle increases agent accuracy with up to 45x fewer retries, effectively reducing cost for agentic workflows with up to 4.5x fewer token use. During its beta period, Orbit has been used by more than 3,500 organizations, running over 280,000 queries.

Duo Agent Platform Impact Analytics shows the cost and impact of your AI investment by team, task, and model. Credit and usage controls let you set caps at the subscription, group, or user level, with alerts at 50%, 80%, and 100% of spend, and an automatic pause once you hit the cap you set.

DevOps infrastructure at agent scale

Most of what ships isn't code your team wrote, it's assembled from open source packages, base images, and libraries pulled in from everywhere. When every team runs its own registry, there's no single place to confirm what you actually published or shipped.

Back in June, during Transcend London, we introduced our next-gen source code management solution helping you achieve machine scale with your coding agents. The next machine-scale problem goes to the step after code, when you’re creating a build.

GitLab Artifact Central replaces a separate registry per team with one place to publish and pull from, built next to your source code and CI pipelines. It publishes and pulls Maven, npm, and Docker, and OCI packages directly from CI pipelines, with PyPI and NuGet coming at GA. Artifact Central uses the same identity and permissions as your source code, with virtual repos, native CI/CD authentication, and full build provenance. Early results show roughly 50% lower total cost of ownership compared to alternative tooling.

Governance and security with centralized enforcement

Agents pull in package components to your build at machine speed, making it impossible to manually secure what you ship. When that gap exists, you risk shipping security vulnerabilities into production rather than catching them before they impact customers, and you have to answer for it.

GitLab Dependency Firewall, now in early access, sets rules on package age, vulnerability severity, malicious package detection, and license compliance, with actions to block, quarantine, or warn, enforced on the registries you already use. It works directly with GitLab Artifact Central, and is compatible with JFrog Artifactory and Sonatype Nexus Repository.

With a greater number of builds, another risk emerges: agents inheriting build-time secrets from local dev environments that nobody secured, and using them across CI pipelines. GitLab Secrets Manager gives each build-time secret one home, scoped to the job that needs it, with one-click revocation for a leaked credential and up to 50% savings compared to hosting a separate vault.

The same AI models that let agents write and ship code at machine speed also make existing weaknesses faster and cheaper to discover, connect, and exploit. The GitLab Security Standard lays out five stages for assessing and hardening your agentic software development: authorizing every actor's access, isolating workspaces and their inputs, verifying the checks that judge the work, releasing exactly what was verified, and responding fast when something looks wrong, all built on a foundation of policy, audit, and ownership. Read the full standard for the complete breakdown.

Coming soon, Anthropic’s Claude Mythos 5 and 5.1 will power new GitLab Duo Agent Platform security flows, helping organizations with approved environments find and fix vulnerabilities faster than attackers can discover and exploit them.

How to buy with GitLab Flex

Agentic software engineering makes headcount, credit burn, and new capabilities hard to predict six months out. GitLab Flex is one annual commitment that covers new GitLab capabilities as they ship, without re-procurement. It lets teams reshape seat and AI spend via GitLab Credits on a monthly basis as their needs change.

Where to start

• Turn on GitLab Duo Agent Platform: Existing customers start today with credits already in their subscription, and every new GitLab trial includes 30-day access. To increase the efficiency of your agents, turn on GitLab Orbit beta for GitLab.com.
• Adopt the GitLab Security Standard: GitLab Ultimate is available as a free trial. A Secrets Manager trial is available to Ultimate and Premium customers. GitLab Artifact Central is open in beta, and you can request early access to Dependency Firewall.
• Get more from every dollar with GitLab Flex: One annual commitment for new GitLab innovations without re-procurement - with the ability to reshape your spend for seats and GitLab Credits month to month.
• If you're migrating from GitHub, do it on your own terms with dedicated migration tools, custom migration services, and an exclusive offer to get one year of GitLab free when signing up for a three-year contract.

And if you're ready to start building, join "Life after code: the path to production at the speed of imagination," our three-week hackathon in partnership with Anthropic and Google Cloud.

Wherever you start, you're choosing the same destination: the foundation for a governed software factory where agents accelerate the work and every change stays trusted.

We can’t wait to see what you build next.

Every software build is assembled from open source packages, base images, and libraries, with your code on top. When one of those components is missing or has drifted, the build fails. At agent speed, those failures multiply, and no team can clear them as manual exceptions.

Project-by-project registry sprawl makes it worse because retention rules, storage limits, and publish access all live separately inside each project. Project-level design works when a person sets up each registry by hand, but breaks down when agents are running continuously across hundreds of projects.

At GitLab Transcend today, we announced GitLab Artifact Central: one organization-level registry that replaces hundreds of project-level ones, so every pull or publish by a human or an agent runs through the same governed door, enabling platform teams to assemble the right software the first time.

Here is more on why we developed Artifact Central, and how it can help your team.

Set policy once, enforce everywhere

In GitLab, retention rules, storage limits, and who can publish all live inside each project’s free package and container registry, configured on its own. GitLab Artifact Central moves that job up one level. Teams assign retention rules, quota settings, and access policies once at the organization level, instead of recreating them in every project underneath it.

Every repository is closed by default: Being a member of the organization is the gate, not the grant. Organization membership alone doesn't unlock a single repository until a role grants it. We’ve built four roles specifically for artifacts: Admin, Manager, Contributor, and Viewer. These roles are kept separate from GitLab's existing project roles, so granting someone access to a repository never touches their privileges anywhere else.

One URL for publishing, proxying, or both

Instead of navigating an internal wiki page explaining what is where, developers point to one URL for everything. GitLab Artifact Central does this through three repository types:

• Hosted — The private packages and images your teams build and publish.
• Remote — A proxy in front of an external source, like Docker Hub or Maven Central, with the connection tested before anything depends on it.
• Virtual — A single endpoint that brings hosted and remote repositories together. GitLab checks the hosted repository first, then falls back to the remote source. The first external pull is cached, so subsequent pulls come directly from GitLab without another trip to the internet.

Virtual repositories matter most for teams comparing GitLab with other artifact management solutions. They give developers the familiar single-endpoint experience without requiring them to think about where an artifact lives. Whether it was built internally or pulled from an external registry, developers request it the same way. During the beta period, Artifact Central supports Maven, npm, Docker, and OCI, with more formats to follow.

Trace anything back, automatically

Here's the part that's hard to replicate outside GitLab. Every artifact that publishes through GitLab Artifact Central carries its build provenance automatically: which pipeline built it, which branch and commit it came from, who triggered the job. Since it is the same platform that ran the build, the registry already knows.

Authentication works the same way. Publishing and pulling use CI_JOB_TOKEN, the identity your pipelines already have, for people and agents alike. An agent publishing or pulling through CI pipelines uses that exact same job token, not a bolted-on service account with separate permissions to maintain. With a standalone registry, tracing an artifact back to its source means separately correlating IDs across your CI system and your registry – using a script someone owns and maintains. With Artifact Central, the pipeline, branch, commit, and job are already attached to the artifact itself.

Answer 'what did we publish?' in seconds

Artifact Central lives in the same platform as your code, merge requests, and pipelines, so artifacts published from CI carry their build provenance: the pipeline that built them, the commit, and who published them.

Next, we plan to connect that across your organization through GitLab Orbit, so "which of my running services are affected by this vulnerability?" becomes one question with one answer, instead of a manual search across four or five tools.

Pair Artifact Central with Dependency Firewall

GitLab Dependency Firewall, a separate GitLab product now in early access for Premium and Ultimate customers, works out of the box with Artifact Central. With Dependency Firewall, you can stop risky packages before they ever reach a build. You add its check to each pipeline using the glab CLI, so coverage is pipeline by pipeline, no matter which package manager your teams use. Next, we plan to enable tighter integration between the two capabilities, so that one policy for your whole organization blocks risky packages by vulnerability, license, or package age the moment they're pulled.

Two benefits of the same registry

Here's what that looks like from two different desks: a developer shipping code, and the platform team making sure the whole thing holds together.

A developer publishing from CI. Your pipeline publishes a Maven artifact using the job token it already has without any new secrets to manage. If that same developer needs an internal package alongside something from Maven Central, they point at one virtual repo URL and let GitLab Artifact Central sort out where each one actually lives.

A platform team setting policy once. Instead of configuring rules across 100s of separate projects, an admin sets storage quotas and repository access rules at the organization level, one time — and every repository underneath inherits it. When someone asks how much the company is storing, and where, there's one dashboard with the answer.

Migrating your artifacts

Most companies aren't starting from zero, and switching cold from an existing registry isn't realistic. With GitLab Artifact Central, you can add your existing repos as remotes behind a virtual repo, so developers point at one URL and artifacts move over only when a build actually asks for one. There is no need for bulk copies, weekend migration windows, or moving petabytes of data across your network.

Your old registry remains the system of record. When you're ready, you convert that remote to a hosted repo on Artifact Central. Your migration is safer and gradual.

Try Artifact Central, free in beta

GitLab Artifact Central is available today in beta for GitLab.com, with availability on GitLab Self-Managed planned for later this month. There's no billing during the beta, and nothing to purchase. We're tracking usage to shape pricing ahead of general availability, and we'll share details then.

Help us continue to build GitLab Artifact Central

None of this would be where it is without our design partners, who've been running Artifact Central with real workflows for weeks. Their feedback already shaped what's shipping today, and your feedback will shape what comes next.

No invitation is required to participate in the beta of Artifact Central, just sign up on our website and a member of our team will be in touch to help enable it for your account. If you don’t have a GitLab account yet, you can also sign up for the beta, and a member of our team will reach out.

We can't wait to see what you build.

Watch the replay of our Transcend event to see demos of new platform capabilities and explore what it takes to carry the speed of agentic AI across the full software lifecycle.

Attackers disguise malicious packages as ones you trust. In June 2026, GitLab researchers found five malicious PyPI packages, four of them typosquats of Flask, Requests, and NumPy, that run at install time and steal CI/CD credentials. Additionally, AI coding agents now add open source dependencies on their own, often unreviewed, so developers don't have oversight into what packages may contaminate your build.

Once a malicious or vulnerable package enters your build, its code may run with the same access in your CI pipeline, and it can then reach any system your pipelines touch.

GitLab Dependency Firewall, introduced today at Transcend in early access, can block packages that match your policy, including malicious, vulnerable, and non-compliant packages, before they reach your build. Built-in governance stops risk before install, so your team doesn’t have to trace, remove, or rebuild what a policy blocks. Developers and their agents can keep pulling the dependencies they need without waiting on a manual security review, and packages that satisfy your policy requirements become part of your official build.

Block malicious packages without breaking your build

Without a policy at the point of install, a bad package goes into the build first and gets caught later. Software composition analysis (SCA) scans what you've already pulled in, so by the time it flags a malicious package, a high-severity vulnerability, or a license your legal team won't accept, the dependency is installed and may have shipped in an artifact. Tracing where it went, pulling it out, and rebuilding turns a routine pipeline run into unplanned work for your engineering team.

With Dependency Firewall, you decide what's allowed into your builds before it's installed, by defining policies for:

1. Malicious status — packages flagged in GitLab's malware advisory database
2. Vulnerability severity — the severity you set (critical, high, medium, or low) and the number of findings you allow at that level, including zero
3. License type — the licenses you allow or deny, listed by full name, and how to handle packages whose license can't be determined
4. Package age — the minimum age a package must reach before it can enter a build, so a version published minutes ago can't go straight in before anyone has vetted it

Rolling out enforcement does not have to put delivery at risk. Start in warn mode, where the firewall records what a policy would catch, but lets the build continue. It leaves an audit event, a dashboard entry, and a line in the CI summary, so you can analyze whether or not to block the build.

Once you trust the policies, switch to block mode, which stops the pipeline on a match and gives the reason. When someone has a real need to get an approved package through, a logged bypass lets a designated user or token proceed, on the record.

Set policy once, or tailor it by team

A firewall that enforces only at the registry gives everyone the same policy, but that rarely fits how teams actually work. A payments service and an internal prototype carry very different risk, and your policy should treat them differently.

With Dependency Firewall, you set one policy at the top-level group and every project beneath it inherits the same rules. When a team needs something different, you can set a policy for that group or project.

You can also enforce policy at the registry, so every pull is checked, not just pulls from a pipeline. Rules live as code in a security policy project, so they are reviewed and changed through a merge request like the rest of your configuration. They inherit from the top-level group down to each project, and where rules overlap the strictest one applies. A critical service can be held above the organization's baseline, and no project drops below it.

Check a package before you pull it in

A developer, or an agent working on their behalf, usually finds out a package is not allowed only when the pipeline fails. That costs a build cycle and breaks concentration, right when the work is moving.

You get the answer from GitLab Dependency Firewall before you add a dependency, in the place you already work, allowing you to pick a package that passes the first time.

Using GitLab CLI within the terminal or within a script, a command line check can identify if a package will pass or be blocked by your policy, without requiring developers to open a separate console. It covers common package managers such as npm, pip, Poetry, Maven, Gradle, and Bundler, with more coming soon.

See and prove every decision

A security leader has to be able to prove what a control is doing during an audit. A control that blocks quietly, with no record, does not answer the auditor’s question and does not build trust with the teams it governs.

You get one view of what the firewall has allowed, warned against, and blocked, with an immutable record of each decision you can hand to an auditor.

A Dependency Firewall dashboard shows activity and outcomes across the projects in scope. Every warn, block, and bypass writes an audit event that records the rule that matched, the policy behind it, and the package involved.

Get early access to GitLab Dependency Firewall

You can stop malicious, vulnerable, and non-compliant packages before they reach a build. It is compatible with GitLab Artifact Central and external registries from Sonatype Nexus Repository and JFrog Artifactory, and does not require standing up a separate tool next to your GitLab deployment. Dependency Firewall is now in early access for GitLab.com and GitLab Self-Managed customers in the Premium or Ultimate tier. Request early access today!

GitLab's engineering team builds a lot of our own internal tooling, but one platform in particular forced us to rethink how we handle authorization: our internal GRC tool that serves two very different customer bases under one roof — our Security Compliance team and our Internal Audit team.

If you're building or maintaining an internal Django tool that's starting to serve more than one audience — different teams, different data classification levels, different data that shouldn't cross streams — this post walks through the problem we hit, how we solved it, and how you can apply the same pattern to your own app.

The challenge

Our original tool was a single Django app built for the Security Compliance team with login_required on every view. This was the correct approach until Internal Audit found a new use case for our tool that would include a completely separate workflow, with its own data, its own models, and its own sensitive information that Security Compliance should not see.

login_required answers exactly one question: Are you logged in? It doesn't answer the question that actually matters in a multi-tenant internal tool: Are you allowed to be here? An authenticated Security Compliance user hitting an Internal Audit URL waltzed right past the login check and into data they were never supposed to see.

If your app has ever grown a second audience after the fact, this probably sounds familiar. The question worth asking yourself right now is simple: Does every view in your app check who the user is, or just whether they're logged in? If it's the latter, you likely have the same gap we did.

We needed clean separation — not "pay no attention to this button over here," but an enforced boundary that holds regardless of what URL someone types in.

The architectural decision

When Internal Audit's use case landed on our roadmap, we had the classic fork in the road: Bolt it onto the existing app or restructure? We restructured.

The result is a core Django project — shared auth, user management, audit logging, base UI components — with two independent module apps sitting on top of it. One is for Security Compliance and one is for Internal Audit. Each module owns its own models, views, and API surface.

The constraint we imposed on ourselves, and the one that made this whole thing worth writing about was that core has zero knowledge of compliance or internal audit data. Either module can depend on core. Neither module should depend on the other. That constraint keeps this from becoming two apps stitched together with duct tape and super glue.

Access control

We're a compliance engineering subdivision building a tool that stores sensitive compliance and risk data. Sloppy access control here isn't just a bug, it's a serious credibility problem.

Our design decision was to use something already native to Django: the built-in auth system. Each module maps to exactly one group. A user can belong to one group, both, or neither, and the system enforces the right separation of duty at every layer regardless of which combination applies. The navigation UI, the Django views, and the REST API each independently enforce group membership.

The implementation

There is one reusable class in core that both modules inherit from: GroupRequiredMixin. It checks group membership and raises PermissionDenied if the user isn't in the required group.

Module-level subclasses

Each module gets a three-line subclass that sets required_group_name — a GasGroupRequiredMixin and an IsGasGroupMember for the Security Compliance side, with the same pattern repeating for Internal Audit. That's the whole cost of adding a module's enforcement layer: one new file, one new attribute. The actual checking logic lives in core and never gets touched again.

The UI layer

Finally, there is a template filter, user_in_group, so navigation only renders what a user is actually allowed to view. It wraps a check like user|user_in_group:'erm' around any nav block that should only show up for ERM members.

This is a UX guard, not a security boundary. Hiding a navigation link doesn't stop anyone from typing the URL directly. That's what the mixins and the Django REST Framework permission class are for. The template filter just keeps the UI honest about what a given user can see and do.

What's next for us - and where you could start

Step back out to the platform level and the payoff is that this is a repeatable pattern that is module- and team-agnostic. A hypothetical third module — a vendor risk workflow, an audit management module, whatever comes next — inherits the same access control structure, the same audit trail, and the same shared authentication without a single new line of enforcement logic. The cost of a new module becomes almost entirely a business requirement, not infrastructure scaffolding.

That's the bet we made: Build the foundation once and let every future module ride on top of it instead of reinventing access control from scratch.

If you want to try this in your own app, here's roughly the order we'd suggest:

1. Check your views for the login-versus-authorization gap. Grep for login_required and LoginRequiredMixin and ask, for each one, whether it's actually guarding sensitive data from other authenticated users — not just anonymous ones.
2. Draw the module boundary before you write code. Decide what's genuinely shared (auth, base UI, logging) versus what belongs to one audience only.
3. Write one mixin, not one per view. A single GroupRequiredMixin in your core app, subclassed per module, means your enforcement logic has exactly one place to be reviewed and one place to be wrong.
4. Enforce at every layer independently — views, API, and navigation — so hiding a link is never your only line of defense.

References

• Django authentication system — Using the Django authentication system
• Django class-based views — Using UserPassesTestMixin / permission mixins
• Django REST Framework — Permissions

GitLab's Threat Research Group discovered a command execution vulnerability (GHSA-grg2-7gc6-36m6, CVE-2026-102437) in DeepSeek-Reasonix Studio, a desktop git client designed for developers pairing with AI coding assistants. The flaw, called ConfigPoisoning, could allow attacker-supplied code to execute when a developer views a file's diff. To address this vulnerability, you should update to DeepSeek-Reasonix Studio 2.21.0 or DeepSeek Reasonix npm 1.39.3.

This is not an isolated DeepSeek-Reasonix bug. GitLab's Threat Research Group found that multiple widely used coding agents are susceptible to the same class of vulnerabilities, which allow attacker-controlled commands to run from a repository's own .git/config and .gitattributes files. DeepSeek-Reasonix is the first case we're disclosing in full.

Note: Git repositories hosted on GitLab are not affected by this vulnerability, as cloning a repository over HTTPS or SSH does not transfer local configuration files.

TL;DR

• Critical vulnerability. GitLab's Threat Research Group found a critical command execution vulnerability in DeepSeek-Reasonix Studio, a desktop git client for AI-assisted development, that could run attacker-controlled code when a developer views a file's diff under specific repository configuration conditions.
• The root cause. DeepSeek-Reasonix's own git wrapper hardens several git config keys against command injection, but its own code comment names one gap it hadn't closed: filter.<driver>.clean, which git selects per file through .gitattributes rather than through a fixed config key.
• Immediate recommendations. Update to DeepSeek-Reasonix Studio 2.21.0 or DeepSeek Reasonix npm 1.39.3. If you build tools that shell out to git, don't just patch the one vulnerable key. Override every relevant key on every call, or avoid invoking git's filter and textconv machinery, which are the hooks git uses to transform file content before committing or diffing, altogether.

Why coding agents are a different kind of attack surface

Coding agents run git against any directory a developer opens. They inherit .git/config and .gitattributes from whoever wrote the repo, not from the developer who opens it. Several git configuration keys, among them core.fsmonitor, core.hooksPath, diff.external, and filter.<driver>.clean, run a named command as part of ordinary git operations. Plain git clients already carry advisories for this.

Because every coding agent wraps git its own way, each one tends to close only the primitive that caused its own last incident. DeepSeek-Reasonix's internal/gitcmd closed four of these primitives on every invocation. Its own code comment named the one it hadn't closed.

How the vulnerability works

internal/gitcmd neutralizes core.fsmonitor and maintenance.auto on every call, and adds --no-ext-diff and --no-textconv on diffs. It never touches filter.<driver>.clean. That key isn't picked from a fixed list. .gitattributes selects it per file, so no deny-list can close it the way the others were closed.

Here's the real call, from desktop/workspace_changes.go:

args := []string{"-C", base, "diff", "--no-ext-diff", "--no-textconv", "--relative", "HEAD", "--", filepath.FromSlash(rel)}

The clean filter still runs here. It produces the comparison blob the diff needs, and that step never passes through the flags above.

Full call chain

Here's the full chain, step by step:

1. The setup. secret.bin carries a .gitattributes entry assigning it to a filter driver named pwn, and the repository's .git/config defines that driver's clean command as a script of the attacker's choosing.
2. The diff view opens. A developer opens the file's diff in DeepSeek-Reasonix's desktop app, an ordinary action for any file with an uncommitted change.
3. DeepSeek-Reasonix runs its hardened command. desktop/workspace_changes.go issues git -c core.fsmonitor=false -c maintenance.auto=false -C <repo> diff --no-ext-diff --no-textconv -- secret.bin, with every existing hardening flag in place.
4. The clean filter runs anyway. Git invokes filter.pwn.clean to build the comparison blob, a step none of those flags touch. The attacker's command executes, once for each side of the diff.

Replaying the hardened command ran the payload twice: diff builds a clean-filtered blob for each side of the comparison, so the filter fires once per side. git status only checks which files changed, so it never builds that blob and leaves the filter untouched. That isolates the bug to diff rendering, matching DeepSeek-Reasonix's actual code path.

Scope

.gitattributes survives a clone. .git/config doesn't. Delivery needs an archive, a synced folder, a CI cache, or a devcontainer build. We confirmed this at commit ea28602 and the tagged pre-release studio-v2.9.0. It affects both the desktop app and the npm package.

But there's a more direct vector specific to agentic tooling. A rogue, compromised, or prompt-injected coding agent already running on the developer's machine has the developer's own filesystem access. It can write the poisoned .git/config straight into a repository that was cloned completely normally. No archive, synced folder, or CI cache is required.

Why new tools inherit old bugs

None of this is unique to DeepSeek-Reasonix.

• Repository configuration gets treated as part of the tool. Coding agents read .git/config or .gitattributes as if they were the tool’s own settings, when it’s the repository’s author who controls them. That distinction is easy to miss, since the files sit right next to the code and look like they belong to it.
• We've seen this trust failure before, in a different file. Earlier this year, GitLab's Threat Research Group found the same pattern in Serena, another AI coding tool. It ran attacker code from a project's own configuration file, .serena/project.yml, when a developer opened the repository. In both cases, the tool trusted a file the repository author controlled, and we expect to find the same mistake in other agentic tools.

How this impacts you

If you use DeepSeek-Reasonix

Update to Studio 2.21.0 or DeepSeek Reasonix npm 1.39.3. On older versions, avoid diffing any repo you didn't obtain through a direct clone yourself.

If you build git-wrapping tools

These recommendations apply to any tool that shells out to git against a directory it doesn't control.

• Read blobs with git cat-file or git show, and diff in-process, when you only need byte-level content.
• If you must shell out, override every relevant key on every call. That means core.fsmonitor, core.pager, core.editor, core.hooksPath, diff.external, core.sshCommand, and filter.<driver>.clean or smudge for every driver name across .gitattributes, .git/info/attributes, and global or system files.
• One flag doesn't cover another. --no-ext-diff affects diff.external. It does nothing for core.sshCommand.
• Don't assume the poisoned config has to arrive with the repository. Another agent, extension, or process running with the developer's own permissions can write it straight into an already-cloned repo.
• Test against a deliberately hostile config pair before you ship.

If you lead a security team

A tool that shells out to git on a developer's machine runs with that developer's full access. Ask vendors how they neutralize repository-local configuration, not just how they handle an untrusted remote.

Disclosure timeline

Thanks to the DeepSeek-Reasonix maintainers for accepting the report and shipping a fix.

How GitLab can help

GitLab Duo Agent Platform Security Analyst Agent can help you check your codebase for this same pattern. Begin your investigation by asking the agent:

"Does this code shell out to git against a directory it doesn't control, and does it neutralize `core.hooksPath, filter.*.clean`, and `diff.external` before running?"

The agent then will evaluate the potential impact on your environment.

Looking ahead

DeepSeek-Reasonix's history is a good reminder that even a well-documented, honest gap in security can still ship, simply because knowing about a risk and closing it aren't always the same thing. The same pattern is present in several other widely used agent tools, currently under coordinated disclosure. We'll publish details on each once a fix is available.

Explore more security research from the GitLab Threat Research Group.

Government agencies are feeling twin pressures: While the U.S. Office of Management and Budget (OMB) is urging you to deploy AI faster, the U.S. Government Accountability Office (GAO) wants guardrails in place before that happens.

To accelerate AI coding, many agencies are turning to AI coding assistants like Anthropic's Claude Code. But what about guardrails? GitLab Duo Agent Platform can govern your entire software development lifecycle, regardless of which model creates your code.

The need for speed with control

To realize the full potential of AI, government agencies need to eliminate the friction that currently exists. For instance, OMB points to outdated compliance processes as one of the biggest obstacles to deploying advanced AI-powered cyber defenses, while GAO says a lack of safeguards is a limiting factor to greater AI adoption.

Agencies utilizing coding assistants might be solving the speed issue, but without a governance strategy, they lack true compliance. Writing code has never been cheaper or faster, but knowing what's in that code before production is another matter.

A governed workflow

In February 2026, the NIST Center for AI Standards and Innovation launched the first federal program dedicated to agentic AI security standards, giving agencies a formal reference for how agents should be authenticated, authorized, and audit-logged.

Meeting that bar takes more than connecting Claude Code to GitLab. An integration passes data between two tools. It doesn't create a shared context model, a policy engine, or a single audit trail. GitLab Duo Agent Platform, AI orchestration across the software development lifecycle, starts with context already built in. It holds the project, the issues, the merge requests, the pipelines, and the vulnerability history — the full picture a standalone coding agent simply doesn't have. Every action Duo Agent Platform takes is scoped, logged, and reviewable inside the platform your agency already runs.

Foundational flows fire automatically on software development lifecycle events, run on the GitLab Runners your agency operates, and tie an audit trail to every merge request, with no script for your team to build or maintain. It's one governance plane across every tool your team runs.

That governance also isn't tied to any single model. AI models and providers are a replaceable component of GitLab's architecture, not an inseparable one, so your agency keeps the ability to authorize, restrict, or swap out which model is doing the writing without rebuilding the workflow around it. Claude Code is a strong example of a model that plugs into that architecture well.

A change is only as useful as what happens after it's written: Can it be safely understood in the context of your delivery system, acted on correctly, documented with the right evidence, and handed back into the workflow your team already governs? Which tool wrote better code doesn't answer that.

Running Claude Code as the coding interface inside GitLab Duo Agent Platform, rather than as a separate, disconnected tool, is how agencies get both Claude's coding experience and GitLab's governed execution in the same system of record. Claude Code's prompting skill carries over whether a developer is working standalone or inside Duo Agent Platform. What changes is where that code goes after it's written, not how a developer writes it.

Where agentic coding strains team workflows

The friction isn't only technical. As agents write more first drafts solo instead of with a teammate, teams are hitting a gap they haven't solved: how review and shared context work when the team wasn't in the room while the code was written. That gap is particularly evident in the government, where not every developer holds the clearance needed to review code on classified or sensitive systems and hiring more reviewers is a security determination that can take months.

GitLab’s own research shows that more than three-quarters of developers say they're writing and committing code faster with AI, yet overall software delivery hasn't sped up at the same rate because the bottleneck moved downstream to review, testing, and collaboration. LinearB's 2026 Software Engineering Benchmarks Report found agentic AI merge requests take 5.3 times longer for a reviewer to pick up than unassisted ones. In an agency running lean on reviewers, that lag compounds rather than just adds up.

That's a governance problem as much as a workflow one. A merge request gate that enforces review, scans, and approvals regardless of which tool generated the change means a team's process for absorbing agent output doesn't have to be reinvented every time the coding tool changes.

Network-restricted deployment vs. AI model choice

Flexibility matters most once you leave the browser and consider where the model runs. Federal environments face this same tension: running without any external network path isn't the same as controlling which model does the work. GitLab Duo Agent Platform Self-Hosted runs entirely on infrastructure an agency controls, covering data residency mandates, air-gapped networks, or policies that bar sending code to third-party APIs. GitLab has continued to expand model support, so agencies aren't forced into using the same model for every job, big or small. Those same models can also run on GPU-enabled virtual machines in a private cloud, for teams that want self-managed inference without the hardware costs.

As of August 2026, GitLab Dedicated for Government customers can deploy the AI Gateway for Duo Agent Platform inside their own single-tenant environment and connect the model provider of their choice, including Amazon Bedrock. Inference stays in their chosen region, under the same SLA, encryption, and change-control model an agency already uses for their workflows.

Get started with GitLab Duo Agent Platform

Claude Code and GitLab Duo Agent Platform aren't a trade-off. They're built to work in tandem. The developers who use Claude Code well should keep using it, the same way, without a new tool getting in the way of how they work. What GitLab Duo Agent Platform adds is a governed merge request gate every change passes through before it ships, regardless of which model or tool wrote it.

Your agency shouldn't have to choose between speed and control. See how GitLab Duo Agent Platform delivers both. Try Duo Agent Platform today.

Read more

• Claude Code and GitLab: Three workflows that ship
• Secure every commit to production with Claude and GitLab
• GitLab Duo Agent Platform with Claude accelerates development

The Git project recently released Git 2.56.0. Let's look at some of the highlights of the release, including contributions from the Git team at GitLab.

What's covered:

• Git Merge 2026 and schedule for Git 3.0
• git-history(1) learns drop
• git-branch(1) learns to delete merged branches
• git-refs(1) learns to modify refs
• Google Summer of Code 2026
• Linearizing history with git-replay(1)
• Making the object database pluggable

Git Merge 2026 and schedule for Git 3.0

This release cycle coincided with Git Merge 2026 held in Lisbon. The conference stretched over three days, consisting of a JJ Con day, a Git Talks day, and an unconference and Git Contributor Summit day. The Git talks will be available soon.

One of the main discussion points for the Git Contributor Summit was planning around the release of Git 3.0. The Documentation/BreakingChanges.adoc document in Git discusses the changes expected in 3.0, with the caveat that "There is no planned release date for this breaking version yet". That changed with the discussions held at the contributor summit.

The biggest changes scheduled for Git 3.0 include:

• SHA-256 as the default object hash format
• reftable as the default reference storage format
• Rust no longer being an optional dependency

While the code for these changes is available in current Git versions, they have varied levels of support in the larger Git ecosystem, which includes Git libraries, applications and forges. If the ecosystem doesn't support the changes, users would be left in limbo, where some tools support the new features while others fail.

For SHA-256 specifically, one of the biggest drawbacks was support on the forges. GitLab has been supporting SHA-256 since a year ago, while GitHub has announced a private beta at Git Merge with general availability following in a few months.

With that in mind, the discussions at the summit led to the following schedule for Git 3.0:

The plan is to jump straight from 2.56 to 2.98; this significant jump serves as an indication to both downstream maintainers and consumers that a big change is coming. After that, both 2.99 and 3.0 will be shipped together, the only difference being that Git 3.0 will have the breaking changes feature flag flipped. This keeps feature parity between the 2.99 and 3.0 releases, and keeps the changes in 3.0 small and limited.

The 2.99 release will be an LTS release so that platforms without a Rust toolchain continue to get updates. As usual, the discussion on details will follow on the mailing list.

git-history(1) learns drop

In our blog post for Git 2.55, we learned about the fixup subcommand for git-history(1). In this release, the command learns a new drop subcommand.

If you've ever wanted to delete an existing commit, the flow has been to use git rebase -i and then interactively mark individual commits to drop via an editor. The new drop subcommand allows users to do this in one single line.

$ git history drop <commit>

The provided commit is then removed, and its descendants are rebased on top of its parent. Like other subcommands within git-history(1), any changes made update all branches that are descendants of the original commit to point to the rewritten commit.

This patch was submitted by Patrick Steinhardt.

git-branch(1) learns to delete merged branches

To clean up merged branches, I've generally used some variation of the command:

$ git branch --merged main | grep -v main | xargs git branch --delete

Unfortunately, this only deletes branches merged into the branch provided; it doesn't catch branches forked from main and merged into origin/main. This release adds two new flags to help with this.

First, the --forked flag, which is a listing filter used to show branches whose configured upstream matches the provided ref, remote name or branch.

$ git switch --create feature-a origin/main
Switched to a new branch 'feature-a'
branch 'feature-a' set up to track 'origin/main'.

$ git branch --forked origin
  feature-a
  feature-b
* main

This shows the branches which started from a particular integration branch. We can also see the status of each of the branches:

$ git branch -vv
  feature-a b3ebf58 [origin/main: behind 1] Add feature A
  feature-b 34c0403 [origin/main: ahead 1, behind 1] Add feature B
* main      230a3b0 [origin/main] Document the parser

Here feature-a is behind origin/main, meaning that the branch was merged into origin/main, while feature-b still needs to be. To plug this usability gap, the new option, --delete-merged, comes into play. It deletes all branches whose tips are reachable from their configured upstreams, effectively removing every feature branch that was merged into the integration branch.

$ git branch --delete-merged origin
Deleted branch feature-a (was b3ebf58).

Tip: These options rely on your branches tracking an integration branch. If you usually branch off your local integration branch instead, take a look at the inherit setting for the branch.autoSetupMerge configuration.

This feature was submitted by Harald Nordgren.

git-refs(1) learns to modify refs

git-refs(1), introduced in Git 2.46, has been the new home for reference-related operations. Since its introduction it has grown several subcommands already to migrate references between storage backends, perform consistency checks, list existing references or check for existence of a reference. In this release, the command also learns to create, delete, update and rename references.

$ git refs list
689f6e8164e070ed133d5176806ad69e31d22142 commit refs/heads/branch-d
689f6e8164e070ed133d5176806ad69e31d22142 commit refs/heads/branch-r
689f6e8164e070ed133d5176806ad69e31d22142 commit refs/heads/branch-u
689f6e8164e070ed133d5176806ad69e31d22142 commit refs/heads/main

$ git refs create refs/heads/branch-c main
$ git refs update refs/heads/branch-u main~1
$ git refs rename refs/heads/branch-r refs/heads/foo
$ git refs delete refs/heads/branch-d

$ git refs list
689f6e8164e070ed133d5176806ad69e31d22142 commit refs/heads/branch-c
c4e9b6bafb7ac9a96c5d9337cd60a0ec6d5a240d commit refs/heads/branch-u
689f6e8164e070ed133d5176806ad69e31d22142 commit refs/heads/foo
689f6e8164e070ed133d5176806ad69e31d22142 commit refs/heads/main

The update and delete subcommands also take an optional expected old value, which validates the previous value before performing the operation.

These patches were implemented by Patrick Steinhardt.

Google Summer of Code 2026

The release also marks the successful completion of all four Google Summer of Code projects, each of which was co-mentored by a GitLab engineer.

Add remote-object-info command to git-cat-file(1)

Working in a partial clone allows repositories to operate without downloading every object. Git lazily fetches objects on demand. While git-cat-file(1) supports reading object-info for a given object hash, it only works by transferring the entire object. Git 2.56 adds a new remote-object-info command to git-cat-file(1)'s --batch-command mode, which requests only the metadata over v2 of the Git protocol. Consider a blobless clone that contains no blobs at all:

$ git rev-parse HEAD:model.weights
42ec5fc0f485f764cdf0eaa85ab061c055f5f518

$ git cat-file --batch-all-objects --batch-check | grep -c blob
0

$ echo "remote-object-info origin 42ec5fc0f485f764cdf0eaa85ab061c055f5f518" |
    git cat-file --batch-command
42ec5fc0f485f764cdf0eaa85ab061c055f5f518 blob 3000000

$ git cat-file --batch-all-objects --batch-check | grep -c blob
0

This allows us to obtain the size of the blob without transferring the blob itself: three million bytes of network bandwidth saved.

The project was worked on by Pablo Sabater, continuing previous work started by Eric Ju and Calvin Wan, and mentored by Karthik Nayak and Chandra Pratap.

Improve disk space recovery for partial clones

Partial clones save considerable disk space by only lazily fetching blobs. With time, those fetches accumulate and the repository grows, losing the advantage. This GSoC project involved adding a new --drop-filtered option to git-repack(1) which finds large promisor blobs above the given filter and removes them locally.

Here is a filtered clone of a repository whose history contains a 3MB blob. Fresh out of git clone, the repository size is small, but just looking at the blob fetches it onto the local disk:

$ du -sh .git
144K    .git

$ git cat-file -s b8086a678595c9fce29d980f7a12ca069b466f6c
3000000

$ du -sh .git
3.1M    .git

While this blob isn't required in the working tree, nothing removes it. Running --drop-filtered drops the blob, allowing Git to lazily refetch it when needed in the future.

$ git repack -a -d --filter=blob:limit=1k --drop-filtered
$ du -sh .git
156K    .git

This project was worked on by Siddharth Shrimali and mentored by Christian Couder and Siddharth Asthana.

Improve the new git repo command

The git-repo(1) command retrieves information about the repository. As part of the GSoC project, the git repo info subcommand was extended with path.gitdir and path.commondir, each available in both absolute and relative forms.

$ git repo info --all
layout.bare=false
layout.shallow=false
object.format=sha1
path.commondir.absolute=/home/karthik/code/git/.git
path.commondir.relative=.git
path.gitdir.absolute=/home/karthik/code/git/.git
path.gitdir.relative=.git
references.format=reftable

Further patches to add more path based information are currently on the mailing list.

This project was worked on by K Jayatheerth and mentored by Justin Tobler and Lucas Seiki Oshiro.

Reduce Git's global state

Git's core codebase still heavily relies on global state, from the famous the_repository variable to numerous config options. This acts as a blocker to the libification efforts in Git. This project moves some of the global config variables into a new repo_config_values struct on struct repository. Call sites get updated to pass the struct repository explicitly instead of using the global the_repository.

This project was worked on by Tian Yuchen, mentored by Christian Couder, Ayush Chandekar and Bello Caleb Olamide.

Linearizing history with git-replay(1)

git-replay(1) is an experimental Git command which allows server-side rebases and doesn't require a working tree to operate:

$ git log --oneline --graph --all
* 1756840 (main) main: unrelated upstream work
| * 286e7f1 (topic) topic: add two
| * 4324bcd topic: add one
|/
* 9497867 Initial commit

$ git replay --ref-action=print --onto main topic
update refs/heads/topic a144de2fc13ac40c8a481052be5e4d42071c4908 286e7f186f229ac4dd5ecb68a372951003f16224

$ git log --oneline --graph a144de2fc13ac40c8a481052be5e4d42071c4908
* a144de2 topic: add two
* 6422f37 topic: add one
* 1756840 (main) main: unrelated upstream work
* 9497867 Initial commit

Until now there was one issue: the command didn't work with commit ranges containing merge commits. Consider a scenario where you're working on a feature branch, and a bugfix which lands on main is also merged into your feature branch. This causes the feature branch to contain a merge commit as shown:

$ git log --graph --oneline --decorate --all
* cb996b6 (HEAD -> feature) feature: handle the empty-input edge case
*   4f76f3d Merge branch 'bugfix' into feature
|\
| * 4959734 (main, bugfix) bugfix: do not crash on null input
* | 829b62c feature: add parser tests
* | 7fd60db feature: add the parser
|/
* 9497867 Initial commit

$ git replay --onto main main..feature
fatal: replaying merge commits is not supported yet!

As you can see, git-replay(1) refuses to rebase the branch due to the existing merge commit. In Git 2.56 we now have --linearize, which is similar to the already default --no-rebase-merges option in git-rebase(1).

$ git replay --linearize --onto main main..feature
$ git log --graph --oneline --decorate --all
* da8df6e (HEAD -> feature) feature: handle the empty-input edge case
* f68889f feature: add parser tests
* f13885b feature: add the parser
* 4959734 (main, bugfix) bugfix: do not crash on null input
* 9497867 Initial commit

This feature was submitted by Toon Claes.

Making the object database pluggable

In the 2.54 release blog we discussed what pluggable object databases are and how they work. As a primer, Git stores its objects (blobs, trees and commits) under .git/objects in two different formats: "loose" objects, which are individual files, and "packfiles", which consist of objects compacted together. Since there was no abstraction layer, different subsystems reached directly into the storage layer to interact with objects. This changed in 2.54 as an abstraction layer was finally put in place.

This release takes further steps in the direction of providing the required interfaces in the backends to make them truly pluggable, namely:

• Creating the on-disk data structures. During the initialization of the repository, the .git/objects folder gets created. This responsibility is now moved to individual backends.
• Consistency checks. The consistency checks that are part of git-fsck(1) have now moved into the object source layer, so backends can implement their own consistency checks.
• Housekeeping. The existing files-backend-specific housekeeping logic that exists as part of git-gc(1) and git-maintenance(1) (incremental repacking, geometric repacking and pruning) has moved out of the command and into the files object source.
• Packfile generation. Git produces packfiles as part of the protocol during the fetch/push commands by making a call to git-pack-objects(1). Now, backends can serve packfiles themselves.
• Individual object sources. Following the loose object backend in the last release, the packed object backend has now also been moved into its own object source.
• Read and write streams. The separate read and write object streams are now unified under a single struct odb_stream, making it possible to stream arbitrary object types.
• Using ODB transactions. git-receive-pack(1) is now adapted to use ODB transactions, which ensures that the command writes objects via the interface without making assumptions about the backend.

And much more. While a multitude of changes landed in this release, from the user's perspective everything stays the same, which is as intended. This provides us at GitLab with the infrastructure required to build Git at scale, by being able to swap out the backend as needed, while doing so as part of the Git community. Stay tuned, as more details are to follow.

These changes were collaboratively submitted by Justin Tobler and Patrick Steinhardt.

Read more

This article highlighted just a few of the contributions made by GitLab and the wider Git community for this latest release. You can learn about these from the official release announcement of the Git project. Also, check out our previous Git release blog posts to see other past highlights of contributions from GitLab team members.

At enterprise scale, even small architecture choices can have outsized consequences. A deployment that works for a handful of teams can become a constraint once thousands of developers, repositories, and pipelines depend on it.

That makes each decision made before rollout especially consequential. For example, your:

• Deployment model defines what your team must operate
• Runner strategy shapes how CI/CD workloads execute and stay isolated, as well as how much operational load falls on your platform team
• Availability targets shape redundancy and recovery
• Workload determines how much capacity the platform needs

Together, those factors determine how well the platform can absorb growth without creating new operational constraints.

In this guide:

• Architecture decisions to make before you scale
• How to plan your runner strategy
• Planning for high availability and disaster recovery
• Where pipeline performance breaks down at scale
• Kubernetes and cloud-native deployment considerations
• An architecture validation checklist for platform teams

Architecture decisions to make before you scale

Your GitLab deployment model determines which parts of the platform your team must size, secure, monitor, upgrade, and recover. For enterprise deployments, the three core options are:

GitLab.com: GitLab’s multi-tenant software-as-a-service (SaaS) offering. GitLab operates the application and underlying infrastructure, while your organization manages its GitLab configuration, integrations, and any self-managed runners.

GitLab Dedicated: A fully managed, single-tenant SaaS offering hosted on Amazon Web Services (AWS). GitLab operates the underlying infrastructure, including updates, high availability, and disaster recovery; your organization controls user and data access through application-level controls.

GitLab Self-Managed: Your organization installs, administers, and maintains its own GitLab instance. You manage the infrastructure and assume responsibility for operating, scaling, securing, and recovering the environment.

Choose the model based on the control your organization requires and the infrastructure responsibility it can sustain. For example, you may want to choose:

• GitLab.com when a multi-tenant SaaS model meets your requirements and minimizing infrastructure operations is the priority
• GitLab Dedicated when you need single-tenant isolation or control over areas such as networking and data residency without operating the GitLab infrastructure yourself
• GitLab Self-Managed when requirements call for direct control over the underlying infrastructure and your team has the capacity to operate the platform

Before you decide, document any requirements that could rule an option in or out. Pay particular attention to data residency, network isolation, recovery objectives, and infrastructure control. Then map the operational work each model leaves with your team, including upgrades, monitoring, capacity planning, backups, and incident response.

That exercise should clarify the central tradeoff: how much infrastructure responsibility your organization needs and can realistically own.

Once you define that operating boundary, it’s time to plan the compute layer that will execute your CI/CD workloads.

How to plan your runner strategy

GitLab Runner executes CI/CD jobs, and the GitLab application coordinates the pipelines behind them. That separation matters at enterprise scale because application capacity and runner capacity respond to different types of demand. The application handles Git, web, API, and automation traffic; the runner fleet absorbs the volume and concurrency of CI/CD work.

For this reason, you should size the runner fleet based on the workloads themselves rather than on developer headcount. Start by documenting:

• Job volume and duration
• Peak concurrency
• Operating system and compute requirements
• Network paths and specialized hardware
• Privileged or sensitive workloads
• Peak periods such as release windows or scheduled scans

Use those inputs to estimate how many jobs must run at once to meet your queued-duration target. Workload data matters more than team size because two organizations with the same number of developers can generate very different CI/CD demand based on pipeline frequency, automation, and job requirements.

Choose the right runner scope

Runner scope determines how broadly teams can use each pool. Instance runners can serve projects across the GitLab instance, while group runners limit access to projects and subgroups within a defined group. Project runners provide the narrowest scope and fit workloads that need dedicated credentials, specialized infrastructure, or stronger isolation. Because that capacity is reserved for fewer workloads, project runners may also sit idle when job volume is intermittent, so factor utilization into the decision.

Use the broadest scope that meets the workload’s trust and compute requirements. Broader pools generally improve utilization, while sensitive deployment jobs or specialized workloads may justify dedicated infrastructure.

Plan for autoscaling

Autoscaling lets runner capacity expand or contract with demand, but operating that infrastructure also takes platform engineering time. If you manage your own runner fleet, account for how quickly new resources become usable: instance provisioning, cloud quotas, image downloads, and cache availability can all affect queued duration during a spike. Keep enough ready capacity to absorb short-term demand while additional compute comes online.

You can also shift that operational work to GitLab. GitLab-hosted runners are available for GitLab.com and GitLab Dedicated, with GitLab managing the underlying runner infrastructure and autoscaling. For teams that want to reduce the time spent provisioning, patching, and scaling runner machines, that changes the runner strategy from an infrastructure-management decision to more of a capacity and workload-placement decision.

Match the executor to the workload

Executor choice determines where CI/CD jobs run and what infrastructure your team must operate. For cloud-native environments, the Kubernetes executor uses an existing Kubernetes cluster. For autoscaled workloads on public-cloud virtual machines, GitLab provides the Docker Autoscaler and Instance executors.

The right choice depends on the environment your jobs need and the infrastructure your team is prepared to manage. With the Kubernetes executor, each CI/CD job runs in its own pod, making cluster behavior part of runner performance. Scheduling delays, resource requests and limits, node capacity, and autoscaling can all affect how quickly jobs start and complete.

Account for those constraints in your capacity plan so the executor does not become a bottleneck as CI/CD demand grows.

Planning for high availability and disaster recovery

Availability planning should begin with the business impact of downtime and data loss. Define:

• Service level objective (SLO): The level of service the platform should maintain during normal operation
• Recovery time objective (RTO): How quickly service must be restored after an outage
• Recovery point objective (RPO): How much data loss the organization can tolerate

Together, these targets define the redundancy and recovery capacity the architecture needs.

How much of that work falls to your platform team depends on the deployment model. If you use GitLab Self-Managed, your team owns those architecture decisions. Use the GitLab reference architectures as a production-ready starting point, then adapt the topology to your availability and recovery requirements.

With GitLab Dedicated, GitLab manages the underlying disaster recovery infrastructure and failover process. Customers can choose a secondary AWS region for geo-based disaster recovery, while GitLab maintains replication between the primary and secondary regions and manages failover when required.

For Self-Managed deployments, your recovery design should treat high availability, disaster recovery, and backups as distinct but complementary layers:

• High availability limits the impact of component failures within the primary environment.
• Disaster recovery restores service after the loss of a site or region.
• Backups protect against corruption, deletion, and other failures that replication can carry to a secondary site.

In addition, for Self-Managed deployments, turn your recovery targets into architecture requirements. Decide where redundancy is needed, how data will replicate, and how backups will protect critical data. Include dependencies such as identity and networking services in the recovery plan.

GitLab Geo provides an active-passive disaster recovery architecture with secondary sites that synchronize from the primary. For Self-Managed, failover requires customer-managed operational steps, so rehearse the process under realistic conditions and measure the results against your RTO and RPO.

Record any failed dependencies or manual steps that could slow recovery, then use those findings to strengthen the design.

Where pipeline performance breaks down at scale

As GitLab adoption grows, performance planning shifts from sizing for expected demand to validating the platform’s behavior under real-world load. The first step is to identify where time is being lost.

GitLab separates queued duration from execution duration, which gives you a useful starting point for diagnosis. A job’s queued duration shows how long it waited to start, while job duration captures execution time. Pipeline duration measures the time spent running the pipeline and excludes pending queue time.

Those metrics point to different constraints. A high queued duration may indicate insufficient runner capacity. Longer execution times, by contrast, can stem from pipeline design, test suites, dependency downloads, or repository transfers.

Establish a performance baseline

Test representative projects under both normal and peak demand to see where performance starts to degrade. Include conditions such as release windows, scheduled security scans, and periods of heavy commit activity, then track the signals that surface the bottleneck:

• Queued duration
• Job and pipeline duration
• Runner utilization
• Retries and failures
• Cache performance
• Artifact transfer time
• Infrastructure saturation

Break the results down by runner pool and workload type so organization-wide averages don’t hide bottlenecks affecting specific teams or workloads. From there, use what you learn to set thresholds for expanding runner capacity, optimizing pipelines, or scaling the GitLab application.

Test large repositories and monorepos separately

Large repositories and monorepos place distinct demands on GitLab and runner infrastructure. Frequent clones and fetches can increase CPU, memory, disk, and network usage, especially when many pipelines access the same repository simultaneously.

Look beyond repository size when estimating that impact. Clone frequency, concurrent CI/CD activity, branch patterns, and the amount of data each job transfers can all shape platform load.

Optimize the workload before scaling capacity

Pipeline design can reduce demand on the platform itself. Run independent jobs in parallel, avoid unnecessary pipelines, cache frequently downloaded dependencies, and limit artifact retention. For monorepos, trigger jobs only when relevant paths change and reduce the amount of repository data each job needs to transfer.

Continue measuring after rollout as usage evolves. For Self-Managed environments, actual resource utilization and workload patterns provide the clearest signal for when the architecture needs to scale.

Kubernetes and cloud-native deployment considerations

Kubernetes can play two different roles in a GitLab architecture. The Kubernetes executor can run CI/CD jobs as pods in an existing cluster, while GitLab Self-Managed can run in a cloud-native architecture on Kubernetes.

These choices affect different parts of the platform and should be evaluated separately. Using Kubernetes for runners changes how CI/CD compute is provisioned and scaled. Running GitLab on Kubernetes changes how your team operates the application and its supporting infrastructure.

Plan Kubernetes runners as part of the cluster

With the Kubernetes executor, a runner manager calls the Kubernetes API and creates a pod for each CI/CD job. That makes the cluster itself part of your runner architecture.

Plan the Kubernetes resources and controls those jobs will rely on, including namespaces, service accounts, resource requests and limits, and workload isolation. Sensitive deployment jobs may also require stronger separation from less-trusted build workloads.

Capacity matters just as much as configuration. Test whether cluster autoscaling can add nodes quickly enough to meet your queued-duration targets. Even when the cluster eventually provides enough compute, slow node provisioning can leave jobs waiting during demand spikes.

Choose the right architecture for GitLab on Kubernetes

Running GitLab itself on Kubernetes requires a broader architecture decision. GitLab recommends its Cloud Native reference architecture for new Self-Managed deployments. In this model, GitLab components run in Kubernetes, while PostgreSQL, Redis, and object storage remain external.

Cloud Native Hybrid remains an option when specific components need to stay outside Kubernetes. Teams that require a Gitaly Cluster for repository-level high availability, for example, should evaluate a hybrid or VM-based reference architecture because the standard Cloud Native architecture runs Gitaly in a non-clustered configuration.

Whichever model you choose, include Kubernetes in the operating plan for the wider GitLab platform. Your team will need observability across the cluster and external services, along with an upgrade process that accounts for GitLab and its infrastructure dependencies. Capacity and recovery testing should cover the cluster as part of the production environment.

The GitLab cloud-native overview provides more context on this deployment model. Choose Kubernetes when its operating model fits your infrastructure requirements, and your team has the skills to run it reliably.

An architecture validation checklist for platform teams

Use this checklist before rollout to validate the major architecture decisions across deployment, sizing, runners, recovery, and performance. For each item, document the evidence that supports the decision or assign an owner to close the gap.

Enterprise scale puts every early architecture decision under pressure. The strongest GitLab environments reflect how the organization actually operates and leave enough room for demand to change.

Those conditions will evolve as adoption expands. Keep measuring, revisit the architecture as demand shifts, and let evidence drive the next decision. That discipline turns GitLab from a platform that simply supports more users into one that can keep pace with the organization around it.

💡 Learn how GitLab Dedicated supports enterprise scale.

GitLab Duo Agent Platform orchestrates and automates complex tasks through agentic flows. A key part of the platform is the Flow Registry, a declarative configuration framework, built from reusable components, that compiles YAML into fully functional LangGraph flows. By using Flow Registry, agent builders — both our GitLab engineers and our customers can use declarative YAML configurations instead of repetitive, ad-hoc Python implementations. Flow Registry turns bespoke state management and agent wiring duplicated across agents into a set of reusable components and primitives available to agent builders.

Using Flow Registry has reduced our own code-per-agentic-flow by 45%. What is this translating to?

• Faster iteration speed due to a declaration framework with reusable components and primitives.
• Increased reliability because one-off implementation mistakes and boilerplate bugs are handled on a component level.
• Lower maintenance cost because platform improvements are made once, but benefit all agents.
• Backward compatibility for our functionalities, for both our GitLab-authored foundational flows and also customers’ custom flows, because of the abstraction layer.

All of these benefits are available to customers orchestrating and building agents on GitLab Duo Agent Platform.

In this article, we share the architectural principles and lessons from this effort and how to apply them in your environment.

LangGraph as the foundation for GitLab Duo Agent Platform

After releasing GitLab Duo Code Suggestions and Duo Chat, we dug into a then-novel technology, autonomous agents. We researched available AI frameworks and selected LangGraph, an agent runtime and low-level orchestration framework from LangChain, as the foundation for GitLab Duo Agent Platform.

LangGraph's rich feature set, which includes a broad range of model adapters, durable execution, and traceability, combined with an excellent level of engineering autonomy, brought all the necessary building blocks we looked for to start GitLab Duo Agent Platform development.

During the initial months, GitLab engineers, empowered by LangGraph, swiftly built the foundations of Duo Agent Platform, and before long the team shipped four agentic flows:

• Software Development Flow
• Duo Agentic Chat
• Convert to GitLab CI/CD Flow
• Developer Flow

We also quickly realized a critical gap that low-level frameworks such as LangGraph do not address: a lack of structure to support consistent development at scale.

With just four flows present, and a small engineering team working on GitLab Duo Agent Platform at that time, the codebase was growing rapidly. Every flow was implemented as an ad-hoc directed graph, turning into a web of interconnected nodes and edges. The early Duo Agent Platform codebase had no reusability, no composability, and little in the way of shared standards. It became very difficult to develop new features, and any horizontal platform-wide change seemed like an impossible task.

With every flow taking at least 450 lines of ad-hoc Python code and looking like this example, the team's velocity slowed down as engineers struggled to introduce changes, overwhelmed by complexity and coupling.

The graph's complexity spilled into the test suite, as well. Each test case depended on an execution propagating through a whole graph, which changed tests from a quality assurance safety net into a boogeyman that nobody wanted to look at.

It became clear to us that graphs used as an atomic building block at this low abstraction level are not a good match for a platform implementation. To support the scale we envisioned, it was necessary to introduce smaller units, that break down the complexity and reduce cognitive load put on platform engineers maintaining the project.

Furthermore, graphs with low-level nodes managing model API calls or executing function calls produced by said models, were not the right abstraction for AI engineers either, as they are more accustomed to terms like agents and agent orchestration.

Looking for a way out of that maze, we decided to separate those two concerns — AI engineering from platform development — with the introduction of a new layer of abstraction. To do so, we reviewed existing graphs and identified and extracted repeated structures (for example, cycles going between large language model (LLM) calls and tool execution, implementing agent loops). The refactor brought some relief, as the most complex files had been broken down into smaller pieces that formed the new abstraction layer.

However, the platform was still far from a scalable state. The extracted graph pieces unfortunately operated with their own state structures, tightly coupled with the flow from which they originated. This prevented us from reusing extracted entities between different flows, and we were concerned that at that point every new flow would be more likely to create its own set of pieces, rather than be composed from ones that already existed. The system was neither collaborative nor efficient, and it was not sustainable in that state for a longer period of time.

That realization made it apparent — we had to put more effort in, continue to evolve the architecture, and provide clear development guidelines. At that time we already knew that Duo Agent Platform flows wouldn't be exclusively built by other product teams, but that a wider GitLab community would be invited to contribute as well.

Abstracting LangGraph details behind the new Flow Registry framework

Equipped with the past experience, and inspired by ambitious goals, my teammate Alexander Chueshev and I went back to the drawing board, and rethought the system. We set out to introduce a solution that is highly collaborative, composable, and optimized for AI development efficiency.

We wanted this new iteration to hide low-level LangGraph implementation details, and to stop bothering developers with nodes or edges. The system ought to speak their language — the language of AI engineering — with agents being a central component.

It was clear to us that AI development reasons in terms of agents, rather than nodes that invoke models, execute tools, etc. Drawing lessons from the past iteration, we decided to base the new framework on three pillars:

1. Components
2. Routers
3. Shared state structure

We were convinced that if we were able to design them well, the new framework would be flexible enough to support any AI flow that users might want to build.

Pillar 1. AI engineering primitives as components

Components are the central and most important pillar of Flow Registry. They model common primitives such as agents, human-in-the-loop checkpoints, and fixed-logic steps. This pillar lifts the abstraction level to match terminology used within the AI engineering domain. Thanks to components agent builders no longer need to reimplement those primitives from scratch, but can declare them with YAML snippets that look like this example:

     - type: AgentComponent
        name: "developer_agent"
        prompt_id: "developer_agent_prompt"
        inputs:
          - from: "context:goal"
            as: "goal"
          - from: "context:project_id"
            as: "project_id"
        toolset:
          - "read_file"
          - "find_files"
          - "edit_file"
          - "run_command"
          - "create_merge_request"

Under the hood, the AgentComponent is still a piece of a LangGraph’s graph, whose simplified structure is shown in the diagram below. However, now its implementation complexity is hidden from agent builders, who operate with a more familiar primitive. The same architectural boundaries also benefit framework maintainers, giving them more freedom to modify and extend the underlying implementation, with changes propagating to flows transparently.

flowchart LR
    %% External input/output
    input((inputs<br>from<br>shared state)) --> LLMCall
    End --> output((outputs<br>to shared state))

    %% Prompts
    Prompt["You are expert<br>software<br>engineer ..."] --> LLMCall
    subgraph Prompts
        direction TB
        style Prompts stroke-dasharray: 4 4, stroke:#3CB371
        Prompt
    end

    %% LLM and internal component
    LLMCall --> End
    LLMCall --> RunTools
    RunTools --> LLMCall

    subgraph Component
        direction LR
        LLMCall[LLM Call]
        RunTools[Run Tools]
        End[END]
    end

    %% Tools
    EditFile --> RunTools
    ReadFile --> RunTools

    subgraph Tools
        direction LR
        style Tools stroke-dasharray: 4 4, stroke:#1E90FF
        EditFile[Edit file]
        ReadFile[Read file]
    end

The agent as a component, with the ability to delegate work to subagents, is already a powerful base delivered by Pillar 1 alone. Many contemporary agent platforms consider it a complete and sufficient offering. However, GitLab has larger ambitions for Duo Agent Platform, which Flow Registry realizes with the next two pillars.

Pillar 2. Routers to orchestrate components into flows

Flow Registry Routers enable agent builders to orchestrate multiple specialized agents, or even agentic teams, into a flow to model highly complex business, or software development processes. Even though the largest contemporary models are powerful enough to drive complex assignments on their own, a recent rise in popularity of subagent architecture shows that there are many benefits of assembling multiple agents to collaborate over a single task.

To demonstrate a practical example, let’s take a look at GitLab’s foundational flow: Fix pipeline. This flow is configured with an automated trigger to triage, and fix failing CI pipelines. Because CI pipelines can be very complex, not every failure requires any code change to be resolved, for example sometimes a dependency service might be not responsive, and a plain retry is enough to fix a failure. To acknowledge that dual approach, the flow branches early based on an agent that acts as a judge’s decision. The judge agent's ruling on whether a failure is actionable is then used by Flow Registry Routers to navigate flow execution into the correct branch.

routers:
 - from: "fix_pipeline_context"
    condition:
      input: "context:fix_pipeline_context.final_answer.decision"
      routes:
        "add_comment": "fix_pipeline_add_comment"
        "create_plan": "fix_pipeline_checkout_existing_branch"
        "direct_code_suggestions": "fix_pipeline_code_suggestions"
        "no_action": "end"
        "default_route": "end"

It is true that state-of-the-art models should be able to make similar decisions and act on them simultaneously. However, thanks to multi-agent architecture, agent builders can capitalize on the following benefits:

1. Smaller, cheaper models can replace the largest and most expensive ones — a compounding cost advantage for high-frequency automated flows running hundreds of times per day.
2. Security posture improves through role separation — read and write capabilities can be split across distinct agents.
3. Process guardrails can be enforced when the workflow is known upfront, reducing reliance on model judgment for structured tasks.

Pillar 2 gives agent builders a choice: Use a simple flow architecture with powerful models, or offload complexity from models prompts into explicit flow structure — catering to a broad range of possible use cases, cost targets, and risk profiles.

Pillar 3. Shared state structure

The third and final pillar of Flow Registry is a shared state structure that acts as a communication protocol between components. Without it, the previous two pillars could not function, because components would lack a reliable way to communicate. Referring back to the Fix pipeline example: The judge agent's ruling would be of little value if it could not be reliably forwarded to a Flow Registry Router. More broadly, data produced by one agent is often required by subsequent ones, making a well-defined communication contract essential.

Flow Registry state structure includes a special catchall attribute called context, which behaves like a nested key-value store (or a JSON object) granting components a versatile storage space. To further complement context attribute flexibility, Flow Registry introduced a dot-notation declarative access to context, a convention familiar from other domains (such as GitLab CI Functions), where access to shared key-value storage must be expressed within static configurations.

To complete the third pillar, convention is required: Flow Registry supports flexible read operations from shared state via said dot-notation, however all writes follow strict rules, providing a set of stable, predictable outputs on which agent builders can rely. To see that in practice, let’s take a look again at a piece of Flow Registry config for another foundational flow: Code review.

# …

 # Step 5: Fetch lightweight MR metadata (file paths + custom instructions)
  - name: "fetch_mr_metadata"
    type: DeterministicStepComponent
    tool_name: "build_review_merge_request_context"

# ….

  # Step 6: Transform prescan results into structured JSON for review consumption
  - name: "analyze_prescan_results"
    type: AgentComponent
    prompt_id: "analyze_prescan_codebase_results"
    prompt_version: "^1.0.0"
    inputs:
      - from: "context:fetch_mr_metadata.tool_responses"
        as: "mr_context"
      - from: "context:prescan_codebase.tool_responses"
        as: "prescan_tool_responses"
        optional: True
    toolset: []
    ui_log_events:
      - "on_agent_final_answer"

# …..

routers:
 #  ….
  - from: "fetch_mr_metadata"
    to: "analyze_prescan_results"

Code Review’s agent analyze_prescan_results requires data pulled by a preceding fixed step action fetch_mr_metadata, that dependency is expressed via inputs declared for analyze_prescan_results agent

    inputs:
      - from: "context:fetch_mr_metadata.tool_responses"
        as: "mr_context"

Here, dot-notation and strict output conventions work in tandem, giving agent builders a stable and predictable protocol for moving data between components within a flow.

From Python to YAML

Even though Flow Registry uses declarative YAML configurations, we started the design and rearchitecture in Python, and deferred any declarative configuration API to future iterations. However, once all three Flow Registry pillars came together within a single Python block, it became obvious to us that converting those declarations into a YAML config was just a step away, so we took it.

That change completely decoupled the Flow Registry framework from Python and LangGraph, offering a high-level abstraction syntax for declarative AI flow creation. It established a clean boundary between the platform still implemented on LangGraph foundations, and the external framework's declarative interface, which enabled AI engineers to operate with concepts more familiar to them.

Introduction of Flow Registry framework as a basis for GitLab Duo Agent Platform propelled the whole system from vanilla LangGraph per-use-case implementations into declarative YAML configs like this one behind GitLab Duo Developer Flow, which is currently operating in production.

With the platform decoupled from the framework API designed for AI engineers, the underlying Python codebase becomes shareable across all flows, and any improvements introduced to the engine itself are brought to all flows, further emphasizing the efficiency gains from the clear separation.

In addition, the per-flow code cost drops with every new flow added. At the time of writing, the ratio of Python source code per flow has been reduced by 45% in favor of Flow Registry — and it will keep improving with every new flow being built.

Finally, AI engineers and domain experts are no longer required to understand any of the underlying platform implementation details, nor do they need to implement any repetitive boilerplate Python code that would require its own test suite and maintenance. This was proven by almost 7,000 developers who signed up for the GitLab AI Hackathon earlier this year and submitted 600+ agents and flows.

Key learnings

A key observation we made is that modern AI engineering is still a very young branch of software development, in which common architectural patterns and paradigms haven’t fully been formed yet. However, it does not mean that already established good software engineering practices can’t be applied to AI engineering. In fact, as Flow Registry's story shows, reaching back to existing software engineering paradigms and practices, such as identifying repeated code, extracting it into named entities with clear roles within a system, and forming abstraction layers from them, can yield powerful results.

Beyond that, we would also like to share a few other takeaways that apply broadly to any team building agentic systems, while others are practical starting points for teams working with low-level frameworks like LangGraph.

General principles

1. Some contemporary agentic frameworks, despite being very powerful, operate at too low a level of abstraction for AI engineering needs, conflating platform concerns with agent development.
2. Separation of the execution platform from AI engineering enables experts in each domain to operate with more confidence and speed.

Practical starting points for low-level framework users

1. Separation of AI flows from platform implementation can be started by extracting repeated structures from existing AI flows — agentic loops are a good place to start.
2. A flexible shared data model can be achieved thanks to a key-value-store-like attribute introduced to the model, following patterns established by other orchestration frameworks even outside of the AI domain.

Try Flow Registry

To get a feel for how it all works in practice, visit the AI Catalog where GitLab exposes the resulting Flow Registry orchestration framework for anyone to build custom flows.

You can also try GitLab Duo Agent Platform for free.

I joined GitLab at a moment when the way teams build and secure software has been changing rapidly. GitLab CEO Bill Staples recently framed that shift in When Code Is Abundant. When code is no longer the bottleneck, trust becomes scarce, and that constraint shows up first in what reaches production.

As a CISO accountable for the same decisions as my peers, my operating thesis is simple: Agentic software development stays trustworthy only when security, governance, and guardrails sit in the path from plan to production. Leaders must continuously know the attack surface, constrain execution, and close the loop from discovery to verified fix at machine speed. Instead of the number of scans, tickets, or reviews, the metric that matters is time from detection to verified remediation.

That metric becomes more relevant as the economics of an attack change. The risks themselves are familiar: an open server, an over-scoped credential, or an exposed deployment path. AI models make these conditions faster and cheaper to discover, connect, and exploit. I find that more unsettling than a novel zero-day because the exposure was already in our environment; the difficulty of uncovering it was part of what protected us.

Anthropic and OpenAI have both described this shift publicly, and so has every security team I've talked to this year regardless of industry: advanced models and agentic systems are compressing the time and cost required to find and exploit weaknesses. Open weight models are catching up quickly with the most capable security systems available today, which means capabilities that recently lived inside a small set of labs will become available to a much wider set of threat actors.

I can see that acceleration inside GitLab. We have published 317 CVEs so far in 2026, compared with 181 in all of 2025 and 170 in 2024. Our bug bounty program received just over 3,600 reports in the last 90 days, compared with 1,440 in all of 2024.

The same shift, industry-wide

We are not an outlier. In April, the National Institute of Standards and Technology (NIST) stopped enriching most CVEs, conceding that a record year of output still wasn't enough. This year's Verizon Data Breach Investigations Report put exploitation of vulnerabilities ahead of credential abuse as the leading initial access vector for the first time in 19 editions, with median time to resolution slipping from 32 days to 43. The Forum of Incident Response and Security Teams (FIRST) made the same point this summer.

Published advisories and incoming reports measure different things, but they create the same operating pressure: Discovery volume is rising faster than teams can verify, prioritize, and remediate what matters.

Severity models still assume a finding stands alone, but agents can chain a low-severity flaw, an overly broad permission, and an exposed path into a material attack. A queue sorted by CVSS increasingly misses that context while the backlog grows faster than teams can clear it using their traditional tools and processes.

The operating model must change with the economics of attack. Security controls must sit in the execution path, with a closed remediation loop behind every material finding. That governed path across your software development lifecycle (SDLC), under your guardrails, context, and workflows, is the foundation for an enterprise software factory.

Agentic capability gives defenders an advantage

Security teams have always been outnumbered, and our own intake is running about six times the 2025 rate. But capable models change the math in the defender's favor first.

Defenders have access to the code, infrastructure, deployment paths, configuration, identity systems, and operating context. Point the same capability at the same target and we can see much more, if we use it against our own surface first. Models can turn that broader context into machine-speed discovery, prioritization, and remediation. This has never been true before.

The build process is also becoming observable. For years, much of the work on an issue was not captured in systems that security teams could inspect. Security teams reviewed what remained: the diff, the build, and the running application.

When an agent builds software, construction can become an event stream: file reads, tool calls, commands, credentials issued, systems accessed, and approvals granted. That record lets us govern how software is built.

This architectural advantage exists when agents run somewhere their actions can be identified, constrained, and recorded. Once the necessary infrastructure is in place, every improvement in model capability strengthens the defensive system.

I believe machine-speed defense requires three layers that strengthen as model capability and commit volume rise across the SDLC.

Layer 1. Find out where you stand

This is the discovery pass for everything that follows. With the assumption that a capable attacker already has the same models you do, you should use those models on your own surface proactively across code, infrastructure, and deployment paths. The goal is a verified picture of where you stand today.

Frontier labs sit closest to the capability curve, which is where new AI model capacity first shows up in both offense and defense. Their contribution raises the defensive posture the rest of the industry can build on: model-assisted discovery pointed at real systems, and remediations drafted by agents with your team approving the change. We are running that with Anthropic on Project Glasswing, using their models across our critical systems and products, and repeating the pass when a stronger model arrives.

We then use GitLab Duo Agent Platform to continuously triage and remediate those findings, reduce the introduction of new issues, and ship software that has already been verified before production. We are customer zero for the bar we hold the software industry to, as we aim to translate that into trust in what you build on our platform.

Layer 2. Strengthen your foundation

A baseline tells you where you are. The harder problem is maintaining it while code volume, agent capability, and attacker capability continue to increase.

That foundation must satisfy six requirements.

1. Know and continuously scan the entire attack surface. Static application security testing (SAST), dependency, container, secret, API, and dynamic application security testing (DAST) must run as one coverage model. Third-party scanners must feed a common vulnerability management system. An organization cannot reason about risk from partial inventories with different identities, severities, attack paths, owners, and remediation states.
2. Eliminate exposed and long-lived secrets. Centralized secrets management, least privilege, rotation, revocation, and secret detection must be defaults in the paths that create and deploy software. Every credential must have a defined identity, scope, lifetime, and revocation path.
3. Turn vulnerability discovery into continuous remediation. Eliminate false positives, prioritize real vulnerabilities in context, and use agents to generate, test, and validate fixes. A finding stays open until the proposed change is proven against the relevant code, configuration, and deployment path.
4. Put policy in the execution path. Scans, approvals, separation of duties, and deployment controls must be centrally enforced where work executes. Developers and agents cannot be responsible for remembering which policy applies or navigating the correct handoff.
5. Treat agents as privileged actors. Every agent needs an explicit identity, minimum permissions, constrained tools and credentials, sanctioned access paths, and auditable actions. High-risk operations need an attributable approval boundary, especially as agents move from suggesting code to acting across repositories, CI/CD systems, cloud infrastructure, and production.
6. Measure time from detection to verified remediation. Track how long a real vulnerability remains exposed from detection through a fix proven in the relevant environment. Segment it by severity and attack path, then drive it down continuously. For machine-speed attacks, this becomes the primary operating metric.

These requirements work together: continuous coverage so findings have somewhere to go, fixes tested on the path they ship on, policy where the work runs, and agents with their own identity instead of a developer’s access token.

Layer 3. Protect what already shipped

Software and its environment keep changing after production. The artifact you shipped last month can become vulnerable because of a disclosure next month, with exploitation following within days and sometimes preceding an available patch.

As a result, catching up once is not enough: keep scanning after the merge, reassess production as stronger models arrive, and land fixes in the same developer workflow that produced the change. Govern each merge and close each fix so every new finding moves toward remediation.

The operating model is to enforce the security you already have, measure time from detection to verified remediation, and keep customer experience checks in the same build path as security.

WHAT MY PEERS ARE SAYING

Cybersecurity experts and peer CISOs are describing a similar operating approach in an effort to enable governance and remediation at the speed of development.

“Machine scale discovery without an equally fast path to governed remediation is not progress. It is an inventory problem dressed up as security. The organizations that will hold up under agentic development are the ones that treat detection as the start of a closed loop: policy on every change, remediation in the build path, and a baseline they can re-verify as models improve.” Gadi Evron, CISO-in-Residence for AI, Cloud Security Alliance

“A durable security program for agentic software development keeps every agent on lawful rails: an explicit identity, constrained permissions, and a sanctioned path from plan to production. An agent working outside those rails is lawless: no identity, no record, no way to govern what it touched. That discipline has to hold as models improve and agent volume rises.” Bill Shields, CISO, Workday

“Trust in what you ship depends on continuous hardening of the models and development platforms you build on and governance of every change in your software lifecycle. Those layers reinforce each other, and neither substitutes for the other.” Sam Curry, Chief Security Officer, Zscaler

The shadow software factory is an architectural problem

As agents produce a larger share of the code, your SDLC is splitting in two. One path runs through governed repositories, CI/CD systems, identity controls, approvals, and security tooling. The shadow path runs through personal laptops, local credentials, unmanaged tools, and agent sessions outside those controls. It may produce valid code, but without a reliable record of how that code and its related infrastructure changes were made.

A commit shows whose credential was used, but it reveals little about the agent, tools, permissions, commands, and external systems behind the change. Capturing that evidence requires a governed execution environment that connects identity, permissions, tools, policy, and approvals. Without it, security teams inspect artifacts after the important actions have already occurred.

Capturing events is only the beginning. At agentic volume, a complete transcript becomes another backlog. Security systems must turn those events into enforceable policy, attributable decisions, and verified outcomes. Tool calls are evidence, and an agent's explanation of its own reasoning is secondary.

What this looks like in practice

On GitLab, that architecture is becoming concrete. Policy sits in the execution path. Scanning runs where developers and agents already work, early enough that the fix is cheap. Third-party findings converge in one vulnerability system, and agents turn validated findings into tested merge requests carrying the application context needed to fix them. Secrets are short-lived, scoped, and revocable by default. High-risk agent actions stop at an attributable approval boundary. If the pipeline cannot prove it, the pipeline does not ship it.

Authorship capacity is becoming elastic while human review capacity remains constrained. On a recent release, we ran agentic security review across 969 of 997 eligible merge requests, or 97%. A year ago, that level of coverage was inconceivable. Today I treat it as the expectation.

GitLab brings these controls together across the platform. GitLab Duo Agent Platform closes agentic triage and remediation loops on the same governed path as source, security, CI/CD, and merge. If you are a GitLab customer, the opportunity is to put those controls in the execution path and measure whether they shorten your exposure time from detection to verified remediation.

The deeper architectural question is whether agentic work runs through the same governed foundation for your software factory. When it does, teams and agents share a common control plane. When it does not, the shadow software factory persists regardless of how much security tooling surrounds the downstream pipeline.

Making the operating model concrete

A credible program can answer these questions from its operating data:

• What is the complete attack surface, and when was each surface last scanned?
• Which findings are real, which are false positives, and who or what made that determination?
• How long did each real finding remain exposed before a fix was verified in the relevant environment?
• Which secrets were issued, to whom or what, with what scope, for how long, and how were they revoked?
• Which agent performed each action, through which sanctioned path, with which tools and permissions?
• Which policy, approval, separation of duties check, or deployment control stopped or permitted the action?
• Can an independent reviewer replay the evidence and reach the same conclusion?

Those answers should become increasingly automatic. A program that is working keeps coverage continuous across the full attack surface, puts an attributable owner and a tested remediation path behind every material finding, and either eliminates exposed and long-lived secrets or time-boxes them with compensating controls you can defend. Agents run through sanctioned identities and constrained permissions, with a recorded approval on high-risk operations, and you measure detection to verified remediation continuously, by severity and by attack path, driving that time toward machine speed.

We are learning what that takes by running the model ourselves. In the coming months, GitLab will publish a blueprint that turns these principles into operational guidance: the controls, architecture, metrics, and practices to establish a baseline. The blueprint will aim to help you keep agentic software development on a governed path, eliminate shadow production work, and continuously move findings through verified remediation.

The goal is practical: Give security and engineering leaders something they can implement and measure, regardless of where they are starting.

The standard has changed

I'm writing this as a peer accountable for the same class of decisions you are. When code generation is abundant and trust is scarce, your agentic software development demands machine-speed verification and remediation. Security, governance, and guardrails have to be part of your foundation, not a set of gates around it.

The opportunity right now is unusual. The same models increasing offensive capacity can also expand defensive capacity. As cybersecurity professionals, we have more context than the attacker, greater access to our own systems, and a chance to make the construction of software itself observable and governable. We have to use that advantage.

Expect continuous hardening from the platforms you build on. Ask for evidence of what they find, how quickly they remediate it, and whether the controls survive the next increase in model capability. Apply the same standard to your own software development. GitLab customers can use Duo Agent Platform to bring agentic triage and remediation into the same governed path as source code management, CI/CD, and the rest of the SDLC.

The new standard now is to move “detection to verified remediation” at machine speed.

Join us at Transcend, our livestreamed event on October 6, where we will dive deeper on the topic and share our latest innovations to help you secure your agentic software development.

Complex tasks hit a wall at the end of every chat turn. Developers already know what they're trying to accomplish. What stalls the work is the handoff back and forth between each step. Without a pre-defined definition of success, the agent stops and waits for direction or clarification, so you end up re-prompting it step by step, effectively acting as its continue button until the task is done.

Depending on the team, that handoff can mean minutes of back-and-forth, or it can mean the request sits until someone is free to look at it again. A back-and-forth like this is manageable for small, well-scoped requests, but it breaks down for the kind of open-ended work developers actually spend their time on: fixing the failing tests, getting this build past checks, or cleaning up the lint errors across a module.

With GitLab 19.4, GitLab Duo CLI includes the /goal slash command, a governed, goal-driven flow that takes on that open-ended work directly, running locally while you stay in control.

GitLab Transcend returns in October

Coding agents are increasing your speed of development, but your reviews, security policies, and release cycles still have to keep pace. Our Transcend event on October 6 will demonstrate how GitLab is helping teams close that gap and explore what it takes to carry the speed of agentic AI across the software lifecycle.

Register for the livestream today!

Why turn-by-turn chat keeps costing you time

This isn't about the assistant getting smarter. Turn-by-turn chat requires someone to keep it moving: read the response, decide the next instruction, send it, repeat. Even a capable model still waits at the end of each turn for a person to unstick it, so a developer's attention stays tied to how long a task takes, not how much of it they actually need to do by hand. That's why AI assistance so far has mostly changed the shape of a developer's time rather than given much of it back.

Delegate it, and get a verified result back

With /goal, you describe the outcome you want and move on. No one needs to babysit the run: work continues, gets checked against what you asked for, and either finishes or tells you what it couldn't resolve. You come back to a completed result and a record of what was verified, the same way you'd check in on something you delegated to a colleague, instead of staying anchored to the conversation until it's done.

From single prompts to standing goals

You just name the job and define what "done" looks like, and GitLab takes the wheel, staying active and focused until that specific finish line is crossed.

/goal Fix the failing tests. Ensure CI is fully green and the fix is reviewed by Duo Developer.

GitLab then works the problem: It makes changes and runs verification, iterating as needed. A separate model checks that work against your stated goal at each step, deciding whether it's genuinely done or another iteration is needed, up to a configured limit. This is the difference between an assistant that answers questions and one that drives a task to completion.

Automation that stays governed

Handing off a goal does not mean losing visibility into it, though. You can stop a /goal run at any point and set a new goal if requirements change, so a session in progress never has to run to its full conclusion if it's off-track.

• Stop the run at any point if you need to step in.
• Set a new goal and restart, if requirements have changed.
• Review what the verifier checked at the end of each turn, so you can see why it decided to continue or stop.

That combination — an agent that can work autonomously toward a defined outcome without requiring a supervising human to stay glued to every step, while still exposing clear points of human oversight — is what makes this a step toward practical automation rather than a novelty.

Getting started

The /goal slash command is available now in interactive mode. To use it, run:

/goal <task>. <done when...>

For example:

/goal Fix the failing tests in spec/models/user_spec.rb. Continue until all tests pass locally and CI is green.

Watch /goal in action in this demo:

Meeting developers where they work

The value of a goal-driven flow depends on the surfaces through which developers can reach it. /goal launches first in the CLI because much of this iterative, hands-on work already takes place in the terminal, but the underlying capability is not limited to any single client. Developers should be able to delegate a goal from within the tools they already use, rather than switching to a separate interface to access this automation.

A GitLab Duo Slack agent is coming soon, letting developers work with GitLab Duo Agent Platform conversationally, right inside Slack. Mention @GitLab in any channel or thread to ask questions about your codebase, trigger an agent flow, or create a GitLab issue from the conversation, with no separate tool, tab, or command syntax required. GitLab Duo streams its progress back into the thread in real time, so the whole exchange — ask, work, and result — stays where the conversation is already happening.

Start delegating the work you already repeat

/goal is now available in GitLab Duo CLI, and it marks a first step toward moving the decision-making behind a task, including when a goal is done and when to keep going, out of any single client and into a governed workflow that every GitLab surface can call on. As that same capability extends to Slack, the iterative fixes and verifications your team already runs by hand become governed, goal-driven flows, without asking developers to change where they work.

Ready to try /goal? Start with the documentation for GitLab Duo CLI slash commands.

/goal requires GitLab 19.3 and later, and GitLab Duo CLI 9.17.0 and later. It's available on GitLab.com, GitLab Self-Managed, and GitLab Dedicated, on the Premium and Ultimate tiers.

/goal is part of GitLab Duo Agent Platform, so you'll need it turned on to use this and other agentic capabilities. You can get access with a free trial of GitLab Duo Agent Platform. On the Free tier, you can sign up in a few simple steps.

Already on GitLab Premium or Ultimate? Start by turning on Duo Agent Platform and use the GitLab Credits included with your subscription.

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 these statements are reasonable, they are subject to known and unknown risks, uncertainties, assumptions and other factors that may cause actual results or outcomes to differ materially. Further information on these risks and other factors is included under the caption "Risk Factors" in our filings with the SEC. We do not undertake any obligation to update or revise these statements after the date of this blog post, except as required by law.

Agentic tools are moving fast past code completion into running pipelines, opening merge requests, and triaging work on a team's behalf. The Model Context Protocol (MCP) has become the common way these agents reach into a team's existing tools, which means the agents touching an organization's software delivery pipeline are no longer only the ones a platform team chose and configured themselves.

That reach is also where automation typically stalls. The more an agent can do, the more a platform team has to think about what it should be allowed to do without asking first, and that's a governance problem that tends to get solved by restricting access rather than by extending it. Left unaddressed, it doesn't resolve on its own: Teams either lock agents down to a handful of safe, read-only actions, or they open things up and hope, neither of which scales.

GitLab's answer is to make wide tool access and consistent governance travel together. As platform engineers roll out agents across their organization, whether that's a GitLab flow or a third-party client connected through the GitLab MCP server, it needs the same reach into GitLab. But broader reach raises the stakes on control: a human should decide which actions an agent can take on its own and which need a reviewer, so routine, read-only lookups move fast while anything that writes, merges, or deletes waits for the reviewer that team chose.

GitLab Transcend returns in October

Coding agents are increasing your speed of development, but your reviews, security policies, and release cycles still have to keep pace. Our Transcend event on October 6 will demonstrate how GitLab is helping teams close that gap and explore what it takes to carry the speed of agentic AI across the software lifecycle.

Register for the livestream today!

Built for how platform teams scale automation

With GitLab 19.4, platform teams can automate more of the software lifecycle end to end: An agent can run a pipeline, open and update a merge request, or triage a vulnerability, not just look one up. Read-only actions run without a human in the loop by default, so agents move at the pace of the work. Anything that writes, merges, or deletes still waits for the reviewer a team chose, so widening what agents can touch doesn't widen what they can do unsupervised.

The GitLab MCP server's tool set grows substantially with this release, adding CI/CD, merge request, work item, vulnerability, and project tools.

See these MCP server tools in action:

A wider automation surface, tool by tool

GitLab is adding a substantial set of new MCP server tools, giving agents the coverage they need to complete real work end to end.

• CI/CD tools. save_pipeline runs, retries, cancels or renames a pipeline. get_job returns job by default; passing include: ["log"] adds the job trace, paginated via byte_offset and byte_limit (512 KB per page), so an agent can pull a failed build's log and diagnose the problem directly.
• Merge request tools. save_merge_request opens and updates an MR. get_merge_request can return diffs, conflicts, or approvals (one at a time via the include param), with diffs defaulting to stats-level detail unless you request detail: full_patch for the patch text. list_merge_requests works at group scope. save_merge_request_review covers the full review flow in one tool: posting a line-level or summary comment, replying in or resolving a discussion, submitting a full review, triggering a Duo review, and approving or unapproving. accept_merge_request merges an MR immediately by default, or waits for checks to pass when you pass strategy: merge_when_checks_pass (or adds it to a merge train with add_to_merge_train_when_checks_pass).
• Repository tools: list_repository_tree allows exploring the file tree. list_branches and list_tags enumerate refs and list_releases allows inspecting published releases. list_commits, get_commit, and add_commit allow for direct interaction with the repositories contents and history. fork_repository forks a project to allow an agent to do change without affecting the upstream repository.
• Project and user tools. get_project and list_projects find and read project details. list_project_members lists members and their roles. get_user looks up user details for assignment and mentions.
• Work item tools. get_work_item reads a single item in depth and covers what get_issue did, list_work_items searches across a group or project, and save_work_item creates or updates any supported work item type, covering what create_issue did. Issues and epics are themselves work item types. save_note comments on a work item or merge request and can reply inside an existing thread. It supersedes create_merge_request_note and create_workitem_note.
• Vulnerability tools (available on Ultimate). list_vulnerabilities lists vulnerabilities in a project, filterable by severity and report type, with cursor pagination. get_vulnerability returns full details for a single vulnerability by ID. save_vulnerability consolidates five write actions, dismiss, confirm, revert to detected, update severity, and create a linked issue, into a single tool.
• A new merge request trigger. GitLab 19.4 adds Created as a trigger action for merge requests: A flow or external agent can now run the moment someone opens a merge request, once GitLab generates the diff. Use it for a first-pass review, or to pull in context from related issues. Configure it under AI > Triggers in your project, or when you enable a flow.

Scale automation, one agent at a time

The expanded set of tools are currently available in beta. They mark a first step toward a platform where every agent, internal or third-party, runs under the same governed rules and reaches the same depth of GitLab context. As more tools and triggers ship, that governance model extends with them, so platform engineers configure guardrails once rather than for every new client.

Ready to try it? Start with the MCP server tools documentation and tool governance documentation.

The new MCP server tools are available in beta on the Free, Premium, and Ultimate tiers, with the exception of the vulnerability tools, which require Ultimate. The Merge request created trigger requires Premium or Ultimate and GitLab Duo Agent Platform turned on. See the triggers documentation to configure it for your project.

Already on Premium or Ultimate and want the Merge request created trigger? Start by turning on Duo Agent Platform and use the GitLab Credits included with your subscription.

Scaling AI across your organization depends on knowing where the budget is going and who’s using it. While a subscription cap keeps your total spend within budget, it can’t tell you how much AI was used by individual teams. And predicting future budget needs ahead of business needs gets more challenging as teams grow. Without per-user data you can’t set a fair cap on AI spend, explain a spike, or show a department what it consumed.

GitLab 19.4 makes GitLab Credits manageable per user: Set individual budgets, see the spend, and export a detailed report that explains the invoice. You can give each team its own budget and each developer their own consumption view. If a power user risks draining the team’s shared credit pool, you can limit usage, and pull exact session data behind your last spike. As consumption changes, you can adjust spend caps, so no teams need to slow down to renegotiate whose work gets priority.

The need for AI spend controls is urgent. In GitLab's AI Accountability Report, 98% of respondents have allocated or expect to allocate budget to AI governance. Committed AI budgets across departments require clear, explainable, and reportable usage data.

GitLab Transcend returns in October

Coding agents are increasing your speed of development, but your reviews, security policies, and release cycles still have to keep pace. Our Transcend event on October 6 will demonstrate how GitLab is helping teams close that gap and explore what it takes to carry the speed of agentic AI across the software lifecycle.

Register for the livestream today!

Granular attribution and visibility

Every GitLab Credit tracks spend by user, namespace, and project (where applicable) with a timestamp. The record that controls when a user hits their cap is the same one that answers which team consumed how credits, on what activity, and when. The platform that ran the agent session is the one that recorded the credits, so you don’t have to reconcile two systems to produce that record.

Show each team its usage numbers, then decide on chargeback

Showback is the practice of reporting each team's consumption back to that department. Show each team what it consumed and let departments judge whether they are using what they already paid for. Most teams make adjustments once they see their consumption, and you keep the record for future chargeback.

Forecasting requires a per-team baseline

Before agentic flows move through your CI pipelines, you need to know what a team of 200 developers consume in a typical month. And you need per-user data to understand the cost of the credits consumed based on the model before you can compare two teams' usage.

Speed needs control

Platform engineering teams spent the last decade making it safe for delivery teams to work independently in CI/CD and security by pairing autonomy with boundaries that are visible and enforced. Agentic automation scales the same way. You give a team its own budget, see what it spends, and approve the next set of flows based on your visibility into its cost.

Budget guardrails for every level of the organization

Reach the subscription cap and credit-consuming features are suspended for all users until the next billing period or an administrator raises it. Reach a personal cap and only an individual is impacted.

You receive clear warnings. The GitLab Credits dashboard notifies admins via email at 50%, 80%, and 100% of credit usage, and again when a subscription cap is reached. One caveat: Usage syncs periodically rather than in real-time, so spend already in flight can cross a cap before enforcement catches up.

GitLab Flex adds a second control layer. You mark each capability Restricted, Usage cap, or Unlimited against your shared reservation, so one capability's overage stops drawing down what every other capability needs.

Per-user caps and exceptions from a settings page

The Credit caps page puts both per-user controls on one screen. Set a default for everyone, then raise or lower it for individuals.

• Flat user cap. Enter the number of GitLab Credits any user can consume per billing period and turn on enforcement. Every user on the subscription inherits this limit unless you override it.
• Per-user overrides. Select Add override, search for one or more users in the picker, set their cap, and save. Overrides can go above or below the flat cap, so the same page raises a staff engineer and lowers a contractor.
• Reversible exceptions. Each override has its own enabled toggle. Switch the toggle off and save to restore the user to the flat cap. Undoing an exception never deletes anything, and the number waits in the table for the month you want it back.

The flat cap toggle remains the master switch: Turn it off and overrides stop applying too.

Usage exports down to the billable event

Exports now run in the background and arrive by email with a secure download link. Each export covers up to 31 days and contains three files: the daily summary you already use, a new per-event file, and a manifest.

• Event ID, timestamp, and event type
• Product and flow type
• Session identifier
• User ID
• Namespace ID
• Project ID
• Credits consumed, quantity, and unit of measure
• LLM call count, token totals, and models used
• Flex capability and subscription name

Where a group has turned off Display GitLab Credits user data, the user columns follow that setting.

Group by namespace ID and you have a department's line, which is what showback runs on. Filter by user ID and date and you have the session behind last Tuesday's spike. Because namespaces seldom match finance cost centers directly, you can perform a one-time mapping so future monthly exports seamlessly reflect your cost structure.

What developers see

Any member of your top-level group can open their own GitLab Credits view under User settings and see a daily chart of their consumption, with the same product filter and date range controls as the group dashboard, scoped to their own events.

Included promotional credits now go before evaluation credits

Included promotional monthly credits are now applied on a per-user basis before any shared evaluation credits are used, so each user spends what they are already entitled to first. Included credits are 12 per Premium seat and 24 per Ultimate seat per month. The evaluation pool is shared across the subscription. Your invoice does not change: Monthly Commitment Pool, One-Time Charge, and On-Demand credits keep their order.

To fund one team's heavy usage without opening the budget to everyone, set a low flat cap, then override it for the people doing agentic work. Everyone under the flat cap still gets their full included credits every month because caps are enforced only after included credits run out. Your shared pool pays for the exceptions, not for everybody.

Getting started

GitLab Credits usage visibility is included and already available with Premium and Ultimate subscriptions.

• If you have Owner or Administrator access, visit the Credit caps page on GitLab.com and Self-Managed.
• If you manage the billing account, you can get the per-event export on GitLab.com, Self-Managed, and Dedicated.
• If you are a developer, you can check out your own usage view on GitLab.com.

1. Set the subscription ceiling. Billing account managers, this appears in the Customers Portal under GitLab Credits dashboard > Spend controls. Caps On-Demand credits across everyone.

2. Set per-user limits. Group Owners, on the Credit caps page, go to Settings > GitLab Credits > Credit caps for a top-level group; administrators on GitLab Self-Managed, go to Admin> GitLab Credits> Credit caps. One default for everyone, plus overrides.

3. Export what happened. From the GitLab Credits dashboard or the GitLab Flex month overview, select Export usage data. One row per billable event, up to 31 days, delivered by email.

To report per-user data, ensure Display GitLab Credits user data is turned on for your top-level group on GitLab.com or your Self-Managed instance. This setting is on by default, so most groups need no change.

None of the settings you’ve already set up changes. The subscription cap works as it did, enforcement behavior is unchanged, and the GraphQL API still writes to the same records the page reads, so existing automation continues working. The usage order documentation sets out the full sequence across every credit type.

Next steps

Set your subscription cap today, then get started by exporting and analyzing last month's usage.

New to GitLab Duo Agent Platform? Start a free trial. Already on Premium or Ultimate? Turn on Duo Agent Platform and use the credits included with your subscription.

There’s no single best model for every software development task. Implementing a new feature, diagnosing a failed pipeline, and resolving security vulnerabilities all place different demands on the model handling them. GitLab Duo Agent Platform is expanding GitLab-managed model choice with three hosted open weight models: Kimi K3, GLM 5.3, and MiniMax M3.

Together with the frontier models already available in GitLab, your team now has more control over how you optimize for quality, latency, and cost, tuned to the needs of each workload. Point a hard task at Kimi K3 or GLM 5.3, which outperformed comparable frontier models in internal testing and costs less per call, or hand routine, high-volume work to MiniMax M3. Either way, your team gets up to 4x more calls per GitLab Credit than some comparable frontier models, with more AI model options to match cost to task complexity.

GitLab Transcend returns in October

Coding agents are increasing your speed of development, but your reviews, security policies, and release cycles still have to keep pace. Our Transcend event on October 6 will demonstrate how GitLab is helping teams close that gap and explore what it takes to carry the speed of agentic AI across the software lifecycle.

Register for the livestream today!

Why one model has been the easy way out

Different tasks in agentic development need different things from an AI model. A long-running refactor needs a large context window and deeper reasoning, while a routine, high-volume task is often better served by a faster, more cost-efficient model. Optimizing for one task type means giving up ground on the other.

As teams work through the technical tradeoff, whether they can actually access a new model emerges as an additional governance challenge. In regulated environments, every model and the infrastructure it runs on has to clear security, compliance, and internal review before the team can use it. Reviews and approvals move slowly enough that many teams standardize on one approved model, even when it isn’t the best fit for every task.

The cost of that compromise compounds. If your team standardizes on a higher-cost model to cover its hardest tasks, that same model will end up tackling routine work that could have been handled by a faster, lower-cost model. As agent workloads make repeated model calls across long-running, multi-step work, the gap between cost and performance grows.

The cost-performance advantage of open weight models

Open weight models turn model choice into a lever for balancing cost with performance. They can potentially lower the inference costs of many agentic tasks, with performance in line with some frontier models.

The new open weight models hosted in GitLab offer notably more calls with one credit than many comparable frontier models already available on Duo Agent Platform. A call is a single request GitLab Duo Agent Platform sends to a model, and one agent action or chat message can trigger several calls.

Kimi K3 outperforms the default model behind most GitLab Duo Agent Platform features in our internal testing, at 1.82 calls per credit, just under the default model’s 2 calls per credit. GLM 5.3 gets 5 calls per credit while also delivering strong performance in internal testing, and MiniMax M3 builds on that cost efficiency at 8 calls per credit.

Together, they give your team another lever for balancing cost and performance, task by task. For more information on credit multipliers and a breakdown of credit usage per model, visit the GitLab Credits models page.

Each of the hosted open weight models now available in GitLab Duo Agent Platform brings its own strengths.

• Kimi K3 (Moonshot AI) is the company's newest flagship model, giving teams room to work across large codebases or long-running agent sessions.
• GLM 5.3 (Z.ai) is built for long-horizon coding tasks, giving teams a model tuned to hold context and accuracy across extended agent sessions.
• MiniMax M3 (MiniMax) is designed to keep compute costs down on long-running work and tuned for high-volume, multi-step agent work, making it a strong option when cost efficiency matters at scale.

Watch this demonstration of available open weight models:

Model choice with built-in control

With a broad roster spanning open weight and frontier GitLab-managed models, your Duo Agent Platform implementation now has more freedom to optimize model selection for each task.

Your admins maintain centralized control over which models your teams can use, built directly into your software development workflows. While GitLab selects default models based on performance, the owner of your top-level group can set a different default model for each feature and curate which models teams can choose from, settings that apply consistently across every child group and project.

You can align model selection with your security, compliance, and infrastructure requirements through GitLab-managed, self-hosted, or hybrid AI deployment options. GitLab-managed models run entirely within GitLab's environment, with no infrastructure for your team to stand up or maintain. Self-hosted models run on infrastructure your team manages, keeping model traffic inside your own network. Hybrid deployments let your team mix both, running some models through GitLab and others on your own infrastructure, based on what each workload requires.

Before a new model joins the GitLab Duo Agent Platform roster, we evaluate it against internal performance and quality requirements. GitLab-managed models carry their own built-in assurance. Before selecting a vendor to host models for Duo Agent Platform features, GitLab puts it through a third-party risk management process to verify it meets a defined security bar. That includes a review of the vendor's security program and controls, such as access management, data governance, and risk management practices, along with third-party security attestations like a SOC 2 Type 2 report or active ISO 27001 certification, and periodic penetration testing with risk-based vulnerability remediation.

All three hosted open weight models are served through Fireworks AI, which meets that bar. For GitLab Duo Agent Platform requests, GitLab maintains a zero data retention policy with Fireworks, meaning model input and output data is discarded immediately after each response and is not stored for abuse monitoring.

With that governance and security foundation in place, your team can bring open weight models into your workflows with the same confidence you'd expect from any GitLab-managed model.

Start building with open weight models

You can now select Kimi K3, GLM 5.3, and MiniMax M3 as optional models in GitLab Duo Agent Platform, or set one as the default model for a feature so your team uses it automatically. For a deeper look into model support in Duo Agent Platform and guidance on model selection, read the GitLab AI model documentation.

New to Duo Agent Platform? Start a free trial. Already on Premium or Ultimate? Turn on Duo Agent Platform.

GitLab.com hosts millions of projects for teams of every size that need a platform they can rely on. Demand is climbing quickly, and we expect platform load to grow several times over this year. Predictable limits are what keep GitLab.com fast for everyone on it, including the automation and agent workloads teams are building on the platform.

To hold that as we scale, we're updating how rate limits work. Starting October 19, 2026, rate limits on GitLab.com will align with your subscription tier. Free accounts and unauthenticated requests happen first, on October 19. Premium and Ultimate move in January 2027.

What is changing

Limits align with your subscription. Free, Premium, and Ultimate subscription plans get their own limits, applied per user and per top-level group. Free takes effect October 19; Premium and Ultimate in January 2027.

Signing in gets you the full limit. An authenticated request is governed by your subscription plan below. A request that arrives with no credentials gets 60 requests per hour per IP address.

The per-plan limits are published in the rate limits documentation.

What happens on October 19

There will be two preview windows for Free and unauthenticated traffic, on October 7 and October 14 from 15:00 to 19:00 UTC. Signed-in Premium and Ultimate requests are not affected, since those limits do not change until January. Unauthenticated requests are capped no matter where they come from, including automation running against a paid account without credentials. A preview window (engineers call these brownouts) is a short, planned window where we switch the new limits on and then switch them back off. Nothing else about the service changes while it runs. The point is to give you a real look at how your own workloads behave under the new limits, weeks before they apply for good.

On October 19 the new limits take effect.

We set these limits by looking at how GitLab.com is actually used. Almost all users are already inside the new limits and won't notice any change. We also looked at what similar platforms allow. The Free limit and the anonymous allowance match the industry norm, while Premium and Ultimate are more generous, at levels other platforms reserve for their enterprise tiers or don't publish at all.

If you're close to a limit

If you find that you are nearing a limit, authenticate your requests. It's usually a small change: Invoking a personal access token, an OAuth token, or the CI/CD job token all move a request off the anonymous 60 requests per hour and onto your plan's limits, which are much higher.

Next, look at how you're calling the API. Batching, caching, and pagination go a long way, and polling in a tight loop burns through your allowance fast. When you do cross a limit, you get an HTTP 429 back with a Retry-After header saying how long to wait, so a client that reads its own response headers mostly fixes itself. Backing off exponentially recovers faster than retrying immediately.

Upgrading to Premium or Ultimate increases the limits, too, per user and per top-level group.

If you need a higher limit on an ongoing basis, we are working on a way to purchase capacity above the standard plan limits, with details coming later this year. If that sounds like you, reach out to your account team or email limits@gitlab.com and tell us what you need.

What changes and what doesn't

These limits are set so no single workload can slow the platform for everyone else. Ordinary signed-in work isn't the target, and, for almost all users, a normal day looks identical. Browsing the UI, working in your editor, pushing and pulling with git, and running CI/CD within your plan all carry on exactly as they do today. Some heavy automation and a small number of Free-tier workloads will reach the new ceilings.

What doesn't change:

• You can always reach and export your own data and repositories.
• GitLab Self-Managed and GitLab Dedicated limits stay with your operator. This is only a GitLab.com change.
• We'll notify you before we make additional changes.

A reminder: Make sure to authenticate your requests to GitLab.com so your limits are higher.

FAQ

How do I know whether this affects me?
Compare your busiest minute against the published limits for your plan. Most customers are not close. The quickest signal in the meantime is the RateLimit-Remaining header on your API responses, which tells you how much of your current window is left, and we are building a view in the product for release later this year that shows your usage against your plan's limits.

My project is public and busy. What are my options?
Three things help. Ask the automation that calls your project to sign in, which moves it onto its own limits rather than the anonymous allowance. Make the project private if the traffic is not coming from the audience you built it for, which stops anonymous callers reaching it at all. Or upgrade to Premium or Ultimate for much higher limits.

What if I am a member of several top-level groups?
Your user limit will be the highest subscription tier available to you. If you are a member of an Ultimate group, you will have access to the Ultimate limit.

What happens when I hit a limit?
You get 429 Too Many Requests with RateLimit-* headers and a Retry-After. Wait the interval it gives you, then retry.

My integration genuinely can't authenticate. What now?
Reach out to us at limits@gitlab.com. There are legitimate anonymous patterns, a public status badge being the obvious one. If you are concerned that an integration you own may be affected, contact us.

Does this apply to GitLab Self-Managed or GitLab Dedicated?
No. This is a GitLab.com-only change.

Additional resources

• Rate limits by plan
• Authenticating your API requests
• Questions, or you've encountered a case we haven't thought of? Contact your account team or email limits@gitlab.com.

You're probably running some version of this experiment already: Point a frontier model at a merge request and ask it to double as a vulnerability scanner. On a single merge request, it often works well. The model reads the code, reasons about what it's supposed to do, and catches real issues, sometimes ones a pattern-based scanner misses entirely.

So the next thought is reasonable: If a model reviews one merge request this well, why not let it replace the scanner across your whole pipeline? That’s where it breaks down. Running a frontier model as your primary scanner on every commit across an enterprise codebase costs more and behaves less predictably, than asking it to review one merge request.

If you run application security for a platform or product team, the decision was never mutually exclusive: static application security testing (SAST) or LLM scanners. It's which one runs where. Get that split right and you keep deterministic coverage on every commit, add reasoning where it earns its place, and avoid both an unpredictable inference bill and gaps in your audit trail. Here's how the two compare:

The cost of scanning every commit

Better: SAST

The cost of an LLM reviewing one merge request might seem marginal, but when you point that same model at every commit across an enterprise codebase, the math no longer works. Every scan becomes an unpredictable paid inference call, and that cost compounds with every commit, every day. SAST runs at the same volume for fractions of a cent per scan, the same way every time, predictably. SAST keeps per-commit scanning cheap and predictable, so security coverage never competes with the budget. An LLM in that role makes the cost scale with usage and difficult to forecast.

Consistency and producing audit evidence

Better: SAST

Run the same code through an LLM twice and the vulnerabilities identified may differ. It's not because the model made a mistake, it's how sampling-based reasoning works. That inconsistency becomes a challenge when you need to prove a scan happened and can be trusted for audits. Auditors independently verify the completeness and accuracy of scanners by rerunning them and confirming the results match. Because a deterministic scanner is rules based, it gives you consistency by design. When you rerun it, you get the same result every time.

Vulnerability types

Better: Both

Static scanners and LLM scanners are strong on different classes of vulnerabilities. A deterministic scanner is built for pattern-based vulnerabilities like injection flaws, hardcoded secrets, and insecure crypto calls. It follows fixed rules, so it flags the same issues on every run.

An LLM scan works differently. It can read the context around the code, the epics, issues, and docs that describe what the system is supposed to do, which a scanner does not have the ability to process. That context is what lets it flag business logic issues like a missing authorization check or a broken ownership assumption. When that context is available, a LLM can catch what a pattern-based scanner structurally never can.

Validating a finding

Better: LLM scanners

A deterministic scanner flags candidates, but it can't tell you whether a finding is actually exploitable. An LLM can go further. It writes a quick test that tries to trigger the flaw, so you see whether a finding is real before it reaches your queue. That saves your team from spending time investigating false positives, and it earns the developer trust in the quality of the findings.

Security programs are heading toward both

Security teams aren't picking one type of scanner, they're building towards a program running both. Deterministic scanning stays the baseline that runs on every commit, no matter what, because that's the coverage a program can't compromise on. LLM scanners layer on top for the reasoning-heavy checks they excel at, usually at the merge request level rather than on every commit. That's where they can catch vulnerabilities where a deterministic scanner structurally cannot. Together they give you comprehensive coverage, the deterministic scanning that catches patterns at a predictable cost and LLM scanners for the reasoning to catch logic flaws.

New to GitLab? Advanced SAST scans every commit, and Security Review Flow, GitLab’s security LLM scanner, adds reasoning based review, all in the same pipeline. Start a free trial of GitLab Ultimate.

Already on GitLab Ultimate? Turn Security Review Flow on to run alongside the SAST scans you're already running.

FAQ

Can AI replace SAST?

Not as the only scanner. AI-based review can find real issues, but it can flag or miss different vulnerabilities on the same code from one run to the next, and running an LLM over every commit at enterprise scale costs more and is harder to forecast than a scanner built to run continuously and deterministically.

Why does having reproducible audit evidence matter for compliance?

Frameworks for secure coding like SOC 2, PCI DSS, and the European Union's Cyber Resilience Act require reproducible, auditable evidence. A scanner is information an auditor independently verifies by rerunning it and confirming the result matches. A deterministic scanner supports independent confirmation by design. A probabilistic model doesn't guarantee the same results with each scan.

What can AI-based reviews catch that SAST can't?

AI-based reviews can catch business logic flaws: missing authorization checks, broken ownership validation, and bugs that depend on understanding what the code is supposed to do, not just how it's written. AI-based reviews enable reasoning about intent, which pattern-based scanning isn't built to do.

Should security teams use both?

Yes. SAST and AI-based reviews specialize in detecting different vulnerability types. Programs could run SAST continuously, on every commit, and reserve AI-based review for the reasoning-heavy checks, such as business logic vulnerabilities, that a scanner structurally cannot detect.

Additional resources

• Delivering faster and smarter scans with Advanced SAST
• GitLab Advanced SAST documentation
• GitLab Duo Security Review Flow documentation
• GitLab Duo Security Review spots logic flaws scanners miss

Enforcements such as NIS2 are no longer a future planning consideration. The European Union Agency for Cybersecurity's (ENISA) NIS360 report confirms that supervisory authorities are actively assessing cybersecurity maturity across critical sectors. The agency is moving from guidance and consultation into active oversight, scrutiny, and accountability. This is the regulatory environment European enterprises now operate in.

Multi-tenant cloud platforms remove operational overhead but place source code and pipelines on shared infrastructure regulators now scrutinize. Self-managed solutions provide isolation but transfer responsibility for upgrade cycles, security patches, and disaster recovery (DR) tests to an already stretched platform team. Both deployment options leave gaps in risk management, data sovereignty, and furnishing audit evidence.

In this article, you'll discover how GitLab Dedicated, a fully isolated, single-tenant SaaS solution deployed in your preferred Amazon Web Services (AWS) region and hosted and managed by GitLab, addresses these challenges and helps you keep pace with evolving compliance requirements.

"NatWest Group is adopting GitLab Dedicated SaaS to enable our engineers to use a common cloud engineering platform; delivering new customer and colleague outcomes rapidly, frequently, and securely with high quality, automated testing, on-demand infrastructure, and straight-through deployment."

— Adam Leggett, Platform Lead for Engineering Platforms, NatWest Group

Regulations are driving change

In the European Union, key regulations are driving the need for a different platform approach. These regulations converge on a decision most enterprises made before they existed: a platform their developers build on. That decision now carries audit consequences it didn't before.

1. Digital Operational Resilience Act (DORA), which came into force across EU financial services in January 2025, requires financial institutions to keep critical technology resilient, avoid over‑reliance on key providers, and strengthen incident reporting.
2. NIS2 Directive, adopted in December 2022, requires essential and important sectors to strengthen cybersecurity, secure technology supply chains, and rapidly report significant incidents to relevant authorities across the European Union.
3. General Data Protection Regulation (GDPR), applicable since May 2018, requires organizations to protect personal data, document where it is stored and who accesses it, and ensure a valid legal basis for every use.

Shared infrastructure and operational exposure

On multi-tenant platforms, shared execution, runners, and storage mean a single CVE or misconfiguration can simultaneously expose multiple tenants. On self-managed deployments, risk concentrates internally: Secrets and credentials accumulate and aren’t regularly rotated, while manual, incident-driven changes cause drift from infrastructure-as-code baselines, obscuring the real attack surface from audits.

GitLab Dedicated codifies operations

Site reliability engineers (SREs) manage your GitLab Dedicated instance in an isolated AWS account without default direct access to customer environments. All operational changes use automated, approval-gated workflows via a defined control plane, not live system intervention. CI/CD variables and runner tokens can rotate on a cadence defined by you, reducing configuration drift and keeping the operational attack surface tightly controlled through codified processes.

Disaster recovery is built in by default for every GitLab Dedicated customer, with each Dedicated customer instance having a secondary region that maintains a backup. GitLab Geo provides asynchronous, continuous replication between the two sites. The deployment architecture aims to minimize the impact of regional cloud failures and maintain business continuity for our customers. GitLab Dedicated provides disaster recovery with these recovery objectives:

• Recovery Time Objective (RTO): Service is restored to your secondary region in eight hours or less.
• Recovery Point Objective (RPO): Data loss is limited to a maximum of four hours of the most recent changes, depending on when the disaster occurs relative to the last backup.

Data sovereignty and customer‑controlled security

Auditors need clarity for GDPR and data sovereignty: data location, access ownership, and whether runner traffic leaves approved regions. In multi-tenant platforms, the provider controls these and data may cross borders. In self-managed deployments, you have to define storage policies, key management, and network routing to keep everything within your chosen region.

GitLab Dedicated brings isolation with control

Region selection at provisioning pins object storage, artifacts, and compute data to your chosen AWS region. You also select a secondary failover region, so the only cross-region movement is the replication you explicitly enable between those two regions. Customers in the European Union can keep both regions in-jurisdiction. GitLab manages failover against defined Recovery Time Objective and Recovery Point Objective targets.

Bring-your-own-key (BYOK) provisions customer managed keys so GitLab cannot access encrypted data if you revoke the key. AWS PrivateLink creates a VPC endpoint in your account; traffic between your network, CI/CD jobs, and GitLab Dedicated stays on AWS’s private backbone.

One constraint applies across all major cloud providers and cannot be resolved at the infrastructure layer: As a U.S. corporation, Amazon Web Services remains subject to U.S. legal obligations, including the Clarifying Lawful Overseas Use of Data (CLOUD) Act, which can compel data disclosure regardless of where servers are physically located.

BYOK addresses the GitLab-layer exposure as GitLab holds no keys and cannot decrypt your data. But this does not alter AWS's obligations under U.S. law. Organizations with strict jurisdictional requirements should address the residual exposure through legal and contractual mechanisms: data processing agreements, transfer impact assessments, and documented legal basis for transfers alongside infrastructure controls.

Audit evidence gaps

On multi-tenant SaaS, logs and incident records live in shared infrastructure, so auditors need the provider’s help to extract tenant-specific evidence. For self-managed deployments, the primary audit risk is CVE exposure caused by upgrade delays. Falling behind on releases leaves known vulnerabilities in the environment where source code resides, which is more difficult to justify to auditors than straightforward capacity constraints.

GitLab streamlines compliance

GitLab Dedicated SREs keep your instance up to date on a pre-defined monthly upgrade cadence without a ticket in your platform team's backlog. Your instance runs the N-1 minor release and receives one minor and two patch releases each month inside a fixed weekly maintenance window, with emergency maintenance outside that window for S1 security issues.

Through the GitLab Trust Center self-service portal, you can access the latest GitLab Dedicated compliance documentation and assurance artifacts. For example, the latest DORA audit report by Schellman. With the out-of-the-box audit reports and centrally maintained evidence, your compliance and security teams no longer need to piece together years of self-managed configuration history or extract data from shared records for each regulatory submission or annual review. This builds a repeatable path to audit readiness with minimal operational overhead.

Check out this click-through demo to see how GitLab simplifies the management and operation of your Dedicated instance.

Moving to GitLab Dedicated

When you consider a move to GitLab Dedicated, you get more choice and more control delivered with a secure, compliant single-tenant SaaS. Infrastructure patching, availability evidence, and DR testing move into GitLab's audit scope, so your team documents and evidences the application layer rather than rebuilding infrastructure evidence for every submission.

Book a demo today to learn how GitLab Dedicated can meet your security and compliance needs.

There’s nothing like budget pressure to put your DevOps platform under a microscope. But subscription fees and license costs only tell one part of the story. The total cost of ownership (TCO) for a DevOps platform also includes variable costs like CI/CD compute and AI usage, along with the infrastructure, tools, and employee time required to keep software delivery moving.

That wider view matters when you’re tasked with defending platform spend or comparing options with a head of finance. Designing a useful TCO model can:

• Make those costs transparent for stakeholders
• Shine a light on the reasoning (or lack thereof) behind each cost
• Identify areas to reduce spend without negatively impacting software delivery

What total cost of ownership really includes

The core challenge of calculating TCO is that DevOps platforms package and price capabilities differently. For example, one platform may bundle CI/CD or AI capabilities into a per-seat subscription, while another could price usage separately. A third may appear less expensive upfront but require additional tools and ongoing integration work.

That’s why list prices or pricing tiers alone won’t give you a useful comparison. Start with the capabilities and workloads your organization actually needs, then calculate what it takes to support them on each platform.

Use the same scope and time period for every option — often one year — and define which teams, applications, environments, and delivery stages are included. Separate recurring costs from one-time expenses and external spend from internal labor, so finance can audit the assumptions and forecast future years.

A useful TCO model, therefore, answers two questions:

• What does it cost to meet our requirements today?
• Which variables will cause that cost to rise or fall as our usage changes?

The cost categories that drive your bill

Most DevOps platform costs fit into the following categories:

As you can see, some costs change with headcount, while others depend more on usage or operational complexity. Model these drivers independently rather than assuming platform costs will rise in lockstep. Pipeline frequency or job duration, for example, can increase CI/CD compute costs even when team size stays the same.

AI introduces another variable. Depending on the platform, AI may be priced by seat, consumption, or a combination of the two. That can make AI consumption inherently difficult to predict and pricing confusing to understand. As adoption grows, model AI usage separately from headcount and account for which AI capabilities teams actually use, since both can affect the total.

Additionally, cost drivers are only one part of the comparison. DevOps platforms package capabilities differently, so compare the cost of meeting the same requirements rather than matching tier names. If one option includes security testing and another requires separate products, include those products — along with the work required to integrate and operate them — in the comparison.

How your runner strategy affects CI/CD compute costs

While seat licenses are fairly predictable, CI/CD compute is not. As pipeline activity grows, longer jobs or higher concurrency can push costs up even if your team size stays the same.

Runners are where that compute gets used. They pick up CI/CD jobs, execute them on a machine or container, then return the results to the platform.

A key cost decision is who manages that compute:

• Vendor-hosted runners shift more of the expense into metered usage. They reduce the infrastructure your team has to operate, but costs can rise quickly as usage grows.
• Self-managed runners give you more control over the execution environment and infrastructure. They can be more economical for large, predictable workloads or when you already have capacity in place. The tradeoff is that your team owns the runner fleet and its operational overhead.

When determining your runner strategy, consider total cost — including storage, networking, security, monitoring, and maintenance — rather than infrastructure price alone. A strong approach should balance compute spend with operational overhead and developer experience as workloads change.

The hidden cost of tool sprawl

Tool sprawl doesn’t happen overnight. It takes shape gradually, as teams add a tool for planning, another for CI/CD, one more for security, and so on. AI can accelerate the pattern as teams adopt coding assistants, agents, and other AI tools alongside the existing stack.

Add up the invoices, and you still won’t see the full cost, because each tool brings more work:

• Integration maintenance: Connections between systems need to be built and updated as APIs change.
• Administration: Teams have to manage access, permissions, upgrades, and vendor contracts.
• Troubleshooting: When a workflow breaks across tools, someone has to find where the problem started.
• Developer time: Switching between systems and piecing together context can slow down everyday work.

That time can add up quickly. GitLab research found that DevSecOps professionals lose an average of 7 hours per week — nearly a full work day — dealing with inefficient processes.

The good news is that consolidation can reduce some of this overhead. If one platform replaces several tools without sacrificing capabilities your teams rely on, you may be able to lower licensing costs while also reducing the number of integrations and systems you have to maintain.

A worksheet to estimate annual cost

Use the worksheet below to turn the cost categories we’ve examined into a working annual TCO estimate. Keep the assumptions consistent across every platform you evaluate, and capture the inputs behind each number so you can revisit the model as usage or pricing changes.

At a high level, annual TCO = platform costs + CI/CD compute and infrastructure + AI usage + adjacent tools + operational labor + allocated migration and change costs.

It’s important to put your TCO estimate in context. Dividing it by a useful unit — such as active developers or applications supported — can show how costs change as adoption grows.

Next, pressure-test your model. Build a few scenarios around changes in headcount, pipeline activity, AI adoption, or concurrency so you can see which costs change the most. Not every category will scale at the same rate, which is exactly why documenting your assumptions matters.

The same approach works for narrower product comparisons. If you’re evaluating CI/CD tools on their own, include more than platform and compute charges. Runner infrastructure, adjacent tools, and the labor required to operate them still belong in the model.

Ready to run the numbers? Try GitLab’s ROI calculator to model your current toolchain and identify potential cost or time savings.

How to reduce your platform TCO

While the ideal cost-saving strategy will depend on your unique workloads and priorities, there are several best practices that can likely help you reduce unnecessary spend.

Right-size licenses before renewal

Start with what you’re already paying for. Compare provisioned licenses with actual usage, then identify inactive seats or users on tiers that offer more capability than they need.

Renewals are also a good time to check for overlapping products. If you’re paying separately for a capability your platform already includes, compare the value of the specialized tool with its full cost (not just its license fee).

Eliminate CI/CD work you don’t need

Before trying to make CI/CD compute cheaper, reduce the amount of compute you consume in the first place.

Look for pipelines that run when they don’t need to, jobs that continue after newer pipelines make them irrelevant, or steps that consistently take longer than expected. Artifact retention and caching policies are also worth reviewing, as both can affect storage and pipeline efficiency.

Once unnecessary work is gone, right-size the remaining compute. The FinOps Foundation's usage optimization guidance recommends the same general sequence: remove waste first, then continue adjusting resources as demand changes.

Build flexibility into AI spend

AI spend deserves the same attention. Watch how adoption and usage change rather than assuming AI costs will scale directly with headcount. When usage is difficult to predict, pricing flexibility can help reduce the risk of paying for capacity you don’t use, or having to revisit procurement every time demand grows.

GitLab Flex is one example of this approach. It brings platform seats, AI usage, and other eligible usage-based capabilities under one annual commitment that can be reshaped month to month as needs change.

Match runner capacity to demand

As mentioned previously, runner strategy can have a big impact on CI/CD costs. Keeping self-managed capacity available for peak demand can leave infrastructure idle during quieter periods, while relying entirely on metered compute may become expensive at high volumes.

Choose runner capacity and pricing based on the shape of the workload. Autoscaling can help self-managed runner fleets scale up and down with demand. For steady, predictable workloads, committed infrastructure or pricing models may make more economic sense.

Consolidate where it makes sense

The best consolidation opportunities are often where work already has to move between tools. Bringing more of the software lifecycle into one platform can reduce handoffs and give teams a more consistent view of the work, which is especially useful when teams need to trace a change or troubleshoot a failure.

That doesn’t mean every point solution has to go. Keep specialized tools when they solve a distinct problem well enough to justify the added complexity. Otherwise, consolidation can simplify the toolchain and how teams work across it.

Make cost optimization continuous

TCO changes as the business changes. A model built before a renewal may look very different six months later if pipeline volume grows, teams adopt new capabilities, or infrastructure changes.

Assign clear owners to the major cost drivers and review them regularly. Platform engineering might own CI/CD consumption, for example, while procurement tracks contracts and finance validates labor assumptions.

It’s also important that you prioritize optimization work by its likely return. A small saving may not be worth a large engineering project or added operational risk. For example, cutting a recurring compute expense with a simple pipeline change may be worth doing; re-architecting a stable workflow to save a marginal amount each month probably isn’t.

When you're ready to run GitLab through your model, see GitLab plans and pricing to fill in seats, compute minutes, and AI usage with published rates.

Starting on September 11, 2026, many businesses that place software on the European Union (EU) market will have 24 hours to file a report once they learn that a vulnerability in one of their products is being actively exploited. This is a new requirement under the Cyber Resilience Act (CRA), the EU law that sets cybersecurity requirements for products with digital elements sold in Europe, put in place to ensure those products are secure by design and supported against new threats. The most stringent requirements under the CRA apply to the manufacturers that make those products, from large software vendors to companies shipping connected hardware.

The challenge a business faces to stay compliant is not the filing itself. It is finding out fast enough that a vulnerability in something you shipped is being actively exploited in your software supply chain. The 24-hour clock starts the moment you become aware, this is why detection is so important. Continuous detection is an engineering solution rather than a one-off compliance one. GitLab's software supply chain security capabilities are built to help you find active exploitation in what you shipped, automatically and continuously. This article walks through four questions you should ask yourself about your own pipeline’s continuous detection solution today.

Reporting requirement starts in September 2026

Beginning September 11, 2026, manufacturers have to report an actively exploited vulnerability within 24 hours of becoming aware of it. The reporting runs in three stages each submitted simultaneously to the European Union Agency for Cybersecurity (ENISA) and to the Computer Security Incident Response Team (CSIRT) designated as coordinator.

1. Early warning, within 24 hours of becoming aware of the actively exploited vulnerability. A short first alert that exploitation is happening. You are not expected to know the full scope of impact or the fix yet.
2. Notification, within 72 hours. A fuller account, covering what is affected, what you know so far, and what you are doing about it.
3. Final report. For an actively exploited vulnerability, no later than 14 days after a corrective or mitigating measure is available.

Four questions GitLab can help you answer

Deciding whether a vulnerability in your product is reportable is your call. Here are four questions you can ask yourself today to prepare for the CRA, and how GitLab can help you answer each one.

Spot active exploitation in what you already shipped

Is a component in something I shipped being actively exploited right now?

Continuous dependency scanning watches your SBOM and flags newly published advisories against it. KEV status and EPSS scores on each finding tell you which ones attackers are actually using, so you can prioritize the vulnerabilities with real risk. Container Scanning covers the images you ship, and Operational Container Scanning covers what is running in your clusters today.

Find every product and repository affected

Which of my products are impacted, and which repository?

One search in the group-level dependency list returns every project that ships that component. Security attributes tell you which of those are internet-facing or business-critical, so you know where to start. That list is fed from both sides, a CycloneDX SBOM from Dependency Scanning for what your code declares including transitive dependencies, and one from Container Scanning for the OS packages baked into the image. A single search reaches everything in your software supply chain—everything you actually shipped.

Document when a vulnerability was identified

Can I show when I found out?

The activity log on each vulnerability records when it was detected, in which pipeline, and every status change after it with the person and the time attached. The vulnerability events webhook pushes those same moments into whatever system runs your clock. When someone asks when you found out, the answer is already captured.

Show the fix shipped, and when

Did a fix ship, and when?

Dependency scanning auto-remediation opens the upgrade merge request for you. Merge request approval policies can gate on known-exploited status, so the rule holds without anyone relitigating it. Compliance frameworks define the controls behind all of this, the compliance status report tracks where every project stands against them, and the compliance violations report picks up anything that slipped.

Everything else you are already running

Much of the information you will need to assess your reporting obligations under the CRA is already in the GitLab platform your code lives in. The inventory, the exploitation signals, the continuous re-matching, the timestamps, and the policy gates are not five tools to evaluate, buy, and wire together. They are capabilities you turn on in the pipelines you already run, with no new agents and no new data plane.

GitLab's security scanning, including Static Application Security Testing (SAST), Secret Detection, Secret Push Protection, Infrastructure-as-Code (IaC) Scanning, and GitLab's security policies, might not be needed to answer these questions, however, they can help address the next phase of CRA requirements that will arrive in December 2027.

Looking ahead: Stop risky packages before they enter your supply chain

GitLab's security capabilities help you respond fast. It is also worth setting your environment up so you have fewer vulnerabilities to report in the first place.

Not every supply chain risk arrives as a Common Vulnerabilities and Exposures (CVE) entry. A package published one character away from a library your team types every day never gets an advisory or a severity score, and neither does a package name that an AI assistant invented that somebody else then registered. There is nothing to patch, because the package itself is the attack.

Looking forward, GitLab will soon allow you to apply a preventative policy at the registry rather than detecting a vulnerability in a review three weeks later, so you can prevent harmful packages from entering into your supply chain before it reaches a build. To get information about the Dependency Firewall closed beta, coming soon, fill out our form.

For existing GitLab customers, try it on one component. Open your group-level dependency list, pick something you know ships in a product, and time how long it takes you to answer all four questions. If the answers come quickly, turn on continuous dependency scanning and add known-exploited status to a merge request approval policy.

If you are not on GitLab Ultimate yet, see if your shipped components carry vulnerabilities known to be exploited in the wild, in one view. Start a free trial.

If you'd like to continue your reading, check out the following: The European Commission's Cyber Resilience Act overview, its reporting obligations page, the summary of the legislative text, and the Commission's implementation guidance.

Amit Shalem is Principal Product Manager, Software Supply Chain Security, at GitLab.

GitLab users bring firsthand experience of the workflows they want to improve. Through our Co-Create program, they collaborate directly with us to design, build, and deliver product improvements that benefit more teams.

In the first half of 2026, our users helped us extend APIs, add CI/CD capabilities, expand language support for AI-powered code understanding, strengthen security controls, increase the flexibility of integrations, and make GitLab easier to use and understand.

Co-Create gives customers a direct path from a real-world challenge to a product improvement. Customers collaborate with us on the problem and solution, and help deliver the change. Unlike a feedback-only model, this puts real workflow context into the product development process. It creates a shorter path from need to value while helping us validate improvements in real conditions and extend their benefits to more GitLab users.

“Over ten years ago, we set out to build code.siemens.com, our internal coding platform based on GitLab, which today serves close to 100,000 people. We’ve run and scaled the platform with a tiny team, guided by a 'for developers, from developers' philosophy. We co-created hundreds of features such as x509/gpg signed commits, protected container/packages, and project and social features such as follow users, allowing us to strengthen the security and collaboration culture at the scale of Siemens.”

— Roger Meier, Distinguished Engineer, Siemens

From a specific need to a shared improvement

Some of the best product improvements start with a specific, real-world need.

GitLab contributors helped us address the following needs:

• Making Scala codebases understandable to Orbit and GitLab Duo
• Giving security administrators a way to enforce Secret Push Protection across an entire instance
• Letting high-throughput teams configure merge train pipeline limits
• Showing the platforms supported by multi-architecture images
• Providing screen reader users with more context on documentation pages

These are different problems, but they have something in common. They are specific enough to solve and important enough that the solution can help more than the person who first raised it.

In the first half of 2026, more than 650 contributors made 4,874 product improvements across more than 100 product groups. These changes included product and CI/CD catalog work. The number matters less than what those changes made possible for users.

Expanding what teams can automate

GitLab users helped us expand the ways teams can connect GitLab to their existing tools and workflows.

The new User Applications REST API lets teams programmatically create, view, update, and delete user-owned OAuth applications. That gives teams a safer way to manage applications for workflows such as dynamically deploying and removing review apps without relying on wildcard redirect URIs.

GitLab users also added SCIM token support to the Token Information API. Identity and access management systems can now identify SCIM tokens through the same API used to inspect other GitLab tokens, making it easier to build accurate automation around token inventory and governance.

New CI_TRACEPARENT and CI_TRACESTATE predefined variables bring W3C Trace Context into CI/CD jobs. Teams can now correlate traces across parent and child pipelines and follow work across distributed systems, making it easier to understand how delivery workflows behave end to end.

These improvements give teams more control over integrations, make automation more capable, and help them operate GitLab as part of a larger engineering system.

Building security and delivery controls

Through Co-Create, our users also helped us expand the controls teams use to protect code and manage delivery at scale.

A team engaged with us to add an instance-level enforcement setting for Secret Push Protection. Administrators can now mandate Secret Push Protection across all projects, giving security teams a consistent way to apply the control across an entire GitLab instance.

Another contributor implemented configurable merge train pipeline limits. Teams can now set limits that match their plan and capacity, giving organizations with high-volume development workflows more control over how changes move through validation and merge.

GitLab users also helped us complete the REST API for Terraform state protection rules. Teams can retrieve, create, update, and delete protection rules programmatically, making it easier to apply infrastructure-as-code governance consistently across projects.

These outcomes give teams more control over security and delivery without forcing them to manage each project manually.

Giving more codebases and workflows useful context

GitLab users also helped us extend what GitLab can understand and show.

A contributor added Scala language support to GitLab Orbit, which indexes your GitLab instance and exposes your software development lifecycle as a queryable property graph. Scala repositories can now produce code-graph definitions for classes, traits, objects, functions, and values, giving GitLab Duo useful context when working with Scala codebases.

Another contributor added supported-platform details to container image indexes. Teams can now see which operating systems and architectures an image supports directly in the container registry, making it easier to select the right image for a target environment.

These improvements broaden the range of codebases GitLab can understand and give teams clearer information when they choose, configure, and operate software.

Making GitLab easier to use for more people

Our contributors also improve the details that determine whether a feature is understandable and accessible in real-world conditions.

They helped us improve API documentation by clarifying tier information for merge request approval endpoints. Developers can now distinguish which endpoints are available on the Free tier and choose the right API for their needs without trial and error.

GitLab users also improved the experience of navigating and reading GitLab. Examples include support for non-Latin heading slugs in non-Markdown markup, more descriptive alternative text for diagrams, a clearer explanation of the period keyboard shortcut for opening the Web IDE, and a PDF export option for Markdown files.

Each improvement removes a different kind of friction. A user can find the right section of a document, a screen reader user gets useful context, a new user discovers a shortcut, and a team can share installation instructions without maintaining a second copy outside the repository.

Accessibility and usability are not separate from product quality. They are product quality, measured in whether more people can understand, navigate, and use the same workflow successfully.

Collaboration extends beyond code

Product changes are only one way to collaborate. The Contributor Platform also supports documentation, translation, project templates, discussions, and events. Translation is a direct product outcome: people help make GitLab available in more languages, and reviewed translations can be included in future GitLab releases. These paths make it easier to improve, understand, and use GitLab.

Build with us

Co-Create can take many forms.

The common thread is shared product impact. It starts with a real need and ends with a clearer, safer, faster, or more capable experience for other GitLab users.

If you have an idea for how to improve GitLab, take action and co-create the solution with us. If you do not have a specific idea but want to help improve GitLab for everyone, pick up an existing issue and help us solve it.

Co-Create supports different ways to collaborate.

• For individuals who want to improve GitLab, use the Contributor Platform to find guidance and useful resources for getting involved.
• For teams and organizations seeking guided, direct collaboration with GitLab, explore a Co-Create engagement.

The path can vary. The outcome is what matters.

OpenAI's newest frontier model GPT-6 Astra is now on GitLab Duo Agent Platform, delivering faster runs and lower token usage.

In GitLab's internal evaluation, GPT-6 Astra finished a typical run 43.4% faster than GPT-5.6 Sol and used 42.7% fewer tokens per run, while completing every task in the benchmark. For your team, that means agentic tasks such as dependency updates, build fixes, and small multi-file changes come back faster, and stretch your token budget across more of your team’s backlog.

Faster agentic work, even on your slowest runs

Wait time factors into how your team uses an agent. A run that comes back in a few minutes is one you stay engaged with. A longer run is one you let work in the background while you move to another task. When it finishes, you switch context from the work you're in, reread what you asked the agent for, and review a diff you last thought about 30 minutes ago.

The longer runs that result in context switching are the ones GPT-6 Astra shortened most in GitLab's internal testing. At the 95th percentile, the slower tail of its runs, GPT-6 Astra finished 49.2% faster than GPT-5.6 Sol, and 43.4% faster on a typical run.

Astra's slowest runs finish in roughly the time Sol needed for an average one. With GPT-6 Astra, your team waits less on high volume, routine work.

Every task finished, at a lower token usage per run

In GitLab's internal testing, GPT-6 Astra completed 100% of benchmark tasks. No run stalled, timed out, or came back empty, so your team isn't left waiting on runs that finish with nothing to review. Astra resolved 63.3% of those tasks, returning a change that passed the benchmark's tests, compared to a 76.7% resolution rate for GPT-5.6 Sol. Misses return as patches to correct rather than runs that produced nothing.

Astra reached its completion rate using 42.7% fewer tokens per run than Sol, measured across the same set of tasks. That savings compounds across a backlog, so your token budget covers more of the work your team delegates.

Where Astra saves your team the most

Many factors go into the model your team chooses to use for a particular task. GPT-6 Astra is a strong choice where turnaround and token consumption per run matter most, such as dependency updates, build fixes, and small multi-file changes. It fits the work your team reviews before it merges, while your team might prefer to use GPT-5.6 Sol when a change has to be right the first time.

With GitLab Duo Agent Platform, your admin sets the model per feature in model selection, so each workload your team sends to an agent runs on the model you chose for it. That flexibility comes with consistent governance, with every model going through the same context layer, policy checks, and audit trail.

Put Astra to work

GPT-6 Astra is available now on GitLab Duo Agent Platform and, like other models, runs on GitLab Credits. New to Duo Agent Platform? Start a free trial today. Already a GitLab Premium or Ultimate subscriber? Turn on Duo Agent Platform and use the GitLab Credits included with your subscription.

For many organizations, the question about AI coding tools isn't whether they help, but where the code goes. Teams under data sovereignty, residency, or regulatory constraints need to know which network handles their source code before they can adopt anything. GitLab Duo Self-Hosted answers that by letting administrators connect GitLab Duo features to models running on infrastructure they choose, with control over hosting, region, network path, and credentials.

In this tutorial, we'll connect GitLab Duo Self-Hosted to models hosted in Microsoft Foundry. Foundry is worth treating as a general-purpose serving platform rather than an OpenAI endpoint: Its catalog spans OpenAI GPT, Anthropic Claude, Meta Llama, and Mistral, and the families GitLab supports overlap heavily with what Foundry offers.

That matters because GitLab lets you assign a model per feature. You can run one family for agentic work, a code-specialized model for Code Suggestions, and a smaller model where request volume dominates, all deployed and billed through one Azure subscription.

The setup steps are the same regardless of family. Only the model you deploy, the deployment name you reference, and the Model family you select in GitLab change.

Microsoft's catalog moves quickly and will contain releases newer than GitLab's supported-model matrix. Catalog availability alone does not establish GitLab Duo support, so always check both vendors' documentation before choosing a model.

Why GitLab Duo Self-Hosted?

GitLab Duo Self-Hosted lets you connect GitLab Duo to models deployed on-premises or through a supported cloud provider. Microsoft Foundry is useful when your organization already operates in Azure and wants to manage model deployments, access, networking, and consumption there.

Key benefits include:

• Deployment choice: Select the Azure region and deployment type that meet your availability and data-residency requirements.
• Multiple model families, one platform: Deploy GPT, Claude, Llama, or Mistral models side by side instead of contracting with each provider separately.
• Feature-level configuration: Assign models to individual GitLab Duo features instead of applying one model globally, mixing families if that suits your workloads.
• Azure integration: Apply Microsoft Entra identity, role-based access control, network isolation, and Azure Policy to your Foundry resources.
• Centralized operations: Monitor model usage and costs alongside your other Azure services.

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. Model endpoints: One or more model deployments exposed through Microsoft Foundry.

A single AI Gateway serves every model you configure, and GitLab decides which deployment to call based on the feature that made the request:

flowchart LR
    subgraph self["Your infrastructure"]
        GL["Self-Managed<br/>GitLab"]
        GW["AI Gateway<br/>(port 5052)"]
    end

    subgraph azure["Your Azure tenant"]
        subgraph foundry["Microsoft Foundry"]
            M1["duo-chat<br/>Agentic Chat, Agent Platform"]
            M2["duo-code-gen<br/>Code generation"]
            M3["duo-code-completion<br/>Code completion"]
        end
    end

    GL -- HTTPS --> GW
    GW --> M1
    GW --> M2
    GW --> M3

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

What leaves your network

This shape of deployment is what makes GitLab Duo workable for teams with data sovereignty obligations, so it's worth being precise about where data travels.

In a fully self-hosted configuration, GitLab's documentation states that inference data — code inputs, model prompts, and model responses — does not leave your network. Requests go from your GitLab instance to your AI Gateway to your Foundry deployment, all within infrastructure you control. GitLab also does not capture which model or model provider you use.

What does leave, on an online license, is billing metadata: an instance ID, a de-identified user ID, a call count, and a timestamp. On an offline license, your instance doesn't connect to GitLab's billing components at all.

Two conditions attach to that:

• It applies only to features backed by your own models. If you route a feature to a GitLab-managed model, that feature's requests go to the GitLab-hosted AI Gateway instead, and the deployment is hybrid rather than fully self-hosted.
• Within Azure, residency depends on deployment type. Data at rest stays in the Azure geography you choose, but where inferencing runs depends on whether you pick a global, data zone, or regional deployment. This is the setting to get right if you have jurisdictional requirements.

Where GitLab support and the Foundry catalog overlap

Choosing a model means satisfying two independent constraints: GitLab must support it, and Foundry must offer it. Neither implies the other.

GitLab rates each supported model against four capability areas: code completion, code generation, GitLab Duo Agentic Chat, and GitLab Duo Agent Platform. These families appear in both GitLab's supported-model table and the Foundry catalog:

Specific version numbers move quickly on both sides, so this post deliberately avoids naming a "best" model. Instead, pick using these rules:

• Simplest path: Choose a current general-purpose GPT model rated full functionality in all four areas.
• Ratings are per feature, not per family: This is a model that is excellent for GitLab Duo Agentic Chat can be rated limited for code completion. Check each feature you plan to enable rather than assuming a family is uniformly strong.
• Newer is not automatically supported: Foundry ships releases ahead of GitLab's matrix, and also carries families such as Grok, DeepSeek, and Phi that are not in GitLab's supported list. Use those only after GitLab adds them, or evaluate them under GitLab's compatible-models beta, which accepts any model exposed through an OpenAI-compatible endpoint.
• Older GPT-4 era models still appear in GitLab's table but are not the best starting point for a new deployment.

Always confirm current ratings in GitLab's supported models page before you commit, and treat any model named in this post as an example rather than a recommendation.

Prerequisites

Before we begin, you'll need:

• A GitLab Premium or Ultimate Self-Managed instance. GitLab Duo Self-Hosted has been generally available since GitLab 17.9, but individual features have their own minimums, and GitLab Duo Agent Platform Self-Hosted requires a considerably later release. Check the feature versions table for the features you plan to enable, and prefer a recent release for current model support.
• The applicable GitLab Duo add-on for your deployment.
• Administrator access to GitLab.
• An Azure subscription with access to Microsoft Foundry.
• Quota for each model you plan to deploy, in a supported Azure region and deployment type. Check region availability for models sold by Azure or models from partners first.
• For partner models such as Claude or Mistral, an Azure subscription eligible for Marketplace purchases and the required Marketplace permissions. Student, free-trial, and credit-only subscriptions are not supported.
• A local AI Gateway installed according to the GitLab installation documentation.

Note: If you aren't a GitLab customer yet, you can start a free trial of GitLab Ultimate.

Implementation steps

1. Deploy one or more models in Microsoft Foundry

Open the Foundry portal, select your project, and deploy your chosen models from the catalog. Model availability varies by region, cloud, and deployment type, and some subscriptions require an approved quota increase.

Before you deploy, confirm your model is offered in the region and deployment type you intend to use. Microsoft publishes this in Region availability for Foundry Models sold by Azure, with separate tabs for standard, provisioned, and batch. Coverage is uneven: a model can be broadly available as Global Standard yet offered in only a handful of regions as Regional Provisioned Managed.

Partner models are more constrained than Azure OpenAI models. Claude, for example, is concentrated in a small number of regions, and deploying it requires accepting Marketplace terms. Verify both region and subscription eligibility before committing to a family.

Give each deployment a name you can trace later. GitLab references the deployment name rather than the catalog model name, so a vague name is hard to audit.

Naming by role rather than by model version, such as duo-chat or duo-code-completion, has a practical advantage: when you upgrade to a newer model, you can point the deployment at it without editing the model identifier in GitLab. Naming by version, such as duo-gpt-5-2, is more explicit but means reconfiguring GitLab on every model change.

If you're starting out, deploy a single model and expand once it works end to end.

After deployment, record these values for each deployment:

• The endpoint URL
• The deployment name
• An API key with access to the deployment

Use a secret-management process approved by your organization. Do not commit the API key to a repository.

2. Install the AI Gateway

The AI Gateway routes requests between GitLab and the selected model endpoint. Install it with Docker or the Helm chart by following the current AI Gateway installation guide.

Avoid copying an old image tag or API-version example from another tutorial. The AI Gateway and GitLab versions should remain compatible, and GitLab's installation guide provides the current image and required settings. The Foundry endpoint and API key are entered when you add each model to GitLab in step 4; they do not need to be embedded in the example Docker command.

One gateway serves every model you configure, so you don't need a separate gateway per deployment or per model family.

3. Configure GitLab to access the AI Gateway

Now that the AI gateway is running, 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 (e.g., https://ai-gateway.example.com:5052).
• Select Save changes.

For production deployments, use TLS and restrict network access to the gateway. If the gateway uses a private IP address or internal hostname, add it to GitLab's outbound-request allowlist.

4. Add each deployment to GitLab

Repeat this procedure once per Foundry deployment you want GitLab to use.

• In the upper-right corner, select Admin.
• In the left sidebar, select GitLab Duo.
• Select Configure models for GitLab Duo.
• Select Add self-hosted model.
• Complete the fields:
  • Deployment name: Enter a recognizable name, such as Agentic Chat on Microsoft Foundry.
  • Model family: Select the family that matches the model, such as GPT or Claude.
  • Endpoint: Enter the endpoint URL from your Foundry deployment.
  • API key: Enter the API key for the deployment.
  • Model identifier: Enter azure/YOUR-DEPLOYMENT-NAME, using the exact deployment name from Foundry. For example, azure/duo-chat.
• Select Add self-hosted model.

The prefix describes how a model is served, not who built it. Foundry can expose non-OpenAI models through the Azure OpenAI endpoint, in which case azure/ still applies. If you deploy a partner model that you reach through a different Foundry endpoint, confirm the correct prefix in GitLab's configuration documentation rather than assuming. A mismatched prefix produces the "Model not found" error described below.

5. Assign models to GitLab Duo features

• In Admin > GitLab Duo, select Configure models for GitLab Duo.
• Select the AI-native features tab.
• For each feature you want to route to Foundry, select a deployment from the dropdown list.

This is where the breadth of the catalog pays off, because features do not have to share one model or even one family. One reasonable split:

• Code completion: a smaller, faster model from the family you chose, where request volume is high and latency is most visible.
• Code generation: a code-specialized model, such as a Codex or Codestral variant.
• GitLab Duo Agentic Chat: a broadly capable general-purpose model. If you don't set a model for an individual chat sub-feature, it inherits the model configured for General Chat in the Admin area.
• GitLab Duo Agent Platform: any model rated full functionality for Agent Platform in GitLab's matrix. Smaller models are often rated lower here than they are for completion and chat.

Treat that split as a starting hypothesis rather than a tuned configuration. Begin with a single model across the features you plan to enable so you have a clean quality, latency, and cost baseline, then introduce a second model only where your own measurements justify it.

Verifying your setup

To ensure that your GitLab Duo Self-Hosted implementation with Microsoft Foundry 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 required GitLab Duo add-on is active.
• 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. Scaffold a FastAPI service with code generation

Code generation is a good first test because it exercises the whole path end to end and produces an unmistakable result. It also sends more context than code completion, so a misconfigured endpoint or an undersized quota shows up immediately.

Code Suggestions has two distinct behaviors, and knowing which one you're triggering matters when you interpret the result:

• Code completion fires as you type and finishes the current line. Low latency, usually under a second.
• Code generation fires when you press Enter after a comment describing what you want. It can return whole functions or classes, and may take more than five seconds.

To scaffold a FastAPI service:

1. Open a project in your IDE and create an empty file, such as main.py. Code generation is more accurate when the file has fewer than five lines, so an empty file is the ideal starting point.
2. Write a comment that names the framework and states the outcome you want:

   # Create a FastAPI service with a health check endpoint and CRUD endpoints for
   # a "tasks" resource backed by an in-memory list. Use Pydantic models for
   # request and response bodies, and return appropriate HTTP status codes.
   

3. Press Enter after the comment. The trailing newline signals that your instructions are complete.
4. Wait for the suggestion, then press Tab to accept it or Esc to reject it.

Naming the framework explicitly is what makes this work. GitLab's guidance for code generation is to state the outcome, stay specific but concise, and name the library or framework you want. A vaguer comment such as # web service gives the model far less to work with.

Two things to expect. Code generation output is capped at roughly 2048 tokens, so you'll get a solid scaffold rather than a finished application. And because these models are non-deterministic, the same comment won't produce identical code twice, which is normal rather than a sign of misconfiguration.

If you assigned different models to different features, test them separately so a failure points at one deployment. Confirming code generation also confirms that the model you mapped to Code generation in Step 5 is the one actually serving the request.

3. Check AI Gateway logs

Review the AI gateway logs to see requests being routed to your Microsoft Foundry deployments:

In your terminal, run:

docker logs gitlab-ai-gateway --tail 100 -f

You should see log entries indicating successful requests to the configured model endpoint. Avoid enabling prompt logging unless your organization's data-handling policy permits it.

Next steps

Here are the next steps to take.

Keep model selection current

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

• Full functionality: The model can likely handle the feature without any loss of quality.
• Partial functionality: The feature works, but there might be compromises or limitations.
• Limited functionality: The model is unsuitable for the feature and might produce significant quality loss or performance issues.

Do not infer compatibility from the model name or from its presence in the Foundry catalog. Use GitLab's models and hardware requirements page as the source of truth for GitLab's current ratings.

Cost optimization strategies:

• Begin with a single model rated full in all four areas across the features you plan to enable.
• Measure quality, latency, token use, rate-limit behavior, and cost with representative workloads.
• Move high-volume features such as code completion to a smaller model once you have confirmed the quality trade-off is acceptable, and check its GitLab Duo Agent Platform rating before reusing it there.
• Consider a code-specialized model for Code Suggestions if generation quality matters more than cost for your teams.
• Review the GitLab support matrix and Microsoft's model-retirement schedule regularly.
• Monitor consumption through Azure Cost Management and configure budgets or alerts appropriate to your organization.

Going beyond Microsoft Foundry

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

1. On-premises with vLLM: Serve a supported or OpenAI API-compatible model on infrastructure you manage.
2. Amazon Bedrock: Similar to Microsoft Foundry, you can use Amazon Bedrock for cloud-hosted models.
3. Other validated providers, including Anthropic, OpenAI, and Gemini Enterprise Agent Platform.

Enterprise integration with Azure

Microsoft Foundry offers unique advantages for organizations already invested in the Azure ecosystem:

• Unified billing: Track model consumption with your other Azure services.
• Microsoft Entra integration: Apply existing identity and role-management practices to Foundry resources.
• Private networking: Evaluate private endpoints and your GitLab-to-Azure network path based on your security architecture.
• Regional deployment: Choose among the regions and deployment types where the selected model is available, keeping in mind the residency distinction described earlier.

These capabilities can support a compliance program, but they do not make a GitLab Duo deployment compliant by themselves. Validate the complete architecture, data flows, logging, retention, contracts, and operational controls against your requirements.

Summary

GitLab Duo Self-Hosted with Microsoft Foundry lets organizations serve GitLab Duo features from Azure-hosted models. Because Foundry's catalog spans GPT, Claude, Llama, and Mistral, and GitLab supports models from each, one Azure subscription can cover the families you need. Start with one broadly capable model, then assign different models to different features as your measurements justify.

Model names in this post are examples, not recommendations. Both catalogs change frequently, so treat the two vendor matrices as the source of truth at the time you deploy.

The durable lesson is to treat model selection as a compatibility decision, not a catalog-shopping exercise. Check GitLab's support matrix, confirm availability and lifecycle status in Microsoft Foundry, deploy the models, and then validate them with your own workloads before broad rollout.

Get started

• Read the GitLab Duo Self-Hosted documentation for the full configuration reference.
• Explore what you can build with the GitLab Duo Agent Platform.
• New to GitLab? Start a free trial of GitLab Ultimate.
• Planning a rollout across teams? Contact a GitLab representative to talk through licensing and architecture.

GitLab's Threat Research Group found a critical sandbox escape vulnerability in vm2, one of the most widely adopted Node.js sandboxing libraries. The vulnerability uses a configuration copied straight from vm2's own README. We found the flaw, rated CVSS 3.1: 10.0, critical, using our own AI automated tools. Anyone running vm2 Version 3.11.6 or earlier with require.external turned on should treat this as directly exploitable.

Once we found the vulnerability, we verified GitLab does not use vm2. We also reported it privately to vm2 and the maintainer fixed it fast, in vm2 Version 3.11.7. When we tested that fix again, it blocked the exact attack we reported.

For anyone relying on vm2, it’s worth flagging that there's a broader configuration risk here that goes beyond this one patch, based on the maintainer's own description of the fix.

TL;DR

Critical vulnerability: GitLab's Threat Research Group discovered a critical sandbox escape (CVSS 3.1: 10.0) in vm2, a widely used Node.js sandboxing library, which allows for remote code execution.

The root cause: The vulnerability stems from default configurations found in the library's own "Quick Examples" README, where the sandbox fails to properly isolate itself from the host system, allowing malicious code to gain unrestricted access.

Fix limitations: While updating to Version 3.11.7 blocks the specific attack reported, it does not fully resolve the underlying configuration risk; developers remain vulnerable if they continue to use require.external with overly broad require.root settings.

Immediate recommendations: Users should update to Version 3.11.7, but must also manually harden their configurations by restricting require.root to only necessary files and setting context: 'sandbox' instead of relying on the default 'host' setting.

Long-term advice: Due to vm2's history of recurring sandbox escape bugs, it is recommended to avoid using it for isolating truly untrusted code and instead opt for more robust methods like containers or separate processes.

Why sandboxing libraries are a high-value target

Apps that run code they don't fully trust (plugin systems, coding playgrounds, CI test runners, and now tools that let an AI run its own generated code) can't just hand that code to Node's normal require() and eval() functions. If they did, the code would have the same power as the app itself.

vm2 is built to close that gap. It gives the untrusted code a fake version of a normal JavaScript environment, and blocks anything that tries to reach the real system underneath. But if an attacker can break out of that sandbox, none of that protection is real, even though it still looks fine to the developer who installed vm2. And because so many apps use vm2, one hole in it becomes a hole in every app built on it.

How the vulnerability works

vm2's NodeVM has a require option that controls whether the sandboxed code can load modules outside JavaScript's built-in ones. Here's the first example from vm2's own README, under "Quick Examples":

const vm = new NodeVM({
  require: { external: true, root: './' },
});

external: true lets the sandboxed code call require() on outside files. root is supposed to limit that to one safe folder. But in a normal npm project, ./node_modules, which includes vm2's own installed copy of itself, sits inside ./. So root: './' looks like a safety rule, but it doesn't actually keep vm2 out.

Two default settings in lib/resolver-compat.js turn that gap into full code execution:

const {
  external: externalOpt,
  root: rootPaths,
  context = 'host',   // defaults to 'host'
  ...
} = options;

isPathAllowed(filename) {
  if (this.rootPaths === undefined) return true;
  // otherwise: is filename inside rootPaths?
}

require('./node_modules/vm2') passes the check, because that path is inside the root. And because context defaults to 'host', the file loads through Node's real, unsandboxed require(), instead of vm2's own loader:

loadJS(vm, mod, filename) {
  if (this.pathContext(filename, 'js') !== 'host') return super.loadJS(vm, mod, filename);
  const m = this.hostRequire(filename);   // real Node.js require()
  mod.exports = vm.readonly(m);
}

At that point the sandboxed code isn't holding a limited, wrapped copy of vm2. It's holding the real thing, with full power. It uses that real copy to start a second NodeVM, with rules it sets itself:

const real = require('./node_modules/vm2');
const inner = new real.NodeVM({ require: { builtin: ['child_process'], external: false } });
module.exports = inner.run(
  "module.exports = require('child_process').execSync('whoami').toString().trim()",
  'inner.js'
);

The outer sandbox's rules don't apply to the inner, because it's a brand new sandbox that the attacker built themselves, with child_process switched on.

If the attacker tries to reach fs or child_process straight from the outer sandbox, that still fails like it should (require('fs') and require('child_process') both throw "Cannot find module"). Every normal block still works. The one gap is requiring a file that happens to be vm2's own package. At that point the attacker isn't holding a blocked, fake copy anymore. They're holding the real one.

vm2 has had two earlier sandbox escape bugs with the same end result: a nesting: true bypass (GHSA-8hg8-63c5-gwmx) and a require.root symlink bypass (GHSA-cp6g-6699-wx9c). Neither fix touches this code. A developer who fixed both of those is still fully open to this one.

Here's the full chain, step by step:

1. The setup. A developer creates the sandbox exactly as shown in vm2's README, under "Quick Examples": new NodeVM({ require: { external: true, root: './' } })..
2. The untrusted code runs. vm.run(untrustedCode) starts executing whatever code the attacker controls.
3. The code requires vm2 itself. It calls require('./node_modules/vm2'). Two things go wrong here, both in resolver-compat.js:
   • isPathAllowed() returns true, because that path sits inside root.
   • context defaults to 'host', so hostRequire() runs instead of vm2's own loader. The result: The attacker's code now holds the real, unwrapped vm2 module, not a sandboxed copy.
4. The code builds a second, unrestricted sandbox. Using that real vm2 module, it creates a new NodeVM with its own settings: new real.NodeVM({ require: { builtin: ['child_process'] } }).. This second sandbox is entirely under the attacker's control.
5. The code runs, unrestricted. inner.run("require('child_process').execSync(...)") executes, and the attacker has arbitrary command execution on the host.

The fix, and what it actually covers

The maintainer confirmed how it works, and folded in a duplicate report we had also filed (GHSA-w9c4-gw9x-53mq), closing it in favor of this one. The fix they shipped, in lib/resolver-compat.js, blocks a sandboxed require() of vm2's own lib/ folder and main file. That closes the nested-VM trick no matter what require.root is set to. It leaves nesting: true alone, since that's a different bug entirely.

That said, the fix is narrower than it might first appear. If you turn on require.external: true with no require.root set at all, vm2 now just prints one warning instead of blocking it, and the code still runs.

But point that same README setup to any other file on disk that exposes child_process, not vm2's own package, and you still get full remote code execution on 3.11.7. No error, no warning:

// evil-helper/index.js, unrelated to vm2
module.exports = require('child_process');

const cp = require('./evil-helper/index.js');
module.exports = cp.execSync('whoami').toString().trim();

That new warning in 3.11.7 only shows up if root is missing entirely. If the root is set but still too wide, which is exactly what the README example does, you get no warning at all. We tested both cases ourselves to check this.

Two more things to know:

• The CLI fix the maintainer shipped alongside this has its own separate advisory (GHSA-jxxv-8r27-vm4p).
• Version 3.11.7 is a combined release that also fixes three other, unrelated bugs.

So, in short: Version 3.11.7 closes this one attack path well. The wider risk, for any app that uses require.external without a strict, empty root folder, is a bigger and more challenging problem that's still worth addressing separately.

Checking your exposure

vm2 has been used inside plugin systems, code-running platforms, and CI tools for years, and more and more inside AI tools that run code an AI model wrote. However you measure it, it's used a lot: about 1.25 million downloads a week and over 5 million a month on npm, plus more than 4,000 GitHub stars and 328 forks.

This isn't a case of someone setting it up wrong. It's the first example in vm2's own README. Any developer who copied that example, without separately working out where node_modules sits relative to root, is affected by default, before and after updating to Version 3.11.7, unless they lock down require.root themselves.

Note that vm2 continues to be vulnerable because of the following characteristics:

• A default setting that looks safe but isn't. root: './' reads like a limit, but whether it actually limits anything depends entirely on what else is sitting in that folder.
• A risky default with no warning next to it. context defaults to 'host', and that fact is buried in plain code comments, unlike nesting: true, which gets a bold warning and its own section in the README.
• A pattern that's easy to miss. An earlier bug reached this same "unrestricted nested VM" result through nesting: true. That fix, and this one, both do a good job closing the specific trick that got reported. The shared root cause behind both is harder to fully close in one pass, and that's a common challenge across vm2's disclosure history: It's had a long string of critical sandbox escape bugs through 2026, and it's understandably taken more than one round to fully address a few of them.

What this means for you

If you use vm2: Update to Version 3.11.7. But don't stop there. Updating alone won't fix this. Point require.root at a folder that only has the files the sandbox actually needs, and keep node_modules and anything that can reach child_process or fs out of it, directly or through another file. Set context: 'sandbox' yourself instead of leaving it on default. And given vm2's track record, don't pick it to isolate truly untrusted code in a new project. Isolating it with containers or separate processes is a stronger wall.

If you build sandboxing tools: A "limit it to this folder" setting is only as safe as the weakest file sitting in that folder. Look just as closely at any setting that changes how code loads (sandboxed vs. real) as you do at settings that change what can load. Test a library's default settings yourself instead of trusting them just because they're official. And don't assume a fix solves the real problem just because it stops your one test attack.

Disclosure timeline

Thanks to the vm2 maintainer for accepting the report and shipping a fix in the same release. What we found above builds on the maintainer's own explanation of the fix. It doesn't go against it.

How GitLab can help

GitLab Duo Security Analyst Agent, part of GitLab Duo Agent Platform, can help you check your codebase for this same problem. A question like "does this project run untrusted code through a sandboxing library with require.external turned on?" is a good place to start.

Looking ahead

vm2's history is a good reminder that even a fast, well-handled fix can leave a broader configuration risk in place, simply because the reported case and the underlying pattern aren't always the same thing. When you look at a sandboxing library's security history, it's worth asking not just whether a report got fixed, but whether the fix covers the wider pattern too. And it's always worth checking the actual code change yourself before telling anyone else it's safe.

Give two engineering teams the same AI tool and you can end up with two very different outcomes. One team ships faster with fewer bugs, while the other gets burned by an agent that confidently generates the wrong output.

At GitLab, our team had AI tools at their fingertips and some found real value fast, working faster and catching issues earlier. Meanwhile, others hadn't quite found an entry point yet to develop effective AI-native workflows.

We learned that building AI fluency — how our team members know what to delegate to AI, how to build the right AI-native processes, and how to judge what comes back — was just as important as AI tool adoption and access. Building that fluency across GitLab was both an operational and technical challenge requiring close partnership between our Enterprise Technology and Talent Development teams.

We’re sharing our internal playbook so other technical leaders gain another perspective on how to encourage the right kinds of AI adoption across their own organizations.

An AI strategy built for the pace of our work

Part of building the right paths for our technical teams was predicated on establishing smart foundational infrastructure. Enterprise Technology considered a few different structures to our governance. The first was a fully centralized team, but we worried that with the speed of AI technology, shipping approvals from one group could end up as a bottleneck. As a result, team members could become impatient and try to circumvent governance infrastructure to experiment with AI. The second was a fully decentralized approach, but that could fragment efforts across the company, which adds complexity and makes guardrail consistency challenging.

We landed on a hybrid model, building governance and enablement into a model that used the best aspects of centralized and decentralized strategies:

• Enterprise AI acts as a central governance and technology hub: Based out of our Enterprise Technology team, Enterprise AI operates as the platform hub, setting standards and security guardrails. They also own the central strategy for our largest AI vendors and homegrown solutions that support governance and control; any other AI tool sits on top of these guardrails.
• AI transformation owners build decentralized, function-specific AI strategy: Each function has an embedded AI Transformation Owner, a senior leader close enough to the work to spot where AI can help automate.
• AI champions evangelize the right adoption and access paths: An AI champions community in each function acts as an in-house center of excellence. This is made up of individuals inside each function that are the first to experiment, support teammates, and help drive the right AI adoption established by the Enterprise AI team and AI Transformation Owners.

"At GitLab, part of what we provide to our customers is Speed with Control. Internally, one of our operating principles is Speed with Quality. Our governance model combined those two — allowing teams to ship quickly, in a high-quality manner that aligns with corporate governance and compliance needs." — Manu Narayan, CIO

The result is a federated model where foundational AI tools are governed centrally, while experimentation and functional strategy develops locally – right where the action happens.

The partnership central to making this work

To make the roles of each group in this model effective, we also needed to understand where our team members were within their AI journey.

Talent Development helped Enterprise Technology make AI access useful and customized. A senior engineer and a new hire do not need the same type of support, so we built a self-assessment tool, the AI Literacy Ladder. This tool identifies where each team member actually stands for AI fluency and recommends a role-specific path forward, including a specific, dedicated learning pathway for engineering.

Engineering pathways center on practical knowledge and workflows: planning, code review, fixing a broken pipeline, and security remediation. Grounding the curriculum in someone’s day-to-day work helps fluency actually stick.

"Our goal wasn't to teach today's tools, it was to build the judgment and durable skills that enable our team members to adapt with confidence as AI keeps evolving." — Rob Allen, Chief People Officer

We paired the AI Literacy Ladder with hands-on upskilling. All-company lessons provided everyone a shared baseline, followed by function-specific sessions. For engineers, we held advanced workshops, including practical labs; 87% of attendees said they learned something they could apply immediately. Across a separate set of non-technical workshops, 95% of participants said they were likely to apply something from the training within two weeks, and 92% reported increased confidence using the AI tool from the workshop.

Based on training feedback, more than 87% of participating engineers confirmed they were likely to apply what they learned in the next two weeks. And a month after we launched the AI Ladders initiative, we saw a 22.3% jump in daily interactions with the primary internal AI coding tool trusted by our engineers.

We measure program impact holistically

To measure success, we watch three core areas for signal:

• Reach tells us how many team members are completing the self-assessment and the pathways.
• Depth tells us whether team members are consistently moving across the pathways.
• Applied value, which is measured through workshop feedback, clarifies whether engineers are finding practical value in training work. We also look at if there’s meaningful growth in tool usage that correlates to the program’s launch.

We evaluate all of these in conjunction with one another, since individually they don't tell the full story. Together, they help us get a clearer picture of if enablement is actually driving fluency and real value as we work through AI transformation.

Lessons to consider as you build your own playbook

You really can’t chase the perfect AI adoption strategy. AI evolves so quickly and interacts with internal culture and processes in distinct ways for every organization. Your adoption strategy needs space to flex as the market continues to shift.

If you’re earlier in this journey, here are six lessons from our own approach that helped build success:

1. Put Enterprise Technology and Talent Development in the same room from day one. Adoption is an operational and behavior change problem as much as a technical one, and neither function solves it alone.
2. Build governance that moves at the pace of AI adoption. New AI tools release weekly, so governance needs to give Enterprise Technology control without slowing down adoption, experimentation, or tool deprecation.
3. Meet people where they are instead of mandating a single curriculum. Team members have different variable rates that they’ll adopt AI at and it’s important to make the curriculum practical to effectively build fluency with late adopters.
4. Treat AI enablement as a living product. The AI tools underneath how your teams work will continue to change. Fluency needs to be continuously supported with resources from Talent Development and Enterprise Technology teams.
5. Teach durable judgment. Using AI tools and functionality is just one small part of the fluency. How and what to delegate to AI, as well as evaluating what it hands back, are just as important.
6. Don’t wait for the perfect enablement strategy. AI moves too quickly to wait for a fully comprehensive strategy. Progress requires stacking small wins and iterating from there.

AI is changing business for everyone and much faster than anyone could have anticipated. We believe in giving our team members the tools and infrastructure to help them adopt and build the fluency needed to navigate work right now. The partnership between our Enterprise Technology and Talent Development teams is at the core of how we’re building that AI-first culture, one rung at a time.

If you're curious about how to build greater AI maturity, GitLab also offers an AI Modernization Assessment to help you accelerate AI-powered development through a personalized AI maturity roadmap. Take the assessment to learn where your organization stands as you continue to build AI-enabled engineering teams.

Every team runs on people who go above and beyond. The engineer who fixes the flaky test nobody else will touch. The reviewer who turns your merge request around in an hour. The teammate who finishes their certification. Or the community member who shows up release after release. Whether your team is a company, an open source project, or a community, GitLab had no built-in way to say "we see you." GitLab Achievements changes that.

What are GitLab Achievements?

An achievement is a custom badge you create once and award to people for their behavior. That might be a contribution, a milestone, or simply getting the most out of GitLab. Each one has a name, a description, and an avatar. Think "First merged MR", "Certified", or "Contributor of the month". Awarded achievements appear on the recipient's profile, alongside their contribution history.

There are two halves to the achievement. The achievement itself is a reusable template you define at the group level. Awarding that achievement to someone is a separate action, and it can carry an optional personal message. That message supports GitLab Flavored Markdown, so you can link straight to the merge request, issue, or event that earned it. The same "Contributor of the month" badge can then tell a different story every time you award it.

Recipients stay in control. An award doesn't appear on anyone's profile until they accept it using a link from an email notification. Recognition is offered, never forced onto someone's profile.

Achievements are generally available as of GitLab 19.2, across Free, Premium, and Ultimate, on GitLab.com, GitLab Self-Managed, and GitLab Dedicated.

Why recognition matters

Recognition is one of the least expensive, most effective tools you have for retention, motivation, and belonging. A visible badge on a profile costs you a minute to award and gives the recipient something lasting. And "team" is broad: It might be your company, your open source project, or your wider community. The value depends entirely on who you are and what you're trying to reinforce.

Internal engineering and platform teams

This is where most teams will start. Reward the people who keep the wheels turning: your fastest reviewers, engineers who complete onboarding or earn a certification, members of a guild or chapter, or the ones who show up during an incident. A badge makes the effort that usually goes unnoticed visible to the whole organization.

Open source maintainers and community programs

This is our own story, and the reason we built the feature. Open source contributors are rarely paid so recognition is often the only reward on offer. It needs to be genuine and visible. Achievements give you a way to celebrate external contributors at scale: Award a "First contribution" badge automatically, or a "Notable contributor" badge each release. Contributors get something concrete to point to, and you get a consistent way to celebrate people behind it.

Ways to use achievements

Here are five ways to use GitLab Achievements.

Identify your team and core contributors

The use case that started it all: Badge your team and core contributors so your community knows who's who. When someone new lands in your project, a glance at profiles tells them who maintains it, who reviews it, and who will field questions. Add a "Hackathon winner" badge and you've turned a one-off event into lasting recognition. Recognition becomes something people can see, not something buried in a changelog.

Reward great reviews and fast turnarounds

We've since expanded our own use internally to recognise great reviews and fast turnarounds. This is the quiet lesson of achievements: You reinforce the behavior you reward. Badge thoughtful reviews, quick responses, or mentoring, and you signal to the whole team what good looks like. It costs nothing and it compounds.

Reward adoption and learning

Recognition isn't only for the people who build GitLab, it works just as well for the people getting the most out of it. Award a badge when someone earns a certification, finishes an enablement path, or adopts a capability your team has been trying to roll out. For customer success and platform teams, this turns dry adoption metrics into something people are proud of. Learning to use a tool well is a contribution, too.

Celebrate milestones and first contributions

Achievements come in three flavors:

• Awarded once and kept forever ("First merged MR")
• Awarded once but revocable ("Core team member")
• Awarded repeatedly ("Contributor of the month")

Use them to mark the moments that matter, a first contribution, a 100th contribution, a hard problem finally solved.

This is where the personal message earns its keep. For a recurring award, attach a message linking to the exact merge request or issue that earned it, with a line on why. The badge stops being a generic sticker and becomes a record of a specific achievement.

Run programs, hackathons, and campaigns

Because achievements can be awarded multiple times and revoked, they suit time-boxed events. Run a hackathon and award a badge to every participant. Run a quarterly contribution drive and award a limited-edition achievement that only that cohort will ever hold. It's a lightweight way to give a campaign a lasting footprint.

How to create and award an achievement

The Achievements documentation covers creating, awarding, accepting, and revoking in full.

Everything is scriptable through the GraphQL API, so you can award in bulk or wire achievements into your own automation. Awarding a "First contribution" badge the moment someone's first merge request merges, for example.

Built by the community, for the community

Achievements didn't come from the core product team. The feature started as a gap that our team, Co-create and Community Engineering, and the wider community set out to fill, captured in Epic #9429. It's the "everyone can contribute" value in action: a feature that lets you recognize contributors was itself co-created by contributors.

Community contributor and Core Team member Niklas van Schrick was key to making it happen. There's a neat symmetry to that. A feature for recognizing contributors, delivered by a contributor, and now we get to recognize him for it. If you've ever wanted to shape GitLab itself, this is proof that you can! Start contributing here.

How AI helped us ship it

Getting Achievements to general availability fell to Mattias Michaux, who had just joined the company, and our team. The feature was part-built and had sat idle for a while, so his first job wasn't writing code, it was working out where the previous effort had got to, what was left to do, and how this corner of an enormous, unfamiliar codebase actually fitted together.

That's usually the slowest part of picking up someone else's half-finished work. This is where GitLab Duo and Orbit came in. Mapping the existing code, understanding what remained, and getting productive quickly. Doing all of that in the time we had simply wouldn't have been feasible without them.

The takeaway isn't about us. It's that these tools collapse the ramp-up cost of a large, unfamiliar codebase whether you're a new hire on your first week or a first-time contributor sending your first merge request. The barrier to contributing has never been lower.

Get started

Recognition works best when it's a habit, not an afterthought. So create your first achievement and award it to someone this week: a reviewer, a mentor, a first-time contributor.

Want to help build the next feature like this one? Start contributing to GitLab. And if you have a use case we haven't thought of, let us know in the Achievements epic.

Compliance is the part of software delivery that everyone agrees is important, yet nobody enjoys. It often lives in spreadsheets, screenshots, and the quiet dread of an upcoming audit. GitLab's custom compliance frameworks work differently. Instead of documenting what should be true about your projects, you define the controls once and let the platform continuously verify what is true.

In this article, you'll learn why compliance adherence matters, how to stand up a SOC 2 framework in minutes using a template, how to monitor adherence on an ongoing basis, how to enforce compliance with policies, and which standards already ship as ready-to-use templates. You'll also get a look at where AI-specific compliance templates are heading. You can watch the video below to see it in action:

Tier note: Compliance frameworks are available in Premium and Ultimate. Framework requirements and controls, the checks that power adherence reporting and the compliance status report, require Ultimate. Everything here applies to GitLab.com, GitLab Self-Managed, and GitLab Dedicated.

Why compliance adherence matters and how custom frameworks help

Regulatory and contractual obligations like SOC 2, ISO 27001, PCI DSS, and FedRAMP exist because customers, partners, and regulators need assurance that your software is built and shipped responsibly. Falling short isn't just a paperwork problem. It can block deals, trigger fines, delay product launches, and erode trust. Compliance also isn't a one-time event. A project that was compliant at audit time can drift the moment someone disables a scanner, removes branch protection, or merges without the required approvals.

Custom compliance frameworks are designed to close that gap. A compliance framework in GitLab is a label you create on a top-level group to identify projects that carry specific compliance obligations or need extra oversight. On its own that label provides organization and visibility. In Ultimate, a framework can also carry requirements made up of controls, which are automated checks against the configuration and behavior of every project the framework is applied to.

Instead of asking an engineer to confirm that static application security testing (SAST) is running, that the default branch is protected, and that merge requests need two approvals, GitLab evaluates those conditions for you on a schedule and whenever relevant project settings change. Compliance stops being a snapshot you assemble before an audit and becomes something you can watch year-round. Frameworks are created on the top-level group and inherited by all subgroups and projects beneath it. You can apply up to 20 frameworks to a single project when it needs to satisfy several standards at once.

This changes the day-to-day effort in a few ways. Compliance moves left into the development workflow, audit preparation becomes a matter of exporting a report rather than reconstructing evidence, and consistency is enforced by the platform rather than by good intentions.

Applying a template to adhere to SOC 2

Building a framework by hand means defining every requirement and every control one at a time. For a standard like SOC 2 that maps to many controls, that's repetitive and error-prone. Templates solve this by giving you a complete, predefined framework, with the name, description, color, requirements, and controls all configured, and that you can adopt in a single step.

The Compliance Adherence Templates project hosts a library of these frameworks as JSON files, and soc2.json is one of them.

There are two ways to get a template into your group.

Option A: Create from a template in the Compliance center

You can create a framework directly from a built-in template without leaving the UI:

1. Go to your top-level group.
2. In the sidetab, select Secure > Compliance center.
3. Click the New framework button.
4. Choose Create from template.
5. Scroll down to the SOC 2 template, and select View details to see the controls the template implements.
6. Press the Use template button to implement the SOC 2 template. customize the name, description, and color if you'd like. Select Next when complete.
7. Preview the included requirements and controls.
8. Apply the framework to the groups/projects that require it.
9. Press the Create framework button.

Your framework is created and will be applied to the groups/projects you selected.

Option B: Import the SOC 2 JSON template

If you're on a GitLab version without the in-product template picker, or you want to keep the template under version control and tweak it first, import the JSON directly:

1. Go to the Compliance Adherence Templates project and download soc2.json.
2. Go to your top-level group.
3. Select Secure > Compliance center.
4. On the Frameworks tab, select New framework, then Import framework.
5. Choose the soc2.json file from your local system.
6. When the import succeeds, the SOC 2 framework appears in your frameworks list.

A framework only does something once it's attached to projects. Make sure you apply this framework to the groups/projects where it will be used.

Note: Imports fail with an Unable to determine the correct upload URL error if a framework with the same name already exists. Rename or remove the existing one first.

Edit and apply the framework to your projects

You can also edit the newly created framework as well as apply it to additional groups/projects:

1. In Secure > Compliance center, open the Frameworks tab.
2. Hover over the SOC 2 framework and select Edit Framework.
3. In the Requirements & Controls section, under Action, select the ... > Edit.
4. Perform any necessary changes to the requirements or controls.
5. In the Scoping section, select the groups/projects that fall under SOC 2.
6. Select Update Framework.

If you want every new project in the group to inherit SOC 2 automatically, set the framework as the group default in the Basic information section. The framework will then be applied to all newly created and imported projects going forward.

What the SOC 2 template actually checks

Once applied, the SOC 2 framework maps GitLab controls to the relevant Trust Services Criteria. A few highlights:

After the framework is applied to a project, GitLab runs a compliance scan and begins reporting on whether each control passes. No manual evidence gathering required.

Continuously viewing compliance status

Applying a framework is only half the value. The other half is knowing, at any moment, where you stand. That's the job of the compliance status report (Ultimate), found in your top-level group under Secure > Compliance center > Status.

The report surfaces the most recent instances where projects do and do not adhere to a framework's controls, so you can spot and close gaps fast. Each row tells you:

• Status: whether a requirement is in or out of compliance
• Requirement: the specific controls in a requirement that failed (for example, "At least two approvals")
• Framework: which framework the control belongs to (for example, SOC 2)
• Project: where the non-adherence was found
• Last Scanned: when the gap was first recorded
• Fix Suggestions: information on how to resolve the issue

You can filter by project, framework, or requirement, jump straight into a project's compliance detail view, and export the whole report (delivered to your inbox as an attachment) when an auditor asks for evidence.

Behind the scenes, scans that refresh the report are triggered automatically when a framework is added to a project, when an associated framework's requirements change, and on a recurring 12-hour schedule. Results typically appear five to ten minutes after a scan runs. This means compliance drift becomes visible within hours rather than at the next annual audit. To view the report, you'll need to be an administrator, or have the Security Manager or Owner role for the group.

Adhering to compliance via policies

Reporting tells you when something is wrong. Policies stop the wrong thing from happening in the first place. This is where compliance frameworks move from observation to enforcement, and it's an Ultimate capability tied to the framework label.

A compliance framework can act as the scope for Security policies. Scan execution policies, Pipeline execution policies, and merge request approval policies can be scoped to a compliance framework, so every project carrying that label automatically inherits them. For example, you can require that SAST, secret detection, and dependency scanning run on the default branch, and require approval from a designated security team before a merge request that introduces new critical vulnerabilities can be merged. Because the policy is bound to the framework rather than to individual projects, adding a new project to the framework instantly brings it under the same guardrails.

The pieces work together. The framework defines the obligation, controls and the status report measure adherence, and policies and compliance pipelines enforce the behavior. You're not just documenting that SOC 2 requires two approvals and running scanners. You're making it difficult to ship anything that violates those requirements. When a control fails, the status report flags it. When a policy is in place, the non-compliant change is blocked before it merges.

Available templates

GitLab ships a growing library of predefined framework templates in the Compliance Adherence Templates project, each mapping a recognized standard to GitLab controls. As of publication, these include:

Each template's exact requirement-to-control mapping is documented in the compliance standards reference. You can import any of them as-is, or use them as a starting point. Export a framework as JSON, adjust the requirements and controls to match your organization's interpretation of a standard, and re-import. The JSON schema is straightforward. A framework has a name, description, color, and an array of requirements, each with its own controls and evaluation expression. That makes templates easy to keep in version control and share across groups.

A look ahead: AI-specific compliance templates

The compliance standards covered today were largely written for traditional software. As organizations embed AI into their products and their own development workflows, a new class of obligations is emerging around governing how AI systems are built, approved, and monitored. Examples include the EU AI Act, ISO/IEC 42001, and the NIST AI Risk Management Framework.

GitLab is exploring AI governance compliance templates (Epic #16808, with planning tracked in Work item #22336) to extend the same template-driven model into this space. The intent is to let teams adopt an AI-governance framework as easily as they adopt SOC 2 today, with predefined requirements and controls that map to AI-specific obligations, applied to the projects that build or deploy AI capabilities, and surfaced through the same compliance status report.

It's worth keeping one distinction in mind. Compliance is the state of meeting a defined set of requirements, while governance is the ongoing capability to keep AI systems compliant as both the systems and the rules evolve. GitLab's broader direction pairs AI-assisted detection with human-in-the-loop approval and auditable, policy-based enforcement, so AI findings inform decisions but accountable humans and measurable controls still gate what ships. AI-specific templates would be the onramp, giving you a fast way to encode emerging AI requirements into the same framework, control, status report, and policy machinery you're already using for everything else.

Summary

Custom compliance frameworks let you define your obligations once and have GitLab continuously verify them. Templates take the manual setup out of getting started, so a SOC 2 framework is a few clicks or a single JSON import away. The compliance status report keeps adherence visible on a 12-hour cadence, and security policies plus compliance pipelines turn that visibility into enforcement. With a library of standards already available and AI-specific templates on the horizon, the path from "we should be compliant" to "we can prove we are, continuously" is shorter than it's ever been.

Learn more with our compliance frameworks documentation and try the custom compliance frameworks click-through demo.

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 these statements are reasonable, they are subject to known and unknown risks, uncertainties, assumptions and other factors that may cause actual results or outcomes to differ materially. Further information on these risks and other factors is included under the caption "Risk Factors" in our filings with the SEC. We do not undertake any obligation to update or revise these statements after the date of this blog post, except as required by law.

The industry is now racing to rebuild source code management for agents. We showed our answer at GitLab Transcend, but let’s reiterate why rebuilding the Git backend is only half the problem.

Three things break when agents become the primary users of a Git server. Every developer running hundreds of agents hits the same wall, regardless of tools:

• The clone tax. An agent clones an entire repository to read a single file, then does it again for the next agent, and the next retry, transferring far more data than the task requires and burning context on a local grep or blame it shouldn't have needed to run. One agent invocation today can mean 5GB to 10GB transferred and 30+ seconds of setup, just to answer a single question.
• Concurrency collapse. Thousands of sessions hit a backend that was originally designed for human scale, producing bottlenecks and unpredictable availability.
• No isolation. Agents share accounts and one branch space, so they overwhelm the repository, leave no clean way to discard abandoned work, and keep no record of which agent did what.

Our platform data shows how fast the pressure is building. Over the past year, our customers created 40% more CI/CD pipelines, and code pushes to GitLab.com were up 50%. While the secure repositories grew by 60%, codebase sizes have also grown by up to 500%.

When we announced next-generation source code management (next-gen SCM) at GitLab Transcend in June, we walked through how Git, as an operational model, was not designed for the load agents placed on it. A few weeks later, new entrants, including Git hosts built specifically for agent-scale concurrency, are validating that claim independently. That convergence sharpens why rebuilding the Git backend is necessary, but on its own, it’s still not enough.

What we’re building for agent scale

Next-gen SCM runs on the Git protocol for backward compatibility, with a redesigned backend and interfaces built for agents. Instead of cloning a full working tree, agents query the repository server-side for exactly what a task requires, with each agent limited to the minimum visibility its task needs. It’s the same Git compatibility and auditability with a different motor underneath.

The architecture separates an intelligence layer (routing, caching, background work) from elastic compute that scales on demand and elastic object storage. Purpose-built read and write APIs let agents retrieve file, blame, and history data and commit changes without pulling the whole repository. Developers can run agents on any repo, fan them out by the thousands, and let them experiment safely. In practice, that means an agent gets a single batch-read instead of a full clone, a diff-stat request instead of clone-then-diff, and a last-commit-for-path lookup instead of clone-then-blame.

This isn't designed for cloud-only. The compute and storage tiers talk to each other over the standard S3 API, so the same architecture that runs on GitLab.com runs on a customer's own infrastructure, whether that's a major cloud provider's object storage or a self-hosted, S3-compatible system running in a customer's own data center. For air-gapped, regulated, and sovereignty-constrained environments, that means the same horizontal scaling and consistency guarantees, without repository data ever leaving infrastructure the customer controls.

In early internal testing, agents running against next-gen SCM showed:

• Up to 50x faster wall-clock time
• Up to 2x fewer tokens
• Up to 1,000x less network traffic

These are ceilings, not guarantees, measured under our own testing conditions. The workload that actually stresses a Git backend at agent scale is concurrent reads and writes from many independent agents against the same repositories, sustained under load — so a number only means something if the test runs close to that target, the load generator isn't the bottleneck, and the full latency distribution is reported rather than a single best case.

We hold our own results to that bar, and we'd encourage anyone evaluating this category to ask the same three questions of every number they're shown, including ours. That bar is built into the architecture itself, not only our test conditions. Storage maintenance compacts small artifacts into larger, frozen ones on a geometric schedule, which puts a hard ceiling on how much data any node has to fetch to catch up to the latest snapshot. With a 1GB freeze threshold and a 2x compaction ratio, that ceiling is 2GB, regardless of how large the repository has grown.

Next-generation source code management is now in private beta, and here it is in action:

Rebuilding the backend is half the problem

The new entrants are building Git hosts: standalone destinations, or fast mirrors that sit in front of an existing host to absorb read traffic. That solves concurrency, and concurrency is a real problem. But it leaves two questions unanswered, and both are central to how we think about GitLab’s agentic infrastructure.

The first is provenance. When agents push code, touch dependencies, and trigger deployments by the hundreds, the operative question stops being “did we scan?” and becomes “which agent did what, under which policy, and can we prove it?” Our agent APIs attribute every agent action to a specific workflow, model, and token. Every agent operation is routed through the same project authorization and role-scoped human-in-the-loop controls that already govern human contributors. Attribution and policy are platform properties, not repository features, so a standalone Git host isn't built to answer this natively.

The second is what happens to the work after it succeeds. A successful agent experiment lives on a standalone host. On GitLab, next-gen SCM is a Git backend inside a platform that already runs CI, policy management, governance controls, and audit of the resulting code. When an agent's ephemeral experiment works, it graduates directly into a governed, observable production pipeline, without requiring a separate platform or destination.

Next-gen SCM handles execution at agent scale. GitLab Orbit gives every agent and human context on the full software lifecycle as a knowledge graph, and GitLab Duo Agent Platform orchestrates governance and security around every agent action — so agents plan and carry out work across the full lifecycle, not just the Git operations. A faster Git backend hosts the code agents generate. Paired with GitLab's governance, lifecycle context, and orchestration, that code ships through the same CI, policy, and audit path as everything else in the platform.

Every enterprise will hit this wall

Every customer will use agents for coding, and every customer running them at scale will run into the same limits described above, regardless of which models or tools they standardize on. That's what makes this an evolution within the infrastructure layer. The teams that move fastest in the agentic era will be the ones who can host, govern, and absorb agent output back into a lifecycle that was already built to ship trusted software.

Get started

Next-generation source code management is in private beta. Request early access today!