GitLab 19.1 makes the AI Catalog event-driven and gives admins the off switch

Now that GitLab 19.1 is out, the AI Catalog — GitLab's registry of Duo agents and flows — runs against repository events instead of waiting for someone to invoke it. The release ships a set of event-driven triggers for Duo Flows alongside admin controls that let an organization say which agents are allowed to run, where their definitions may come from, and whether a broken configuration is even allowed to save.

GitLab frames the changes around a question it says security teams keep asking admins: "What's actually running in our environment, and who put it there?" Most of what is new in 19.1 is plumbing in service of being able to answer it.

The triggers that replaced the click

Per the release post, a Duo Flow can now start on four new platform events:

• A merge request where a code conflict has been detected.
• A merge request moving from draft to ready for review.
• A merge request that has been approved.
• A new work item being created.

The pipeline-event trigger picks up a filter at the same time: a Flow can subscribe to specific pipeline states — failure, success or cancellation — instead of every run.

None of these are exotic CI/CD concepts. They are the same hand-offs that already drive merge trains, compliance checks and notification webhooks. The change is that AI agents now sit on the same bus as everything else the platform reacts to, rather than living in a separate, manually invoked corner.

Why this matters in a pipeline

Each new trigger is a place where a human used to have to remember to invoke an agent. Moving invocation onto a platform event closes the gap between a state change and the response: a conflict gets summarized before the author reopens the MR, a draft flipped to ready can fire a compliance check, an approval can hand off to a follow-up step without a separate piece of glue.

For reliability work the pipeline-state filter is the more useful piece. It is the difference between a Flow that wakes up on every build and one that only fires on failure or cancellation — the only practical way to point a triage agent at red pipelines without paying for it on green ones, and the only way the cost story stays defensible past a few thousand runs a day.

The governance surface

The release adds three admin controls that did not exist before 19.1:

• A setting to disable custom agents and flows outright.
• An option to restrict the AI Catalog to your group hierarchy, so external or community-contributed content cannot be pulled into production.
• Config validation that runs at save time, refusing a flow whose configuration is broken instead of letting it persist and fail later.

A separate model-allowlist control is described as available initially for Duo Agentic Chat, in beta, letting admins pin approved providers and set an organization-wide default.

The save-time validator is the one platform engineers will feel first. Catching a misconfigured flow at the moment of authoring is cheap; catching it after it has already fired against five hundred merge requests is not.

Where event-driven invocation bites

Event-driven invocation is a blast-radius multiplier in either direction. A misbehaving Flow that used to need a human button now runs the moment a draft MR flips to ready, and on a busy monorepo that is a lot of moments. Rate limits, retries and idempotency stop being theoretical and start being load-bearing — the same hardening a webhook consumer needs once it sits on a real event bus.

The save-time check helps, but it validates structure, not intent. A Flow that is wired correctly can still be the wrong Flow, attached to the wrong group, acting on the wrong event. That is a review problem, not a parser problem.

The governance controls also have to be turned on to do anything. Restrict-to-group-hierarchy is opt-in, the custom-agent off switch is opt-in, and the model allowlist sits behind a beta. Out of the box, the answer to the question the release post leads with — what is running, and who put it there — is still whatever it was in 19.0, until an admin spends time on the configuration.

What platform teams should plan for

Manual invocations of Duo Flows keep working; the events are new surface, not a rewrite. The piece worth budgeting time for is the governance config: which agents are allowed, which groups can publish them, which pipeline outcomes a Flow may attach to, and what the review process looks like for changes to any of that. That is the work that converts a feature list into an actual answer to the security team's question — and the part that, skipped, leaves a 19.1 install no easier to audit than a 19.0 one.