GitLab 19.5 makes MCP server and Secrets Manager generally available

MCP server opens GitLab tools to external agents

According to GitLab, MCP clients could previously reach only a limited set of GitLab tools. With the MCP server now generally available, any MCP-compatible agent, such as Claude Code or Cursor, gets direct access to the expanded GitLab catalog of tools, as well as to GitLab Duo Agent Platform agents and flows.

GitLab says this lets agents work across more of a team's GitLab workflow and run Agent Platform agents and flows without leaving the preferred tool. The feature is available in the Free, Premium and Ultimate tiers on GitLab.com, GitLab Self-Managed and GitLab Dedicated.

GitLab 19.5 also lets administrators on GitLab Self-Managed and GitLab Dedicated pick any subgroup, not just top-level groups, in the Restrict access based on group membership setting for GitLab Duo. Direct members of the selected subgroup get access. GitLab says this makes it easier to run a pilot or roll out access one division at a time, particularly for organizations with a single top-level group.

Secrets Manager and AI governance

GitLab Secrets Manager is now generally available on GitLab.com and GitLab Self-Managed for the Premium and Ultimate tiers. GitLab argues that without a centralized secrets store, credentials can end up scattered across over-scoped CI/CD variables, local config files and standalone vaults, which makes them harder to manage, protect and audit.

The feature is built on OpenBao and uses existing group and project permissions, so no separate access model is needed. Each CI secret is scoped to the job that needs it, based on environment, branch and branch protection rules. Audit logs are generated for every create, read, update and delete. GitLab Secrets Manager consumes GitLab Credits, and a free 30-day trial is available.

On the governance side, the AI Governance Dashboard previously showed activity only from GitLab Duo Agent Platform agents. After a one-time glab govern setup, teams can now connect Externally Connected Agents (ECAs) such as Claude Code, Cursor and Codex through the GitLab CLI. When Allow external agents and Store AI audit events are enabled, every qualifying agent session is captured, including who ran it, which agent, which project and when. Sessions and tool calls appear in the dashboard and the AI audit events report, and audit events can flow to a SIEM through audit event streaming. Tool output is not sent, except for short error messages from failed tool calls. This feature is in beta.

New GitLab Duo CLI and review capabilities

The /goal command in GitLab Duo CLI is generally available in version 9.27.0. Users describe an open-ended goal, and GitLab Duo hands it to a governed, goal-driven flow that runs locally and handles both implementation and verification. It requires GitLab 19.3 or later and GitLab Duo CLI 9.17.0 or later.

The CLI also gains an auto mode, in which GitLab Duo uses tools without asking for approval first, so longer tasks are not interrupted by each shell command, git operation or MCP tool call. It is off by default. Administrators, Owners and Maintainers can enable it for instances, groups and projects, and Administrators and group Owners can lock it to Always off. Tools set to Always Deny stay blocked. GitLab advises using auto mode only in trusted repositories and on branches that can be discarded. It requires GitLab Duo CLI 9.22.0 or later.

Organizations can now configure the CLI with settings files. System administrators can deploy a managed settings file through a mobile device management tool or group policy, and its settings take precedence over the user settings file, command-line options and environment variables. The settings file requires CLI 9.26.0 or later, and the managed file requires 9.27.0 or later.

Code Review Flow now handles follow-up reviews. GitLab Duo uses comment threads from earlier reviews, including user replies, focuses on lines added after its last review, avoids repeating points it already raised and lists outstanding findings in its summary.

Security tracking and what it means for teams

Non-default branch tracking is now generally available for the Ultimate tier. Teams can track three additional branches or tags on the security configuration page, filter by tracked ref on the vulnerability report and by branch on the project-level security dashboard, and update vulnerability status on tracked branches. Vulnerability management policies evaluate each tracked branch separately. GitLab recommends targeting a small number of long-lived release branches.

Taken together, the release gives teams that use external coding agents a way to connect them to GitLab tools and to oversee their activity, while giving administrators more control over who can use GitLab Duo and how the CLI behaves. The release notes also name Dhairya, a Level 3 contributor, as this month's Notable Contributor for work on offline transfer and Organizations support for import.