GitLab shipped its 19.4 release on September 17, 2026, and buried in the changelog is an answer to a question most engineering teams haven't formally decided: what should an AI agent be allowed to do without asking first? (GitLab) The release folds MCP server tools into the same permission settings that already govern Duo's own tools, so they now appear alongside internal tools in your group and project GitLab Duo settings instead of running as a separate, ungoverned category (GitLab). That's a small technical change with a bigger implication. GitLab picked a default for AI agent permissions, and it's worth stealing whether or not you run GitLab at all.
What GitLab 19.4 changed (Sept 17, 2026)
The change ships across every tier, Free, Premium, and Ultimate, at the group and project level (GitLab), and it's available on GitLab.com, GitLab Self-Managed, GitLab Dedicated, and GitLab Dedicated for Government (GitLab). Before 19.4, MCP tools sat outside the settings admins already used for Duo's built-in tools; now they're in the same list, subject to the same rules.
Worth being precise about what this isn't. 19.4 is not the general availability launch of the Duo Agent Platform. It's an incremental release that extends an existing settings screen to cover a new class of tools. Don't read more into it than that, and don't let a vendor's changelog rewrite convince you this is bigger news than it is.
The default: read-only allowed, write and delete ask first
The rule itself is simple. Read-only tools default to Always Allow, so routine lookups run without interrupting your team (GitLab). Tools that write or delete default to Always Ask, giving reviewers a checkpoint before an agent changes anything (GitLab). Split the world that way and you get a system that runs itself for the boring stuff and stops for the stuff that's expensive to undo.
That split isn't a Duo-specific insight. It's the right baseline for any agent that can call tools, whether it's Claude Code reading a file, Cursor querying a database, or a Copilot workspace agent hitting a production API. The blast radius of a read is bounded. The blast radius of a write or a delete usually isn't, and pretending otherwise until something breaks is how teams end up writing a policy after an incident instead of before one.
Blanket trust in an agent was always the wrong starting assumption anyway. AI coding tools don't uniformly speed up experienced developers, and an agent that's fast on a task it knows can still be wrong about one it doesn't. A permissions default that assumes competence varies by task, not by vendor, matches how these tools actually behave in practice.
How to set an AI agent permissions policy
1. Inventory every tool your agent can call, not just the ones it uses today
Pull the full list of tools registered to the agent: MCP servers, internal integrations, any plugin that's enabled, and write it down somewhere a human can read it. Most teams can name the two or three tools an agent uses daily. Few can name the ten it's technically allowed to call. Start there. You can't set a policy on a tool you forgot exists.
2. Classify by blast radius, not by tool name
Don't sort tools by category (database, ticketing, CI). Sort by what happens if the agent gets it wrong. A read that returns bad data is an annoyance. A write that corrupts a record is a cleanup job. A delete or a deploy is an incident. Two tools with similar names can sit in different tiers: search_issues and close_issue look related, but one is reversible with a click and the other might not be.
3. Default write and delete to require approval
Match GitLab's baseline here. Anything that changes state, writes, deletes, deploys, merges, needs a human to confirm before it runs. This is the step teams skip under deadline pressure, and it's the one that matters most. An agent that can merge its own pull request without review isn't saving time. It's moving the review to after the damage instead of before it.
4. Default read-only lookups to run unattended
Searches, status checks, and lookups don't need a human in the loop, and forcing approval on them trains reviewers to click approve without reading, which defeats the point of having a checkpoint at all. Keep the friction where it's actually earning something.
5. Revisit the thresholds as the agent earns trust
Treat the policy as a starting point, not a permanent setting. The same logic applies to how long it takes an AI-assisted engineer to earn trust in a codebase: trust builds from a track record on real work, not from a vendor's claim about a model. Loosen a specific tool's threshold once you've watched it perform correctly across enough real cases to count as evidence, and log the change so the next person can see why the threshold moved.
What this costs
Always Ask isn't free. Every approval prompt is a context switch for whoever's reviewing it, and if an agent asks often enough, reviewers start clicking through without reading, which is worse than no checkpoint at all because now there's a false sense of oversight. GitLab's split works because most of an agent's calls are reads that never trigger a prompt; the approval budget only gets spent on the calls that matter. A policy that requires approval for everything doesn't protect a team more. It just trains people to stop paying attention faster.
There's a slower cost too: an agent loop that pauses for approval on every write runs slower than one that doesn't, and if the approver isn't at their desk, the agent just sits there. That's the trade-off, and it's the right one to make until a tool has earned a looser threshold under step five.
What a per-tool default doesn't solve
A read and write split answers one question and leaves several others open. It says nothing about which model is doing the reasoning behind those tool calls, or where that model's weights and training data come from. It doesn't give a team an audit trail that spans tools: if an agent reads from one system and writes to another, someone still needs their own logging to reconstruct what happened, because a settings screen won't do it for them. And it does nothing for the team running three different agents, Duo on one repo, Claude Code on another, Cursor on a third, with three different permission models and no shared source of truth across them.
GitLab's default is a good pattern to copy. It isn't a governance layer on its own, and treating it like one is how a team ends up with consistent rules inside GitLab and none anywhere else it runs an agent.
Model choice, unbundled from permissions
19.4 also decoupled model selection from the permissions question, and it's worth knowing about even though it's a separate decision. Developer Flow now supports independent model selection on Premium and Ultimate tiers (GitLab), and three open-weight models, GLM 5.3, Kimi K3, and MiniMax M3, joined the list of selectable defaults (GitLab). Users with the Owner role for a group, or administrators, are the ones who get to set that default (GitLab).
Don't read this as evidence of some bigger platform shift. It's a separate axis from tool governance: which model reasons about a task is a different decision from what that task is allowed to touch once the model decides to act. A CTO evaluating 19.4 should treat these as two settings to configure, not one feature to adopt.