GitLab Duo Agent Platform Security for Agents, Flows, Tool Approvals and MCP
GitLab Duo agents now open merge requests, fix pipelines, triage vulnerabilities and run custom flows on your runners, and Claude Code, Codex, Cursor and other MCP clients can act on GitLab directly. GitLab ships real controls for this. This page shows what each one covers, the four places they stop, and when a second control earns its cost.
Direct answer
GitLab Duo Agent Platform security rests on five native pieces: composite identity, which caps a flow at the lower of the triggering user and its service account; tool governance with Always Allow, Always Ask and Always Deny per tool; a runner sandbox with a network allowlist for flows; prompt injection detection; and AI audit event reports. They govern GitLab Duo agents well. They do not ask a human during background flows, they set rules per tool rather than per argument, and they do not govern third-party MCP clients such as Claude Code or Cursor that connect straight to the GitLab MCP server.
Try it live
Watch AgentShield block an attack in real time.
Pick a scenario and drive the inspection lane yourself. No signup needed.
Run a request
Runs the live engine on your text. Nothing is stored, no account needed.
Inspection lane
INSPECTINGPolicy trace
High-risk action held for approval
Audit trail
- § · → → →
The risk
A US fintech turns on the Developer flow so issues labeled for automation become merge requests overnight. The flow runs in the background, so its write tools are set to Always Allow, because GitLab documents that background access supports only Always Allow and Always Deny with no user present to approve. An issue filed from a public support form carries a hidden instruction to add a new CI variable and a deploy job that posts environment data to an outside URL. The flow is allowed to edit the pipeline file in that project, the change looks routine, and nobody is asked. The same week, three developers connect Claude Code to the GitLab MCP server with their own tokens, and the group tool rules that the security team spent a sprint on do not apply to any of them.
How AgentShield handles it
Use GitLab first. Keep tool governance on its defaults or tighter, switch prompt injection protection from Log only to Interrupt, run flows with the sandbox and a narrow egress allowlist, keep protected branches and merge request approval rules on every repository an agent can touch, and read the AI audit event report on a schedule. Then put AgentShield in front of the MCP servers and APIs your agents and coding assistants call, so rules can look at the arguments of a write call, background actions that matter wait for a named approver instead of running silently, and every decision lands in one record across GitLab, GitHub and anything else your developers use.
The controls
The controls that secure which GitLab Duo agent tool calls run and which wait for a named approver.
What GitLab Duo Agent Platform secures natively
GitLab treats an agent as a constrained teammate rather than an admin. Its documentation tells you to "apply the principle of least privilege to agents, just as you would for human team members," and the platform gives you more native controls than most agent products. The Agent Platform reached general availability in GitLab 18.8 in January 2026 and requires the Premium or Ultimate tier. Here is what each native control does, read from docs.gitlab.com in October 2026.
| GitLab control | What it does | Where it applies |
|---|---|---|
| Composite identity | Combines a service account and the human who started the flow into one token. The effective role is the more restrictive of the two, and the service account holds the Developer role | Flows. GitLab states that "Composite identity does not apply to GitLab Duo Agentic Chat in the UI and IDE" |
| Tool governance | Sets each tool to Always Allow, Always Ask or Always Deny by action category. Defaults are Always Allow for reads and Always Ask for writes and deletes. Always Deny hides the tool from the agent entirely | Agentic Chat, IDE extensions, IDE-run flows and GitLab MCP server tools called by Duo agents. Beta, Premium and Ultimate |
| Runner sandbox | Flows run in GitLab Runner jobs, isolated by the sandbox when it is applied, with a configurable allowlist and denylist for network egress | Flows. Chat sessions in the GitLab UI do not apply a sandbox, and IDE agents have unrestricted network access unless the local sandbox is turned on |
| Prompt injection detection | Third-party prompt scanning through HiddenLayer with three settings, No checks, Log only and Interrupt. Log only is the GitLab.com default | GitLab native agents and flows, configured by a group Owner. GitLab states that "This scanning is not available for external agents" |
| Secret redaction | Client-side Gitleaks redaction before content reaches the model | Flows and IDE agents. Not applied for Chat |
| AI audit event reports | A downloadable record of agent sessions from the Governance page | Beta since GitLab 19.2 |
Add the controls you already run for people, which apply to agents too: protected branches, merge request approval rules, CODEOWNERS and security policies. Merge requests a flow creates are attributed to the triggering user rather than the service account, which GitLab designed so segregation of duties still holds for SOC 2, SOX, ISO 27001 and FedRAMP reviews.
What GitLab shipped for agent security in 2026
The control set has changed almost every month this year, and several pieces are still beta or sit behind feature flags. If your last review of GitLab Duo was before the summer, it is out of date. This is the timeline from GitLab's release notes and documentation.
| Release | What changed for agent security | Status |
|---|---|---|
| 18.8, January 2026 | Duo Agent Platform generally available, with usage billed in GitLab Credits | GA |
| 19.1 | Agent tool governance introduced, with Read, Write and Delete categories | Beta, flag on by default |
| 19.2, July 16, 2026 | Custom flows GA with human-in-the-loop checkpoints you define, service accounts and composite identity. Duo CLI GA with tool approvals. AI audit event reports | GA, audit reports beta |
| 19.3 | Blocking of whole external MCP servers. Tool governance for background flows behind a flag that is off by default | Beta |
| 19.4, September 17, 2026 | Tool governance extended to GitLab MCP server tools, feature flag removed, MCP server blocking enforced by default, credit caps page for admins | Beta |
| 19.5 | Default for local file reads changed to Always Allow | Beta |
| 19.6, upcoming | Server-side Always Deny enforcement for third-party MCP clients, behind flags that are off by default | Not yet released |
The direction is right and GitLab is moving fast. The practical consequence is that your approval posture depends on your GitLab version, your tier and which flags an admin has turned on, so write those three things into your agent risk register next to each workflow.
How GitLab Duo tool approvals work on each surface
The question buyers ask first is whether GitLab Duo agents can auto approve tool calls. The answer depends on where the agent runs. GitLab's own security threats page lists who approves on each surface, and the differences are large.
| Surface | Who approves tool calls | Isolation and scanning |
|---|---|---|
| Agentic Chat in the GitLab UI | The user approves write API tool calls | No sandbox. Composite identity does not apply. Secret redaction not applied |
| IDE and Duo CLI agents | The user approves write API tool calls and terminal commands | Optional local sandbox. Unrestricted network unless it is on |
| Flows on GitLab Runner | Human-in-the-loop is listed as "Not applied". Tool restrictions are set in each flow definition, and background tool access supports only Always Allow and Always Deny | Isolated VM and sandbox when the sandbox is applied, with an egress allowlist |
| External agents (Claude Code, OpenAI Codex, Amazon Q, Gemini) | Run as a CI/CD pipeline under a service account with the Developer role. The external provider "manages all security controls" | Prompt scanning not available. GitLab notes they "do not have the same level of network isolation" as native agents |
| Third-party MCP clients on the GitLab MCP server (Claude Desktop, Claude Code, Cursor) | Group tool rules "do not govern" these clients. Always Ask depends on the client | Whatever the client and the user's token allow |
So yes, in practice GitLab Duo actions can run without a human. In interactive chat and the IDE a person sees an approval card for writes. In a background flow nobody does, by design, because there is nobody there. That is correct engineering for a background job and it is exactly the case where a manipulated issue does the most damage.
Four gaps that remain after GitLab controls are on
None of these is a GitLab bug. Each is the edge of what a single platform can see. Check them against your own setup before deciding whether you need anything else.
| Gap | Why it matters | What closes it |
|---|---|---|
| Background flows cannot ask a person | Any write tool set to Always Allow so a flow can run unattended will run for every input, including an issue or comment that carries an injected instruction | Custom flow checkpoints where you can place them, plus an external approval that holds the specific risky call and pages a named reviewer |
| Rules are per tool, not per argument | Always Ask on a write tool asks about every write, so teams either drown in approvals or flip it to Always Allow. The docs describe no rule that allows a commit to a feature branch but holds one that edits a pipeline file or adds a CI variable | Argument-level rules on paths, branches, variables and destinations, so routine writes pass and the rare risky one waits |
| Direct MCP clients are outside group rules | A developer's Claude Code or Cursor session on the GitLab MCP server acts with that developer's token and is not governed by the group's tool rules until server-side Always Deny ships, and Always Ask still depends on the client | Route coding assistants through a gateway that applies the same policy to every client and every token |
| Actions outside GitLab | Flows can use ID tokens for OIDC, and GitLab warns that an ID token "grants access to any service that trusts its aud claim". Agents also call cloud, ticketing and database MCP servers GitLab does not see | A narrow aud claim on every token, and a control in front of the outside systems that records what was attempted there |
Prompt injection detection is a fifth, smaller gap. It defaults to Log only on GitLab.com and does not cover external agents. Switching it to Interrupt needs the GitLab AI Gateway and the group Owner role but no extra purchase, and it is the first change we would make.
GitLab Duo Agent Platform pricing and the security lines outside it
GitLab bills the Agent Platform in GitLab Credits. These figures come from GitLab's credits documentation, read on October 21, 2026, and they change often, so confirm them on your order form.
| Item | What GitLab documents |
|---|---|
| On-demand rate | Billed monthly "at the list price of $1 per credit used", after included credits and any monthly commitment pool run out |
| Included credits | Individual to each user and cannot be shared. Unused credits do not roll over to the next month |
| Agentic features | Most are billed per model call, so cost depends on the model you pick |
| Flat-priced flows | Code Review Flow 4 executions per credit on GitLab-managed models. SAST Vulnerability Resolution Flow 0.25 executions per credit. Self-hosted models get a 20% discount |
| Failed flows | On GitLab.com, a flow that fails before it completes deducts no credits |
| Spending limits | Admins and group Owners can set credit caps from GitLab 19.4 |
What the credits buy is agent work inside GitLab. Three security lines sit outside that number and belong in the same budget: engineering time to tune tool rules per group and keep up with monthly changes, review time for the approvals your rules generate, and any control you add for agents and coding assistants that act outside GitLab or reach it from an unmanaged client.
GitLab Duo agent security checklist for US engineering teams
- Record your GitLab version, tier and the state of every agent-related feature flag. Your approval posture depends on all three.
- Leave writes and deletes on Always Ask for interactive use, and set Always Deny on any tool an agent has no reason to call. Denied tools are invisible to the agent.
- List every background flow and every write tool it holds on Always Allow. For each one, write down what happens if the input that triggers it was written by an attacker.
- Switch prompt injection protection from Log only to Interrupt for groups that hold production code.
- Run flows with the sandbox applied and an egress allowlist that names only the domains the job needs.
- Set the narrowest possible aud claim on every ID token a flow can request, as GitLab's own docs advise.
- Keep protected branches, merge request approval rules and CODEOWNERS on every repository an agent can reach. These are your strongest controls and they cost nothing extra.
- Inventory which developers connect Claude Code, Cursor or other MCP clients to the GitLab MCP server, with which tokens, and decide how those sessions are governed.
- Pull the AI audit event report on a schedule and reconcile it against what your rules say should have happened.
When to buy nothing, use GitLab controls, or add AgentShield
| Your situation | What to do |
|---|---|
| Developers use Agentic Chat and IDE agents with the default approval cards | Buy nothing. Keep the defaults and protected branches |
| You run GitLab security flows such as SAST false positive detection and vulnerability resolution | Buy nothing. Their output still goes through merge request review |
| You worry about prompt injection in issues and comments | Buy nothing first. Turn on Interrupt and split reader and writer agents as GitLab recommends |
| Flows run in the background with network access | Use GitLab. Apply the sandbox and a tight egress allowlist |
| Background flows hold write tools on Always Allow and touch pipelines, CI variables or deploy jobs | Add AgentShield on those write calls, with argument rules and a named approver |
| Developers run Claude Code, Cursor or Codex on GitLab and GitHub, or agents call cloud and ticketing systems | Add AgentShield as one policy and one record across every client and system |
Four of six rows end without a purchase from us. If your developers split time between platforms, our GitHub Copilot agent security page covers the matching controls on the GitHub side, and the Codex CLI security page covers one of the external agents GitLab runs. For a side-by-side of the tools GitLab buyers shortlist, read our AI agent security software for GitLab Duo buyer guide, and for the approval mechanics themselves see approval gates for AI agents.
FAQ
Common questions about gitlab duo agent platform security.
Is GitLab Duo Agent Platform secure?
GitLab Duo Agent Platform ships strong native controls: composite identity, per-tool governance with approval cards, a runner sandbox with an egress allowlist, prompt injection detection and AI audit reports. They govern GitLab Duo agents well. Background flows cannot ask a person, rules are per tool rather than per argument, and third-party MCP clients are outside group rules.
Can GitLab Duo agents auto approve tool calls?
Yes, depending on the surface. Tools set to Always Allow run silently, and reads default to Always Allow. In chat and the IDE, writes default to Always Ask and show an approval card. Background flows support only Always Allow and Always Deny because no user is present, so any write a flow needs runs without a human.
What is composite identity in GitLab Duo?
Composite identity combines a service account and the human who started a flow into one token, and the effective role is the more restrictive of the two. A flow can reach only projects both identities can access. Merge requests it creates are attributed to the human for segregation of duties. It does not apply to Agentic Chat in the UI and IDE.
Does GitLab Duo protect against prompt injection?
Yes, partly. GitLab scans prompts through HiddenLayer with three settings, No checks, Log only and Interrupt, and Log only is the GitLab.com default, so detection does not block until a group Owner switches it to Interrupt. GitLab states this scanning is not available for external agents such as Claude Code or Codex running in GitLab.
Do GitLab tool governance rules apply to Claude Code and Cursor?
Not when they connect directly to the GitLab MCP server. GitLab documents that its rules do not govern third-party MCP clients such as Claude Desktop, Claude Code or Cursor, and that Always Ask depends on the client. Server-side Always Deny for these clients is listed for GitLab 19.6 behind flags that are off by default.
Can GitLab Duo Agent Platform be self-hosted?
Yes. Tool governance and the Agent Platform are offered on GitLab.com, GitLab Self-Managed and GitLab Dedicated, and features that run on a self-hosted model receive a 20% discount on the credits they consume. On Dedicated, the AI Gateway runs in your AWS environment, and admins can lock subgroups so the Agent Platform stays off.
How much does GitLab Duo Agent Platform cost?
GitLab bills the Agent Platform in GitLab Credits. On-demand usage is billed monthly at a list price of 1 USD per credit after included credits and any commitment pool are used, and included credits do not roll over. Most agentic features are billed per model call, while flows such as Code Review are priced per execution.
Does AgentShield work with GitLab Duo Agent Platform?
Yes, on the MCP servers and APIs your GitLab agents and coding assistants call. Point those calls at an AgentShield gateway endpoint with rules on arguments such as file paths, branches, CI variables and destinations. Matching calls wait for a named approver, routine ones pass, and every decision is recorded across GitLab and every other client.
More use cases