Proteja sua fábrica de software

O GitLab Security
Standard

As organizações estão migrando para um mundo em que os agentes desenvolvem software sem um humano em cada passo. O GitLab Security Standard mostra como chegar lá com segurança: fundamentos de segurança que fortalecem a fábrica de software e etapas em que os agentes conquistam autonomia.

v1.0Publicado em 6 de outubro de 2026

A economia mudou

Código é abundante. Confiança é escassa. Os mesmos modelos de IA que permitem aos agentes escrever e entregar código na velocidade das máquinas também tornam mais rápido e barato descobrir, conectar e explorar fraquezas existentes. O volume de descobertas agora cresce mais rápido do que as equipes conseguem verificar, priorizar e corrigir o que importa.

Confie nos seus agentes

Pirâmide de cinco etapas, Autorizar, Isolar, Verificar, Liberar e Responder, sobre uma base de políticas, auditoria e responsabilidade, com a autonomia no topo e um ciclo de encontrar, corrigir e aprender que devolve as falhas à base.

Nossa abordagem para construir confiança em uma frota de agentes começa pela fábrica de software em que eles trabalham. A segurança está incorporada em cada etapa, de modo que os agentes operam sob controles que não podem contornar, e a autonomia não é concedida. Ela é conquistada, uma etapa de cada vez.

Cinco etapas, construídas sobre uma base de políticas, auditoria e responsabilidade, definem o que cada agente precisa comprovar. Quanto mais um agente comprova, mais autonomia ele conquista.

Base · Onde a confiança começa

Políticas, auditoria, responsabilidade

Regras a serem aplicadas, um registro do que aconteceu e uma pessoa nomeada responsável quando elas falham. Sem a base, nenhuma etapa pode ser comprovada.

  • Políticas

    Pessoas definem o que os agentes podem e não podem fazer: quais ferramentas usam, o que podem acessar e quais ações precisam de aprovação. Essas políticas são definidas e aprovadas antes que qualquer código seja escrito e depois aplicadas automaticamente.

  • Auditoria

    Uma trilha de auditoria imutável de cada agente e modelo, até cada prompt, etapa de raciocínio, chamada de ferramenta e ação, vinculada da tarefa à implantação.

  • Responsabilidade

    Cada agente, conta de serviço e controle tem uma pessoa nomeada como responsável.

  1. 01Autorizar

    Propósito

    Quem e o que pode agir, e dentro de quais limites?

    Cada pessoa, agente e serviço tem uma identidade conhecida ou composta, um responsável nomeado e acesso limitado à tarefa em questão.

    Exemplos de controles

    1. Inventário de agentesCada agente, integração e conta de serviço é conhecido e tem um responsávelCatálogo de IA
    2. Identidade do agenteCada ação de um agente pode ser rastreada até o agente e a pessoa que a acionouIdentidade composta
    3. Gerenciamento de segredosCentralizado, com privilégio mínimo, rotacionado e revogável, com escopo e vida útil definidos para cada credencialGitLab Secrets Manager

  2. 02Isolar

    Propósito

    Uma entrada ou ferramenta comprometida pode ir além da tarefa?

    O trabalho é executado em um ambiente isolado cujos limites se mantêm mesmo quando o agente segue uma instrução maliciosa.

    Exemplos de controles

    1. Execução isoladaEspaço de trabalho efêmero com armazenamento e rede restritosAmbiente de execução do Duo Agent Platform
    2. Dependências confiáveisOs pacotes passam por um proxy controlado e são verificados antes de chegarem ao buildDependency FirewallBeta fechado
    3. Ferramentas e caminhos de acesso autorizadosOs agentes usam apenas ferramentas, conexões e servidores MCP aprovadosGovernança de IABeta

  3. 03Verificar

    Propósito

    A alteração é segura, verificada por controles que quem age não pode modificar?

    Cada alteração, humana ou de agente, passa por verificações de segurança aplicadas de forma centralizada, que não podem ser modificadas nem dispensadas.

    Exemplos de controles

    1. Políticas no caminho de execuçãoVarreduras, aprovações e controles de implantação são aplicados de forma centralizada, não por projetoPolíticas de execução de pipeline
    2. Verificações protegidasQuem age não pode editar o pipeline ou a política que o avaliaBranches protegidos
    3. Separação de funçõesO autor, humano ou agente, não pode ser o único aprovadorPolíticas de aprovação de merge requests

  4. 04Liberar

    Propósito

    A produção recebe exatamente o que foi verificado?

    As decisões de implantação são vinculadas ao artefato exato que passou na verificação, identificado por digest e procedência, e não por nome ou rótulo de versão.

    Exemplos de controles

    1. Procedência e assinaturaCada artefato traz evidências assinadas de origem, entradas e buildGeração de procedência SLSA
    2. Verificar antes de implantarO digest implantado precisa corresponder ao aprovadoVerificação de atestação de artefatos
    3. Referências imutáveisTags e imagens não podem ser sobrescritas após a aprovaçãoTags de contêiner protegidas

  5. 05Responder

    Propósito

    Conseguimos interromper, rastrear e recuperar?

    Atividades suspeitas e resultados vulneráveis se conectam a uma resposta capaz de interromper a tarefa, rastrear o que ela afetou e verificar a correção.

    Exemplos de controles

    1. Interruptor de emergência testadoInterrompa uma tarefa, revogue o acesso, pause as liberaçõesBloqueio de contas de serviço
    2. Rastreie o impactoIdentifique cada alteração e cada liberação que um agente afetouEventos de auditoria
    3. Monitore ações relevantesO uso de ferramentas, o acesso a credenciais, as alterações de permissões e as implantações ficam visíveisStreaming de eventos de auditoria

O ciclo de feedback

Encontre, corrija e aprenda

Quando algo falhar, aprenda com isso e atualize a política, para que as regras melhorem antes que a autonomia seja restaurada.

Ao mesmo tempo, agentes de segurança detectam, fazem a triagem e corrigem vulnerabilidades continuamente.

Correção automatizada

O que medimos

  • Tempo até a contenção
  • Tempo até a correção verificada

Alinhamento com frameworks

O padrão se alinha aos frameworks que suas equipes de segurança e conformidade já usam nos relatórios.

EtapaOWASP SAMMOWASP Top 10 for Agentic ApplicationsMITRE ATLASNIST SSDF & SP 800-53
BasePolíticas, auditoria, responsabilidade
  • Least agency (princípio central)
  • SSDF PO.1, PO.2, PO.3
  • SP 800-53 AU
01Autorizar
  • 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
02Isolar
  • 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
03Verificar
  • ASI05 Unexpected Code Execution
  • ASI09 Human-Agent Trust Exploitation
  • SSDF PO.4, PW.7, PW.8
04Liberar
  • ASI04 Agentic Supply Chain Vulnerabilities
  • SSDF PS.2, PS.3
  • SP 800-53 SI-7, SR-4
05Responder
  • ASI10 Rogue Agents
  • SSDF RV.1 a RV.3
  • SP 800-53 IR, AU

O MITRE ATLAS cataloga técnicas de adversários contra sistemas de IA, por isso nem toda etapa tem uma correspondência direta.

Autonomia conquistada

A autonomia é concedida por fluxo de trabalho, e cada fluxo de trabalho precisa passar nos testes de cada etapa antes de conquistar mais. Fluxos de trabalho diferentes podem operar com níveis diferentes de autonomia ao mesmo tempo.

  • O que o agente pode fazer
    Recomendar; pessoas fazem a alteração
    Exemplo de fluxo de trabalho
    Configuração de pipelines e políticas (alterações nos próprios controles)

Seus agentes conquistaram autonomia?

Solicite sua avaliação gratuita e descubra como conquistar o próximo nível de autonomia no seu ambiente.

Todos os campos são obrigatórios

O GitLab aplica este padrão à sua própria fábrica de software. Ele é público, de acesso livre e está em constante evolução. À medida que as ameaças, os modelos e nossas próprias capacidades mudarem, continuaremos atualizando-o e mostrando o que mudou.