GitLab Model Context Protocol Server Tools Risk Table: What Each Tool Can Change

Why tool-level classification matters

With the Model Context Protocol, the model decides which tools to invoke, when, and with what parameters. In a traditional API integration, developers control every call. When an AI coding assistant or agent is connected to GitLab through an MCP server, each exposed tool becomes an action the model can choose to take against projects, issues, merge requests and pipelines.

Many teams cannot say which of those tools are read-only and which can change repository state, collaboration records or CI/CD behavior. That gap leaves access decisions undefined at the point where they matter: the moment an agent calls a tool.

Credentials add a second layer. OWASP guidance describes the confused deputy problem, where the server acts with its own, often broad, privileges rather than those of the requesting user. It also describes over-scoped tokens. The real blast radius of a tool is therefore set by the tool's behavior and by the credential the server runs with. Classify both.

GitLab MCP tool risk table by capability class

Tool names and counts vary by server and version, so classify by what a tool can change and then bind each tool name to its class. The table below gives the action, the objects affected, reversibility, and a suggested policy treatment. Reversibility ratings are general: they assume that deleted data and merged or executed changes are harder to undo than edited records.

• Read project, repository, issue and merge request data: Action: retrieve. Can change: nothing. Reversibility: not applicable, but disclosed data cannot be recalled. Risk: low to moderate, because content may include secrets or sensitive discussion. Policy: allow, redact sensitive values, rate limit.
• Create or update issues, comments and merge request metadata: Action: write to collaboration records. Can change: issues, notes, labels, assignees, merge request fields. Reversibility: mostly correctable, though notifications cannot be recalled. Risk: moderate. Policy: allow for approved projects only, rate limit, keep before and after values.
• Change repository content (branches, files, commits, merges): Action: write to code. Can change: repository state and anything built from it. Reversibility: partial, and weaker once merged or deployed. Risk: high. Policy: escalate for human approval, block on protected targets.
• Trigger, retry or modify pipelines and CI/CD configuration: Action: start or alter automation. Can change: CI/CD behavior and any external action a job performs. Reversibility: low, because executed jobs cannot be undone. Risk: high. Policy: escalate for human approval, rate limit, block configuration changes by default.
• Delete projects, branches, issues or other objects: Action: remove. Can change: existing data and history. Reversibility: treat as irreversible. Risk: critical. Policy: block by default, with a documented approval path if a legitimate need exists.
• Tools with file path or URL parameters: Action: read local files, upload content or call endpoints. Can change: credential exposure and data location, regardless of the tool's nominal purpose. Reversibility: low once a token leaks. Risk: critical until parameters are constrained. Policy: block, or allow only with validated parameters and redaction.

Criteria for rating a tool

Four criteria are enough to place most tools. Impact asks what object classes the tool can change: a comment, a branch, a pipeline. Reversibility asks whether the change can be undone cleanly, and by whom. Execution effect asks whether the tool changes code or starts automation that acts on other systems. Data exposure asks whether outputs or parameters can carry secrets or reach files and hosts beyond the project.

Two further factors adjust the rating. First, call sequences: delegated permissions and chained tool calls mean a low-risk read tool can feed a later write tool, so a read of untrusted text followed by a repository or pipeline action deserves more scrutiny than either call alone. Second, definition drift: OWASP describes rug pull attacks, where a server changes its tool definitions after approval. A rating tied to a tool name or description can go stale, so re-approve a tool whenever its definition changes.

OWASP's MCP Top 10 also lists privilege escalation through scope creep, where loosely defined permissions expand over time. Review ratings and allowlists on a schedule, not only at first approval.

Transport and configuration can outweigh tool semantics

Two 2026 NVD entries for the third-party @zereight/mcp-gitlab package show how configuration changes risk independently of what a tool is meant to do. These findings concern that package and should not be attributed to other GitLab MCP servers.

CVE-2026-61560 states that in versions before 2.1.27, SSE transport mode exposed all MCP tools without authentication. It also states that the upload_markdown tool read arbitrary local files through an unsanitized file_path parameter and uploaded them to a GitLab project. Combined, an attacker could read the server's environment, take its personal access token and take over the GitLab account. A tool described as an upload became a credential-exfiltration path.

CVE-2026-61559 states that with dynamic API URLs enabled, the server used a request header as the base URL for outbound GitLab API calls, checking only that the value was a well-formed URL, and attached the victim's token. The token could be delivered to an attacker-controlled host.

The lessons are general. Require authentication on every transport. Do not let client-controlled headers redirect outbound API destinations or carry tokens. Review any parameter that accepts a file path or URL. These checks sit alongside the risk table, not inside it.

Turning the table into enforceable policy

A classification only matters if something applies it when the agent calls a tool. The steps below convert the table into tool-call policy.

• Bind each tool to a class: Map every tool the server advertises to one row of the table. Treat an unclassified tool as blocked.
• Default deny with allowlists: Keep an allowlist of approved servers and tools per agent or context, as OWASP recommends, and restrict which tools each agent can invoke.
• Narrow the credential: Run the server with narrowly scoped tokens. Tool policy limits what an agent may attempt, and token scope limits what succeeds if policy fails.
• Define approval triggers: Require explicit human confirmation for actions with high impact or low reversibility, such as code changes, pipeline triggers and deletes.
• Rate limit and redact: Apply rate limits to reads and record changes, and redact secrets from returned content before it reaches the model.
• Record every decision: Capture the tool, parameters, policy decision and outcome for each call, centralize the records, and treat missing telemetry as a risk.

Enforcing these decisions at runtime

Trussed enforces policy in the execution path across agents, tools, MCP servers and coding assistants, at the level of individual interactions and tool calls. For GitLab MCP tools, that means each call can be allowed, redacted, blocked, rate limited or escalated for human approval as it happens. Policy is enforced at runtime, not reviewed after the fact.

Each enforced decision also produces audit-ready evidence, so a regulated enterprise can show what an agent was permitted to do and what it did. Trussed has run in continuous production in a regulated enterprise for more than 18 months. The risk table in this guide is useful with or without it: the classification is the policy input, and where and when that policy is enforced is the decision that determines whether it holds.