GitLab 19.5 Makes Agentic Development a Governed Part of the DevOps Platform

GitLab 19.5, released on October 15, puts agentic software development and governance at the centre of the platform, making its GitLab MCP server generally available while expanding how external AI agents can interact with GitLab.

The release allows MCP-compatible tools such as Claude Code and Cursor to access GitLab's broader tool catalogue and invoke GitLab Duo Agent Platform agents and flows. At the same time, GitLab is adding controls for governing those external agents, giving security teams visibility into which agents are being used, by whom, and against which projects.

The generally available GitLab MCP server provides agents with access to GitLab capabilities through the Model Context Protocol. New tools allow agents to discover groups, inspect individual CI/CD artifact files, and start or monitor GitLab Duo agents and flows. Administrators can also select which MCP toolsets are exposed, reducing unnecessary tools and the context they consume.

Giving an agent every available tool increases both context consumption and the number of actions the model could potentially take. Toolset selection provides a relatively simple form of least-privilege agent design.

GitLab.com also introduces MCP rate limits of 60 requests per minute for Free users and 600 for Premium and Ultimate users, with reconnects and retries counting towards the limit.

One of the more significant additions is the ability to bring Externally Connected Agents into GitLab's AI Governance capabilities.

Previously, the AI Governance Dashboard focused on GitLab Duo Agent Platform agents. GitLab 19.5 allows tools such as Claude Code, Cursor, and Codex to be connected through the GitLab CLI. Once configured, organisations can record qualifying agent sessions, including the user, agent, project, and timing, with activity appearing alongside GitLab's own agents. Audit events can also be streamed to a SIEM.

This is an important step beyond simply providing an MCP endpoint. Connectivity creates capability; governance determines whether that capability can be safely used at organisational scale.

GitLab Duo CLI also gains an auto mode, allowing agents to execute tools without requesting approval for every shell command, Git operation, or MCP call. The feature is disabled by default and can be controlled at instance, group, and project levels, while tools explicitly marked Always Deny remain blocked.

The /goal command is also now generally available, allowing developers to describe an open-ended objective and have GitLab Duo delegate implementation and verification to a governed flow.

Together, these features move GitLab closer to an agent operating model in which developers provide intent while agents execute multiple steps across the development environment.

That makes the governance controls increasingly important: the more autonomous the agent becomes, the less practical it is to rely on a human approving every individual action.

The release also makes GitLab Secrets Manager generally available. Built on OpenBao, it integrates with existing GitLab group and project permissions, scopes secrets to the jobs that require them, and generates audit events for secret operations.

GitLab is also expanding security configuration profiles, allowing organisations to centrally customise settings such as excluded paths, analyzer images and full-history scans for Secret Detection and SAST rather than repeating configuration in every project's CI/CD file.

These changes complement the agent features by strengthening the controls around the repositories, credentials, and pipelines that agents may access.

GitLab's direction increasingly resembles GitHub's strategy of turning coding agents into participants in the software lifecycle, but GitLab is placing particular emphasis on connecting external agents to its existing DevSecOps governance model.

GitHub's ecosystem benefits from the reach of GitHub Copilot and coding agents, while tools such as Cursor and Claude Code focus more heavily on the developer's local environment. GitLab's MCP approach instead attempts to make the DevOps platform itself agent-accessible, including repositories, issues, pipelines, artifacts, and GitLab-native agents.

The competitive question GitLab is looking at is moving beyond which coding assistant generates better code to which platform provides the safest and most useful environment for autonomous agents to perform engineering work.