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

Resumo Técnico: O Orçamento de Segurança de LLMs de Código

Definição do Problema
Assistentes de programação baseados em IA dependem cada vez mais de prompts de linguagem natural como a interface primária para o desenvolvimento de software. Essa mudança introduz uma vulnerabilidade crítica: pequenas perturbações em um prompt (ex: substituição de sinônimos, renomeação de identificadores ou injeção de comentários) podem alterar o código gerado enquanto deixam a intenção do usuário parcialmente reconhecível. As avaliações existentes frequentemente dependem das taxas de execução bem-sucedida (pass@1) antes e depois da perturbação. No entanto, os autores argumentam que isso é insuficiente para assistentes interativos porque falha em distinguir entre um modelo que perdeu toda a informação da tarefa (tornando a "robustez" sem sentido) e um que retém informação suficiente para ser reconhecível, mas altera a implementação. Há uma necessidade de uma visão de "nível de orçamento" que separe a informação da tarefa, o vazamento do prompt e a estabilidade da geração para entender os compromissos entre capacidade funcional e segurança sob perturbação.

Metodologia
O artigo formaliza esse compromisso usando a teoria da informação, definindo duas quantidades principais para um LLM de código $\pi$:

1. Capacidade ($Cap$): A informação mútua entre a solução canônica $c^*$ e a geração do modelo $c_\pi$, denotada por $I(c^*; c_\pi)$. Isso mede quanto da tarefa o modelo captura.
2. Segurança ($Sec$): A informação mútua entre a geração sob o prompt original $p$ ($c_\pi$) e a geração sob um prompt adversário perturbado $\tilde{p}$ ($\tilde{c}_\pi$), denotada por $I(c_\pi; \tilde{c}_\pi)$. Isso atua como um "canal de retenção de perturbação", medindo a informação compartilhada entre as saídas limpa e perturbada.

Estrutura Teórica
A principal contribuição teórica é o Teorema 1, que estabelece um limite superior para a soma dessas duas quantidades:
$$Cap + Sec \leq H(c^*) + I(p; \tilde{p})$$
Aqui, $H(c^*)$ é a entropia da solução canônica (entropia da tarefa) e $I(p; \tilde{p})$ é a informação mútua entre o prompt original e o perturbado (vazamento do prompt). A prova baseia-se em desigualdades padrão da teoria da informação:

• $Cap \leq H(c^*)$ segue da definição de informação mútua.
• $Sec \leq I(p; \tilde{p})$ segue da Desigualdade do Processamento de Dados (DPI), assumindo que as gerações $c_\pi$ e $\tilde{c}_\pi$ são condicionalmente independentes dado o par de prompts $(p, \tilde{p})$.

Para tornar o limite acionável sem acesso aos dados de treinamento internos do modelo, os autores derivam o Teorema 2, um companheiro de limite de forma fechada e agnóstico ao modelo para $H(c^*)$. Este limite utiliza a compressibilidade do código fonte:
$$H(c^*) \leq \min(L_{max} \log V, |c^*|_{gz})$$
onde $L_{max}$ é o comprimento máximo de tokens, $V$ é o tamanho do vocabulário e $|c^*|_{gz}$ é o comprimento esperado da solução canônica comprimido via gzip.

Validação Empírica
Os autores validam o Corolário 1 (Limite de Variável Embutida) usando um protocolo de embedding apenas de saída. Para preservar a cadeia de Markov necessária para a prova ($z_\pi \to p \to \tilde{p} \to \tilde{z}_\pi$), o embedding $E$ é aplicado apenas ao código gerado, excluindo o contexto do prompt.

• Modelos e Datasets: Experimentos foram conduzidos no CodeLlama-7B e Qwen2.5-Coder-7B nos datasets HumanEval e MBPP-sanitizados.
• Estimadores: A informação mútua foi estimada usando os estimadores MINE (Mutual Information Neural Estimation) e KSG (Kraskov-Stögbauer-Grassberger) nos estados ocultos do último token (reduzidos via PCA).
• Perturbações: Um conjunto de 23 perturbações foi utilizado, incluindo trocas de sinônimos, negação, injeção de comentários (incluindo anti-comentários de segurança) e renomeação de identificadores.

Principais Resultados

1. Satisfação do Limite: Em seis configurações de validação individuais (variando modelos, datasets, precisão e ablações de embedding), o check de embedding satisfez a desigualdade. A razão de saturação $(Cap + \max_T Sec) / (H(z^*) + \max_T I(p; \tilde{p}))$ variou de 0,27 a 0,92, com folga positiva do teorema (2,36 a 26,94 nats).
2. Estabilidade: Um diagnóstico de estabilidade de três sementes mostrou uma saturação média de 0,87.
3. Testes de Estresse: Testes de estresse adaptativos, incluindo um pool de 23 perturbações, um sufixo de anti-segurança universal fixo e um ataque PGD baseado em gradiente, todos resultaram em folga positiva, confirmando que o limite se mantém mesmo sob estratégias agressivas de perturbação.
4. Sinal por Problema: Embora o limite teórico utilize embeddings apenas de saída, um cosseno de embedding de contexto misto (condicionando tanto o prompt quanto o código) foi encontrado como correlacionado com o pass@1 de execução (ex: $\rho=0,36$ para CodeLlama-HumanEval), servindo como um sinal de alinhamento prático distinto do limite de segurança.
5. Análise de Vazamento: O estudo identificou que a renomeação de identificadores e a substituição de sinônimos deixam os maiores tetos de informação compartilhada (alto $I(p; \tilde{p})$), enquanto os anti-comentários de segurança vazam menos informação do prompt, mas são mais perigosos para a segurança.

Significância e Alegações
O artigo afirma fornecer um orçamento quantitativo e informacional para a estabilidade da geração de código. Sua significância reside na:

• Decomposição: Separar o "orçamento" entre a entropia da tarefa e o vazamento do prompt, permitindo que desenvolvedores entendam que reduzir o vazamento do prompt ($I(p; \tilde{p})$) aperta o canal máximo disponível para um adversário sem necessariamente aumentar a capacidade funcional.
• Teto Agnóstico ao Modelo: O limite de forma fechada para $H(c^*)$ permite que um teto de segurança seja computado para qualquer novo modelo em um conjunto de tarefas conhecido sem exigir acesso ao modelo ou aos dados de treinamento, baseando-se apenas no tokenizador e na distribuição da solução canônica.
• Salvaguardas Práticas: Os autores argumentam que as salvaguardas de assistentes de programação devem ser avaliadas não apenas pelo pass@1, mas pela informação de perturbação de prompt que elas deixam disponível para um adversário. O limite oferece um teste para o endurecimento de prompts: reduzir $I(p; \tilde{p})$ deve estreitar o orçamento de segurança.

Os autores mantêm-se modestos, observando que a contribuição é a instanciação desses conceitos para a geração de código (definindo o orçamento e o teto de forma fechada) em vez de um novo teorema de processamento de dados. Eles reconhecem limitações, incluindo a sensibilidade dos estimadores de MI (onde o MINE pode superestimar próximo aos limites) e o fato de que o limite caracteriza o orçamento de estabilidade disponível, em vez de provar que adversários realistas sempre saturarão esse orçamento.