Best AI Agent Security Software for GitLab Duo Agent Platform and GitLab Duo Agents
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 best AI agent security software for GitLab Duo depends on how your agents run. If developers use Agentic Chat and IDE agents with approval cards, GitLab's own tool governance, protected branches and merge request approvals cover most of what you need, and you should buy nothing. If background flows hold write tools, or developers connect Claude Code and Cursor straight to the GitLab MCP server, you need a control that sits outside GitLab and can hold one specific call for a named approver.
We sell that last option. We start with "you may not need us" on purpose, because for a team whose agents mostly read code and draft merge requests that a human reviews anyway, it is the right answer.
Why GitLab buyers are reviewing agent security now
Three things changed in 2026. The Agent Platform went generally available in GitLab 18.8 in January and moved to usage billing in GitLab Credits, so agents are now a budget line someone has to defend. Custom flows went GA in GitLab 19.2 on July 16, so teams are writing their own multi-step automations that run unattended on GitLab Runner. And GitLab 19.4 on September 17 extended tool governance to the GitLab MCP server, which is a good change that also made it obvious how many developers were already connecting outside MCP clients to it.
GitLab's documentation is unusually candid about the limits. Background tool access "supports only Always Allow and Always Deny" because no user is present to approve. The rules "do not govern third-party MCP clients that connect directly to the GitLab MCP server, such as Claude Desktop, Claude Code, or Cursor." And for external agents, prompt scanning "is not available." Each of those is a reasonable design choice. Each is also a question your security review will ask.
Five options compared
| Option | What it covers | Where it stops | Best for |
|---|---|---|---|
| GitLab tool governance and composite identity | Always Allow, Always Ask or Always Deny per tool, approval cards in chat and the IDE, flows capped at the lower of the user and service account roles | Per tool, not per argument. Background flows cannot ask. Direct MCP clients are outside group rules | Every GitLab Premium or Ultimate customer, as the baseline |
| GitLab runner sandbox and egress allowlist | Flows in an isolated VM with only the domains you allow, plus an optional local sandbox for IDE agents | Limits where data can go, not which repository change is acceptable. Chat in the UI has no sandbox | Teams running flows with network access |
| HiddenLayer prompt scanning inside GitLab | Detection of injected instructions in prompts, with Log only or Interrupt | Log only by default on GitLab.com. Not available for external agents. Detects text, does not judge an action | Any group holding production code, switched to Interrupt |
| A self-hosted MCP proxy or policy engine | One place to route MCP traffic, with rules you write in code, often on Open Policy Agent | You build the approval flow, the reviewer routing and the evidence record, and you run it on call | Platform teams with spare engineering time and one policy owner |
| AgentShield | Rules on the arguments of each tool call, a named approver for the risky ones, one policy and one record across GitLab, GitHub and every MCP client | Does not replace GitLab governance, branch protection or code review, and adds a vendor to the path | Teams with background flows on write tools, or many coding assistants across platforms |
Two of the five cost nothing beyond the GitLab tier you already pay for, and the third is a setting change. That ordering is deliberate. Do those first.
How to choose for GitLab Duo agents
Who triggers the work? If a person is in the loop, in Agentic Chat or the IDE, GitLab's approval cards on writes and deletes are a real control. If an issue, a merge request event or a schedule triggers a flow, nobody sees a card, and whatever you set to Always Allow will run for an input an outsider wrote.
Which calls write? The useful question is not whether an agent can write, it is which writes you would want a second person to see. Most teams land on a short list: changes to pipeline files, new or changed CI variables, deploy jobs, protected branch settings and anything touching secrets. GitLab's categories are Read, Write and Delete. A rule that lets a flow commit to a feature branch but holds an edit to the pipeline file needs something that looks at the arguments.
How many clients reach GitLab? Count the developers who run Claude Code, Cursor or Codex against the GitLab MCP server with personal tokens. If that number is above zero, your group rules describe only part of what happens in your repositories, at least until server-side Always Deny ships in a later release and is switched on.
Do agents act outside GitLab? Flows can request ID tokens for OIDC, and GitLab warns that an ID token "grants access to any service that trusts its aud claim." If your flows deploy to cloud accounts or call ticketing and database tools, the decision about whether an action is acceptable has to be made where that action lands. If a flow does ship a bad pipeline change anyway, recovery goes faster when your incident management tooling pages the right engineer rather than a shared channel.
Budgeting for GitLab Duo agent security
GitLab bills the Agent Platform in GitLab Credits, with on-demand usage at a documented list price of 1 USD per credit used after included credits and any commitment pool run out (GitLab credits documentation, read October 21, 2026). Included credits are per user and do not roll over. Admins and group Owners can cap credit spend from GitLab 19.4. None of that pays for security work outside GitLab. Budget engineering time to tune tool rules per group as GitLab changes them monthly, reviewer time for the approvals your rules create, and any external control for coding assistants and flows that act beyond GitLab. We do not publish competitor prices here because they change and are usually quoted per deal.
When you need nothing extra
If your agents read code, answer questions and draft merge requests that go through protected branches and approval rules before anything merges, GitLab is enough. Keep writes on Always Ask, switch prompt injection protection to Interrupt, apply the runner sandbox, and pull the AI audit event report every month. Adding a vendor to that setup buys you a second dashboard and little else.
Does GitLab Duo have built-in AI agent security?
Yes. GitLab Duo Agent Platform includes composite identity, tool governance with Always Allow, Always Ask and Always Deny, a runner sandbox with an egress allowlist, HiddenLayer prompt injection detection, Gitleaks secret redaction for flows and IDE agents, and AI audit event reports. Tool governance and the audit reports are still beta, and several controls depend on your version and feature flags.
Do I need a separate tool for Claude Code and Cursor on GitLab?
Only if they connect directly to the GitLab MCP server or act outside GitLab. GitLab documents that its group tool rules do not govern third-party MCP clients such as Claude Desktop, Claude Code or Cursor, and Always Ask then depends on the client. When those same developers also work on GitHub, see our notes on GitHub Copilot agent security and the broader coding agent security page.
What should a GitLab Duo agent security tool log for SOC 2?
For each agent action, log the agent, the human it acted for, the tool and its arguments, the rule that decided, the decision, who approved and when, and the result. GitLab's composite identity already attributes merge requests to the triggering user for segregation of duties. What auditors still ask for is what the agent was permitted to do at that moment, which our per-action audit trail records.
Our full breakdown of the native controls, the four gaps and a nine-step checklist is on the GitLab Duo Agent Platform security page. If you decide the risky writes need a gate, start with argument-level tool permissions and test one background flow before you roll it out.
See the firewall block an attack live.
Drive the Threat Console and watch a real prompt injection get stopped, then put AgentShield in front of your own agents.