Controlling AI Agents with a GitLab MCP Server on Self-Managed GitLab Behind the Firewall

How the MCP server fits into a firewalled GitLab deployment

A GitLab MCP server sits between an agent or coding assistant and GitLab. The agent sends a tool call, such as reading a file or opening a merge request. The server turns that call into a GitLab API request using a credential it holds or is given. On self-managed GitLab behind a firewall, this shapes the design without requiring any exposure of GitLab to the internet.

Three decisions matter most. The first is network placement. The server needs to reach the GitLab API from inside the network, and agents need to reach the server. Both paths can stay internal, and the policy layer should sit on the agent-to-server path so that no call bypasses it. The second is identity. Whatever credential the server uses determines what the agent can do, so the choice of identity is the main access control decision. The third is data residency. Tool calls carry repository content, merge request text and pipeline output, so decide where policy decisions and evidence are processed and stored.

Egress deserves equal attention. Data returned by a tool becomes input to whatever model the agent uses. If that model is hosted outside the network, code and CI/CD output can leave with it. Treat the agent runtime's outbound connections as part of the same control model.

Where agent access risk arises

The main risk is inherited authority. If the server runs on a broad personal token, every agent using it acts with that person's reach, across repositories and CI/CD resources the task never required. Shared credentials also make it impossible to tell which agent did what.

Tool exposure is the second risk. Each tool the server offers is an operation an agent can attempt. Read operations expose code and may expose secrets committed to repositories. Write operations, including creating merge requests, changing issues and triggering pipelines, change state and can cause harm that is hard to reverse. NIST material on agentic security flags destructive actions and data exfiltration as agent risks, which maps directly onto write tools and broad read access.

Platform version matters as well. CVE-2022-4143 affected GitLab versions from 15.7 before 15.8.5, from 15.9 before 15.9.4 and from 15.10 before 15.10.1, and allowed crafted, unapproved merge requests to be merged without authorization. It is a historical, version-specific issue, but it shows that approval rules depend on the running version. Agent controls should assume GitLab is patched and should not be the only barrier in front of merges.

What is native and what must be enforced at runtime

GitLab and MCP provide a foundation. The gaps appear when a permitted identity makes a call that is valid in general but wrong in context.

• Authentication: Native: GitLab authenticates the token or identity the server presents. Runtime: confirm each call maps to a distinct agent identity, not a shared credential.
• Permissions: Native: roles and token scopes limit what the identity can reach. Runtime: evaluate the specific project, branch and action in each call.
• Tool availability: Native: tool definitions set what the server offers. Runtime: restrict the exposed set per agent and task.
• Per-call decisions: Native: a call either succeeds or fails on permissions. Runtime: allow, redact, block, rate limit or escalate based on policy.
• Evidence: Native: platform activity records show API use. Runtime: capture the decision and its basis for each tool call.

Enforcing policy in the execution path of tool calls

NIST IR 8587 notes that API access typically sits behind resource servers, which can act as a policy enforcement point to support the contextual security needed for access decisions. Treating the MCP server, or a gateway in front of it, as that resource server is a reasonable design inference. It is not a pattern defined by NIST for MCP specifically.

Policy at this point can produce five outcomes. Allow passes a call that fits policy. Redact removes sensitive content from parameters or results, such as credentials in file contents. Block stops calls outside policy, for example a write to a protected project. Rate limit caps call volume so a looping agent cannot flood GitLab. Escalate holds a call until a named person approves it.

NIST's proposed agent identity tenets support the escalation model. Organizations define risk thresholds that, when reached, trigger human review, and technology components should be able to route that escalation to the correct authority. Merges and pipeline runs are natural thresholds. NIST SP 800-204D adds that source-code management systems should delay CI workflow runs until a maintainer with write access approves them, so an agent-triggered pipeline should respect that gate or add its own. The same tenets call for monitoring agentic access, warning on anomalous behavior and using agent-specific thresholds to manage interaction scale.

Trussed enforces policy in the execution path across agents, tools, MCP servers and coding assistants, at the level of individual interactions and tool calls. It can be deployed self-managed in the customer cloud, with configurable retention and data residency, which suits a firewalled GitLab environment. It adds to GitLab permissions and does not replace them.