Atualização da ferramenta LLM corrige falha que vazava chave da OpenAI para outros provedores

A versão 0.37.2 da CLI de Simon Willison fecha duas brechas que podiam enviar a chave da OpenAI para endpoints de terceiros configurados como compatíveis. Quem monta agentes com múltiplos provedores precisa atualizar.

A LLM, a ferramenta de linha de comando criada por Simon Willison para rodar modelos de linguagem a partir do terminal, lançou a versão 0.37.2 em 11 de novembro de 2026. A atualização corrige uma falha de segurança reportada por Daniel de Araujo e catalogada em duas advisories do GitHub, GHSA-v9h7-jj4g-f862 e GHSA-r639-rr7r-x72w. O problema: em certas configurações, a chave da API da OpenAI podia ser enviada sem querer para um provedor diferente, configurado apenas como "compatível com a API da OpenAI".

Para quem usa a LLM só com a OpenAI, o impacto é zero. Mas quem monta agentes e scripts que alternam entre vários provedores (Groq, Together, OpenRouter, um modelo local via Ollama exposto como endpoint OpenAI-compatível) precisa entender exatamente o que vazava e atualizar agora.

Como funciona o mecanismo de endpoints compatíveis

A LLM tem um recurso chamado extra-openai-models.yaml, que permite registrar qualquer API compatível com o formato da OpenAI como se fosse mais um modelo disponível na ferramenta. Desde a versão 0.37, esse arquivo passou a ser gerenciado também por um comando dedicado, llm openai endpoint add, que evita editar o YAML na mão.

Esse mecanismo depende de um campo chamado api_key_name, que indica qual chave armazenada deve ser usada para autenticar cada endpoint configurado. O objetivo é isolar credenciais: cada provedor guarda sua própria chave, armazenada separadamente via llm keys set nome-da-chave, para que a chave da OpenAI nunca circule fora da OpenAI. É exatamente esse isolamento que falhava em dois cenários específicos.

Os dois cenários exatos do vazamento

Daniel de Araujo encontrou duas formas de a chave da OpenAI escapar para um endpoint de terceiro:

1. Chave nomeada nunca armazenada: se o api_key_name apontava para um nome de chave que o usuário nunca chegou a salvar com llm keys set, a LLM caía de volta para a chave da OpenAI e a enviava ao endpoint configurado, que podia ser qualquer provedor externo.
2. Modelo responses: true rodado com -o chat_completions 1: modelos marcados com responses: true no YAML usam o formato mais novo da OpenAI, a API de Responses. Ao forçar manualmente o modo antigo de chat completions na hora da chamada (-o chat_completions 1), essa troca de formato também abria brecha para a chave da OpenAI vazar.

Nos dois casos, o resultado prático é o mesmo: a chave da OpenAI acaba sendo enviada ao endpoint de terceiro configurado, sem que isso apareça como erro na tela de quem está rodando o comando.

O risco real: sua chave da OpenAI batendo na porta de outro provedor

O estrago concreto aqui não é um bug que trava o programa, é uma chave de API paga trafegando para um serviço que não deveria recebê-la. Qualquer provedor que registre logs de requisição (a maioria registra, por padrão, para debug e billing) passa a ter acesso à sua chave da OpenAI. A partir daí, o risco vira o de sempre com credencial exposta: uso indevido, cobrança inesperada na sua conta OpenAI, ou a chave aparecendo em algum log que vaza adiante.

Para quem roda agentes em produção, com rotação de múltiplos endpoints e automações que chamam a LLM programaticamente, isso é particularmente sensível: o erro não aparece na tela, a chamada simplesmente funciona, só que com a credencial errada no header.

Como saber se você foi exposto

A nota oficial não detalha um procedimento de verificação, mas, na prática, vale uma inspeção manual antes de seguir em frente: checar no seu extra-openai-models.yaml se algum api_key_name aponta para um nome de chave que você nunca chegou a registrar com llm keys set, e revisar se algum modelo marcado como responses: true já foi chamado com o override -o chat_completions 1. Qualquer um desses dois casos é compatível com os cenários de vazamento descritos por Daniel de Araujo.

Se qualquer um desses casos bater, a recomendação prática é rotacionar a chave da OpenAI no painel da própria OpenAI, não só atualizar a LLM.

Atualizando e configurando com segurança

A correção está na versão 0.37.2. A LLM em si é uma ferramenta de código aberto e gratuita: o custo real está nos tokens cobrados por cada provedor configurado, e é exatamente por isso que vazar uma chave para o provedor errado tem peso financeiro, não só reputacional.

Como boa prática daqui pra frente, vale sempre registrar a chave de cada provedor explicitamente com llm keys set nome-do-provedor antes de adicionar o endpoint com llm openai endpoint add, e evitar misturar o override -o chat_completions 1 em modelos que já foram configurados como responses: true. Separar completamente as credenciais por provedor, sem depender de fallback implícito, é o que o próprio mecanismo de api_key_name deveria garantir e que a 0.37.2 volta a cumprir.

Fonte: Simon Willison