Vazamento no OpenCode: proteja chaves com Synthorai Trusted IPs

Em 17 de outubro de 2026, o OpenCode informou que um invasor havia acessado um sistema legado por trás do OpenCode Console, seu serviço hospedado. Segundo a empresa, as chaves de provedores externos salvas ali “podem ter sido expostas”. Depois, usuários relataram cobranças de algumas centenas de dólares até $1,700 em suas contas da OpenAI, Anthropic e Google. Uma chave de provedor é a chave de API que você recebe da OpenAI ou da Anthropic. Armazená-la em uma ferramenta hospedada para que ela faça chamadas ao provedor em seu nome é o chamado BYOK (bring your own key). O prejuízo de uma chave vazada depende de duas coisas: de onde ela pode ser usada e quanto pode gastar antes de ser bloqueada.

TL;DR

• Segundo o OpenCode, a invasão do Console afetou 1.4% dos usuários do Console; as chaves armazenadas pelo OpenCode CLI local não foram afetadas.
• As regras de IP e os limites de gastos de um gateway só se aplicam ao tráfego que passa por ele. Uma chave de provedor vazada precisa de um limite rígido no próprio provedor.
• Com a opção “Aprovação de novos IPs” ativada, a Synthorai rejeita chamadas de qualquer endereço não aprovado para aquela chave de API, com HTTP 403 e ip_not_trusted.
• Cada chave da Synthorai pode ter limite de gastos, limites de requisições e tokens por minuto e data de expiração.

O que aconteceu na invasão do OpenCode Console?

Uma pessoa não autorizada acessou “um sistema legado que estávamos desativando”, segundo o email do OpenCode aos usuários afetados. As chaves de provedores salvas nos workspaces desses usuários no Console podem ter sido lidas. O OpenCode apontou 17 de outubro, às 00:30 UTC, como o primeiro momento possível da exposição. Esta é a sequência dos eventos, com base em publicações do OpenCode, de funcionários dos provedores e da imprensa:

Um ataque de destilação usa respostas de um modelo, coletadas em larga escala, para treinar outro. Chaves roubadas são uma das formas de bancar essas chamadas. O OpenCode não explicou a relação entre a invasão e a destilação. O cofundador Dax Raad afirmou que a invasão envolveu “o OpenCode Console, não o OpenCode em si” e que as chaves adicionadas no CLI local nunca chegam à empresa. Até 21 de outubro, o OpenCode não havia divulgado a causa raiz, se as chaves armazenadas eram criptografadas, quantas contas correspondiam aos 1.4%, uma política de reembolso ou um post-mortem (The Hacker News, BleepingComputer).

Quais chaves foram expostas e quais controles ajudam?

As chaves expostas eram de provedores. Uma chave de provedor roubada é usada diretamente no provedor, sem passar pela ferramenta que a armazenava. Isso limita o que um gateway de LLM pode fazer. O gateway fica entre seu código e os provedores de modelos, encaminhando suas requisições. Portanto, só consegue observar e limitar o tráfego que passa por ele. Convém separar os dois tipos de chave:

Trusted IPs e limites de gastos, tratados nas próximas duas seções, protegem a primeira linha. Para a segunda, a última barreira é o limite rígido configurado na OpenAI, Anthropic ou Google. A seção seguinte às duas lista essas configurações.

Como a Synthorai protege as chaves da plataforma e as chaves BYOK?

As chaves de provedor adicionadas ao cofre BYOK são criptografadas em repouso com AES-256-GCM, um algoritmo padrão de criptografia autenticada. Depois de salvas, nenhuma API, ferramenta MCP ou página do console as retorna: o console mostra apenas os últimos quatro caracteres. O gateway só descriptografa uma chave em memória, para a requisição que a utiliza, e apenas o proprietário do workspace pode adicionar, rotacionar ou remover chaves. As chaves de provedor que a Synthorai usa para sua própria capacidade são armazenadas da mesma forma. Nenhuma página do console ou API as exibe, nem mesmo o console administrativo. A criptografia protege cópias do banco de dados; se o serviço em execução for comprometido, ainda será possível acessar as chaves enquanto estiverem em uso. Por isso, o limite no provedor descrito abaixo é a última barreira para chaves BYOK.

As chaves de API que a Synthorai emite para você são armazenadas apenas como hash, uma impressão digital unidirecional que não permite recuperar a chave. A chave completa é exibida uma única vez, na criação. Todas as consultas posteriores, pelo console, pela API de gerenciamento ou pelo servidor MCP, retornam apenas o prefixo. Uma chave de inferência só pode chamar modelos: a API de gerenciamento a rejeita. Assim, uma chave de inferência roubada não permite consultar logs, uso ou outras chaves (API keys, admin keys).

Como Trusted IPs bloqueia uma chave vazada?

O recurso IPs confiáveis rejeita chamadas de qualquer endereço que não tenha sido aprovado para aquela chave de API. Uma chave copiada de um log de CI ou de um notebook retorna um erro, em vez de uma resposta, quando alguém tenta usá-la de outro lugar. Um proprietário ou administrador ativa o recurso em Configurações › Segurança, na opção “Aprovação de novos IPs”. A caixa de diálogo lista os endereços de onde cada chave foi usada nos últimos sete dias, todos marcados para aprovação. Revise a lista antes de confirmar e desmarque os endereços que não reconhecer: se uma chave já tiver vazado e sido usada, o endereço do invasor também estará ali.

Depois disso, uma chamada de um novo endereço retorna HTTP 403 (o endereço abaixo é um exemplo para documentação):

{
  "error": {
    "type": "permission_error",
    "code": "ip_not_trusted",
    "ip": "203.0.113.9",
    "message": "Requests from IP address 203.0.113.9 are held until this address is approved for the key. ...",
    "approve_url": "https://synthorai.io/console/settings?tab=security"
  }
}

Quem criou a chave recebe um email com o endereço, a localização, o cliente e o modelo solicitado. A aprovação ocorre no console, após o login, portanto encaminhar o email não aprova nada. É possível aprovar um endereço ou seu bloco /24 (256 endereços IPv4 vizinhos), para clientes cujo endereço muda. O gateway obtém o endereço do cliente pela conexão, conforme observado por seus próprios proxies. O cliente não consegue se passar por outro endereço enviando seu próprio cabeçalho X-Forwarded-For, usado por proxies para repassar o endereço original do cliente. Testamos isso com um cabeçalho forjado, e a resposta de bloqueio continuou mostrando o endereço real.

# From an address not yet approved for the key, with a forged header:
curl -s https://synthorai.io/v1/models \
  -H "Authorization: Bearer $SYNTHORAI_API_KEY" \
  -H "X-Forwarded-For: 203.0.113.9"
# The 403's "ip" field is the caller's real address, not 203.0.113.9.

Também é possível criar uma chave com uma ip_allowlist fixa, mas essa lista faz parte das configurações da chave. Cada novo escritório, servidor ou ponto de saída de VPN exige editar a chave, e uma entrada esquecida continua liberada. Trusted IPs parte dos endereços já usados pela chave, pede aprovação antes de confiar em um novo endereço e reúne os endereços de todas as chaves em uma única lista, onde basta um clique para confiar em um endereço conhecido. Se uma chave tiver sua própria allowlist, apenas essa lista será considerada. Use uma opção ou a outra para cada chave.

A confiança é definida por chave. Funções serverless e runners de CI que usam um novo endereço a cada execução seriam bloqueados todas as vezes. Não aprove os blocos publicados por um provedor de CI hospedado: esses endereços são compartilhados por todos os clientes do provedor, então qualquer pessoa executando um job ali passaria pela verificação. Encaminhe essas chamadas por um endereço de saída fixo, como um runner próprio ou um gateway NAT, e aprove esse endereço. Outra opção é fornecer uma chave de curta duração com limite baixo.

Como os limites de gastos contêm o prejuízo de uma chave roubada?

Cada chave de API da Synthorai pode ter seu próprio limite de gastos. Se ela vazar mesmo assim, para de funcionar ao atingir o valor que você definiu. No console, você define o limite, os modelos permitidos e a expiração ao criar a chave:

Os limites de taxa por chave e as demais configurações abaixo são definidos pela API de gerenciamento:

Uma chave para um único serviço, restrita ao que ele precisa, criada com uma chave de administrador (uma chave de gerenciamento que pode criar e limitar chaves, mas não chamar modelos):

curl https://synthorai.io/api/v1/keys \
  -H "Authorization: Bearer sk-syn-admin-..." \
  -H "Content-Type: application/json" \
  -d '{
    "name": "support-bot prod",
    "limit_usd": 50,
    "limit_reset": "daily",
    "rate_limit": {"rpm": 60, "tpm": 200000},
    "allowed_models": ["claude-haiku-5-5"],
    "expires_at": "2027-01-31T00:00:00Z"
  }'

Os proprietários de workspaces também podem definir limites de gastos diário e mensal por membro. Quem atingir o limite mensal recebe HTTP 402 até o mês seguinte. Esses limites se aplicam ao tráfego que passa pela Synthorai. Se BYOK estiver incluído na contagem, eles também cobrem requisições BYOK feitas pelo gateway, mas não uma chave de provedor que vaze e seja usada diretamente.

O que esses controles não bloqueiam?

Trusted IPs bloqueia o uso de uma chave a partir de um novo endereço, mas não faz nada quando ela é usada em uma máquina confiável. Os roubos mais comuns acontecem justamente ali: malware no notebook de um desenvolvedor, um job de CI comprometido ou um servidor induzido a enviar requisições para um invasor. Nesses casos, o que limita o dano é o teto de gastos da chave, sua lista de modelos e uma expiração curta.

A aprovação depende de uma pessoa. Um invasor pode provocar uma requisição bloqueada e torcer para que alguém a aprove por hábito. A página de aprovação mostra o endereço, a localização, o cliente e o modelo. Aprove apenas quando esses dados corresponderem a uma chamada que você fez.

Um limite de gastos com renovação diária permite que uma chave roubada gaste até aquele valor todos os dias, até alguém perceber. Combine limites com detecção: o email de cada endereço bloqueado, os gastos por chave no console e o log de auditoria das alterações nas chaves. Se houver suspeita de vazamento, exclua a chave no console e crie outra. Para detectar chaves antes que vazem, adicione ao serviço que hospeda seu código uma regra de detecção de segredos para o prefixo sk-syn-, por exemplo, um padrão personalizado do GitHub com proteção de push.

O que configurar no provedor para uma chave BYOK?

Dê a cada ferramenta sua própria chave de provedor, em um projeto ou workspace separado, com um limite rígido de gastos. Assim, uma chave vazada só consegue consumir o orçamento daquele projeto. Revogue a chave vazada no painel do provedor: excluí-la da ferramenta que a armazenava não a revoga. Nenhum dos três provedores oferece limites por chave; a menor unidade é o projeto ou workspace:

Alertas de gastos e orçamentos que apenas enviam email não interrompem um ataque em andamento. Vale mantê-los como um segundo sinal, além do limite rígido. A página de BYOK no console da Synthorai traz links para as configurações de limites de cada provedor abaixo das chaves:

É possível usar o OpenCode com a Synthorai?

Sim. As chaves usadas pelo OpenCode CLI local ficam na sua máquina, uma configuração que não foi afetada pela invasão. opencode auth login https://synthorai.io autentica o OpenCode pelo navegador com um código de uso único. O OpenCode recebe uma chave de API própria, que expira em 7, 30 ou 90 dias (guia de configuração). Se a opção “Aprovação de novos IPs” estiver ativada e você autorizar o login pela mesma rede, o endereço usado no login será automaticamente considerado confiável para aquela chave. Chamadas de qualquer outro endereço ficam aguardando aprovação. Quando a solicitação de login vem de uma rede diferente da do navegador, a página de confirmação exibe um aviso, e o endereço só passa a ser confiável depois que sua primeira chamada é aprovada. Se você não executou o comando, cancele a solicitação.

A chave aparece na página de chaves de API como “OpenCode”, onde você pode adicionar um limite de gastos ou excluí-la. Uma chave guardada em um notebook ainda pode ser roubada por malware nessa máquina. Escolha uma chave de 7 ou 30 dias e mantenha “Aprovação de novos IPs” ativado: uma cópia da chave não funcionará em nenhum outro endereço e expirará em pouco tempo.

Perguntas frequentes

As chaves armazenadas no OpenCode CLI foram expostas na invasão?

Não. O OpenCode afirmou que a invasão ficou restrita ao OpenCode Console. As chaves adicionadas no CLI local ou no aplicativo desktop são armazenadas na máquina do usuário e nunca são enviadas ao OpenCode.

Excluir uma chave de provedor de uma ferramenta hospedada a revoga?

Não. Excluir uma chave de uma ferramenta remove apenas a cópia dela. A chave continua funcionando no provedor até você revogá-la no painel do provedor e criar outra.

O limite de gastos de um gateway protege uma chave de provedor que vazou?

Não. Os limites de um gateway contabilizam apenas as requisições que passam por ele. Uma chave de provedor vazada é usada diretamente no provedor, portanto o limite que se aplica é o do próprio provedor.

Veja também: IPs confiáveis, cofre BYOK, chaves de administrador e limites de chaves, configuração do OpenCode.

Fontes consultadas em 21 de outubro de 2026: publicações e emails do OpenCode citados pela imprensa, publicações de funcionários dos provedores e a documentação dos provedores nos links acima. O teste com cabeçalho forjado foi executado no gateway de produção da Synthorai em 21 de outubro de 2026.

← Voltar ao blog