Cuando tu agente encuentra una vulnerabilidad

Nicholas Carlini, científico investigador en Anthropic, apuntó Claude Code al código fuente del kernel de Linux y le pidió que encontrara vulnerabilidades. La configuración: un script bash de 10 líneas más un contenedor Docker con compilaciones instrumentadas con ASAN. Iterar sobre archivos fuente, pedirle al modelo que busque errores, pasar al siguiente archivo.¹³

El resultado, según detalla el análisis de Michael Lynch sobre la charla:² un desbordamiento de búfer de heap explotable remotamente en la caché de repetición LOCK de NFSv4, presente desde marzo de 2003 — anterior al propio Git. Dos clientes NFS cooperando pueden leer memoria sensible del kernel desbordando un búfer de 112 bytes con un identificador de propietario de bloqueo de 1.024 bytes. Carlini encontró al menos cuatro vulnerabilidades más en el kernel durante el mismo barrido. Por separado, la misma metodología produjo 122 entradas que generaban fallos enviadas a Mozilla, de las cuales 22 recibieron CVEs.³ Describió “varios cientos de fallos” que no ha tenido tiempo de validar y reportar.²

Estas son vulnerabilidades confirmadas reportadas a los mantenedores, encontradas por un agente usando Opus 4.6 — la misma clase de modelo que los profesionales ejecutan a diario para revisión de código, refactorización y desarrollo de funciones. Carlini presentó los hallazgos en la conferencia de seguridad de IA [un]prompted en abril de 2026.¹

Resumen

La metodología de Carlini fue mínima: iterar sobre archivos fuente, pedirle a Claude que encontrara vulnerabilidades en cada uno, verificar los hallazgos con aserciones ASAN. Opus 4.6 encontró sustancialmente más vulnerabilidades que Opus 4.1 (8 meses más antiguo) o Sonnet 4.5 (6 meses más antiguo), lo que sugiere que se cruzó recientemente un umbral de capacidad.² El cuello de botella ahora es la validación humana, no el descubrimiento por IA. Esto tiene implicaciones directas en cómo los profesionales construyen hooks de seguridad, ejecutan revisiones de código y piensan en la auditoría asistida por agentes.

Puntos clave

• Ingenieros de seguridad: La capacidad es real y mejora rápido. Si ejecutas revisión de código asistida por agentes, tus hooks de seguridad PreToolUse son más importantes que nunca — no para bloquear a Claude, sino para controlar qué puede hacer con lo que encuentra.
• Constructores de harness: El cuello de botella en la verificación (“varios cientos de fallos que no he validado”) es un problema de harness. La clasificación automatizada, la deduplicación y la categorización por severidad son la siguiente capa de infraestructura.
• Todos los demás: El mismo modelo que introduce regresiones de rendimiento de 446x también encuentra errores que 23 años de revisión humana pasaron por alto. Ambas cosas son ciertas simultáneamente.

La metodología

El enfoque de Carlini no requirió un framework de seguridad personalizado, un modelo ajustado ni prompts especializados. Lo describió como “un script bash de 10 líneas más un contenedor Docker”:³

1. Compilar el objetivo con instrumentación ASAN (AddressSanitizer)
2. Iterar a través de los archivos fuente, usando el modelo para evaluar la relevancia de seguridad
3. Darle a Claude Code un encuadre de captura la bandera para archivos de alta relevancia
4. Ejecutar múltiples pasadas por objetivo (5-20 dependiendo del código base)
5. Usar agentes de crítica automatizada para verificar los hallazgos antes de la divulgación

El encuadre de captura la bandera importa. Decirle al modelo “este código tiene un error” activa un modo diferente que “revisa este código buscando problemas”. Los desarrolladores han notado el mismo patrón en el uso diario — Claude encuentra más problemas cuando le dices que existe un problema que cuando le preguntas si podría existir uno.²

El costo del barrido se mide en tokens de API, no en meses-persona. Carlini encontró cinco vulnerabilidades confirmadas en el kernel de Linux y 22 CVEs de Firefox usando un CLI de agente comercial.³ La misma herramienta que escribe tus pruebas unitarias y formatea tus importaciones.

El umbral de capacidad

El hallazgo más llamativo es la brecha generacional entre modelos. Carlini intentó reproducir sus resultados con modelos anteriores:²

• Opus 4.6 (lanzado ~2 meses antes de la charla): encontró el desbordamiento de heap y múltiples vulnerabilidades adicionales
• Opus 4.1 (8 meses antes): encontró solo una pequeña fracción
• Sonnet 4.5 (6 meses antes): encontró solo una pequeña fracción

Algo cruzó un umbral entre generaciones de modelos. La capacidad de mantener un código base complejo en contexto, razonar sobre el flujo de datos a través de los límites de funciones e identificar discrepancias sutiles en las especificaciones parece haber emergido en lugar de mejorar gradualmente.

Carlini lo expresó sin rodeos: “Nunca había encontrado uno de estos en mi vida. Es muy, muy, muy difícil de hacer. Con estos modelos de lenguaje, tengo un montón.”²

La paradoja

La misma arquitectura de agente que introduce regresiones de rendimiento — 118 funciones con ralentizaciones de 3x a 446x — también encuentra vulnerabilidades de seguridad que décadas de revisión humana experta pasaron por alto. Son aspectos complementarios del mismo perfil de capacidad. La investigación de vulnerabilidades es fundamentalmente reconocimiento de patrones contra clases conocidas (desbordamientos de búfer, uso después de liberación, errores de signo en enteros), lo cual es una fortaleza de los LLM.⁴ La optimización de rendimiento requiere lo opuesto: razonar sobre contextos de ejecución específicos, comportamiento de caché y complejidad algorítmica. El modelo reconoce un desbordamiento de búfer en millones de líneas de código, pero no puede decirte que un mapa hash es más lento que un arreglo ordenado para tu patrón de acceso. Construye tu harness acorde — hooks de seguridad que señalen hallazgos, hooks de rendimiento que midan antes de hacer commit.

El cuello de botella en la verificación

La admisión más reveladora de Carlini: “Tengo tantos errores en el kernel de Linux que no puedo reportar porque aún no los he validado.”²

El cuello de botella se ha desplazado del descubrimiento a la clasificación. Encontrar vulnerabilidades potenciales ahora es más barato que confirmar que son reales. Esto crea un nuevo problema de infraestructura para los equipos de seguridad:

El descubrimiento está automatizado. Un agente puede barrer un código base en horas.

La verificación es manual. Cada vulnerabilidad potencial necesita una prueba de concepto, una evaluación de impacto y un proceso de divulgación responsable.

La clasificación es la brecha. Ordenar cientos de hallazgos generados por agentes en vulnerabilidades reales, falsos positivos y ruido de baja severidad es el trabajo que aún no tiene buenas herramientas.

Es el mismo patrón que vemos en la revisión de código asistida por agentes: el agente produce resultados en bruto más rápido de lo que los humanos pueden evaluarlos. El valor no está en la generación — está en la infraestructura que procesa, filtra y dirige los resultados.

Para los constructores de harness, esto significa que el próximo hook de alto valor no es un escáner de seguridad. Es un sistema de clasificación de seguridad: deduplicación, categorización por severidad, filtrado de falsos positivos y generación automática de pruebas de concepto. Los hooks de gobernanza que controlan la salida del agente son más importantes que las capacidades de escaneo en sí.

Qué significa esto para los profesionales

Si ejecutas Claude Code en códigos base de producción, ya estás operando un sistema capaz de encontrar vulnerabilidades reales. La pregunta no es si la capacidad existe — es si tu harness está diseñado para manejar lo que el agente encuentra.

Tres movimientos prácticos:

Agrega un barrido de seguridad a tu pipeline de revisión. Un hook PostToolUse en Write/Edit puede disparar un escaneo de seguridad dirigido en los archivos modificados. El hook lee la ruta del archivo desde stdin (Claude Code pasa el JSON del evento por stdin a los hooks):

#!/bin/bash
# .claude/hooks/security-scan.sh
FILE_PATH=$(jq -r '.tool_input.file_path // empty' < /dev/stdin)
[ -z "$FILE_PATH" ] && exit 0
[ ! -f "$FILE_PATH" ] && exit 0

claude -p "This file has a security vulnerability. Find it and describe the impact: $FILE_PATH" \
  --output-format json >> .claude/security-findings.jsonl 2>/dev/null &
exit 0  # non-blocking — runs in background

{
  "hooks": {
    "PostToolUse": [{
      "matcher": "Write|Edit",
      "hooks": [{ "type": "command", "command": ".claude/hooks/security-scan.sh" }]
    }]
  }
}

Esto es un punto de partida, no algo listo para producción — necesitarías agregar deduplicación, filtrado por severidad y limitación de tasa. Pero el patrón central coincide con la metodología de Carlini: un bucle sobre archivos con un prompt dirigido.³

Construye infraestructura de clasificación. Hallazgos de vulnerabilidades en bruto sin categorización por severidad son ruido. Si tu agente produce 50 hallazgos por barrido, necesitas deduplicación automatizada y puntuación de prioridad antes de que un humano vea la lista. Este es un problema de harness, no un problema de modelo.

Acepta la paradoja. El mismo modelo que necesita barandillas de rendimiento es genuinamente excelente en reconocimiento de patrones de seguridad. Diseña tu harness para aprovechar la fortaleza y compensar la debilidad. Hooks de seguridad que escanean. Hooks de rendimiento que miden. Hooks de calidad que verifican. Cada uno cubre lo que los otros no.

La vulnerabilidad de 23 años en el kernel de Linux no estaba oculta. Estaba a plena vista, en un archivo que miles de ingenieros habían leído. El modelo la encontró porque el reconocimiento de patrones a escala es lo que estos sistemas hacen. La lección no es que los agentes sean mejores que los humanos en seguridad. La lección es que los agentes cubren una superficie diferente — y el harness que orquesta ambos es lo que hace confiable la combinación.

Fuentes

Preguntas frecuentes

¿Puedo reproducir el enfoque de Carlini con Claude Code?

La metodología está documentada en la entrevista del podcast.³ El bucle central: compilar con ASAN, iterar sobre archivos fuente, darle a Claude un encuadre de captura la bandera, verificar los hallazgos. Carlini reportó que Opus 4.6 encontró significativamente más vulnerabilidades que modelos anteriores — los resultados con otras generaciones de modelos pueden variar.

¿Significa esto que los agentes de IA son mejores que los humanos encontrando errores de seguridad?

No. Significa que los agentes cubren una superficie diferente. Los agentes sobresalen en el reconocimiento de patrones contra clases conocidas de vulnerabilidades en códigos base extensos. Los humanos sobresalen en la comprensión de vectores de ataque novedosos, fallos de lógica de negocio y propiedades de seguridad dependientes del contexto. La combinación es más fuerte que cualquiera de los dos por separado.

¿Debería preocuparme por atacantes usando esta capacidad?

Carlini advirtió explícitamente sobre “una gran ola que viene”. La misma capacidad que ayuda a los defensores a encontrar vulnerabilidades está disponible para los atacantes. La asimetría es que los defensores pueden automatizar la clasificación y el parcheo, mientras que los atacantes aún necesitan desarrollar exploits — pero la brecha en el descubrimiento se está cerrando.