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 isguildai~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 writeALLOW 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 isguildai~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.
Usage
Selecting specific tools
Tools are named with thegitlab_openapi_ prefix. Use pick() to include only what your agent needs.
Tools
Tools in the latest published version ofguildai~gitlab-openapi:
All 167 tools
All 167 tools
Frequently asked questions
Can I limit an agent to read-only GitLab access?
Can I limit an agent to read-only GitLab access?
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.Does the GitLab integration support webhook triggers?
Does the GitLab integration support webhook triggers?
No. The catalog entry for
guildai~gitlab-openapi lists no webhook events, so the integration does not support event-driven triggers from GitLab.Can I use different GitLab tokens in different workspaces?
Can I use different GitLab tokens in different workspaces?
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.
How do I give one agent its own GitLab token?
How do I give one agent its own GitLab token?
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.