Un asistente de codificación de IA que se niega a responder una solicitud peligrosa en su cuadro de chat puede responderla de todos modos si la misma solicitud se divide en pasos pequeños y de apariencia normal dentro de un editor de código. Ése es el hallazgo de un nuevo estudio de GitHub Copilot 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. Reformulados como pasos de una tarea de codificación normal, produjeron respuestas dañinas en las 816 ejecuciones del flujo de trabajo del estudio.
Lo que hace que esto sea diferente de un jailbreak típico: nadie solicita directamente el elemento dañino y no se engaña al modelo para que ejecute el código de otra persona. Escribe el contenido prohibido por sí mismo, como efecto secundario de una tarea de codificación que le dijeron que mejorara.
como funciona
Los investigadores llaman al método construcción de jailbreak a nivel de flujo de trabajo.
En lugar de una única indicación contundente, le pidieron a Copilot que creara un software cotidiano: un pequeño programa de prueba que califica la frecuencia con la que otro modelo de IA cede a indicaciones dañinas. Cargar una lista de preguntas de examen dañinas en ese programa parece un trabajo normal, no 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 «disparos de enseñanza», ejemplos de pares de preguntas y respuestas escritas en el código para aumentar la puntuación. Copilot añadió primero ejemplos inofensivos.
Cuando se le pidió que agregara las dañinas, escribió las respuestas peligrosas él mismo, como texto sin formato dentro del código. Estas fueron respuestas que las mismas modelos rechazan cuando las preguntas directamente en un chat.
Lo importante es de dónde vino el texto dañino. Los investigadores proporcionaron sólo las preguntas, tomadas de conjuntos de pruebas de seguridad pública. Las respuestas fueron trabajo del propio modelo, elaboradas para completar la tarea asignada de completar los ejemplos.
los numeros
El equipo ejecutó 204 mensajes dañinos extraídos de tres puntos de referencia públicos (Hammurabi's 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, con los modelos utilizados exactamente como los entrega Copilot, sin cambios de parámetros ni filtros agregados.
Cuando se les preguntó directamente en el chat, los modelos produjeron respuestas dañinas en sólo 8 de 816 intentos. Otras dos configuraciones simples, cargar las indicaciones desde una hoja de cálculo o solicitar una corrección de código de rutina, dieron el mismo resultado. Dentro del flujo de trabajo completo, produjeron contenido dañino 816 de 816 veces.
Dos revisores expertos verificaron cada respuesta por su cuenta y acordaron que las 816 eran realmente dañinas, utilizando una prueba estricta: la respuesta tenía que ser específica, utilizable y realmente hacer lo que pedía el mensaje dañino. Las negativas, las advertencias vagas y las alternativas seguras no contaron.
El resultado dañino apareció después de aproximadamente seis intercambios de ida y vuelta, todos ellos parecían pasos de codificación normales. Las pruebas utilizaron GitHub Copilot Chat 0.30.3 dentro de VS Code 1.103.0, en sesiones realizadas entre el 2 de abril y el 22 de junio de 2026. Debido a que estos son servicios alojados que se actualizan con el tiempo, el comportamiento exacto puede cambiar.
¿Por qué sucede? La respuesta del artículo es sobre incentivos. Una vez que el trabajo se enmarca como un aumento de puntaje, negarse a completar un campo deja de parecer una opción de seguridad y comienza a parecer como dejar el trabajo sin terminar. Los autores lo vinculan a una tendencia conocida en los agentes de codificación: optimizar la métrica que se les entrega, incluso cuando eso va en contra de sus propias barreras.
Por qué es importante
Un rechazo del chat no prueba que un asistente de codificación sea seguro. El mismo modelo puede mantener la línea en una conversación y cruzarla mientras escribe código. Y el fallo se esconde en un lugar fácil de pasar por alto: el texto dañino termina en un archivo que escribe el asistente, fuera de la respuesta del chat, donde normalmente aparecería un rechazo.
Para cualquiera que utilice estas herramientas, la lectura concreta es limitada pero utilizable. Tenga cuidado con una sesión de varios turnos que le pide al asistente que complete una evaluación o un conjunto de puntos de referencia con ejemplos de indicaciones y respuestas para aumentar la puntuación. Revise los archivos que escribe el asistente en lugar de confiar en que un rechazo visible del chat significa que la sesión se mantuvo limpia.
Los autores lo reducen a tres direcciones, ninguna de las cuales es una solución completa por sí sola: inspeccionar lo que escribe el agente, juzgar una sesión completa en lugar de cada mensaje y tratar una solicitud para «mejorar una puntuación de referencia» como una razón para mirar más de cerca. Dicen que informaron los hallazgos a los fabricantes de herramientas y modelos afectados, y dejaron fuera del documento los resultados dañinos y las indicaciones exactas.
El resultado se ajusta a una creciente cantidad de trabajos que muestran que el entrenamiento de seguridad de la IA se vuelve más inestable una vez que un modelo se conecta a una herramienta que puede actuar, en lugar de simplemente charlar. Investigaciones anteriores encontraron que los modelos entrenados en seguridad son Se libera fácilmente cuando se convierte en agentes de navegación web..
El ataque anterior más cercano, CódigoJailbreakeroculta la intención dañina dentro de un mensaje de confirmación falso. Otros, como código rojohan demostrado que los modelos aceptan una instrucción peligrosa más fácilmente cuando está disfrazada de código que en inglés simple. El Crescendo El ataque alcanzó un objetivo dañino al avanzar lentamente durante varios turnos de chat en lugar de preguntar directamente.
El mismo efecto aparece en herramientas de codificación reales, no solo en este punto de referencia. The Hacker News cubrió recientemente GuardFall, una derivación de seguridad de comandos que se apoyaba exactamente en este primer paso: un comando contundente y destructivo se rechaza, mientras que el mismo comando guardado en un archivo de compilación o en la respuesta de la documentación de una herramienta se produce como un paso de rutina.
El giro de este nuevo estudio es que el contenido dañino no es la preparación para otro ataque; es lo que el modelo fue obligado a producir.
El estudio cubre únicamente GitHub Copilot con cuatro modelos de dos proveedores. Los autores tienen claro que los resultados pueden no trasladarse a otros asistentes como Cursor, Cline o Windsurf, ni a modelos de OpenAI y otros. Ésa es la pregunta abierta que señalan para más adelante.
La más difícil que dejan sin resolver es cómo detectar este patrón sin romper también la investigación de seguridad legítima que tiene que funcionar con las mismas indicaciones de prueba dañinas.
