La IA de Chainguard ataca tu app en ejecución para probar el fallo. Evalúa el sandbox antes que el modelo

Un escáner estático lee el código y hace conjeturas. Un servicio de vulnerabilidades que ejecuta el código e intenta romperlo puede demostrar. El segundo tipo es mucho más útil para un equipo de seguridad ahogado en dudas, y cambia lo que usted compra: ya no un generador de informes, sino un entorno donde un modelo de frontera ejecuta ataques contra su software.

Chainguard Harness, anunciado el 14 de octubre, es ese tipo de servicio. Chainguard compila la aplicación del cliente desde el código fuente, tal como se enviaría a producción, la arranca en un microVM aislado y deja que Claude Mythos 5.1 sondee la instancia en ejecución en busca de fallos explotables: errores de lógica, inyección, agotamiento de recursos. El resultado es un informe con la severidad y el impacto, los pasos para confirmar cada hallazgo y una corrección recomendada redactada para el código del cliente. Describe los problemas y cómo confirmarlos, no un ataque funcional.

Harness está en beta, con lista de espera y acceso inicialmente limitado a un grupo reducido de organizaciones. También se venderá a través de Claude Marketplace, donde los clientes pueden aplicar parte de un compromiso existente con Anthropic.

El aislamiento es la arquitectura

Cuando un modelo ejecuta comandos contra una aplicación en producción, el diseño del sandbox importa más que la habilidad del modelo. El anuncio de Chainguard es concreto al respecto, y esos detalles son los que un comprador debería revisar:

Hasta dónde puede llegar el modelo atacante y hasta dónde no

Operaciones de Chainguard

• Un ingeniero con nombre y apellido revisa cada corrección y cada informe

Bucle del agente

• Se ejecuta fuera del sandbox
• Cada llamada a herramientas y cada comando quedan registrados

microVM de búsqueda

• Sin salida de red
• Sin credenciales
• Solo shell y paquetes compilados por Chainguard

Aplicación bajo prueba

• Compilada desde el código fuente
• Tratada como datos no confiables

• La preparación y la búsqueda son fases separadas. Un modelo de preparación compila la app y obtiene las dependencias; después, el microVM se suspende. La búsqueda lo reanuda sin salida de red y sin credenciales.
• El bucle del agente se ejecuta fuera del sandbox, y cada llamada a herramientas y cada comando quedan registrados.
• El código bajo prueba se trata como datos no confiables, una defensa contra la inyección de prompt escondida en comentarios o cadenas.
• El acceso al repositorio es de solo lectura, mediante una GitHub App o un archivo de código fuente subido.

Esa lista es una buena plantilla para evaluar cualquier sistema de IA que ejecute código, desde probadores de seguridad hasta agentes de programación. Es el mismo razonamiento que hay detrás de el aislamiento como la verdadera frontera de seguridad de los agentes: dé por sentado que se puede persuadir al modelo, y decida de antemano hasta dónde puede llegar un modelo persuadido.

Reproducible, o no cuenta

La segunda decisión de diseño responde a la principal queja sobre los hallazgos de seguridad generados por IA: son ruidosos. Chainguard reproduce cada exploit en un microVM nuevo, y los hallazgos que no se reproducen siempre quedan excluidos. Cada corrección recomendada debe hacer que el exploit falle contra el código parcheado.

Es lo opuesto a un escáner que enumera todo lo que podría estar mal. Cambia exhaustividad por evidencia. El trueque tiene sentido para los hallazgos que llegan a los desarrolladores, porque un exploit reproducible es difícil de descartar, y encaja con el patrón de la semana: la frase de Snyk de que el generador no puede ser el validador, y GitHub manteniendo su aviso sobre hallazgos de IA.

Chainguard no publica cifras de precisión, ni de falsos positivos ni de falsos negativos; tampoco precios, ni idiomas admitidos ni duraciones de ejecución. Un informe limpio le dice qué demostró Harness, no qué se le escapó.

Preguntas antes de entregar su código fuente

1. ¿Dónde se hace la compilación y en qué jurisdicción? Su código fuente y sus dependencias salen de su entorno y van al de Chainguard.
2. ¿Qué pasa con el microVM, sus logs y las notas de trabajo del modelo después de la ejecución? La custodia de los artefactos importa tanto como la custodia del código.
3. ¿Quién ve la salida sin procesar del modelo? Solo el personal de Chainguard opera el modelo; los clientes no pueden instruirlo ni ver su salida sin procesar. Eso limita el mal uso, y también limita su propia auditoría.
4. ¿A qué le compromete una corrección recomendada? Nada se despliega automáticamente. La corrección es una propuesta que pasa por su revisión como cualquier otro cambio.
5. ¿Cómo se gestionan los fallos en las dependencias upstream? Chainguard afirma que coordina la divulgación con los mantenedores de código abierto y distribuye compilaciones parcheadas a través de su repositorio; acuerde de antemano cómo se le informará.

Las pruebas de seguridad con IA están pasando de leer el código a ejecutarlo. Cómprelo como compraría una prueba de penetración con un tester muy rápido: revise primero las reglas de compromiso.