Violação de segurança do OpenCode expôs chaves de provedores de IA, mas instalações locais enfrentam um risco diferente

O OpenCode divulgou uma violação de segurança que afetou 1,4% dos usuários do Console depois que invasores acessaram um sistema legado e possivelmente obtiveram chaves vinculadas de provedores de IA. Essas credenciais poderiam autorizar solicitações cobradas a serviços da OpenAI, Anthropic, Google e outros provedores de modelos.

A violação de segurança do OpenCode não estabeleceu que todas as instalações locais do OpenCode foram comprometidas. A exposição relatada se concentrou no OpenCode Console, um serviço hospedado opcional que pode armazenar credenciais de provedores para espaços de trabalho compartilhados. Segundo sua documentação e seus mantenedores, o aplicativo local do OpenCode usa um caminho diferente para as credenciais.

Essa distinção limita o escopo confirmado, mas não elimina o problema operacional. As equipes de segurança ainda precisam localizar instalações do OpenCode, identificar quem usou o Console, rastrear credenciais vinculadas e revisar a atividade dos provedores. O incidente transforma uma ferramenta de programação com IA em uma investigação de gerenciamento de credenciais entre máquinas de desenvolvedores, espaços de trabalho hospedados e contas externas de cobrança.

O que a violação de segurança do OpenCode realmente expôs

O evento central foi o acesso não autorizado a chaves de provedores armazenadas pelo OpenCode Console, e não um comprometimento confirmado de todos os clientes OpenCode.

O OpenCode divulgou o incidente em 17 de outubro de 2026. A empresa afirmou ter sofrido uma violação de segurança relacionada ao que chamou de ataque de destilação em larga escala. Ela informou que 1,4% dos usuários do OpenCode Console foram afetados e disse ter notificado esses usuários por e-mail.

A notificação da empresa aos clientes atribuiu a exposição a um acesso não autorizado envolvendo um sistema legado que estava sendo desativado. Ela alertou os destinatários de que chaves de provedores terceiros salvas em seus espaços de trabalho poderiam ter sido expostas. A notificação orientou os clientes afetados a revogar essas chaves, substituí-las e revisar o uso recente.

O OpenCode Console é um serviço hospedado associado ao agente de programação de código aberto. Seus recursos de espaço de trabalho permitem que administradores conectem contas de provedores e disponibilizem modelos aprovados para outros membros. A documentação de provedores do Console do OpenCode informa que o serviço armazena a credencial do provedor e a insere ao encaminhar solicitações por seu gateway.

Essa arquitetura impede que membros comuns do espaço de trabalho vejam o segredo subjacente. Ela também posiciona as credenciais armazenadas atrás de uma fronteira de serviço compartilhada. Se essa fronteira falhar, um único incidente pode afetar contas em diversos provedores upstream.

Relatos de usuários afetados descreveram uso inesperado de modelos e alertas de gastos. Alguns afirmaram que atividade não autorizada surgiu em mais de uma conta de provedor. OpenAI, Anthropic e Google teriam trabalhado para bloquear credenciais expostas, restaurar o acesso ou lidar com cobranças não autorizadas.

As informações disponíveis não fornecem um número verificado de chaves expostas. O OpenCode não publicou o total de usuários do Console, portanto o número de 1,4% divulgado pela empresa não pode ser convertido em uma contagem confiável de vítimas.

A empresa também não detalhou publicamente como os invasores entraram no sistema legado. Ela não explicou como as credenciais eram protegidas em repouso, quais controles os invasores contornaram ou se os intrusos acessaram outros dados dos espaços de trabalho.

Essas lacunas importam porque a expressão “ataque de destilação” descreve o propósito presumido do acesso roubado aos modelos, não necessariamente a técnica de intrusão. A destilação de modelos geralmente envolve coletar saídas de um modelo para treinar ou aprimorar outro. Chaves de API roubadas podem financiar essa atividade, mas não explicam como as chaves foram obtidas.

A divulgação inicial, portanto, sustenta uma conclusão mais restrita. Invasores alcançaram um sistema legado do Console, chaves de provedores podem ter sido expostas e houve uso não autorizado de modelos. O caminho preciso da intrusão e as evidências que conectam esse acesso à destilação de modelos permanecem não divulgados.

Reportagem independente também documentou uma complicação incomum durante a resposta. O cofundador do OpenCode, Dax Raad, disse que alguns modelos de fronteira inicialmente ajudaram a analisar o incidente, mas depois recusaram solicitações quando material malicioso acionou seus controles de segurança.

Posteriormente, o OpenCode recebeu acesso ao programa Daybreak Blue da OpenAI, que, segundo relatos, dá a defensores avaliados acesso a modelos com menor probabilidade de recusar investigações legítimas de segurança. Esse episódio adiciona uma segunda questão à violação: os defensores dependem cada vez mais de sistemas de IA cujas políticas de segurança podem interromper a análise de incidentes.

A fronteira do Console muda quem está em risco

As organizações devem separar a exposição confirmada no Console da postura de segurança mais ampla do agente local do OpenCode.

O OpenCode pode ser executado localmente e se conectar diretamente aos provedores de modelos. Sua documentação informa que as credenciais adicionadas pelo fluxo local legado /connect eram armazenadas em ~/.local/share/opencode/auth.json. Instalações mais recentes do OpenCode V2 armazenam credenciais salvas em um banco de dados SQLite local, geralmente no mesmo diretório de dados do OpenCode.

Essas credenciais locais seguem um caminho diferente dos segredos de provedores salvos em um espaço de trabalho do Console. O mantenedor do OpenCode, Dax Raad, afirmou que a violação envolveu o OpenCode Console, e não o OpenCode em si. Ele também disse que chaves configuradas diretamente no aplicativo não chegavam à empresa.

Essa afirmação é importante, mas não deve encerrar uma investigação empresarial. Inventários de ativos raramente distinguem uma ferramenta de linha de comando de sua conta opcional na nuvem. Desenvolvedores podem usar um agente local, entrar no Console, participar de vários espaços de trabalho e conectar diferentes contas de provedores ao longo do tempo.

Assim, uma máquina pode conter o OpenCode sem ser afetada pela violação relatada. Por outro lado, um desenvolvedor pode ter usado o Console em um navegador ou em outra máquina que já não contém o executável. A busca apenas em endpoints não produzirá uma lista completa de vítimas.

A unidade correta de investigação é a relação entre quatro registros: a identidade do desenvolvedor, a instalação local do OpenCode, o espaço de trabalho do Console e a credencial do provedor. As equipes de segurança precisam reconciliar os quatro.

Isso cria pressão imediata para organizações de engenharia com adoção descentralizada de ferramentas. Um funcionário pode ter conectado uma chave pessoal de provedor, uma credencial de equipe ou uma conta de serviço específica de um projeto. Cada escolha produz um raio de impacto diferente.

Uma chave pessoal pode gerar cobranças diretas e expor a conta do provedor do funcionário. Uma chave compartilhada pela equipe pode afetar diversos aplicativos. Uma credencial de nuvem com privilégios amplos pode gerar consequências além do uso de modelos caso pertença a um projeto maior na nuvem.

A mesma distinção se aplica ao código-fonte e aos dados de conversas. As informações públicas atuais sustentam uma possível exposição de credenciais de provedores armazenadas. Elas não estabelecem que todos os repositórios, prompts, arquivos locais ou conversas do OpenCode foram acessados.

No entanto, os investigadores devem evitar transformar incerteza em garantia. Até que o OpenCode publique um relatório detalhado pós-incidente, as organizações afetadas devem perguntar se o sistema legado continha registros de solicitações, metadados de contas, membros dos espaços de trabalho ou outras informações úteis a um invasor.

A própria documentação de segurança do OpenCode também afirma que seu agente local não é isolado em sandbox. O sistema de permissões ajuda os usuários a ver e aprovar ações, mas não oferece isolamento de segurança. O OpenCode recomenda um contêiner ou uma máquina virtual quando é necessário isolamento real.

Esse modelo de ameaça é separado do incidente do Console. Ainda assim, ele explica por que localizar instalações importa. Um agente capaz de executar comandos de shell, modificar arquivos e acessar a web merece governança deliberada mesmo quando não há evidências de que seu endpoint foi violado.

As organizações devem tratar a exposição do Console como um incidente urgente de credenciais. Devem tratar os agentes locais identificados como uma questão mais ampla de segurança de endpoints e desenvolvimento. Combinar essas conclusões em uma única afirmação superestimaria a violação ou subestimaria os privilégios normais do agente.

Como localizar o OpenCode em máquinas de desenvolvedores

Um processo útil de descoberta combina buscas por executáveis, evidências de processos, caminhos de dados locais, registros de pacotes e informações de identidade.

Comece perguntando aos desenvolvedores se eles usaram o OpenCode Console ou receberam um e-mail sobre o incidente. Essa consulta é mais rápida do que uma varredura cega de endpoints e aborda diretamente o grupo de exposição confirmado. Preserve o e-mail e registre cada espaço de trabalho e credencial mencionados antes de alterar qualquer coisa.

As equipes de identidade devem pesquisar logs de logon único, registros de acesso do navegador, telemetria de DNS, eventos de gateway seguro da web e registros de despesas em busca de domínios do OpenCode. Essas fontes podem identificar ex-usuários e acessos somente por navegador que inventários de pacotes em endpoints deixam passar.

No macOS e Linux, os defensores podem verificar se o executável está disponível no shell atual:

Os dois primeiros comandos localizam caminhos de executáveis conhecidos pelo shell. O comando de versão pode confirmar que um binário encontrado é executado, mas as equipes devem evitar executar um arquivo não confiável durante a coleta forense. Em vez disso, gere um hash ou coloque um binário suspeito em quarentena.

Processos ativos fornecem outro sinal:

As buscas por processos mostram apenas o software em execução no momento da coleta. Elas não podem provar que o OpenCode nunca foi instalado, e um executável pode ter sido renomeado.

Gerenciadores de pacotes podem fornecer evidências históricas ou atuais de instalação. Em sistemas de desenvolvedores, revise fórmulas e casks do Homebrew, pacotes JavaScript instalados globalmente, registros de instalação do shell, catálogos de aplicativos gerenciados e inventários de software de ferramentas de gerenciamento de endpoints.

As equipes devem procurar explicitamente por um executável opencode em vez de presumir um único nome de pacote. Métodos de empacotamento e instalação podem mudar, enquanto projetos com nomes semelhantes podem gerar falsos positivos.

Diretórios de dados do OpenCode fornecem evidências mais fortes do que um executável isolado. Para instalações locais legadas, inspecione o caminho documentado:

Não imprima o conteúdo de arquivos de credenciais em logs de terminal, tickets ou sistemas de chat. Uma simples listagem de diretórios pode comprovar a presença sem expor segredos.

O OpenCode V2 pode informar a localização de seu banco de dados por meio de comandos de depuração. Sua documentação de provedores informa que o caminho local usual do banco de dados é ~/.local/share/opencode/opencode.db, embora configurações de ambiente e canais de lançamento possam alterá-lo.

No Windows, os defensores podem procurar o executável e os processos ativos com comandos integrados:

Perfis de usuários, inventários de gerenciadores de pacotes, logs de controle de aplicativos do Windows e telemetria de detecção de endpoints podem revelar instalações adicionais. Pesquise cada perfil em vez de verificar apenas a conta que executa a varredura.

Ambientes de desenvolvimento em contêineres exigem cobertura separada. Pesquise imagens de desenvolvimento aprovadas, configurações de Dev Container, históricos do Docker, espaços de trabalho remotos e ambientes efêmeros de CI. Uma varredura em laptops de funcionários não identificará um agente instalado apenas dentro de um contêiner ou host de desenvolvimento em nuvem.

As buscas no repositório podem encontrar arquivos de configuração do OpenCode, referências de políticas ou scripts de configuração. Elas não devem coletar indiscriminadamente código-fonte ou segredos. Restrinja a busca a nomes de configuração conhecidos e comandos de instalação e, em seguida, valide cada resultado com o proprietário do repositório.

Os históricos de shell também podem conter evidências de instalação ou execução. Esses registros são sensíveis porque podem incluir tokens e comandos privados. Colete-os apenas de acordo com os procedimentos de resposta a incidentes e privacidade da organização.

A detecção deve responder a mais do que apenas se um binário existe. Para cada instalação confirmada, registre o usuário, dispositivo, versão, método de instalação, última execução observada, localização dos dados locais, status de login no Console, participação em workspaces e provedores conectados.

A questão mais importante é se o usuário salvou uma credencial de provedor em um workspace do Console afetado. Uma instalação local com apenas credenciais locais fica fora do escopo da violação descrita até agora. Um usuário do Console pode exigir rotação imediata mesmo que nenhum executável do OpenCode permaneça no dispositivo atual.

O fluxo regular de provedor local do OpenCode oferece suporte a muitos serviços. Seu guia de provedores locais documenta credenciais diretas e autenticação em nuvem baseada em variáveis de ambiente. Essa variedade significa que os scripts de descoberta devem buscar relações, não copiar todos os segredos possíveis para um relatório central.

As variáveis de ambiente exigem tratamento especial. Seus nomes podem indicar quais provedores estavam disponíveis para um processo, mas seus valores são segredos. Os sistemas de detecção devem registrar que uma variável existiu sem capturar seu conteúdo completo.

As equipes de endpoints também devem procurar o modo de servidor não autenticado do OpenCode. De acordo com o modelo de ameaças do projeto, o modo de servidor é opcional e deve usar OPENCODE_SERVER_PASSWORD para autenticação HTTP Basic. Um servidor local ou remoto exposto representa um risco separado que exige contenção, mesmo não sendo a causa relatada da violação do Console.

Para organizações sem um inventário de software confiável, este evento é um motivo para criar um. Agentes de programação com IA são ferramentas de desenvolvimento executáveis com acesso à rede e relações com credenciais. Eles devem aparecer nos mesmos controles de ativos usados para extensões de IDE, gerenciadores de pacotes, ferramentas de build e softwares de administração remota.

Um sistema técnico de documentos pesquisável pode ajudar as equipes a preservar registros de instalação, decisões de resposta e responsabilidades sem espalhá-los por mensagens privadas. O mesmo princípio se aplica a uma base de conhecimento de engenharia: a evidência só é útil quando os responsáveis pela resposta conseguem recuperá-la e conectá-la.

A Resposta Começa Com a Contenção no Provedor

Revogar uma credencial exposta junto ao provedor que a emitiu é mais confiável do que excluí-la do aplicativo que a armazenou.

Primeiro, preserve a notificação e identifique cada credencial nomeada pelo OpenCode. Registre seu provedor, workspace, proprietário, projeto, permissões, data de criação e serviços dependentes conhecidos. Nunca cole o segredo completo no registro do incidente.

Segundo, revogue cada chave afetada no próprio console do provedor. Remover uma credencial do OpenCode não invalida uma cópia já obtida por um invasor. A revogação no provedor fecha o caminho de autorização.

Terceiro, crie credenciais substitutas somente após confirmar que as antigas foram desativadas. Use chaves separadas para projetos, ambientes e ferramentas distintos. Evite substituir um segredo compartilhado por outro segredo amplamente compartilhado.

Quarto, atualize os aplicativos legítimos que dependiam da chave revogada. Coordene esta etapa com os proprietários dos serviços, pois uma rotação rápida pode interromper ambientes de desenvolvimento, trabalhos agendados, sistemas de testes e cargas de produção.

Quinto, analise o uso do provedor desde o momento mais antigo plausível de exposição. Relatos situam a possível exposição já em 17 de outubro de 2026, às 00:30 UTC. Uma investigação cautelosa deve incluir uma margem anterior e continuar até a revogação confirmada.

Procure modelos desconhecidos, picos repentinos de tokens, horários incomuns de solicitações, novas redes de origem, regiões inesperadas e projetos atingindo limites de orçamento. Compare esses eventos com a atividade de desenvolvimento, jobs de CI e cargas de trabalho automatizadas conhecidas.

Sexto, inspecione alertas de cobrança e segurança. Solicitações não autorizadas de modelos podem aparecer primeiro como uma anomalia de gastos, e não como um alerta de login, porque uma chave de API não exige uma sessão interativa na conta.

Sétimo, entre em contato com o provedor por seu canal oficial de suporte ou segurança. Peça que ele preserve metadados relevantes das solicitações, identifique uso abusivo, restaure projetos suspensos incorretamente e explique o processo de reembolso.

Oitavo, remova credenciais obsoletas e conexões de provedores de todos os workspaces do Console. Não reconecte segredos substitutos até que o OpenCode forneça informações técnicas suficientes para que o responsável de risco da organização aprove essa decisão.

Nono, reduza o valor de qualquer chave futura roubada. Use orçamentos no provedor, limites de taxa, separação de projetos, permissões mínimas, expiração, restrições de rede ou identidades de serviço, quando houver suporte.

Os controles de orçamento não são uma fronteira de segurança. Eles podem limitar perdas financeiras e acelerar a detecção, mas um invasor ainda pode consumir capacidade sensível de modelo ou provocar medidas de fiscalização na conta antes que o orçamento se esgote.

Décimo, inspecione as máquinas locais sem presumir que elas causaram a exposição. Revise os caminhos de dados do OpenCode, versões, processos ativos, configuração e parâmetros do modo de servidor. Preserve artefatos suspeitos antes de desinstalar o software.

Se as credenciais locais nunca foram armazenadas no Console, faça sua rotação com base em evidências e na política organizacional, e não em uma alegação não comprovada de que todos os segredos do OpenCode vazaram. A rotação é barata para uma chave de desenvolvimento isolada, mas uma rotação em massa descuidada pode causar indisponibilidades e ocultar a linha do tempo do incidente.

Décimo primeiro, identifique segredos subsequentes disponíveis ao agente local. O OpenCode pode acessar ferramentas de shell e arquivos de projeto com aprovação do usuário. Uma chave de provedor comprometida não expõe automaticamente tokens de repositório, credenciais de nuvem ou chaves de assinatura, mas esses ativos merecem revisão se evidências do endpoint mostrarem comandos maliciosos ou acesso não autorizado.

Décimo segundo, monitore as credenciais substitutas. As novas chaves devem receber alertas mais rigorosos que as antigas. Os investigadores precisam saber se as solicitações suspeitas param após a rotação ou reaparecem por outro caminho de acesso.

Décimo terceiro, documente a decisão sobre o uso contínuo do Console. O registro deve indicar o responsável de risco, as evidências analisadas, as incógnitas remanescentes e os controles necessários antes que as credenciais possam ser armazenadas nele novamente.

Por fim, mantenha a investigação aberta até que a atividade do provedor, os registros de cobrança, os logs de identidade e as conclusões dos endpoints estejam alinhados. Uma varredura limpa em um laptop não elimina o risco de uma credencial do Console. Uma chave revogada não elimina o risco de um servidor local exposto. Cada camada responde a uma pergunta diferente.

O Rótulo de Destilação Ainda É a Parte Mais Frágil da História

O OpenCode associou o incidente à destilação de modelos em larga escala, mas as evidências públicas ainda não estabelecem esse motivo ou mecanismo.

Uma campanha de destilação pode usar as saídas de um modelo para treinar ou refinar outro modelo. Em escala, esse processo exige muitas solicitações e pode gerar cobranças substanciais dos provedores. Chaves de API roubadas dariam a um invasor acesso à inferência paga sem usar sua própria conta de cobrança.

Essa explicação é plausível, mas plausibilidade não é atribuição. O OpenCode não divulgou amostras de solicitações, padrões de tráfego, modelos-alvo, infraestrutura do invasor ou outros indicadores que mostrem que o uso não autorizado alimentou um pipeline de treinamento.

A expressão também pode confundir duas ações distintas. O acesso não autorizado a um sistema legado é a violação. Consultas em alto volume com credenciais roubadas são o abuso. A destilação é uma possível finalidade desse abuso.

As equipes de segurança não precisam resolver o objetivo final do invasor antes de agir. A resposta continua a mesma para roubo de credenciais usado em destilação, spam, benchmarking, revenda ou outra inferência não autorizada.

O rótulo importa para a responsabilização, porém. Chamar um evento de ataque de destilação pode deslocar a atenção para competição entre modelos e restrições geopolíticas de acesso. Chamá-lo de violação de credenciais direciona a atenção para armazenamento, segmentação, monitoramento e aposentadoria de sistemas legados.

Ambos os temas merecem investigação, mas apenas um foi claramente estabelecido. O incidente documentado envolve acesso não autorizado a sistemas legados e credenciais de portador expostas. A conexão alegada com destilação continua sendo uma caracterização da empresa à espera de evidências de suporte.

O incidente também expôs um conflito na defesa assistida por IA. A equipe do OpenCode supostamente usou agentes de IA continuamente enquanto invasores continuavam sondando seus sistemas. Alguns modelos mais tarde se recusaram a analisar conteúdo malicioso porque as solicitações se assemelhavam a atividades ofensivas proibidas.

Um problema semelhante surgiu em um incidente anterior envolvendo o Hugging Face. Defensores argumentaram que as proteções dos modelos não conseguiam distinguir de forma confiável os responsáveis pela resposta a incidentes dos invasores que analisavam o mesmo material de exploração. A resposta frequentemente passa a ser o uso de modelos controlados localmente ou especialmente aprovados.

Essa troca não significa que modelos sem restrições sejam automaticamente mais seguros. Um modelo com menos recusas pode ajudar um responsável autorizado, mas também pode auxiliar um invasor. Controles de acesso, trilhas de auditoria, ambientes isolados de análise e programas verificados para responsáveis continuam necessários.

A violação, portanto, contrapõe duas promessas à realidade operacional. Gateways de IA hospedados prometem acesso mais simples a muitos provedores, mas podem centralizar credenciais valiosas. Modelos com proteções prometem comportamento mais seguro, mas esses controles podem interromper uma resposta legítima a incidentes.

Nenhum dos problemas tem uma única solução no nível do produto. As organizações precisam de uma arquitetura que presuma que um gateway pode falhar e de procedimentos de resposta que não dependam de um único modelo concordar em analisar código hostil.

O modelo público de ameaças do OpenCode é um contexto útil. O agente pode executar comandos e acessar arquivos, enquanto seus prompts de permissão não são um sandbox. Esse design dá flexibilidade aos desenvolvedores, mas também torna identidade, isolamento de endpoints e escopo de credenciais controles centrais de segurança.

A violação não deve ser usada para alegar que agentes de código aberto são inerentemente inseguros ou que ferramentas proprietárias são inerentemente seguras. A questão central é onde as credenciais ficam, quem pode usá-las, como a atividade é monitorada e o que acontece quando um serviço confiável é comprometido.

Um post-mortem técnico permitiria conclusões mais robustas. Ele deve explicar o vetor de acesso inicial, o sistema afetado, a proteção das credenciais, a janela de exposição, o método de detecção, as ações do invasor, a linha do tempo de contenção e as evidências por trás da avaliação de destilação.

Até lá, compradores devem avaliar o incidente com uma hierarquia clara de evidências. O número de 1,4% do escopo informado pelo OpenCode é uma declaração da empresa. Relatos de usuários sustentam a ocorrência real de uso não autorizado. A arquitetura do Console explica por que as credenciais de provedores armazenadas eram importantes. A identidade e o objetivo exato do invasor continuam sem solução.

Três Sinais Mostrarão se a Resposta Está Funcionando

O próximo teste é saber se o OpenCode e os provedores afetados substituirão uma divulgação urgente por evidências verificáveis e controles duradouros.

O primeiro sinal é um relatório detalhado do OpenCode após o incidente. Ele deve explicar como o sistema legado permaneceu acessível, como as credenciais eram armazenadas, quais controles falharam e por que a empresa acredita que a campanha envolveu destilação.

Um relatório completo reforçaria a confiança de que a exposição é compreendida e está limitada. A dependência contínua do número de 1,4% sem um denominador, causa raiz ou contagem de credenciais enfraqueceria essa confiança.

O segundo sinal é a resolução por parte dos provedores. OpenAI, Anthropic, Google e outros serviços afetados devem ser capazes de identificar solicitações não autorizadas, concluir os reembolsos apropriados, restaurar projetos suspensos indevidamente e ajudar os clientes a verificar que as chaves revogadas não funcionam mais.

Esse processo mostrará se os provedores de modelos conseguem se coordenar diante de incidentes de credenciais entre plataformas. Também revelará se os controles antifraude atuais detectam chaves de IA roubadas antes que se acumulem grandes volumes de solicitações faturáveis.

O terceiro sinal é uma mudança arquitetural dentro do OpenCode Console. Os usuários devem observar credenciais de duração mais curta, separação mais robusta das conexões com provedores, registros de auditoria aprimorados, aposentadoria mais rigorosa de sistemas legados e alertas mais claros quando uma chave se comporta de maneira anormal.

Esses controles reduziriam a dependência de um único segredo de portador armazenado. Se as chaves de substituição retornarem a uma arquitetura substancialmente igual, o incidente imediato poderá ser encerrado enquanto o risco subjacente de concentração permanece.

A violação de segurança do OpenCode não é evidência de que todas as máquinas de desenvolvedores que executam OpenCode tenham sido comprometidas. É evidência de que uma camada hospedada opcional pode transformar contas vinculadas de provedores em uma superfície compartilhada de incidentes.

As equipes de segurança devem agir com precisão com base nessa conclusão mais restrita. Encontrem as instalações, identifiquem as relações com o Console, revoguem as credenciais afetadas em sua origem e verifiquem a atividade com cada provedor.

Depois, façam uma pergunta mais difícil: sua organização sabe quais agentes de IA podem executar código, onde suas credenciais estão armazenadas e quem é responsável pela resposta quando uma dessas fronteiras de confiança falha?