AI NewsDev toolsAnnouncement

GitLab 19.5 turns on MCP server and governance for outside coding agents

GitLab 19.5 made its MCP server generally available. Security teams can now record outside coding agent sessions.

AI News

Editorial2 min read

LinkedInX
GitLab 19.5 header image from InfoQ showing the GitLab branding.

Image: InfoQ

Why it mattersA security team can now see which outside coding agents ran against which project. The audit trail is the thing a buyer has been missing.

An engineering team can hand a coding agent access to its repositories in a minute. The audit trail is the hard part. It proves which agent did what, on whose account, against which project. GitLab 19.5 fills that gap.

GitLab says the MCP server is now generally available. It runs on GitLab.com, GitLab Self-Managed and GitLab Dedicated. It covers the Free, Premium and Ultimate tiers. An MCP-compatible agent can call GitLab's tool catalog through it. The agent can also start GitLab Duo Agent Platform agents and flows without leaving the editor. GitLab's own notes say administrators can pick which MCP toolsets are exposed. A model does not see every tool by default.

The rate limits and the price of a reconnect

GitLab.com now limits the MCP server to 60 requests a minute on the Free tier. The Premium and Ultimate tiers get 600. GitLab says every reconnect and retry counts toward that limit. A misconfigured client opens a new connection on each call. It can exhaust the budget without doing any useful work. The response is HTTP 429. GitLab's own advice is to check the agent's reconnect and retry settings first. Only then should a team pay for a higher tier.

Outside agents land in the governance dashboard

Before 19.5, the AI Governance Dashboard showed sessions only from GitLab Duo Agent Platform agents. Claude Code, Cursor and Codex ran against a GitLab project from the developer's own machine. The security team saw the merge requests. It did not see the agent calls behind them.

GitLab 19.5 adds Externally Connected Agents to the dashboard. It takes a one-time glab govern setup on the GitLab CLI. The server can then record qualifying sessions from those agents. The record covers who ran it, which agent, which project, which tool calls, and when. Audit events stream to a SIEM through GitLab's existing audit event streaming. Tool output is not sent. Short error messages from failed calls are the one exception. GitLab marks the feature as beta.

The two other items a security team will notice

GitLab Secrets Manager is now generally available on GitLab.com and GitLab Self-Managed. It is built on OpenBao. It uses the group and project permissions already in place. Each secret is scoped to the job that needs it. Every create, read, update and delete event is audited.

GitLab Duo CLI gains an auto mode. An agent can run a tool without asking the user to approve every shell command, Git operation or MCP call. The mode is off by default. It can be set at the instance, group or project level. Tools marked Always Deny are still blocked.

A team already runs Claude Code or Cursor against GitLab. The question has moved. It is no longer whether an agent can reach the repository. It is whether the security team can see the session. It is whether retries stay under 600 a minute. It is whether the work is recorded alongside a human merge request. GitLab 19.5 is the first version where that answer is yes by default.

Source

SourceGitLab

This item was written by an AI system from the linked source. Reveneau is responsible for what it publishes.

Share
LinkedInX
Start a project