Si tu equipo genera código con agentes, la pregunta ya no es si ese código funciona. Es quién comprueba que además sea seguro.
Esta pieza defiende una tesis que va contra la reacción más natural: pedir seguridad al agente, en la especificación o en el prompt, no la garantiza. Lo que no se comprueba no existe. La seguridad se escribe como criterio que se puede ejecutar y la verifica algo independiente del agente, en cada cambio. Y donde el riesgo es alto, decide una persona.
El dato: funciona, pero no es seguro
El 10 de octubre de 2026 se publicó en arXiv LSCBench, un benchmark de seguridad para agentes de código. Sus autores construyeron 450 tareas a partir de 150 vulnerabilidades reales, en 7 lenguajes y 24 tipos de debilidad (CWE). Cada tarea pide solo funcionalidad, con una especificación que nunca menciona la seguridad. Después corrigieron cada solución con pruebas ocultas de funcionamiento y de seguridad.
Dicho de otra forma: en este benchmark, el agente entrega en la mayoría de los casos algo que pasa las pruebas funcionales, y como mucho una de cada cuatro veces algo que también pasa las de seguridad. Las pruebas funcionales en verde no dicen nada sobre lo segundo, por la misma razón que contamos en por qué los tests generados por IA describen el código en vez de probarlo: una prueba solo comprueba lo que alguien decidió comprobar.
Riesgo Son benchmarks, no producción. Las tareas se construyeron a partir de vulnerabilidades conocidas, lo que puede exagerar la tasa frente al trabajo diario de un equipo. El dato no dice que tres de cada cuatro cambios de tu equipo sean inseguros. Dice que «funciona» no es una prueba de «es seguro».
¿Y si se lo pedimos en la especificación?
Es la reacción obvia: si la especificación no hablaba de seguridad, que hable. Otro estudio probó algo parecido. SusVibes, un benchmark de 186 peticiones de funcionalidad sacadas de proyectos reales de código abierto, evaluó 12 configuraciones de agentes con modelos de primera línea. Sus autores concluyen que todos los agentes rinden mal en seguridad: en el ejemplo que destacan, el 57 % de las soluciones son correctas y solo el 11,8 % son seguras.
La parte que importa aquí es el experimento siguiente. Añadieron a cada petición pistas sobre la vulnerabilidad que había que evitar, y concluyen que esa estrategia no resuelve los problemas de seguridad. Avisar al agente no es lo mismo que comprobar lo que hace.
Tampoco lo arregla cambiar de modelo. Veracode probó más de 100 modelos en 80 tareas: el código generado introducía vulnerabilidades en el 45 % de los casos, y los modelos más grandes no lo hacían significativamente mejor que los pequeños. Veracode vende herramientas de seguridad y su nota no detalla cómo diseñó las pruebas, así que es un dato de apoyo, no la base del argumento.
Lo que no se comprueba no existe
Nada de esto quiere decir que la especificación sobre. Al contrario: si un requisito de seguridad no está escrito, no hay nada que comprobar. Lo que dicen estos estudios es que escribirlo es necesario y no suficiente. Hace falta algo, fuera del agente, que lo compruebe cada vez.
Eso es Spec-Driven Development (SDD) bien entendido, como lo explicamos en Spec-Driven Development con IA: la especificación dice qué tiene que cumplirse y una comprobación independiente dice si se cumple. La idea de convertir los criterios de aceptación en la puerta del merge vale igual para los criterios de seguridad que para los funcionales.
Un requisito de seguridad que solo está en la especificación es un deseo. Cuando además es una prueba que falla si se incumple, es un criterio.
Dónde vive cada comprobación
No hay una sola barrera. Hay cuatro, y cada una cubre lo que las otras no ven:
| Comprobación | Qué detecta | Cuándo se ejecuta | Lo que no detecta |
|---|---|---|---|
| Criterios de seguridad escritos como pruebas | Que se incumpla una regla concreta del producto: quién puede ver qué, qué entradas se rechazan | En cada cambio, antes de la revisión | Lo que nadie escribió como criterio |
| Análisis automático del código y de las dependencias | Patrones conocidos de vulnerabilidad y paquetes con fallos publicados | En cada cambio | Errores de lógica propios del producto |
| Lotes pequeños | Nada por sí solos: hacen que cada cambio se pueda revisar y deshacer | Siempre | No sustituyen ninguna de las otras |
| Revisión y decisión de una persona | Riesgos de diseño y de contexto que ninguna prueba recoge | En autenticación, permisos, pagos y datos personales | Lo que no llega a su mesa |
Elaboración de onext; los ejemplos son ilustrativos
La tercera fila no detecta nada, y aun así es la que hace funcionar las demás. DORA lo dice en su modelo de capacidades para equipos con IA: trabajar en lotes pequeños es especialmente útil en un entorno asistido por IA, y como la IA aumenta la velocidad de los cambios, el control de versiones se convierte en una red de seguridad crítica. Cómo preparar esa vuelta atrás está en cómo deshacer lo que hace un agente de código.
La segunda fila incluye las dependencias que añade el agente, que tienen su propio problema, como contamos en la línea que nadie discute. Y la cuarta no es la revisión de todo: es la decisión donde el riesgo es alto. Cómo encaja con el resto del proceso de revisión está en revisar código generado por IA.
Un criterio de seguridad escrito como prueba
Un ejemplo ilustrativo, sin cliente detrás. La especificación de una tienda dice: «un usuario solo puede leer los pedidos de su propia cuenta». Convertido en prueba, queda así:
# Criterio de la especificación: un usuario solo puede leer los pedidos de su cuenta.
def test_un_usuario_no_lee_pedidos_de_otra_cuenta(cliente, ana, pedido_de_luis):
respuesta = cliente.get("/pedidos/" + pedido_de_luis.id, usuario=ana)
assert respuesta.status_code == 404La prueba no le dice al agente cómo implementar los permisos. Solo falla si alguien, persona o agente, deja que Ana lea el pedido de Luis. Se escribe antes de pedir el cambio y no la escribe el mismo agente que escribe el código. Si la escribe él, comprueba su propia interpretación, que es justo lo que no queremos.
Este tipo de pruebas no cubre la seguridad del agente en sí, que es otro problema: qué herramientas tiene, qué permisos y qué instrucciones puede recibir sin que nadie lo vea. De eso hablamos en prompt injection y permisos de los agentes.
Cómo lo planteamos en onext
Si quieres revisar con alguien de fuera qué comprueba hoy tu equipo y qué no, el diagnóstico es gratuito, y si en el diagnóstico no vemos diferencia, no hay Quick-start. Antes, puedes ver en qué punto estás con el autodiagnóstico de SDD. Cómo es el resto del camino está en AI-Accelerated Development.
Preguntas frecuentes
¿Es seguro el código que escriben los agentes de IA?
Funcionar y ser seguro son cosas distintas. En el benchmark LSCBench, publicado en octubre de 2026, seis agentes de primera línea resolvieron correctamente entre el 73,6 % y el 91,3 % de 450 tareas, pero como mucho el 25,1 % de las soluciones eran además seguras. Son pruebas construidas a partir de vulnerabilidades reales, no código de producción, así que el dato no dice qué parte del código de un equipo es insegura.
¿Basta con pedir seguridad en la especificación o en el prompt?
No basta. El estudio SusVibes probó a añadir a cada petición pistas sobre la vulnerabilidad que había que evitar, y los autores concluyen que esa estrategia no resuelve los problemas de seguridad. Pedirlo ayuda a que el criterio exista; lo que lo hace cumplir es una comprobación independiente del agente.
¿Un modelo más grande escribe código más seguro?
No necesariamente. Veracode probó más de 100 modelos en 80 tareas y concluyó que los modelos más grandes no lo hacen significativamente mejor que los pequeños: el código generado introducía vulnerabilidades en el 45 % de los casos. Veracode vende herramientas de seguridad y su nota no detalla el diseño de las pruebas, así que conviene leerlo con esa cautela.
¿Qué es un criterio de seguridad escrito como prueba?
Es un requisito de seguridad de la especificación convertido en una prueba que se ejecuta en cada cambio. Por ejemplo, «un usuario solo puede leer los pedidos de su cuenta» se convierte en una prueba que pide el pedido de otra cuenta y exige que la respuesta sea un error. Si el agente rompe esa regla, la prueba falla, aunque todo lo demás funcione.
¿Dónde tiene que decidir una persona?
En las zonas donde un fallo de seguridad tiene un coste alto: autenticación, permisos, pagos y datos personales. Ahí las pruebas y el análisis automático filtran, pero una persona revisa el cambio y decide si entra. En el resto, la comprobación automática hace la mayor parte del trabajo.
¿Qué tiene que ver esto con Spec-Driven Development?
Es Spec-Driven Development (SDD) bien entendido: la especificación dice qué tiene que cumplirse, incluidos los requisitos de seguridad, y algo independiente del agente comprueba que se cumple. Si la seguridad no está en la especificación, no hay nada que comprobar; si está pero nadie la comprueba, es un deseo.
Fuentes
- Tianyi Wu, Chao Ge, Peng Chen y otros, «Last Secure Code Benchmark: Is the Code You Vibe Secure?», arXiv:2610.14766, v1 del 10 de octubre de 2026 (preprint; 450 tareas, 150 vulnerabilidades reales, 7 lenguajes, 24 CWE, seis agentes).
- Songwen Zhao, Danqing Wang, Kexun Zhang, Jiaxuan Luo, Zhuo Li y Lei Li, «Is Vibe Coding Safe? Benchmarking Vulnerability of Agent-Generated Code in Real-World Tasks», arXiv:2512.03262, v1 del 2 de diciembre de 2025, revisado (v4) el 21 de septiembre de 2026 (preprint; 186 tareas, 12 configuraciones de agentes; el ejemplo del 57 % y el 11,8 % es SWE-Agent con Claude 4 Sonnet).
- Veracode, nota de prensa del «2025 GenAI Code Security Report», 30 de julio de 2025 (80 tareas, más de 100 modelos; fabricante de herramientas de seguridad).
- Kevin M. Storer y Derek DeBellis, «Introducing the DORA AI Capabilities Model», Google Cloud Blog, 23 de septiembre de 2025.
- Las citas de fuentes en inglés están traducidas por onext. La tabla de comprobaciones y el ejemplo de prueba (ilustrativo, sin cliente) son elaboración propia de onext.
Bernat López es fundador y CEO de onext, boutique de IA. Acompaña a equipos de desarrollo y de producto a trabajar con IA con método —especificación antes de programar, una persona que decide donde hay riesgo y Spec-Driven Development— y aplica a su propia empresa lo que propone: onext funciona con su propio sistema agéntico.
LinkedIn →