Un proceso seguro de desarrollo de código con agentes no consiste solo en usar un LLM más grande

TL;DR

• No estamos limitados a usar solo LLM grandes para escribir código seguro, pero sí conviene usar modelos más potentes para razonamientos de seguridad ambiguos, decisiones de arquitectura y revisión de código de alto riesgo.
• La evidencia actual indica que el tamaño del modelo, por sí solo, no es un control de seguridad confiable. La actualización de Veracode de Spring 2026 informa que solo el 55% de las tareas de generación de código con IA evaluadas produjeron código seguro, y que la pequeña ventaja que antes ofrecía el tamaño del modelo prácticamente ha desaparecido.
• Investigaciones anteriores encontraron señales de alerta similares: Copilot produjo programas vulnerables en aproximadamente el 40% de los escenarios evaluados, y un estudio con usuarios encontró que los participantes con un asistente de IA escribieron código considerablemente menos seguro, pese a tener más confianza en el resultado.
• Un flujo seguro con agentes debe tratar el modelo como un componente dentro de un SDLC controlado: requisitos de seguridad, contexto confiable, ejecución en un sandbox, herramientas con privilegios mínimos, análisis estático, escaneo de dependencias, escaneo de secretos, evals adversariales y puntos de aprobación humana.
• Las pruebas unitarias y E2E forman parte de los controles de seguridad: las pruebas unitarias fijan las reglas de validación y autorización, mientras que las pruebas E2E demuestran que los flujos reales de usuario preservan esos controles a través del navegador, la API, la sesión y las capas de datos.
• El objetivo práctico no es «código libre de vulnerabilidades». Esa afirmación es demasiado categórica. El objetivo es un proceso repetible que reduzca la introducción de vulnerabilidades, detecte fallas comunes antes del merge y produzca evidencia auditable.

La hipótesis es tentadora:

Para generar código sensible desde el punto de vista de la seguridad, quizá solo los LLM más grandes sean suficientemente buenos.

Mi respuesta, después de revisar la evidencia actual, es:

Los modelos más grandes ayudan, pero no son el control. El control es el proceso con agentes que rodea al modelo.

Esa distinción importa. Un modelo de frontera puede razonar mejor sobre límites de confianza, flujos de autenticación, modelos de amenazas y detalles sutiles de implementación. Pero un modelo más grande sigue leyendo contexto no confiable, heredando patrones inseguros de los datos de entrenamiento, interpretando mal las políticas específicas de la aplicación y pudiendo ejecutar llamadas inseguras a herramientas si el entorno de ejecución se lo permite.

En seguridad, «el modelo es inteligente» no es una defensa. Un sistema seguro de desarrollo de código con agentes necesita un proceso que asuma que el modelo a veces se equivocará.

Lo que realmente dice la evidencia

La señal más clara en la evidencia actual es que la seguridad del código generado por IA no mejora al mismo ritmo que su corrección funcional.

La actualización Spring 2026 GenAI Code Security Update de Veracode evaluó las principales versiones de modelos en 80 tareas de programación, cuatro lenguajes y cuatro clases de CWE: inyección SQL, cross-site scripting, inyección en logs y criptografía insegura. Su resultado principal fue incómodo: considerando todos los modelos y tareas, solo el 55% de las tareas de generación produjo código seguro. La corrección sintáctica superó el 95%, pero las tasas de aprobación en seguridad se mantuvieron prácticamente estables. Veracode también informó que el tamaño del modelo tuvo un efecto muy pequeño en su actualización de octubre de 2025 y que esa diferencia marginal había desaparecido en gran medida en las versiones más recientes.

Esto respalda una parte de la hipótesis y rechaza otra:

• sí, la capacidad importa para el razonamiento complejo sobre seguridad
• no, el tamaño del modelo por sí solo no basta para confiar en el código generado

Esto coincide con trabajos académicos anteriores. En «Asleep at the Keyboard?», Pearce et al. generaron 1,689 programas con Copilot en 89 escenarios relevantes para la seguridad y encontraron que aproximadamente el 40% eran vulnerables. En «Do Users Write More Insecure Code with AI Assistants?», Perry et al. encontraron que los participantes con acceso a un asistente de IA escribieron código considerablemente menos seguro que quienes no lo tenían, y que también eran más propensos a creer que su código era seguro.

Los benchmarks más recientes apuntan en la misma dirección. CyberSecEval 4 incluye AutoPatchBench, que evalúa si un agente basado en un LLM puede corregir automáticamente vulnerabilidades de seguridad en código nativo. A.S.E, un benchmark de seguridad del código generado por IA a nivel de repositorio, informa que los LLM actuales aún tienen dificultades en entornos realistas a nivel de repositorio y que un mayor presupuesto de razonamiento no necesariamente produce código más seguro. «Rethinking the Evaluation of Secure Code Generation» también advierte que las técnicas de generación de código seguro pueden sacrificar funcionalidad y que depender de un solo analizador estático puede ocultar riesgos reales.

El patrón es claro:

Por qué el desarrollo de código con agentes plantea un problema de seguridad diferente

El riesgo de la generación de código tradicional se concentra principalmente en el texto del código:

• construcción insegura de consultas SQL
• criptografía débil
• falta de verificaciones de autorización
• deserialización insegura
• escape incorrecto de caracteres
• secretos codificados directamente en el código

El desarrollo con agentes agrega otra capa: el agente puede leer archivos, ejecutar comandos, llamar herramientas, navegar por la web, instalar dependencias, modificar código y, a veces, hacer push de cambios. Eso significa que la pregunta de seguridad pasa a ser:

¿Qué puede hacer el agente cuando se equivoca, se confunde o es manipulado?

El Top 10 de OWASP de 2025 para aplicaciones LLM y GenAI enumera riesgos que se aplican directamente a los agentes de programación: prompt injection, riesgo en la cadena de suministro, manejo inadecuado de salidas, autonomía excesiva, exposición de información sensible y consumo sin límites. La guía de amenazas de OWASP Agentic AI plantea esto como un problema de modelado de amenazas, no solo de calidad de los prompts.

La guía de seguridad para agentes de OpenAI recomienda diseñar flujos de trabajo en los que los datos no confiables nunca dirijan directamente el comportamiento del agente, usar salidas estructuradas, mantener activadas las confirmaciones de herramientas, usar guardrails y ejecutar evaluadores de trazas y evals. La documentación de acceso a internet de Codex de OpenAI señala el prompt injection desde contenido web no confiable, la exfiltración de código o secretos, el malware o las dependencias vulnerables y el contenido con riesgos de licencia como razones para mantener limitado el acceso a la red.

La documentación de seguridad de Claude Code de Anthropic usa una arquitectura similar: acceso de solo lectura por defecto, aprobación explícita para operaciones sensibles, bash en un sandbox, límites de escritura, listas de bloqueo para comandos riesgosos que recuperan contenido web y responsabilidad del usuario de revisar el código y los comandos propuestos.

La estrategia de seguridad de IA de Google ofrece un principio conciso para la seguridad de los agentes: necesitan responsables humanos claramente definidos, facultades cuidadosamente limitadas y acciones y planes observables.

Ese es el consenso actual de la industria: los agentes seguros son sistemas controlados.

El proceso actual para desarrollar código de forma segura con agentes

Este es el proceso que usaría para un equipo de ingeniería que desarrolla código con agentes de IA en 2026.

1. Comienza con una especificación de seguridad, no con un prompt de programación

Antes de que el agente escriba código, dale un contrato de seguridad:

• activos: secretos, datos de clientes, credenciales, tokens, salidas de modelos, logs
• límites de confianza: navegador, API, worker, base de datos, servicio de terceros, herramienta del agente
• entradas controladas por un atacante: cuerpo de la solicitud, markdown, texto de un issue, README de una dependencia, archivo cargado, resultado de una herramienta
• controles requeridos: autenticación, autorización, validación, escape de caracteres, límites de tasa, logs de auditoría, valores predeterminados seguros
• patrones prohibidos: concatenación de cadenas SQL sin parametrizar, eval, secretos codificados directamente en el código, criptografía débil, permisos amplios de IAM, scripts remotos sin versión fijada
• evidencia de aceptación: pruebas, resultados de escáneres, lista de revisión, notas del modelo de amenazas

Esto convierte «desarrollar la funcionalidad X» en «desarrollar la funcionalidad X bajo estas restricciones de seguridad».

Un buen agente debe producir un plan que incluya las premisas de seguridad antes de tocar los archivos. Si el agente no puede explicar el límite de confianza, no está listo para generar la implementación.

2. Divide el flujo de trabajo en roles

Usa distintos roles incluso si se ejecutan sobre el mismo modelo:

• Planificador: convierte la solicitud de la funcionalidad en un plan de implementación acotado y un modelo de amenazas
• Implementador: escribe el cambio de código más pequeño que cumple con el plan
• Revisor de seguridad: revisa el diff frente a OWASP, CWE, las políticas del proyecto y los riesgos en el flujo de datos
• Verificador: ejecuta pruebas, SAST, SCA, escaneo de secretos, linting y comprobaciones específicas de explotación
• Control de liberación: decide si el cambio necesita una revisión de seguridad humana antes del merge

Esto no es teatro. Obliga al sistema a separar la generación de la evaluación. El agente que escribió el código no debería ser la única autoridad que declare que es seguro.

3. Asigna modelos según el riesgo, no según el ego

No necesitas un modelo de frontera para cada paso. Sí necesitas uno cuando importan la ambigüedad y la profundidad del razonamiento.

Usa un modelo más potente para:

• modelado de amenazas
• diseño de autenticación y permisos
• elección de mecanismos criptográficos
• refactors que afectan varios archivos y límites de confianza
• revisión de diffs sensibles desde el punto de vista de la seguridad
• decidir si un hallazgo de un escáner es explotable

Usa un modelo más pequeño o económico para:

• convertir los resultados de escáneres en issues
• resumir diffs
• comprobar que las listas de verificación estén completas
• clasificar archivos por categoría de riesgo
• generar pruebas repetitivas a partir de una especificación explícita

Usa herramientas deterministas para:

• SAST
• SCA y escaneo de vulnerabilidades en dependencias
• escaneo de secretos
• verificación de tipos
• linting
• formato
• pruebas unitarias y de integración
• escaneo de IaC y contenedores

La lección de la evidencia no es «los modelos pequeños son seguros». Es «el tamaño del modelo no es el lugar correcto para establecer el límite de seguridad».

4. Trata el contexto recuperado como datos no confiables

Los agentes de programación suelen leer issues de GitHub, documentación, archivos README, páginas de paquetes, fragmentos de Stack Overflow, tickets internos y páginas web. Cualquiera de ellos puede contener instrucciones que no forman parte de tu tarea.

La regla debería ser:

El contenido externo puede aportar información a la tarea, pero no puede conceder permisos, cambiar políticas, solicitar secretos ni provocar la ejecución de herramientas.

Patrones de implementación:

• encapsula el texto recuperado en bloques explícitos de untrusted_content
• extrae información estructurada del contenido no confiable antes de planificar
• exige citas o referencias a archivos para las afirmaciones fácticas
• no pases texto no confiable a los canales de instrucciones de desarrollador o de sistema
• bloquea por defecto el tráfico saliente de red durante la ejecución de código
• usa listas de permitidos para hosts de dependencias y registros de paquetes
• exige aprobación humana para comandos que leen secretos, suben datos, instalan paquetes o modifican infraestructura

Esto es especialmente importante para los agentes de programación porque las instrucciones maliciosas pueden ocultarse en lugares que los ingenieros normalmente leen por encima: descripciones de issues, comentarios, scripts de instalación de dependencias, documentación, fixtures de prueba y markdown generado.

5. Reduce los permisos de las herramientas

La seguridad de los agentes consiste, en gran medida, en diseñar permisos.

Dale al agente la autoridad mínima necesaria para el paso actual:

• acceso de solo lectura al repositorio durante la planificación
• acceso de escritura solo al directorio de trabajo
• ninguna credencial de producción
• ningún permiso de administrador de la nube por defecto
• ningún acceso irrestricto a internet
• ninguna instalación automática de paquetes desde URLs arbitrarias
• ningún acceso de escritura directo a bases de datos de producción
• ninguna capacidad de hacer merge, desplegar, rotar secretos o aprobar su propio PR

Para la ejecución local, usa un sandbox o contenedor. Para la ejecución en la nube, usa credenciales efímeras, listas de permitidos de red acotadas y cuentas de servicio con permisos limitados. Para herramientas MCP o conectores, separa las herramientas de lectura de las de escritura y exige aprobaciones para acciones con efectos secundarios.

El agente debe ser productivo dentro de un entorno limitado. Si necesita salir de él, eso es un evento de seguridad que vale la pena revisar.

6. Genera código en cambios pequeños y fáciles de revisar

Generar código seguro se vuelve más difícil a medida que crece el diff.

Los buenos cambios hechos por agentes tienen estas características:

• una funcionalidad o corrección a la vez
• son lo bastante pequeños para revisarlos línea por línea
• están cubiertos por pruebas en el mismo PR
• muestran explícitamente el flujo de datos
• muestran explícitamente el manejo de errores
• muestran explícitamente las verificaciones de autenticación y permisos
• se pueden rastrear hasta una especificación o un issue

Los malos cambios hechos por agentes incluyen:

• «refactoriza todo el sistema de autenticación»
• «moderniza la capa de API»
• «haz que esto sea seguro»
• «agrega pruebas en todas partes»
• cientos de líneas repartidas entre módulos que no están relacionados

El agente debe optimizar para facilitar la revisión, no para maximizar el volumen de código.

7. Ejecuta controles de seguridad antes de la revisión humana

Todo PR de código desarrollado con agentes debería adjuntar evidencia.

Comprobaciones mínimas:

• pruebas unitarias
• pruebas de integración para los límites de API modificados
• verificación de tipos
• linter
• SAST para el lenguaje correspondiente
• escaneo de vulnerabilidades en dependencias
• escaneo de secretos
• revisión del lockfile de paquetes
• escaneo de licencias si se recuperó contenido de internet o se agregaron dependencias

Los cambios sensibles desde el punto de vista de la seguridad deberían agregar:

• pruebas de casos de abuso
• pruebas negativas de autorización
• pruebas de validación de entradas
• pruebas de regresión para inyección SQL o XSS cuando corresponda
• fuzzing para parsers, entradas de archivos y manejadores de protocolos
• escaneo de IaC para cambios en la nube o Kubernetes
• escaneo de contenedores para artefactos desplegables

El agente verificador puede resumir la evidencia, pero las herramientas deterministas deben producir los resultados que la respaldan.

8. Usa pruebas unitarias y E2E como evidencia de seguridad

Las pruebas unitarias y las pruebas E2E cumplen funciones de seguridad diferentes. Necesitas ambas.

Las pruebas unitarias son la forma más rápida de convertir reglas de seguridad en invariantes ejecutables. Son especialmente útiles para:

• validación de entradas: se rechazan payloads maliciosos antes de que lleguen al almacenamiento, al renderizado o a la ejecución de comandos
• codificación y escape de salidas: las cadenas no confiables se transforman de manera consistente antes de mostrarse
• lógica de autorización: se deniega el acceso a los usuarios que no tienen el rol, scope, tenant o relación de propiedad necesarios
• reglas de límites de tasa y bloqueo: los contadores, las ventanas y el comportamiento de restablecimiento funcionan a nivel de función
• wrappers criptográficos: solo se aceptan algoritmos, modos y tamaños de clave aprobados
• manejo de secretos: las utilidades de redacción eliminan tokens, claves de API y credenciales de los logs y errores
• comportamiento de los parsers: ante JSON, markdown, HTML, CSV, YAML o archivos cargados malformados, se deniega el procesamiento por defecto

Para el código generado por IA, las pruebas unitarias tienen un beneficio adicional: obligan al agente a expresar el requisito de seguridad de una forma que el repositorio puede conservar. Un prompt desaparece. Una prueba unitaria permanece en CI.

Las buenas pruebas unitarias de seguridad suelen ser pruebas negativas:

it("denies access when the user belongs to a different tenant", () => {
  const user = { id: "u_1", tenantId: "tenant_a", role: "member" };
  const resource = { id: "doc_1", tenantId: "tenant_b" };

  expect(canReadDocument(user, resource)).toBe(false);
});

it("redacts API tokens before writing structured logs", () => {
  const logEvent = redactSecrets({
    message: "request failed",
    authorization: "Bearer sk_live_123",
  });

  expect(JSON.stringify(logEvent)).not.toContain("sk_live_123");
});

Las pruebas E2E son más lentas, pero detectan las fallas que las pruebas unitarias, intencionalmente, no modelan:

• flujos de autenticación entre el navegador y la API
• flags de cookies y persistencia de sesión
• comportamiento ante CSRF
• cambio de tenant y enlaces profundos
• flujos de carga y descarga de archivos
• rutas de regresión de XSS a través del renderizado real
• flujos de restablecimiento de contraseña e invitación
• creación de logs de auditoría después de acciones sensibles
• errores de permisos tal como los ven los usuarios reales
• redirecciones, headers y guardias de rutas

En un proceso de desarrollo con agentes, las pruebas E2E deben ser selectivas. No le pidas al agente que genere cientos de pruebas de navegador frágiles. Pídele que genere recorridos de seguridad de alto valor:

1. un usuario anónimo no puede acceder a rutas autenticadas
2. un miembro no puede acceder al recurso de otro tenant cambiando la URL
3. una acción de administrador registra un evento de auditoría con actor, objetivo, acción, marca de tiempo e ID de solicitud
4. la entrada almacenada de un usuario se renderiza como texto, no como HTML ejecutable
5. cerrar sesión invalida la sesión y bloquea el acceso mediante el botón de retroceso
6. una acción destructiva requiere confirmación y falla si no hay protección contra CSRF

El valor para la auditoría es importante. La revisión de seguridad es más sencilla cuando un PR puede indicar que:

• la regla de autorización está cubierta por pruebas unitarias
• el flujo del navegador está cubierto por pruebas E2E
• la prueba verifica el registro de auditoría
• los nombres de las pruebas se corresponden con el riesgo en el modelo de amenazas
• los enlaces a las ejecuciones de CI respaldan la evidencia antes del merge

OWASP ASVS es útil aquí porque les da a los equipos un vocabulario común para los requisitos de verificación. OWASP WSTG es útil porque les da a quienes realizan las pruebas una metodología estructurada para evaluar la seguridad web. NIST SSDF es útil porque sitúa las pruebas como parte de la reducción de vulnerabilidades, la mitigación del impacto de su explotación y el tratamiento de las causas raíz.

Para la generación de código con agentes, la política práctica debería ser:

Esto convierte las pruebas en evidencia para la revisión, en lugar de un ritual impreciso de calidad.

9. Agrega una lista de revisión de seguridad para agentes

Esta lista debe aplicarse a cada PR generado o modificado por IA:

1. ¿El diff afecta la autenticación, la autorización, la criptografía, los secretos, los pagos, el aislamiento de tenants, la exportación de datos, la carga de archivos, la resolución de dependencias, la red, la infraestructura o los logs?
2. ¿Qué entradas controladas por un atacante llegan a este código?
3. ¿Qué límite de confianza cambió?
4. ¿Cada entrada externa se valida, codifica, escapa, parametriza o rechaza en el límite correcto?
5. ¿Los permisos son más acotados que antes?
6. ¿El agente agregó una dependencia, un script, un servidor MCP, una GitHub Action, una imagen de contenedor o un recurso remoto?
7. ¿Están ausentes los secretos del código, las pruebas, los logs, los prompts, las trazas y los artefactos generados?
8. ¿Los hallazgos de los escáneres se resolvieron, se suprimieron con justificación o se escalaron?
9. ¿El PR incluye pruebas unitarias para la regla de seguridad de bajo nivel y pruebas E2E o de integración para el flujo de seguridad visible para el usuario?
10. ¿Las pruebas verifican los eventos de auditoría de las acciones sensibles, incluidos el actor, el objetivo, la acción, la marca de tiempo y el ID de solicitud o correlación?
11. ¿Un prompt injection en un issue, documento, página web o salida de una herramienta cambiaría lo que ejecuta el agente?

Si la respuesta a cualquiera de estas preguntas no está clara, el PR no está listo.

10. Usa puntos de aprobación humana para acciones de alto riesgo

La revisión humana debe ser obligatoria cuando el agente modifica:

• autenticación
• autorización
• aislamiento de tenants
• criptografía
• manejo de secretos
• headers de seguridad
• registro de datos sensibles en logs
• instalación de dependencias
• flujos de CI/CD
• infraestructura como código
• acceso a datos de producción
• migraciones de bases de datos
• reglas de tráfico saliente de red
• permisos de herramientas del agente

Aquí es donde los modelos más potentes son más útiles como asistentes, no como responsables de la decisión. Deja que el modelo produzca el resumen del modelo de amenazas, los archivos afectados, la evidencia de los escáneres y los aspectos sugeridos para la revisión. Deja la aprobación en manos de una persona.

11. Mantén un registro de auditoría

En el desarrollo de código con agentes, el PR debe conservar:

• solicitud original del usuario
• plan del agente
• premisas de seguridad
• comandos ejecutados
• archivos modificados
• llamadas a herramientas
• resultados de escáneres
• pruebas ejecutadas
• riesgos residuales conocidos
• aprobaciones humanas

Esto importa para la respuesta a incidentes. Si una vulnerabilidad llega a producción, necesitas saber si la falla estuvo en el prompt, el modelo, la política de herramientas, la cobertura de los escáneres, la revisión humana o el control de despliegue.

Un flujo de trabajo de referencia práctico

Este es un flujo compacto que los equipos de ingeniería pueden adaptar:

1. Intake
   - classify feature risk
   - identify touched trust boundaries
   - define security acceptance criteria

2. Plan
   - agent reads trusted project context
   - agent produces implementation plan and threat model
   - human approves plan for high-risk changes

3. Generate
   - agent writes a small diff
   - sandboxed execution
   - least-privilege tools
   - network off or allowlisted

4. Verify
   - tests
   - type check
   - lint
   - SAST
   - SCA
   - secret scan
   - targeted security tests
   - unit tests for security invariants
   - E2E tests for high-risk user journeys
   - audit-log assertions for sensitive actions

5. Review
   - security-review agent checks diff
   - reviewer maps tests to threat model and ASVS/WSTG-style requirements
   - human reviews high-risk areas
   - findings become blocking issues

6. Merge
   - evidence attached to PR
   - approvals recorded
   - residual risk documented

7. Learn
   - production signals feed eval cases
   - vulnerabilities become regression tests
   - prompt and policy rules are updated

Lo más importante no es el conjunto específico de herramientas. Es que cada fase tenga un control explícito.

Qué debería significar «libre de vulnerabilidades» en la práctica

Ningún equipo de seguridad serio debería afirmar que un agente puede garantizar código libre de vulnerabilidades. Incluso el código escrito por personas, revisado manualmente y escaneado por completo puede contener vulnerabilidades.

Un objetivo mejor es:

El flujo de trabajo con agentes no debe poder hacer merge de código a menos que haya producido suficiente evidencia para el nivel de riesgo del cambio.

Para cambios de bajo riesgo en el texto de la interfaz, esa evidencia podría ser lint y build. Para un flujo de inicio de sesión, debería incluir pruebas de autenticación, pruebas negativas, resultados de escáneres, comprobaciones del comportamiento de la sesión y revisión humana. Para criptografía, debería incluir el uso de bibliotecas aprobadas y la revisión de la persona responsable de seguridad.

La seguridad no tiene un único umbral universal. Es un control ajustado al riesgo.

Las pruebas forman parte de ese control. Una prueba unitaria demuestra la regla de forma aislada. Una prueba E2E demuestra que la regla se mantiene en el recorrido real de usuarios y atacantes. Una verificación del log de auditoría demuestra que la organización puede reconstruir lo que ocurrió más adelante.

La conclusión sobre el tamaño del modelo

Si tu equipo está creando un flujo de desarrollo de código con IA, yo usaría modelos de frontera para las partes con mayor carga de seguridad. Son mejores para conectar arquitectura, código, políticas y requisitos ambiguos.

Pero no confiaría en ningún modelo, grande o pequeño, como control de seguridad final.

El proceso más sólido actualmente es independiente del modelo, de la misma manera en que la ingeniería segura siempre ha sido independiente de las herramientas:

• define requisitos de seguridad
• restringe la ejecución
• separa las instrucciones confiables de los datos no confiables
• limita los permisos
• escanea el resultado
• prueba casos de abuso
• revisa los cambios riesgosos
• registra lo que ocurrió
• convierte las fallas en pruebas de regresión

El futuro del desarrollo seguro de código con agentes no es «un gran modelo que escribe código seguro».

Es una fábrica de software segura donde los modelos ayudan en cada paso, pero el proceso se niega a confundir fluidez con seguridad.

Fuentes

1. Actualización Spring 2026 de Veracode sobre seguridad del código generado con GenAI - benchmark longitudinal que informa una tasa de aprobación de código seguro del 55% entre los modelos y tareas evaluados, con la seguridad rezagada frente a la corrección sintáctica.
2. CyberSecEval 4 - suite de evaluación de ciberseguridad de Meta, que incluye AutoPatchBench para agentes LLM que corrigen vulnerabilidades en código nativo.
3. CyberSecEval 3: avances en la evaluación de riesgos y capacidades de ciberseguridad en modelos de lenguaje grandes - suite de benchmarks que cubre múltiples categorías de riesgo de ciberseguridad para LLM.
4. ¿Dormidos frente al teclado? Evaluación de la seguridad de las contribuciones de código de GitHub Copilot - estudio empírico que encontró vulnerabilidades en aproximadamente el 40% de los programas generados por Copilot en escenarios relevantes para la seguridad.
5. ¿Los usuarios escriben código más inseguro con asistentes de IA? - estudio con usuarios que encontró que quienes usaban asistentes de IA escribían código considerablemente menos seguro y tenían más confianza en su seguridad.
6. A.S.E: un benchmark a nivel de repositorio para evaluar la seguridad del código generado por IA - benchmark a nivel de repositorio que muestra que los LLM actuales aún tienen dificultades para generar código seguro en contextos de proyectos realistas.
7. Replanteamiento de la evaluación de la generación de código seguro - artículo de ICSE 2026 que advierte que las técnicas de generación de código seguro pueden comprometer la funcionalidad y que una cobertura limitada de los analizadores puede distorsionar los resultados.
8. Top 10 de OWASP para aplicaciones LLM y GenAI 2025 - prompt injection, cadena de suministro, manejo inadecuado de salidas, autonomía excesiva y riesgos relacionados de las aplicaciones GenAI.
9. OWASP Agentic AI: amenazas y mitigaciones - referencia basada en modelos de amenazas para los riesgos y las mitigaciones de la IA con agentes.
10. Seguridad de OpenAI en la creación de agentes - guía sobre prompt injection, salidas estructuradas, confirmaciones de herramientas, guardrails, evaluadores de trazas y evals.
11. Acceso a internet del agente Codex de OpenAI - guía sobre prompt injection, exfiltración, malware, dependencias vulnerables, listas de permitidos y limitación del acceso de los agentes a la red.
12. Seguridad de Claude Code de Anthropic - guía de seguridad que cubre el acceso de solo lectura por defecto, las aprobaciones explícitas, bash en un sandbox, los límites de escritura, las listas de bloqueo de comandos y las protecciones contra prompt injection.
13. Estrategia de seguridad de IA de Google - principios de seguridad para agentes: responsables humanos, facultades limitadas y acciones y planes observables.
14. NIST SP 800-218: framework de desarrollo de software seguro - prácticas de SDLC seguro para reducir vulnerabilidades, mitigar el impacto de su explotación y abordar las causas raíz.
15. Framework de gestión de riesgos de IA de NIST: perfil de IA generativa - perfil de gestión de riesgos de IA generativa para distintos sectores, alineado con la gobernanza del ciclo de vida de la IA.
16. Anuncio de Project CodeGuard de Cisco - framework independiente del modelo para aplicar reglas de seguridad por defecto antes, durante y después de la generación de código con IA.
17. AgentDojo: un entorno dinámico para evaluar ataques de prompt injection y defensas para agentes LLM - benchmark para agentes que llaman herramientas y operan sobre datos no confiables, y para ataques de prompt injection.
18. Estándar de verificación de seguridad de aplicaciones de OWASP - requisitos de verificación y vocabulario para probar controles técnicos de seguridad.
19. Guía de pruebas de seguridad web de OWASP - metodología estructurada y escenarios para pruebas de seguridad de aplicaciones web.