{"slug": "gitlab-19-1-release-notes", "title": "GitLab 19.1 release notes", "summary": "GitLab released version 19.1 on June 18, 2026, introducing AI-powered false positive detection for secret scanning, mandatory GitLab Duo enablement for enterprise governance, automatic code owner reviewer assignment, compliance framework templates, and full-commit secret detection. The update also adds tool-level approval policies for GitLab Duo agents.", "body_md": "On June 18, 2026, GitLab 19.1 was released with the following features.\n\nWe’d also like to announce this month’s [Notable Contributor](https://contributors.gitlab.com/notable-contributors): Pishel65!\n\nWe are excited to recognize [Pishel65](https://gitlab.com/pishel65), a Level 3 contributor with 19 merged MRs and 9 more open since joining in October 2025.\n\nSecret false positive detection with the GitLab Duo Agent Platform is now generally available.\n\nSecurity teams spend significant time investigating secret detection findings that are incorrectly flagged as actual secrets. These false positives create alert fatigue, erode trust in scan results, and divert attention from genuine security risks.\n\nWhen a security scan runs, GitLab Duo automatically analyzes each critical and high severity secret detection vulnerability to determine if it is a false positive. The AI assessment appears in the vulnerability report, so you have immediate context for faster and more confident triage decisions.\n\nKey features include:\n\nWe welcome your feedback in [issue 592861](https://gitlab.com/gitlab-org/gitlab/-/issues/592861).\n\nAdministrators can now set GitLab Duo to be always on for all projects in an entire instance or top-level group. When GitLab Duo is set to always on, group, subgroup, and project owners cannot turn off GitLab Duo, giving enterprises centralized AI governance for compliance and regulated environments.\n\nThis new setting is symmetrical to the existing [always off](https://docs.gitlab.com/user/gitlab_duo/turn_on_off/) setting, closing a gap where GitLab Duo could\nbe locked off but could not be locked on. This new setting is especially valuable for organizations with autonomous divisions or subsidiaries that\nneed to guarantee consistent AI tooling across the business.\n\nTo set GitLab Duo to be always on, go the instance or top-level group GitLab Duo settings and set **GitLab Duo availability** to **Always on**.\n\nPreviously, you needed to select reviewers for each merge request manually,\neven when a `CODEOWNERS`\n\nfile already defined who should review each file.\n\nYou can now configure a project to assign Code Owners as reviewers automatically. GitLab assigns every Code Owner that matches the changed files. This happens when a merge request is created in a ready state, or when a draft is marked ready. If you already assigned a reviewer, GitLab skips automatic assignment and keeps your choice.\n\nTo turn on automatic reviewer assignment, go to **Settings** > **Merge requests** >\n**Automatic reviewer assignment** and select **Automatically assign all code owners as\nreviewers**.\n\nYou can now create compliance frameworks from predefined templates.\n\nPreviously, building a compliance framework required defining every requirement and control by hand, a repetitive process when a framework had dozens of controls.\n\nNow, when you create a new framework in the Compliance center, you can:\n\n19 templates are available, including ISO 27001:2022, SOC 2, FedRAMP, NIST, CIS, TISAX, and more.\n\nIn GitLab versions earlier than 19.1, you couldn’t trust a feature branch pipeline to surface every secret in your branch. A new branch scanned only the latest commit. An existing branch scanned only your most recent push. A credential leaked in an earlier commit could sit undetected, reaching shared branches or production before being flagged.\n\nNow you can catch those secrets where they’re cheapest to fix. In GitLab 19.1, secret detection scans every commit from the branch’s divergence point with the default branch to the latest commit. That means fewer secrets slip through to later stages, less time rotating exposed credentials after the fact, and consistent, predictable coverage across your branches.\n\nAdministrators can now configure tool-level approval policies for GitLab Duo agents, gating sensitive actions with human approval at the moment of execution.\n\nPreviously, after an AI agent was approved for a project, it could invoke any of its tools without further review, including write and destructive operations. Now, you can define rules for groups and projects that map each tool to one of three modes:\n\nWhen an AI agent calls a tool in “ask” mode, the user is prompted with an inline approval card before execution proceeds.\n\nThis beta release includes Agentic Chat, IDE, and flows, and emits audit events for every approval decision.\n\nAdministrators and top-level group Owners can now control which AI agents and flows are available within their organization. They can:\n\nThe AI Catalog now validates your custom flow configuration before saving or triggering it.\n\nPreviously, syntax errors and misconfigured parameters in a custom flow (for example, missing inputs or unknown tool parameters) only surfaced at runtime, after a CI job had already started. This made debugging slow and difficult.\n\nNow, when you save or update a custom flow in the AI Catalog, GitLab checks the configuration upfront and surfaces any errors directly in the UI. Valid flows are unaffected and continue to save and trigger as usual.\n\nPreviously, when Agentic Chat asked you to approve a tool invocation, you could approve it once or approve the tool call with these arguments for the remainder of the session. Different arguments would require additional approval.\n\nWorkflows that repeated similar\ncommands, such as a series of `git`\n\noperations, forced you through a stream of nearly\nidentical prompts.\n\nYou can now choose a third approval option, **Approve all uses of this tool for\nsession**. This option approves invocations of the tool for the remainder of the session whenever the arguments match the approved pattern.\n\nPattern-based approvals are available for Agentic Chat in the GitLab UI, GitLab Duo CLI, GitLab for VS Code, and the GitLab Duo plugin for JetBrains IDEs.\n\nAutomatic reviews in Code Review Flow are now turned on by default for new GitLab Duo trial customers on GitLab.com, so you can start getting AI-powered feedback on your merge requests from day one — without any manual setup.\n\nWith a new flat pricing model, you get immediate value from smarter, faster code reviews right out of the box. If needed, you can opt out in your group settings.\n\nGitLab Duo health checks now include foundational flows readiness checks, which verify:\n\n`gitlab--duo`\n\ntag is registered and\nconnected, and uses a Docker-compatible executor.In previous versions of GitLab, Code Review Flow supported only Anthropic Claude models. Teams that could not use Anthropic models due to contractual, policy, or procurement constraints had no way to run Code Review Flow.\n\nYou can now select GPT-5.2 or GPT-5.3 Codex as the model for Code Review Flow. Top-level\ngroup Owners can switch the model for **Agentic Code Review** in **Settings** > **GitLab Duo** > **Configure features**, under **GitLab Duo Agent Platform**.\nThe GPT models are hosted through the GitLab AI Gateway, so no additional configuration\nis required.\n\nBoth models passed benchmark evaluation against the GitLab Duo code review dataset, with review quality\ncomparable to the default Claude Sonnet 4.6 Vertex model. See the\n[code review benchmark](https://duo-review-bench-6f7260.gitlab.io/) for results.\n\nFor GitLab Duo Agentic Chat, you can now configure an allowlist of approved models, and set an organization-wide default, if you are:\n\nThis gives organizations control over which models users can select when using Agentic Chat.\n\nIn previous versions of GitLab, you could only run flows and external agents when the service account was mentioned, assigned, or added as a reviewer. Coordinating automation around the rest of the merge request lifecycle, or around work item creation, required external glue.\n\nYou can now configure triggers for four additional events:\n\nTo configure a trigger, go to **AI** > **Triggers** in your project, or select one when you enable a flow.\n\nYou can now use the Scanner Enablement Wizard to close scanner coverage gaps across your projects without manually identifying which projects need attention.\n\nSecurity configuration profiles define which scanners run and how. Security inventory shows scanner coverage across your projects and lets you bulk-apply profiles to selected projects or subgroups. The wizard adds a goal-driven workflow on top: you set the goal, and it finds the projects missing coverage and closes only those gaps.\n\nBy default, OAuth access tokens in GitLab expire after two hours. In GitLab 19.1, instance administrators on GitLab Self-Managed and GitLab Dedicated can set a custom lifetime for new OAuth access tokens. You can configure any value from 300 to 7200 seconds. This helps you enforce shorter-lived tokens for security-sensitive OAuth integrations, including MCP clients, without changing the behavior of existing tokens.\n\nYou can now add emoji reactions directly to wiki pages in both project and group wikis.\n\nUse the GitLab emoji picker to react to page content. Each page shows reaction counts and who reacted. Reactions persist across page edits and versions.\n\nScheduled pipeline execution policies are now available as a beta feature and no longer require an experiment flag to enable. You can enforce custom CI/CD jobs on a daily, weekly, or monthly cadence across your projects, independent of commit activity. Use scheduled policies to run compliance scripts, security scans, or dependency checks on repositories that may not have regular code changes.\n\nScheduled policies now enforce variable precedence consistently with regular pipeline execution policies. Each security policy project supports up to five scheduled policies, and GitLab automatically cancels running pipelines when a policy is disabled or deleted. Configure schedules in YAML or the UI, with time zone support, time window distribution, branch targeting, and snooze functionality.\n\nThe Security Manager role is now generally available, providing comprehensive access to security features including vulnerability management, security dashboards, policy configuration, and compliance tools. Security teams no longer need the Developer role or the Maintainer role to access security features, eliminating over-privileging concerns while maintaining separation of duties.\n\nUsers with the Security Manager role have the following access:\n\nTo get started, go to a group and select **Manage > Members** to invite and assign members to the Security Manager role.\n\nYou can now use security findings from any SARIF 2.1.0-compliant scanner with GitLab vulnerability management.\n\nDefine a CI/CD job that runs your scanner and outputs a SARIF artifact. GitLab parses, validates, and imports those findings into your security workflows. Results appear alongside GitLab native scanner output in the pipeline security tab, the vulnerability report, the security dashboard, the merge request security widget, and security policies. This feature gives security teams a single, consolidated view of vulnerabilities regardless of which tool produced them.\n\nGitLab assigns each finding a report type based on its identifiers, mapping results into categories such as `SAST`\n\n, `dependency scanning`\n\n, and `secret detection`\n\n. Supported scanners include Semgrep and Checkmarx for SAST, Trivy and Snyk for dependency and container scanning, and Gitleaks for secret detection.\n\nWiki pages now appear in your recently viewed items, so you can return to pages you visit often.\n\nOn the GitLab homepage, the **Quick access** widget lists recently viewed project and\ngroup wiki pages, alongside issues, merge requests, and epics. GitLab automatically\nremoves pages that are deleted or that you can no longer access.\n\nIn GitLab 19.1, the vulnerability results details page uses consistent, descriptive, and security industry-standard terminology for scan results:\n\nIn GitLab 18.10, audit logs began capturing the specific Git operation performed (clone, pull, fetch, or push) for human users.\n\nIn GitLab 19.1, this extended to all actor types, including runners using deploy tokens and SSH certificate users. Audit logs now reflect a complete picture of all Git activity across your repositories, regardless of who or what initiated it.\n\nPreviously, viewing blame information required navigating to a separate page, breaking your flow when reviewing code.\n\nYou can now toggle blame information directly in the file view. Each line\nshows who last modified it, and you can hover for a commit popover with\nadditional details. Select **View blame prior to this change** to trace history\nfurther, or select **Ignore specific revisions** to exclude specific commits from\nthe blame view.\n\nPreviously, the repository commit list had limited filtering, making it harder to find specific commits in long histories.\n\nThe redesigned commit list includes:\n\nPreviously, when you split a large change into smaller merge requests that build on each other, the UI gave no signal that they were related. Authors and reviewers had to track the sequence manually.\n\nGitLab now detects stacked merge requests automatically and shows them in the merge request\nheader. A merge request joins a stack when it targets another open merge request’s source branch,\nor when another open merge request targets its source branch. The stack control next to the source\nbranch shows the current position (for example, **1 of 2**) and lets you jump to any other merge\nrequest in the stack.\n\nTo create stacked merge requests from the command line, use stacked diffs in the GitLab CLI.\n\nYou can now stream AI audit events to external destinations through the GitLab audit event streaming infrastructure, giving security and compliance teams real-time visibility into LLM and AI interactions.\n\nWith AI audit event streaming enabled, GitLab forwards these events to any active instance streaming destination, including your SIEM (Security Information and Event Management), alongside other audit events.", "url": "https://wpnews.pro/news/gitlab-19-1-release-notes", "canonical_source": "https://docs.gitlab.com/releases/19/gitlab-19-1-released/", "published_at": "2026-06-18 00:00:00+00:00", "updated_at": "2026-06-18 16:42:56.012855+00:00", "lang": "en", "topics": ["ai-tools", "ai-policy", "developer-tools"], "entities": ["GitLab", "GitLab Duo", "Pishel65", "ISO 27001:2022", "SOC 2", "FedRAMP", "NIST", "CIS"], "alternates": {"html": "https://wpnews.pro/news/gitlab-19-1-release-notes", "markdown": "https://wpnews.pro/news/gitlab-19-1-release-notes.md", "text": "https://wpnews.pro/news/gitlab-19-1-release-notes.txt", "jsonld": "https://wpnews.pro/news/gitlab-19-1-release-notes.jsonld"}}