Todo Chamador de LLM Ganhou Proteções de Comprimento de Prompt Hoje

Um prompt ilimitado é um ataque de amplificação de custo esperando para acontecer. A RakuAI trata a disciplina de comprimento de prompt como infraestrutura de segurança — aplicada no build, não deixada à memória.

O runtime chama LLMs em mais lugares do que eu vinha rastreando. Há o óbvio (o XRAssistantService que conduz experiências de AR baseadas em voz). Há o menos óbvio (a camada de comportamento de NPCs, onde o cérebro de um agente no mundo é parcialmente uma chamada de LLM). Há o menos óbvio de todos (ferramentas de tempo de desenvolvimento que começaram a se infiltrar no build do runtime: validadores de schema, analisadores de depuração, um resumidor automático de playtest).

Cada um desses lugares foi escrito de forma independente ao longo dos últimos seis meses. Cada um foi revisado no momento do PR. Nenhum deles, até este fim de semana, tinha uma disciplina uniforme sobre comprimento de prompt.

Este é o post sobre por que isso se tornou um problema, o que a auditoria encontrou e como são as novas proteções.

Como o problema veio à tona

O gatilho foi uma verificação rotineira de monitoramento de custo. Olhando o gasto diário com a API de LLM, um ambiente de desenvolvimento específico estava gastando quinze vezes mais que os outros. Mesma quantidade de agentes, mesma carga de teste, mesmo modelo. Quinze vezes o custo.

Rastrear o pico levou ao caminho de código do resumidor de playtest. O resumidor pega uma sessão de playtest concluída, empacota o estado de cena relevante em um prompt, envia para um LLM na nuvem e recebe de volta uma análise estruturada da sessão. A função havia sido escrita quando as cenas eram pequenas. O “estado de cena relevante” era um resumo estruturado do que aconteceu. Com o tempo, o resumo cresceu. Um ambiente de desenvolvimento específico vinha executando playtests longos que produziam resumos enormes. O resumidor enviava esses resumos sem verificação para o modelo. O modelo cobrava por token.

A correção para esse chamador único era óbvia. Limitar o comprimento do resumo. Truncar se necessário. Registrar quando o truncamento acontece.

A pergunta mais profunda foi a que eu fiz em seguida: quantos outros chamadores no runtime têm a mesma vulnerabilidade? Fui procurar. A auditoria foi o trabalho real.

O que a auditoria encontrou

Onze lugares no runtime que chamam um LLM. Desses onze:

• Dois tinham verificações explícitas de comprimento e comportamento razoável em caso de excesso (truncar, registrar, tentar novamente com contexto menor). Esses estavam bem.
• Cinco não tinham nenhuma verificação de comprimento. Enviavam o que quer que o chamador entregasse.
• Três tinham uma verificação de comprimento, mas era generosa demais para ser útil (cem mil tokens, bem acima de qualquer uso sensato, mas bem abaixo do catastrófico).
• Um era um caminho de depuração que nem deveria estar no binário de produção; tinha uma verificação de comprimento, mas era facilmente contornada por uma flag de depuração.

Os cinco sem verificação de comprimento eram os urgentes. Cobriam: o resumidor de playtest (já identificado), o cérebro de comportamento de NPC (potencialmente enorme se um NPC pudesse observar uma cena complexa), o validador de schema (poderia receber um arquivo arbitrário), o descritor de estado do mundo (poderia descrever um bloco de mundo arbitrariamente grande) e uma das ferramentas de diagnóstico voltadas ao desenvolvedor.

Cada um desses havia chegado em um PR separado. Cada PR tinha sido razoável isoladamente. A disciplina agregada de “todo chamador de LLM tem um limite de comprimento” não era responsabilidade de ninguém. Então ninguém tinha feito.

Como são as proteções

Uma pequena peça de infraestrutura chegou no sábado de manhã e foi aplicada a todo chamador ao longo do dia.

Um utilitário compartilhado LLMCallGuard. Todo lugar que conversa com um LLM agora passa por esse utilitário em vez de construir requisições diretamente. O utilitário recebe um template de prompt, um payload de contexto e um modelo-alvo. Ele aplica um limite de comprimento (configurável por modelo, com padrões sensatos baseados na janela de contexto documentada do modelo). Ele registra o comprimento real do prompt usado em nível INFO no caso orçado, em nível WARNING quando precisa truncar, e em nível ERROR quando o truncamento falha em caber no limite.

Orçamentos por chamador. Cada chamador de LLM no runtime agora tem um orçamento explícito de tokens por chamada. O orçamento fica abaixo da janela de contexto do modelo porque queremos deixar espaço para a resposta e queremos falhar alto e claro antes que o modelo falhe silenciosamente. Os orçamentos variam de alguns milhares de tokens (o validador de schema) a vinte mil tokens (o resumidor de playtest, com um limite real que evita o incidente original).

Telemetria. Toda chamada de LLM agora registra o tamanho do prompt, o tamanho da resposta, o modelo, o orçamento consumido e a latência. A telemetria é o que me permite notar o próximo incidente antes que a fatura chegue.

Uma hierarquia de modos de falha. Quando o payload de um chamador excede o orçamento, o utilitário tenta uma sequência de correções em ordem. Primeiro, tenta truncar de forma inteligente (preservar o contexto mais recente, descartar o mais antigo, manter o prompt de sistema intacto). Segundo, se o truncamento inteligente ainda não couber, tenta um truncamento mais grosseiro (descartar seções inteiras). Terceiro, se nenhum truncamento couber, falha de forma alta e clara com um erro nítido em vez de enviar uma requisição superdimensionada que o modelo vai rejeitar. A hierarquia significa que a maioria dos casos se recupera graciosamente, os casos extremos falham de forma observável, e nenhum chamador jamais envia um payload ilimitado.

Uma verificação de CI que impede regressão. Novo código que conversa com um LLM precisa passar pelo LLMCallGuard. A varredura de CI encontra qualquer nova chamada direta de LLM que contorne o utilitário e sinaliza o PR. O padrão é o mesmo que a auditoria de segurança usou alguns fins de semana atrás para endpoints administrativos: aplicar a disciplina no build, não na revisão.

O que eu aprendi

Três coisas.

Disciplina que não é responsabilidade de ninguém é disciplina que não acontece. Os onze chamadores de LLM haviam sido, cada um, razoáveis no momento do PR. O comportamento coletivo não tinha sido revisado porque ninguém era dono da preocupação transversal. A correção foi tornar essa preocupação transversal uma peça de infraestrutura pela qual todo chamador precisa passar, o que torna a disciplina impossível de esquecer.

Custo é uma preocupação de segurança. Eu vinha pensando em “prompts ilimitados” como uma preocupação de correção ou robustez. O pico de custo no ambiente de desenvolvimento me ensinou a pensar nisso como uma preocupação de segurança. Um atacante que consiga influenciar o conteúdo de uma chamada de LLM a partir do runtime pode gerar custo arbitrário para o operador. As mesmas defesas (limites de comprimento, aplicação de orçamento, telemetria) protegem tanto contra falhas de robustez quanto contra ataques de amplificação de custo.

Auditar em cadência. A auditoria de hoje encontrou cinco vulnerabilidades que a revisão de PR havia deixado passar. A próxima auditoria encontrará outras. A disciplina de executar uma passagem de auditoria agendada sobre uma preocupação transversal específica é a única forma confiável que encontrei para trazer à tona as coisas que a revisão deixa passar.

O que parceiros e desenvolvedores devem levar disso

Se você está rodando qualquer coisa que chame um LLM a partir de código de produção e ainda não auditou todo chamador quanto à disciplina de comprimento de prompt, faça isso. A auditoria é pequena. Os achados são prováveis. O custo de fazer isso hoje é muito menor que o custo de fazer depois de um incidente.

Se você é um laboratório de IA construindo agentes que chamam outros LLMs, a métrica a otimizar é “o agente sinaliza quando está construindo um prompt ilimitado”. A maioria dos agentes não faz isso. Os que fazem são os que eu confio para trabalho sério.

Se você está avaliando um engine para parceria e o engine se integra com LLMs na nuvem, pergunte sobre disciplina de comprimento de prompt. A resposta certa é “todo chamador passa por um utilitário compartilhado, com orçamentos por chamador, com telemetria, com uma trava de CI”. A resposta errada é “ainda não vimos esse problema”.

Sábado à tarde. Todo chamador de LLM no runtime agora passa pela mesma proteção. A próxima cadência de auditoria está na agenda.

Voltando a construir.