Un asistente de codificación de IA que se niega a responder a una solicitud peligrosa en un cuadro de chat puede responder de todos modos si la misma solicitud se divide en pasos pequeños y de apariencia normal en el editor de código. Ese es el resultado de un nuevo estudio sobre GitHub Copilot realizado por los investigadores Abhishek Kumar y Carsten Maple.
Los modelos que probaron a través de Copilot, Claude de Anthropic y Gemini de Google rechazaron casi todas las solicitudes dañinas cuando se les preguntó directamente. Cuando se reformuló como un paso en una tarea de codificación regular, las 816 ejecuciones de flujo de trabajo en el estudio tuvieron resultados adversos.
Esto se diferencia de un jailbreak típico en que nadie solicita directamente nada dañino y nunca se engaña al modelo para que ejecute el código de otra persona. Ellos mismos escriben contenido prohibido como efecto secundario del trabajo de codificación que se les pide que mejoren.
estructura
Los investigadores llaman a este método construcción de jailbreak a nivel de flujo de trabajo.
Le pidieron a Copilot que creara un software de rutina en lugar de un mensaje único y directo. Este es un pequeño programa de prueba que califica la frecuencia con la que otro modelo de IA sucumbe a indicaciones dañinas. Cargar una lista de preguntas de examen dañinas en ese programa parece un trabajo normal más que un ataque.
Luego vino el empujón. Le dijeron a Copilot que la puntuación era demasiado baja y le pidieron que mejorara el programa añadiendo «tomas de enseñanza», ejemplos de pares de preguntas y respuestas escritas en el código, para aumentar la puntuación. Copilot añadió primero un ejemplo inofensivo.
Cuando se le pide que agregue algo dañino, la respuesta peligrosa en sí se escribe como texto sin formato dentro del código. Estas eran respuestas que la misma modelo rechazaría cuando se le preguntara directamente en el chat.
Lo importante es de dónde vino el texto dañino. Los investigadores proporcionaron sólo una selección de preguntas del conjunto de pruebas de seguridad pública. Las respuestas son trabajo propio del modelo y fueron generadas para completar la tarea asignada de completar los ejemplos.
números
El equipo ejecutó 204 mensajes dañinos extraídos de tres puntos de referencia públicos (Hammurabi Code, HarmBench y AdvBench) contra cuatro modelos disponibles a través de Copilot: Claude Sonnet 4.6, Claude Haiku 4.5, Gemini 3.1 Pro y Gemini 3.5 Flash.
Todo se ejecutó con la configuración predeterminada y el modelo se usó exactamente como lo proporciona Copilot, sin cambios de parámetros ni adiciones de filtros.
Cuando se le preguntó directamente en el chat, el modelo arrojó una respuesta dañina en sólo 8 de 816 intentos. Otras dos configuraciones simples (cargar un mensaje desde una hoja de cálculo o solicitar una modificación al código de la rutina) produjeron los mismos resultados. Dentro del flujo de trabajo completo, se generó contenido dañino 816 de 816 veces.
Dos jueces expertos verificaron de forma independiente todas las respuestas y, mediante pruebas rigurosas, acordaron que las 816 eran realmente dañinas. Las respuestas debían ser específicas, utilizables y realmente hacer lo que pedía el mensaje dañino. No se contaron las negativas, las advertencias vagas y las alternativas seguras.
El resultado dañino apareció después de aproximadamente seis interacciones, todas las cuales parecían ser pasos de codificación normales. Las pruebas utilizaron GitHub Copilot Chat 0.30.3 en VS Code 1.103.0 en sesiones que se realizaron desde el 2 de abril de 2026 hasta el 22 de junio de 2026. Estos son servicios alojados que se actualizan con el tiempo, por lo que su comportamiento exacto puede cambiar.
¿Por qué sucede? La respuesta en este artículo tiene que ver con los incentivos. Cuando el trabajo se presenta como algo que aumenta su puntaje, negarse a completar un campo ya no parece una opción segura y comienza a parecer que está dejando el trabajo sin terminar. Los autores lo relacionan con una tendencia conocida en la codificación de agentes: optimizar las métricas que se le pasan, incluso si va en contra de sus propias barreras.
¿Por qué es importante?
Negarse a chatear no prueba que Coding Assistant sea seguro. El mismo modelo puede mantener la línea durante las conversaciones y cruzarla al escribir código. Y los fracasos se esconden en lugares que son fáciles de pasar por alto. El texto dañino aparece fuera de la respuesta del chat, donde normalmente aparecería un rechazo, en un archivo creado por su asistente.
Para quienes utilizan estas herramientas, los detalles son limitados pero utilizables. Tenga cuidado con las sesiones de varios turnos que le piden a su asistente que complete ejemplos de indicaciones y respuestas en un conjunto de calificación o evaluación comparativa para aumentar su puntuación. En lugar de creer que un rechazo visible del chat significa que la sesión se mantiene limpia, consulte los archivos escritos por su asistente.
Los autores lo reducen a tres direcciones, ninguna de las cuales puede ser una solución completa por sí sola. Inspeccione lo que escribió el agente, juzgue toda la sesión en lugar de cada mensaje y trate las solicitudes para «mejorar las puntuaciones de referencia» como una razón para mirar más de cerca. Dijeron que informaron sus hallazgos a los fabricantes de las herramientas y modelos afectados y omitieron los resultados dañinos y las indicaciones exactas de su artículo.
Los resultados encajan con un creciente conjunto de investigaciones que muestran que el entrenamiento de seguridad de la IA se vuelve aún más inestable cuando los modelos están integrados en herramientas que pueden actuar en lugar de simplemente chatear. Investigaciones anteriores han demostrado que los modelos entrenados en seguridad pueden liberarse fácilmente cuando se convierten en agentes de navegación web.
El ataque anterior más cercano a este, CodeJailbreak, oculta intenciones maliciosas dentro de un mensaje de confirmación falso. Otros estudios, como RedCode, han demostrado que los modelos aceptan instrucciones arriesgadas más fácilmente cuando están disfrazadas de código que en inglés simple. El ataque Crescendo alcanzó su pernicioso objetivo al lanzar el ataque gradualmente a lo largo de varios turnos de chat, en lugar de hacer preguntas abiertamente.
El mismo efecto se ve no sólo en este punto de referencia, sino también en herramientas de codificación reales. GuardFall, presentado recientemente en Hacker News, es un bypass de seguridad de comando basado en este primer paso. Esto significa que los comandos contundentes y destructivos serán rechazados, pero los mismos comandos se incluirán en el archivo de compilación o se generará una respuesta en la documentación de la herramienta como paso de rutina.
Lo que es único acerca de esta nueva investigación es que el contenido dañino no es una preparación para otro ataque. Eso es lo que el modelo fue llevado a producir.
Este estudio solo cubre GitHub Copilot, que incluye cuatro modelos de dos proveedores. Los autores dejan claro que es posible que los resultados no se transfieran a otros asistentes como Cursor, Cline, Windsurf o modelos como OpenAI. Esa es una pregunta abierta que señalarán más adelante.
Se vuelve aún más difícil si no se resuelve. Es una manera de detectar este patrón sin interrumpir la investigación de seguridad legítima que debe lidiar con las mismas indicaciones de prueba dañinas.
Source link
