Securing your software factory

The GitLab Security
Standard

Organizations are transitioning to a world where agents build software without a human in every step. The GitLab Security Standard shows how to get there securely: security fundamentals that harden the software factory, and stages that let agents earn autonomy.

v1.0Published October 6, 2026

The economics have changed

Code is abundant. Trust is scarce. The same AI models that let agents write and ship code at machine speed also make existing weaknesses faster and cheaper to discover, connect, and exploit. Discovery volume is now rising faster than teams can verify, prioritize, and remediate what matters.

Trust your agents

Pyramid of five stages, Authorize, Isolate, Verify, Release, and Respond, on a base of policy, audit, and ownership, with autonomy at the top and a find, fix, and learn loop that returns failures to the base.

Our approach to building trust in a fleet of agents starts with the software factory they work in. Security is embedded at every stage, so agents operate under controls they can't bypass, and autonomy isn't given. It's earned, one stage at a time.

Five stages, built on a foundation of policy, audit, and ownership, define what every agent must prove. The more an agent proves, the more autonomy it earns.

Foundation · Where trust starts

Policy, Audit, Ownership

Rules to enforce, a record of what happened, and a named human accountable when they fail. Without the foundation, no stage can be proven.

  • Policy

    Humans define what agents can and can't do: which tools they use, what they can touch, and which actions need approval. Those policies are defined and approved before any code is written, then enforced automatically.

  • Audit

    An immutable audit trail of every agent and model, down to each prompt, reasoning step, tool call, and action, linked from task to deployment.

  • Ownership

    Every agent, service account, and control is accountable to a named human.

  1. 01Authorize

    Purpose

    Who and what can act, and within what limits?

    Every person, agent, and service has a known or composite identity, a named owner, and access scoped to the task at hand.

    Example controls

    1. Agent inventoryEvery agent, integration, and service account is known, with an ownerAI Catalog
    2. Agent identityEvery agent action traces to the agent and the human who triggered itComposite identity
    3. Secrets managementCentralized, least privilege, rotated, and revocable, with a defined scope and lifetime for every credentialGitLab Secrets Manager

  2. 02Isolate

    Purpose

    Can a compromised input or tool reach beyond the task?

    Work runs in a contained environment whose boundaries hold even when the agent follows a malicious instruction.

    Example controls

    1. Isolated executionEphemeral workspace with restricted storage and networkDuo Agent Platform execution environment
    2. Trusted dependenciesPackages are pulled through a controlled proxy and checked before they reach the buildDependency FirewallClosed beta
    3. Sanctioned tools and access pathsAgents use only approved tools, connections, and MCP serversAI GovernanceBeta

  3. 03Verify

    Purpose

    Is the change safe, checked by controls the actor cannot touch?

    Every change, human or agent, passes security checks that are centrally enforced and that cannot be modified or waived.

    Example controls

    1. Policy in the execution pathScans, approvals, and deployment controls are enforced centrally, not per projectPipeline execution policies
    2. Protected checksThe actor cannot edit the pipeline or policy that judges itProtected branches
    3. Separation of dutiesThe author, human or agent, cannot be the sole approverMerge request approval policies

  4. 04Release

    Purpose

    Does production get exactly what was verified?

    Deployment decisions bind to the exact artifact that passed verification, identified by digest and provenance, not by name or version label.

    Example controls

    1. Provenance and signingEvery artifact carries signed evidence of source, inputs, and buildSLSA provenance generation
    2. Verify before deployThe deployed digest must match the approved oneArtifact attestation verification
    3. Immutable referencesTags and images cannot be overwritten after approvalProtected container tags

  5. 05Respond

    Purpose

    Can we stop it, trace it, and recover?

    Suspicious activity and vulnerable output connect to a response that can stop the task, trace what it touched, and verify the fix.

    Example controls

    1. Tested kill switchStop a task, revoke its access, pause releasesService account blocking
    2. Trace impactIdentify every change and release an agent touchedAudit events
    3. Monitor consequential actionsTool use, credential access, permission changes, and deployments are visibleAudit event streaming

The feedback loop

Find, fix, and learn

When something fails, learn from it and update the policy, so the rules improve before autonomy is restored.

At the same time, security agents continuously detect, triage, and remediate vulnerabilities.

Automated remediation

What we measure

  • Time to containment
  • Time to verified remediation

Framework alignment

The standard maps to the frameworks your security and compliance teams already report on.

StageOWASP SAMMOWASP Top 10 for Agentic ApplicationsMITRE ATLASNIST SSDF & SP 800-53
FoundationPolicy, Audit, Ownership
  • Least agency (core principle)
  • SSDF PO.1, PO.2, PO.3
  • SP 800-53 AU
01Authorize
  • ASI03 Identity and Privilege Abuse
  • ASI07 Insecure Inter-Agent Communication
  • ASI10 Rogue Agents
  • SSDF PS.1
  • SP 800-53 AC-2, AC-5, AC-6, CM-3, CM-5, IA, SA-11
02Isolate
  • ASI01 Agent Goal Hijack
  • ASI02 Tool Misuse and Exploitation
  • ASI04 Agentic Supply Chain Vulnerabilities
  • ASI05 Unexpected Code Execution
  • ASI06 Memory and Context Poisoning
  • ASI08 Cascading Failures
  • SSDF PO.5, PW.4
  • SP 800-53 SC-7, SC-39, SR
03Verify
  • ASI05 Unexpected Code Execution
  • ASI09 Human-Agent Trust Exploitation
  • SSDF PO.4, PW.7, PW.8
04Release
  • ASI04 Agentic Supply Chain Vulnerabilities
  • SSDF PS.2, PS.3
  • SP 800-53 SI-7, SR-4
05Respond
  • ASI10 Rogue Agents
  • SSDF RV.1 to RV.3
  • SP 800-53 IR, AU

MITRE ATLAS catalogs adversary techniques against AI systems, so not every stage has a direct match.

Earned autonomy

Autonomy is granted per workflow, and each workflow must pass every stage's tests before it earns more. Different workflows can operate at different levels of autonomy at the same time.

  • What the agent may do
    Recommend; humans make the change
    Example workflow
    Pipeline and policy config (changes to the controls themselves)

Have your agents earned autonomy?

Request your free assessment on how to earn the next level of autonomy in your environment.

All fields required

GitLab runs this standard against its own software factory. It's public, ungated, and always evolving. As threats, models, and our own capabilities change, we'll keep updating it and show what changed.