The Security Budget of Code LLMs: An Information-Theoretic Capacity-Security Bound

Resumen Técnico: El Presupuesto de Seguridad de los LLM de Código

Planteamiento del Problema
Los asistentes de programación basados en IA dependen cada vez más de los prompts de lenguaje natural como la interfaz principal para el desarrollo de software. Este cambio introduce una vulnerabilidad crítica: pequeñas perturbaciones en un prompt (por ejemplo, sustitución de sinónimos, renombramiento de identificadores o inyección de comentarios) pueden alterar el código generado dejando, al mismo tiempo, la intención del usuario parcialmente reconocible. Las evaluaciones existentes suelen basarse en las tasas de ejecución exitosa (pass@1) antes y después de la perturbación. Sin embargo, los autores argumentan que esto es insuficiente para los asistentes interactivos porque no distingue entre un modelo que ha perdido toda la información de la tarea (haciendo que la "robustez" carezca de sentido) y uno que retiene suficiente información para ser reconocible pero desplaza la implementación. Existe la necesidad de una visión de "nivel de presupuesto" que separe la información de la tarea, la fuga de información del prompt y la estabilidad de la generación para comprender los compromisos entre la capacidad funcional y la seguridad bajo perturbación.

Metodología
El artículo formaliza este compromiso utilizando la teoría de la información, definiendo dos cantidades clave para un LLM de código $\pi$:

1. Capacidad ($Cap$): La información mutua entre la solución canónica $c^*$ y la generación del modelo $c_\pi$, denotada como $I(c^*; c_\pi)$. Esto mide cuánto de la tarea captura el modelo.
2. Seguridad ($Sec$): La información mutua entre la generación bajo el prompt original $p$ ($c_\pi$) y la generación bajo un prompt perturbado adversariamente $\tilde{p}$ ($\tilde{c}_\pi$), denotada como $I(c_\pi; \tilde{c}_\pi)$. Esto actúa como un "canal de retención de perturbación", midiendo la información compartida entre las salidas limpias y perturbadas.

Marco Teórico
La contribución teórica central es el Teorema 1, que establece un límite superior en la suma de estas dos cantidades:
$$Cap + Sec \leq H(c^*) + I(p; \tilde{p})$$
Aquí, $H(c^*)$ es la entropía de la solución canónica (entropía de la tarea) e $I(p; \tilde{p})$ es la información mutua entre el prompt original y el perturbado (fuga de información del prompt). La demostración se basa en desigualdades estándar de la teoría de la información:

• $Cap \leq H(c^*)$ se deriva de la definición de información mutua.
• $Sec \leq I(p; \tilde{p})$ se deriva de la Desigualdad de Procesamiento de Datos (DPI), asumiendo que las generaciones $c_\pi$ y $\tilde{c}_\pi$ son condicionalmente independientes dado el par de prompts $(p, \tilde{p})$.

Para hacer que el límite sea accionable sin tener acceso a los datos de entrenamiento internos del modelo, los autores derivan el Teorema 2, un compañero de límite cerrado, agnóstico al modelo, para $H(c^*)$. Este límite utiliza la compresibilidad del código fuente:
$$H(c^*) \leq \min(L_{max} \log V, |c^*|_{gz})$$
donde $L_{max}$ es la longitud máxima de tokens, $V$ es el tamaño del vocabulario, y $|c^*|_{gz}$ es la longitud esperada de las soluciones canónicas comprimida con gzip.

Validación Empírica
Los autores validan el Corolario 1 (Límite de Variable Embebida) utilizando un protocolo de incrustación (embedding) de solo salida. Para preservar la cadena de Markov requerida por la demostración ($z_\pi \to p \to \tilde{p} \to \tilde{z}_\pi$), la incrustación $E$ se aplica únicamente al código generado, excluyendo el contexto del prompt.

• Modelos y Conjuntos de Datos: Los experimentos se realizaron con CodeLlama-7B y Qwen2.5-Coder-7B en los conjuntos de datos HumanEval y MBPP-sanitizados.
• Estimadores: La información mutua se estimó utilizando los estimadores MINE (Estimación Neuronal de Información Mutua) y KSG (Kraskov-Stögbauer-Grassberger) sobre los estados ocultos del último token (reducidos mediante PCA).
• Perturbaciones: Se utilizó un conjunto de 23 perturbaciones, incluyendo cambios de sinónimos, negación, inyección de comentarios (incluyendo comentarios de seguridad-anti) y renombramiento de identificadores.

Resultados Clave

1. Satisfacción del Límite: A través de seis configuraciones de validación individuales (variando modelos, conjuntos de datos, precisión y ablaciones de incrustación), la verificación de la incrustación satisfizo la desigualdad. La relación de saturación $(Cap + \max_T Sec) / (H(z^*) + \max_T I(p; \tilde{p}))$ osciló entre 0.27 y 0.92, con un margen de holgura del teorema positivo (de 2.36 a 26.94 nats).
2. Estabilidad: Un diagnóstico de estabilidad de tres semillas mostró una saturación media de 0.87.
3. Pruebas de Estrés: Las pruebas de estrés adaptativas, que incluyeron un conjunto de 23 perturbaciones, un sufijo de seguridad-anti universal fijo y un ataque PGD basado en gradientes, dieron como resultado una holgura positiva, confirmando que el límite se mantiene incluso bajo estrategias de perturbación agresivas.
4. Señal por Problema: Aunque el límite teórico utiliza incrustaciones de solo salida, se encontró que un coseno de incrustación de contexto mixto (condicionado tanto al prompt como al código) se correlaciona con el pass@1 de ejecución (por ejemplo, $\rho=0.36$ para CodeLlama-HumanEval), sirviendo como una señal de alineación práctica distinta del límite de seguridad.
5. Análisis de Fuga: El estudio identificó que el renombramiento de identificadores y la sustitución de sinónimos dejan los techos de información compartida más grandes (alto $I(p; \tilde{p})$), mientras que los comentarios de seguridad-anti filtran menos información del prompt pero son más peligrosos para la seguridad.

Significado y Reivindicaciones
El artículo afirma proporcionar un presupuesto cuantitativo e informacional para la estabilidad de la generación de código. Su importancia radica en:

• Descomposición: Separar el "presupuesto" en la entropía de la tarea y la fuga de información del prompt, permitiendo a los desarrolladores comprender que reducir la fuga de información del prompt ($I(p; \tilde{p})$) estrecha el canal máximo disponible para un adversario sin necesidad de aumentar la capacidad funcional.
• Techo Agnóstico al Modelo: El límite de forma cerrada para $H(c^*)$ permite calcular un techo de seguridad para cualquier modelo nuevo en un conjunto de tareas conocido sin requerir acceso al modelo o a sus datos de entrenamiento, basándose únicamente en el tokenizador y la distribución de la solución canónica.
• Salvaguardas Prácticas: Los autores argumentan que las salvaguardas de los asistentes de programación no deben evaluarse solo por el pass@1, sino por la información de perturbación de prompt que dejan disponible para un adversario. El límite ofrece una prueba para el endurecimiento de prompts: reducir $I(p; \tilde{p})$ debería estrechar el presupuesto de seguridad.

Los autores mantienen la modestia, señalando que la contribución es la instanciación de estos conceptos para la generación de código (definir el presupuesto y el techo de forma cerrada) más que un nuevo teorema de procesamiento de datos. Reconocen limitaciones, incluyendo la sensibilidad de los estimadores de MI (donde MINE puede sobreestimar cerca de los límites) y el hecho de que el límite caracteriza el presupuesto de estabilidad disponible en lugar de probar que un adversario realista siempre lo saturará.