GitLab Duo and Agentic DevSecOps: AI Features, Security Remediation, Governance, and Usage Controls: Concepts, Architecture, and Mental Model

1. The practical problem: AI can propose and execute work faster than your old review assumptions

Traditional CI/CD automation is usually deterministic: a reviewed YAML file triggers known commands under a defined identity. Generative AI changes the failure model. A model can infer intent incorrectly, use stale context, hallucinate an API or security property, or choose a broader change than the human expected. Agentic systems add another step: the system may invoke tools that read repositories, edit files, run commands, call GitLab APIs, create branches or merge requests, or interact with external systems.

The operational question is therefore not “Is the AI smart enough?” It is: what data did it see, what authority could it exercise, what did it propose or execute, who approved consequential actions, what evidence proves the result, and what did the action cost? Those questions connect directly to earlier GitLab chapters on roles, protected resources, CI/CD runner trust, security findings, audit evidence, and operational diagnostics.

2. Product mental model: non-agentic assistance versus the Agent Platform

GitLab currently documents two related product families that learners should not collapse into one label. GitLab Duo non-agentic features perform focused AI-assisted tasks such as code suggestions, non-agentic Chat, code explanation, root-cause analysis, vulnerability explanation, and vulnerability resolution, subject to their individual entitlements. GitLab Duo Agent Platform adds agentic chat, agents, flows, tools, AI Catalog items, sessions, and execution paths that can perform multi-step work.

3. Architecture: separate data flow, authorization, execution, and verification

The cleanest mental model uses four independent planes. The context plane decides what code, issue, vulnerability, chat history, or tool result reaches the model. The authorization plane combines GitLab role/resource permissions with agent tool governance. The execution plane may be the browser/IDE, local environment, or a CI/CD runner used by a flow. The verification plane consists of tests, security scanners, diffs, protected-branch policies, approvals, and human review.

flowchart TD
  U[Human intent] --> G[GitLab Duo / Agent Platform]
  C[Selected GitLab + repository context] --> G
  G --> M[Configured model/provider]
  M --> P[Proposed plan / tool call]
  P --> TG{Tool governance}
  TG -->|allow / approved| X[Tool or flow execution]
  TG -->|deny| D[No execution]
  X --> R[GitLab resource / workspace / runner]
  R --> E[Diff + tests + scans + audit/session evidence]
  E --> H{Human + repository governance}
  H -->|approved| A[Consequential change accepted]
  H -->|rejected| F[Revise or stop]

The diagram intentionally places tool governance before execution and independent verification after execution. A model can recommend a write, but a write should still face both the tool policy and normal GitLab authorization. A generated merge request must still face branch protection, required pipelines, code review, security policy, and human judgment.

4. Availability is a vector, not one “AI enabled” switch

When a feature is missing, check each dimension independently. A user can have enough project role but no eligible subscription/add-on. A group can have credits but have Agent Platform disabled. A beta feature can be disabled by the feature-preview setting. A Self-Managed instance can be on an older release. A flow can be enabled but remain queued because no compatible runner is available.

5. Credits and add-ons are different commercial mechanisms

GitLab Credits are the usage currency for the Agent Platform. GitLab documents credit consumption at the top-level group/root namespace level and supports credit pools/usage billing patterns that can change over time. The older/non-agentic Duo Pro and Duo Enterprise feature set uses add-on entitlement rather than Agent Platform usage credits. Some features have both agentic and non-agentic variants, so “Chat used no credits yesterday” is not a reliable universal rule.

Cost control belongs in governance because an agent can perform many model actions or invoke background flows. Budget owners need usage visibility, while developers need a graceful fallback when a feature is unavailable. Core GitLab functionality should not depend on an AI feature staying available.

6. Data and privacy: identify exactly what crosses each boundary

GitLab Duo features can send prompts and selected context to GitLab AI services and model subprocessors. Current GitLab documentation names multiple model providers and states that GitLab does not train generative AI models on customer content. Retention behavior is not identical for every provider/model or every product feature. Chat/workflow history, prompt caching, optional expanded/usage logging, and self-hosted model configurations introduce additional boundaries.

7. Tool governance adds a human-in-the-loop boundary

Current Agent Platform tool governance classifies tools as read, write, or delete actions and supports Always Allow, Always Ask, and Always Deny. An approval card for Always Ask exposes the intended tool action before execution. Rules can be set centrally and narrowed at project level; project rules cannot be less restrictive than the governing group rule. GitLab documents fail-closed behavior for persistent governance-resolution errors.

Background runner execution needs special care: there may be no human present to answer an interactive approval prompt. Current documentation says Runner governance supports only allow/deny, not Always Ask. Therefore high-impact background actions should default to deny unless a separately approved workflow and protected environment can safely authorize them.

8. RBAC, composite identity, and tool governance answer different questions

GitLab role-based access control determines whether an authenticated principal may access a project/resource. Agent tool governance determines whether the AI is allowed to attempt a particular tool. Flows can use service-account/composite-identity mechanisms so execution does not escape the initiating user’s authorized scope. These controls overlap but are not substitutes.

9. AI security remediation is an untrusted proposal, not an automatic truth source

Vulnerability Explanation and Vulnerability Resolution can accelerate analysis and generate proposed fixes for supported findings, but GitLab explicitly warns that AI output is not guaranteed correct. The review target is not “does the patch look plausible?” It is: does the scanner finding disappear for the right reason, do tests preserve behavior, does the diff avoid unrelated scope expansion, and does the patch follow project security standards?

AI REMEDIATION REVIEW RECORD
Finding: synthetic path traversal in template lookup
Proposal source: fixture (no live AI call)
Expected security invariant: resolved path must remain under approved base directory
Functional invariant: valid template names still load
Evidence required:
  - focused unit tests
  - negative traversal test
  - diff review
  - security finding / static analysis re-check
  - no new external dependency or privilege
Decision: APPROVE / REJECT with reviewer and evidence IDs

10. Read-only inspection comes before enabling or spending

In a real namespace, start by documenting current state. Do not click “enable,” start a trial, accept billing terms, or run a flow merely to discover whether the feature exists. Inspect the current GitLab Duo settings, feature documentation, subscription/credit state, feature-preview configuration, user role, and runner requirements first.

READ-ONLY PREFLIGHT
[ ] offering and exact GitLab version recorded
[ ] top-level namespace/group identified
[ ] user role recorded
[ ] feature-specific tier/add-on/credits requirement verified in current docs
[ ] GitLab Duo availability inherited state recorded
[ ] Agent Platform availability recorded
[ ] beta/experimental feature-preview setting recorded
[ ] data/privacy and prompt-caching settings reviewed
[ ] tool-governance policy reviewed
[ ] flow runner/network requirement reviewed
[ ] no billable/trial setting changed

Knowledge check

11. Lesson summary and bridge

• GitLab Duo assistance and Agent Platform automation are related but have different authority, billing, maturity, and execution models.
• Availability is determined by multiple independent gates: offering/version, tier/add-on/credits, namespace controls, role, feature status, runner state, and tool governance.
• Data governance must account for prompt/context selection, model/subprocessor boundaries, history, caching, optional logging, and tool results.
• Tool governance does not replace RBAC, and RBAC does not make an AI-requested action appropriate.
• AI-generated remediation remains an untrusted proposal until independently verified and approved.

Next, you will convert this mental model into a completely local fixture lab: inspect feature state, classify tools, test remediation proposals, record a denied action, and build sanitized audit evidence without spending credits.

Primary sources and version notes

These lessons were finalized against current official GitLab documentation on 2026-08-22 with GitLab 19.3 as the release baseline. GitLab Duo and the Agent Platform are unusually version-volatile: feature maturity, model selection, credits, availability, governance behavior, UI placement, and data-processing details can change between releases. Re-check the documentation for the exact offering, subscription, add-on, and GitLab version you use. Current documentation notes that agents and several flow capabilities are GA, while AI audit-event reporting and some governance integrations can remain beta or feature-flagged. Do not generalize one feature’s support level to the entire Agent Platform.

• GitLab 19.3 release
• GitLab Duo Agent Platform
• GitLab Duo non-agentic feature summary
• GitLab Credits and usage billing
• GitLab Duo data usage and privacy
• Control GitLab Duo availability
• Control Agent Platform availability
• Agents
• Flows
• Foundational flows
• Configure flow execution
• Agent tool governance
• Audit AI events
• GitLab Duo prompt guardrails
• GitLab Duo contextual awareness
• GitLab Duo Chat
• Explain vulnerabilities with AI
• Resolve vulnerabilities with AI
• Troubleshoot the Agent Platform