GitLab Extends Agentic AI Controls Into Regulated Environments With 19.3 Release

GitLab has shipped version 19.3 of its DevSecOps platform, adding a set of controls aimed at organisations that want to scale agentic software development without loosening the guardrails they already operate under.

The change with the widest implications for regulated customers is the general availability of the AI Gateway for GitLab Dedicated, which lets single-tenant customers run GitLab Duo Agent Platform inside the same environment and cloud region that already holds their source code, project data and pipelines.

Those customers can connect their own models for inference and keep AI-processed data inside their existing security boundary.

The release also moves GitLab Secrets Manager into limited availability as a paid add-on billed through GitLab Credits. Bulk SAST False Positive Detection and Agentic SAST Vulnerability Resolution enter beta, and the Flow Creator Agent becomes generally available.

Taken together, the four capabilities target three separate groups: engineering teams running pipelines, process owners who want to automate their own workflows and security teams sitting on vulnerability backlogs.

Chief Product and Marketing Officer at GitLab, Manav Khurana (pictured), positioned the release as an extension of controls enterprises already have in place rather than a new set of them.

“These updates extend the speed and control enterprises need deeper into the regulated and data-sensitive segment of the enterprise market,” Khurana said.

“Every capability we shipped this month, from where an agent runs to which secret it can touch, extends that same control into the trusted software delivery workflows enterprises already depend on.”

Agentic AI moves inside the tenancy

GitLab Dedicated is a single-tenant instance managed by GitLab and deployed in an AWS region the customer selects. Customers can bring their own encryption keys and there is no private cloud installation involved.

GitLab operates the instance, including high availability and disaster recovery, and maintains a 99.9 per cent monthly availability target for core services. Dedicated instances follow a stability-first update cadence and sit on the previous minor version, N-1, relative to the current GitLab release.

With the AI Gateway now running inside that single-tenant SaaS infrastructure, agentic workloads follow the same residency and isolation model as the rest of the software development lifecycle on the platform.

Writing in a company blog post, Ozer Dondurmacioglu argued that agentic workflows place demands on the software development lifecycle well beyond AI coding assistance, among them higher pipeline volume, greater risk of vulnerabilities being introduced and context that has to travel with every agent and flow.

The isolation, residency and service level requirements already applied to GitLab Dedicated should extend to the inference path as well, according to the post, particularly as agentic software development is adopted more widely.

Dedicated customers using Duo Agent Platform can connect the AI Gateway to Amazon Bedrock as their model backend so that inference stays in their AWS region. Other model providers can be used instead.

Organisations with specific model requirements, data classification rules or existing commitments can nominate models hosted in Amazon Bedrock for their teams to use with Duo Agent Platform. Duo Agent Platform functions including automated custom code reviews, fixing failed pipelines and security analysis run against those nominated models.

GitLab has pointed Dedicated customers toward a staged rollout: add a self-hosted model, validate model connectivity in a non-production project, then expand agentic workflows under existing change controls.

Secrets management extends past the pipeline

GitLab Secrets Manager is now in limited availability as a paid add-on billed through GitLab Credits for Premium and Ultimate users on GitLab.com. It remains in beta for self-managed deployments, with GitLab Dedicated support flagged as arriving later.

The feature followed a public beta that landed with GitLab 19.0.

Built on OpenBao, Secrets Manager keeps credentials in the same platform that runs code and pipelines, which removes the need to maintain a second permission model in a standalone vault.

The problem it targets is a familiar one. Developers who need a credential and lack a good place to put it tend to improvise, and the value ends up in an over-scoped CI/CD variable, a config file or a .env file committed temporarily.

CI/CD variables set at project or group level get injected into every job, and anyone with pipeline access can read them. A standalone vault solves that but carries what GitLab describes as a permanent operational tax: another system to authenticate against, another access model to maintain and another audit stream to correlate during an incident.

Developers move a secret out of CI/CD variables by declaring it in .gitlab-ci.yml with the secrets keyword. By default GitLab writes the value to a temporary file and supplies the path as an environment variable scoped to that job, which can reduce exposure in subprocesses, crash dumps and telemetry.

Secrets Manager uses existing group and project structure as the isolation boundary. Read, create, update and delete permissions are set per user, group or role using the same controls that govern code. Secrets created at group level are available to every project nested beneath, and access is revoked as soon as someone is removed from a project.

Scoping decisions rest on three job attributes: the environment the job targets, the branch it runs on and whether that branch is protected. Wildcards work on environment and branch, and conditions can be combined, so a single rule can require a job to run on a protected branch and target a production environment before credentials are released.

When a job requests a secret, the backend verifies the job’s identity, then checks branch and environment against the scope rules before returning the value. The secret is discarded when the job ends, nothing persists to the runner and job logs are masked. A CI variable, by contrast, stays readable in project config indefinitely.

GitLab has framed narrow scoping as a blast radius question. When the Axios npm package was compromised, organisations running a poisoned version had to treat every credential their pipelines touched as being in an attacker’s hands, then rotate and audit accordingly.

On the forensics side, create, update and delete events for project-level and group-level secrets are logged to the same audit trail as the rest of the platform. Secret reads from CI/CD pipelines stream as audit events carrying the originating pipeline and job IDs. Audit logging is available on self-managed deployments now, with GitLab.com support anticipated during the public beta program.

Secrets Manager also now works outside CI, covering Kubernetes, Terraform, OpenTofu and custom tools, which puts secrets used by infrastructure under the same permission model as secrets used inside a pipeline.

Existing integrations for HashiCorp Vault, AWS Secrets Manager, Azure Key Vault and Google Cloud Secret Manager continue to operate alongside the native option, allowing a staged migration.

Bulk triage aimed at vulnerability backlogs

The second major addition lets security teams act on a whole vulnerability backlog rather than one finding at a time.

Teams bulk-select findings in the Vulnerability Report and run two agentic flows across the selection. SAST False Positive Detection analyses the code surrounding a finding and returns a confidence score along with an explanation of whether the finding represents real risk. Agentic SAST Vulnerability Resolution then opens a ready-to-merge fix for anything confirmed as a genuine risk, leaving a developer to review and merge rather than write the fix from scratch.

The capability covers every SAST vulnerability in the Vulnerability Report regardless of scanner origin or severity. Findings from any third-party scanner that outputs SARIF can be imported into the unified report.

In a blog post on the feature, Alisa Ho tied the change to the pace at which code is now written and exploited.

Verizon’s 2026 Data Breach Investigations Report found that vulnerability exploitation had overtaken credential abuse as the entry point for the largest share of breaches. Exploitation accounted for 31 per cent of breaches against 13 per cent in previous years, while only 26 per cent of known exploited vulnerabilities were remediated over the year, down from 38 per cent.

The implication drawn by GitLab is that a backlog is no longer only a workload problem. Findings that sit unaddressed carry more risk than they used to, because the same AI accelerating development is also accelerating exploitation.

A second layer handles new findings. Teams can configure pipelines to run False Positive Detection and Agentic SAST Vulnerability Resolution automatically against Critical and High severity vulnerabilities, so new findings are triaged and, where warranted, given a ready-to-merge fix before anyone opens them by hand.

GitLab has confirmed that bulk runs consume Duo Agent Platform credits, though at the same per-execution rate as running detection individually. Bulk simply queues many executions at once.

Concurrency limits are in place to stop bulk jobs competing with other pipeline work, and a progress indicator tracks a running job, which can be cancelled at any point.

Plain language authoring for custom flows

Flow Creator Agent, now generally available, addresses a narrower bottleneck: the Flow Registry schema.

Custom Flows already allowed teams to convert manual, multi-step work into automation triggered by GitLab events, but authoring one meant learning the schema first. That limited flow authoring to people with schema familiarity rather than people with process knowledge.

Rebecca Carter, in a blog post on the release, used two examples: a security analyst who knows which patterns are false positives and who owns each affected dependency, and a planning lead who knows what should happen when a work item changes status. Neither necessarily knows YAML.

Flow Creator is a foundational agent within Duo Agent Platform, invoked through Agentic Chat. A user describes the automation in plain language and receives a complete, runnable flow definition ready to register from the AI Catalog.

Carter offers a sample instruction: when a work item is created with a security-triage label, check it against known false-positive patterns, find the affected dependency and its owner, then post a severity assessment as a comment. That gives the agent a trigger, a set of steps and an output target.

Where a description is ambiguous or incomplete, such as which project the flow should target or whether a step needs human approval, the agent asks for confirmation instead of guessing and returning a flow that runs against the wrong project or skips an approval.

Behind the scenes the agent does three things. It reads current Flow Registry documentation before every response rather than answering from training data. It applies rules encoding failure patterns observed in real flows. It runs a pre-output checklist before any YAML is generated.

Those rules map to four ways flows break in practice: a missing project_id, which leaves the flow without a clear target; broken human-in-the-loop gates, where a flow meant to pause for approval proceeds without it; incorrect sends_response_to targets, where output is written somewhere nobody is watching; and missing stopping instructions, where the agent keeps working past task completion.

Guardrails do not loosen as the pool of authors widens. Every flow runs through a scoped service account under composite identity, so it cannot reach further than the permissions of the person who ran it, and the account is scoped to the top-level group.

Authoring and enabling remain separate steps. Anyone can describe a flow to Flow Creator, but enabling one requires the Maintainer role or higher. Group Owners and instance administrators can switch Custom Flows off entirely.

The generated definition is pasted into the configuration editor when creating a flow from a project or from the AI Catalog. Authors then choose whether the flow is private, restricted or public and add the triggers that should start it.

Spend caps and group-level visibility

Two further capabilities reached general availability with the release.

GitLab Credits usage caps let organisations set a monthly ceiling on agentic AI spend before it turns into an overage. Administrators can set a subscription level cap in the Customers Portal, with options for a default per-user cap or per-user overrides through the GraphQL API.

Restricted visibility for custom agents and flows per GitLab group is also generally available, making them accessible to members across multiple projects within a group. That sits alongside the per-project and public visibility options already offered.

Getting access

Customers already on Premium or Ultimate can switch on Duo Agent Platform and draw on the GitLab Credits included with their subscription. The same applies to existing GitLab Dedicated subscribers. A free trial is available for organisations not currently using Duo Agent Platform, and Free tier signup is open for Flow Creator.

On GitLab.com, Secrets Manager users can create a first secret directly. Self-managed deployments follow a separate installation process.

GitLab has been leaning on external validation for the platform, citing a Forrester Consulting study that put the return on investment for Duo Agent Platform at 400 per cent.

Last Updated on August 23, 2026 by Nick Ross