Skip to main content
Integrations · GitLab
Guild agents read, update, and delete GitLab resources on your team’s behalf. Guild stores the personal access token server-side and injects it as a PRIVATE-TOKEN header, so agent code never sees the credential. Credential policies let you restrict which operations and resources each agent can reach, and every call is auditable through Guild’s credential proxy.

Book a demo

See how teams govern agents that use GitLab.

Talk to sales

Get access to Guild, then connect GitLab to your first agent.

What the GitLab integration exposes

The integration is guildai~gitlab-openapi and covers projects, issues, merge requests, pipelines, branches, commits, runners, container registry protection rules, and package protection rules. Tools support read operations (list and retrieve), write operations (create and update), and delete operations such as removing branches, pipelines, and merge requests. Tools are named with the gitlab_openapi_ prefix and can be narrowed with pick().

How it works

1

Generate a GitLab personal access token

Create a personal access token in your GitLab account with the scopes your agent needs. Guild sends it as PRIVATE-TOKEN on every request.
2

Connect the credential in Guild

Go to Access & setup > Credentials, click Connect, select gitlab-openapi, and paste the token into API Key. See Credentials for workspace, member, and agent-scoped options.
3

Import and wire the tools

Import GitlabOpenapiTools from the @guildai-services/guildai~gitlab-openapi package and spread it into your llmAgent tools object. Use pick() to include only the tools your agent needs.

Why GitLab access needs governing

GitLab tools can delete projects, branches, pipelines, and merge requests, and can unassign runners or remove protection rules. A personal access token scoped too broadly lets any agent that uses it act on any resource the token owner can reach. Guild’s credential policies let you write ALLOW and DENY rules that the credential proxy enforces before any request leaves Guild, limiting agents by operation name, HTTP method, agent identity, or workspace. Guild stores the token server-side and injects it as a header after the policy check passes. Agent code, prompts, and containers never see it. You can scope a credential to one workspace, one member, or one installed agent using the options in Credentials, so the token’s reach matches the agent’s actual job rather than the token owner’s full permissions.

About the GitLab integration

Agents can read and manage GitLab projects, including listing and updating issues, merge requests, pipelines, branches, and commits. They can also delete resources such as branches, pipelines, and merge requests. A GitLab personal access token is required to authenticate. The integration is guildai~gitlab-openapi.

Authentication

  • Type: API key
  • Header: Guild sends the key as PRIVATE-TOKEN: <key>

Setup

1

Connect GitLab

In Guild, go to Access & setup > Credentials, click Connect, select gitlab-openapi, and paste the key into API Key.
See Credentials for workspace, member, and agent-scoped credentials.

Usage

Selecting specific tools

Tools are named with the gitlab_openapi_ prefix. Use pick() to include only what your agent needs.

Tools

Tools in the latest published version of guildai~gitlab-openapi:

Frequently asked questions

Yes. Write a credential policy that denies any rule matching DELETE and POST HTTP methods, or deny operations by name pattern, while allowing everything else. The credential proxy enforces this before any request reaches GitLab.
No. The catalog entry for guildai~gitlab-openapi lists no webhook events, so the integration does not support event-driven triggers from GitLab.
Yes. Connect a separate credential scoped to each workspace from that workspace’s Credentials page. Guild resolves credentials in order: agent-dedicated, member, workspace, then account default, so a workspace credential takes precedence over a shared account credential.
Open the installed agent’s page and connect a Dedicated to this agent credential. Only an admin of the account that owns the workspace, or the person who installed the agent, can connect one. See Credentials for the full resolution order.

Put a governed agent on GitLab this week

Book a demo

See how teams govern agents that use GitLab.

Talk to sales

Get access to Guild, then connect GitLab to your first agent.
Also runs on Guild: Azure DevOps · Bitbucket · GitHub · GitLab GraphQL Read: Docs: Credential policies · Credentials · Tools in agents
Last modified on November 10, 2026