Protege tu fábrica de software

El GitLab Security
Standard

Las organizaciones avanzan hacia un mundo en el que los agentes desarrollan software sin un humano en cada paso. El GitLab Security Standard muestra cómo llegar ahí de forma segura: fundamentos de seguridad que refuerzan la fábrica de software y etapas en las que los agentes se ganan la autonomía.

v1.0Publicado el 6 de octubre de 2026

La economía ha cambiado

El código abunda. La confianza escasea. Los mismos modelos de IA que permiten a los agentes escribir y entregar código a velocidad de máquina también hacen que las debilidades existentes sean más rápidas y baratas de descubrir, conectar y explotar. El volumen de hallazgos crece ahora más rápido de lo que los equipos pueden verificar, priorizar y corregir lo que importa.

Confía en tus agentes

Pirámide de cinco etapas, Autorizar, Aislar, Verificar, Publicar y Responder, sobre una base de políticas, auditoría y responsabilidad, con la autonomía en la cima y un ciclo de detectar, corregir y aprender que devuelve los fallos a la base.

Nuestro enfoque para generar confianza en una flota de agentes empieza por la fábrica de software en la que trabajan. La seguridad está integrada en cada etapa, de modo que los agentes operan bajo controles que no pueden eludir, y la autonomía no se concede. Se gana, etapa a etapa.

Cinco etapas, construidas sobre una base de políticas, auditoría y responsabilidad, definen lo que cada agente debe demostrar. Cuanto más demuestra un agente, más autonomía gana.

Base · Donde empieza la confianza

Políticas, auditoría, responsabilidad

Reglas que aplicar, un registro de lo que ocurrió y una persona designada responsable cuando fallan. Sin esta base, ninguna etapa puede demostrarse.

  • Políticas

    Las personas definen lo que los agentes pueden y no pueden hacer: qué herramientas usan, a qué pueden acceder y qué acciones requieren aprobación. Estas políticas se definen y aprueban antes de escribir cualquier código y después se aplican automáticamente.

  • Auditoría

    Un registro de auditoría inmutable de cada agente y modelo, hasta cada prompt, paso de razonamiento, llamada a herramienta y acción, vinculado desde la tarea hasta la implementación.

  • Responsabilidad

    Cada agente, cuenta de servicio y control tiene una persona designada como responsable.

  1. 01Autorizar

    Propósito

    ¿Quién y qué puede actuar, y con qué límites?

    Cada persona, agente y servicio tiene una identidad conocida o compuesta, un responsable designado y un acceso limitado a la tarea en cuestión.

    Controles de ejemplo

    1. Inventario de agentesCada agente, integración y cuenta de servicio es conocido y tiene un responsableCatálogo de IA
    2. Identidad de los agentesCada acción de un agente se puede rastrear hasta el agente y la persona que la desencadenóIdentidad compuesta
    3. Gestión de secretosCentralizada, con privilegios mínimos, rotada y revocable, con un alcance y una vida útil definidos para cada credencialGitLab Secrets Manager

  2. 02Aislar

    Propósito

    ¿Puede una entrada o herramienta comprometida ir más allá de la tarea?

    El trabajo se ejecuta en un entorno aislado cuyos límites se mantienen incluso cuando el agente sigue una instrucción maliciosa.

    Controles de ejemplo

    1. Ejecución aisladaEspacio de trabajo efímero con almacenamiento y red restringidosEntorno de ejecución de Duo Agent Platform
    2. Dependencias de confianzaLos paquetes se obtienen a través de un proxy controlado y se comprueban antes de llegar a la compilaciónDependency FirewallBeta cerrada
    3. Herramientas y rutas de acceso autorizadasLos agentes solo usan herramientas, conexiones y servidores MCP aprobadosGobernanza de IABeta

  3. 03Verificar

    Propósito

    ¿Es segura la modificación, comprobada por controles que quien actúa no puede tocar?

    Cada modificación, humana o de un agente, pasa controles de seguridad que se aplican de forma centralizada y que no se pueden modificar ni omitir.

    Controles de ejemplo

    1. Políticas en la ruta de ejecuciónLos análisis, las aprobaciones y los controles de implementación se aplican de forma centralizada, no por proyectoPolíticas de ejecución de pipelines
    2. Comprobaciones protegidasQuien actúa no puede editar el pipeline ni la política que lo evalúaRamas protegidas
    3. Separación de funcionesEl autor, sea humano o agente, no puede ser el único aprobadorPolíticas de aprobación de solicitudes de fusión

  4. 04Publicar

    Propósito

    ¿Recibe producción exactamente lo que se verificó?

    Las decisiones de implementación se vinculan al artefacto exacto que superó la verificación, identificado por su digest y su procedencia, no por su nombre ni por su etiqueta de versión.

    Controles de ejemplo

    1. Procedencia y firmaCada artefacto incluye evidencia firmada de su origen, sus entradas y su compilaciónGeneración de procedencia SLSA
    2. Verificar antes de implementarEl digest implementado debe coincidir con el aprobadoVerificación de atestaciones de artefactos
    3. Referencias inmutablesLas etiquetas y las imágenes no se pueden sobrescribir después de la aprobaciónEtiquetas de contenedor protegidas

  5. 05Responder

    Propósito

    ¿Podemos detenerlo, rastrearlo y recuperarnos?

    La actividad sospechosa y los resultados vulnerables se conectan con una respuesta capaz de detener la tarea, rastrear lo que tocó y verificar la corrección.

    Controles de ejemplo

    1. Interruptor de emergencia probadoDetén una tarea, revoca su acceso, pausa las versionesBloqueo de cuentas de servicio
    2. Rastrea el impactoIdentifica cada cambio y cada versión que tocó un agenteEventos de auditoría
    3. Supervisa las acciones relevantesEl uso de herramientas, el acceso a credenciales, los cambios de permisos y las implementaciones son visiblesStreaming de eventos de auditoría

El ciclo de retroalimentación

Detecta, corrige y aprende

Cuando algo falla, aprende de ello y actualiza la política, para que las reglas mejoren antes de restablecer la autonomía.

Al mismo tiempo, los agentes de seguridad detectan, clasifican y corrigen vulnerabilidades de forma continua.

Corrección automatizada

Qué medimos

  • Tiempo hasta la contención
  • Tiempo hasta la corrección verificada

Alineación con marcos de referencia

El estándar se corresponde con los marcos de referencia sobre los que tus equipos de seguridad y cumplimiento ya informan.

EtapaOWASP SAMMOWASP Top 10 for Agentic ApplicationsMITRE ATLASNIST SSDF & SP 800-53
BasePolíticas, auditoría, responsabilidad
  • Least agency (principio fundamental)
  • 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
02Aislar
  • 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
04Publicar
  • 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

MITRE ATLAS cataloga las técnicas de los adversarios contra los sistemas de IA, por lo que no todas las etapas tienen una correspondencia directa.

Autonomía ganada

La autonomía se concede por flujo de trabajo, y cada flujo de trabajo debe superar las pruebas de cada etapa antes de ganar más. Distintos flujos de trabajo pueden operar con distintos niveles de autonomía al mismo tiempo.

  • Qué puede hacer el agente
    Recomendar; las personas hacen el cambio
    Flujo de trabajo de ejemplo
    Configuración de pipelines y políticas (cambios en los propios controles)

¿Se han ganado tus agentes la autonomía?

Solicita tu evaluación gratuita para saber cómo alcanzar el siguiente nivel de autonomía en tu entorno.

Todos los campos son obligatorios

GitLab aplica este estándar a su propia fábrica de software. Es público, de acceso libre y está en constante evolución. A medida que cambien las amenazas, los modelos y nuestras propias capacidades, lo seguiremos actualizando y mostraremos qué ha cambiado.