CodeSpear: cuando la decodificación con restricción gramatical se convierte en superficie de jailbreak

¿Qué es esto?

El 10 de junio de 2026, Yitong Zhang, Shiteng Lu y Jia Li publicaron Grammar-Constrained Decoding Can Jailbreak LLMs into Generating Malicious Code en arXiv (cs.CR, 2606.11817). El hallazgo es deliberadamente contraintuitivo: una técnica adoptada para hacer más fiable la generación de código de los LLM puede convertirse en un jailbreak.

La decodificación con restricción gramatical (Grammar-Constrained Decoding, GCD) es el mecanismo detrás de las funciones de salida estructurada y de «solo código válido». En cada paso, el modelo normalmente muestrearía de su distribución completa de tokens; el GCD aplica una máscara por token que anula cualquier token que rompería la gramática suministrada, de modo que la salida siempre se analiza. Los autores nombran el ataque CodeSpear y muestran que aplicar una restricción gramatical de código de apariencia inocua puede llevar a un modelo a completar una solicitud maliciosa que de otro modo rechazaría. El ataque amplía la superficie del «plano de control» descrita en When Grammar Guides the Attack (arXiv:2503.24191, 31 de marzo de 2025), que planteó por primera vez la salida estructurada como un plano de ataque ortogonal a los ataques por prompt.

Cómo funciona

La alineación de seguridad se entrena de forma abrumadora en el plano del lenguaje natural: el modelo aprende a emitir una frase de rechazo («No puedo ayudar con eso») cuando una solicitud es dañina. Pero ese rechazo es una secuencia de tokens. El GCD opera un nivel más abajo, sobre qué tokens tienen siquiera permitido ser muestreados.

El problema estructural es este: cuando una restricción gramatical exige que los siguientes tokens sean código válido, los tokens que componen un rechazo en lenguaje natural ya no están en el conjunto permitido. El modelo no puede decir «No haré esto» porque esa cadena no satisface la gramática. Obligado a emitir algo que se analice como código, el camino de menor resistencia pasa a ser completar el programa solicitado, token a token. El comportamiento de rechazo que el modelo aprendió en el plano del lenguaje es sencillamente inalcanzable en el plano del código. Medido en 10 LLM y 4 benchmarks, CodeSpear eleva la tasa de éxito del ataque en más de 30 puntos porcentuales de media frente a los jailbreaks de referencia, sin ninguna formulación adversaria en el prompt: la manipulación reside por completo en la restricción de decodificación.

Describimos deliberadamente el mecanismo, no una gramática ejecutable: la lección duradera es que una superficie de control situada por debajo del prompt puede anular la seguridad a nivel de prompt.

Por qué importa

Es una forma de riesgo distinta de los ataques del lado de la entrada como los jailbreaks por codificación matemática o los ataques por slots posicionales. Esos manipulan lo que dices al modelo. CodeSpear manipula la maquinaria de decodificación, lo que le permite sortear defensas que solo inspeccionan el prompt del usuario. Cualquier producto que exponga funciones de salida estructurada o de «código restringido» por API cede al llamante control parcial de esa maquinaria; por eso la amenaza es más aguda para los asistentes de código y los endpoints de generación de código, donde las restricciones gramaticales son una capacidad normal y anunciada. El punto de fondo es arquitectónico: una seguridad entrenada en una modalidad (lenguaje natural) no se transfiere automáticamente a otra (código restringido), y un atacante capaz de elegir la gramática de salida elige la modalidad.

Defensas

El mismo artículo incluye una defensa, CodeShield, y su diseño es la conclusión accionable:

• Alinear la seguridad en la modalidad del código, no solo en el lenguaje. CodeShield enseña al modelo a emitir código señuelo (honeypot) ante una solicitud GCD maliciosa: una salida semánticamente inofensiva (no implementa el comportamiento dañino) pero estructuralmente diversa (imposible de eliminar simplemente apretando la gramática). El modelo permanece seguro incluso cuando el atacante controla la gramática.
• Preservar los rechazos en lenguaje natural allí donde siguen siendo alcanzables. Cuando ninguna gramática fuerza una salida solo-código, CodeShield mantiene el rechazo normal: no se sacrifica la utilidad legítima.
• Tratar la restricción de decodificación como entrada no confiable. Si tu plataforma permite a los llamantes suministrar gramáticas o esquemas JSON, regístralos y acótalos, y no asumas que las barreras a nivel de prompt cubren este camino.
• Ejecutar clasificadores de seguridad del lado de la salida sobre el código generado, con independencia de la restricción de decodificación, para que una compleción válida-pero-maliciosa se detecte igualmente a posteriori.

Se informa de que CodeShield restaura la seguridad frente a CodeSpear en los 10 modelos probados, preservando la utilidad de generación de código legítima.

Estado

CodeSpear y CodeShield se publicaron como preprint de arXiv el 10 de junio de 2026; la superficie de ataque del «plano de control» subyacente se documentó por primera vez en marzo de 2025. Los autores presentan las implicaciones de seguridad del GCD como un riesgo abierto y poco examinado, más que como un único error parcheado: las funciones de salida estructurada están muy extendidas, y la respuesta defensiva es un cambio de alineación consciente de la modalidad, no un arreglo de una línea.