No primeiro episódio da nossa série STRIVE sobre soberania digital, Alex Zinin, da Commvault, e Max Mortillaro, da Osmium Data Group, questionaram um dos maiores equívocos do setor: a soberania digital não é um recurso que se compra — é um problema de negócios que é preciso compreender antes de poder resolver.

Esta conversa retoma o ponto em que a anterior foi interrompida. Desta vez, conversei com Thomas Maurer, Black Belt Global para a área de soberania ( Cloud ) da Microsoft na região EMEA, para explorar o que acontece depois que uma organização decide que a soberania é importante. Como as equipes executivas passam de preocupações gerais sobre regulamentação, jurisdição ou incertezas geopolíticas para decisões práticas de arquitetura?

A resposta, ao que parece, raramente é tão simples quanto escolher um provedor de cloud ou selecionar o modelo de implantação correto. Trata-se de fazer perguntas mais pertinentes antes de tomar decisões técnicas. Assista ao episódio completo.

Pontos principais

• Cada organização define a soberania digital de maneira diferente – e é exatamente por aí que a conversa deve começar.
• A soberania não é resolvida apenas pela tecnologia. Considerações jurídicas, operacionais, arquitetônicas e comerciais influenciam o resultado.
• Cloud e as soluções locais não são estratégias concorrentes. Para muitas organizações, o futuro é uma combinação cuidadosamente planejada de ambas.
• A gestão de riscos — e não o medo — deve orientar as decisões relativas à soberania.
• Uma boa arquitetura começa com a compreensão dos requisitos de negócios, e não com a escolha da infraestrutura.

A soberania tem significados diferentes para diferentes organizações

Uma das primeiras observações feitas por Thomas foi também uma das mais importantes. Não existe uma definição universal para soberania digital. Para uma organização, pode significar simplesmente atender a requisitos regulatórios ou manter os dados dentro de uma área geográfica específica. Para outra, pode envolver independência operacional, continuidade de negócios ou preparação para perturbações geopolíticas. Essa diferença é importante porque muda completamente o rumo da conversa.

Com muita frequência, as organizações partem do princípio de que existe um modelo padrão de soberania pronto para ser implementado. Na realidade, o primeiro desafio não é escolher a tecnologia, e sim entender qual problema a organização está, de fato, tentando resolver. Só então a arquitetura começa a fazer sentido.

A tecnologia deve seguir a estratégia

Um tema que surgiu repetidamente ao longo da nossa discussão foi a tentação de partir diretamente para o projeto técnico. É compreensível. Os arquitetos, naturalmente, pensam em infraestrutura, cargas de trabalho, conectividade e modelos de implantação. Mas Thomas enfatizou que os projetos mais bem-sucedidos começam em outro lugar. Eles começam ouvindo.

Quais são as preocupações que estão impulsionando a iniciativa? O objetivo é a conformidade regulatória? Continuidade dos negócios? Residência de dados? Controle operacional? Proteção contra perturbações geopolíticas? Respostas diferentes levam a arquiteturas diferentes. Isso pode parecer óbvio, mas é surpreendente a frequência com que as organizações começam a avaliar soluções antes mesmo de terem chegado a um consenso sobre o resultado de negócios que pretendem alcançar.

Antevisão: Comece pelo risco, não pelas suposições

Um dos momentos mais práticos da nossa conversa ocorre quando Thomas e eu discutimos por que as iniciativas de soberania devem começar com uma avaliação de riscos – e não com um diagrama arquitetônico.

Cada organização tem uma propensão ao risco diferente. Uma equipe de Fórmula 1, um órgão governamental e uma fabricante global não tomarão as mesmas decisões, nem deveriam. O segredo está em entender quais riscos são mais importantes para o seu negócio, quais concessões você está disposto a fazer e, então, projetar uma arquitetura que apoie essas decisões.

Como Thomas destaca, não existe uma solução perfeita — apenas escolhas ponderadas e bem fundamentadas. Quanto mais cedo as organizações adotarem essa mentalidade, mais sólida será sua estratégia de soberania.

“Cloud ou no local?” é a pergunta errada a se fazer

Uma das partes mais interessantes da conversa questionou outra suposição comum — a de que as organizações devem escolher entre infra cloud a pública e infra a privada. Thomas descreveu uma realidade bem diferente. Muitas organizações não estão substituindo um pelo outro. Elas estão criando ambientes nos quais as cargas de trabalho podem ser transferidas entre eles, de acordo com as necessidades comerciais, os requisitos regulatórios ou considerações de resiliência.

Essa flexibilidade muda a forma como devemos pensar sobre arquitetura. Em vez de perguntar se a nuvem ou o ambiente local é melhor, a pergunta mais útil passa a ser: “Onde essa carga de trabalho se encaixa hoje – e essa resposta poderia mudar amanhã?” Quando a soberania passa a fazer parte do processo de projeto, a mobilidade das cargas de trabalho torna-se tão importante quanto a alocação dessas cargas.

A arquitetura é apenas uma parte da equação

Outra lição que considero importante é o lembrete de Thomas de que a arquitetura, por si só, não resolve a questão da soberania.

• Os contratos são importantes.
• Os marcos legais são importantes.
• Os processos operacionais são importantes.
• As pessoas responsáveis pela gestão do meio ambiente são importantes.

Nenhuma dessas áreas pode atuar isoladamente. A soberania exige que as equipes jurídicas, de segurança, de conformidade e de infraestrutura trabalhem juntas desde o início — e não que passem os projetos de uma para a outra depois que as decisões já tiverem sido tomadas. Esse é um padrão familiar para qualquer pessoa que trabalhe com resiliência cibernética. Os melhores resultados raramente vêm de equipes isoladas. Eles vêm de equipes que atuam de forma coordenada.

O risco deve orientar todas as decisões

No final de nossa discussão, a conversa naturalmente se voltou para o risco. Para mim, é aí que a soberania começa a parecer muito mais familiar. Todo projeto de resiliência começa perguntando o que a organização está tentando proteger, quais ameaças são mais importantes e quanto risco ela está disposta a aceitar.

A soberania digital não é diferente. Em vez de buscar uma solução perfeita, as organizações precisam identificar os cenários específicos de soberania que lhes causam preocupação e, em seguida, determinar quais controles arquitetônicos, operacionais ou contratuais melhor atendem a esses riscos. Essa mudança — da comparação de recursos para a gestão de riscos — é o que, em última análise, leva a melhores decisões.

Por que essa conversa é importante

A soberania digital continua a evoluir rapidamente. Novas regulamentações surgirão. A tecnologia mudará. As realidades geopolíticas continuarão a se transformar. Isso significa que a soberania não é algo que as organizações resolvem de uma vez por todas. É algo que elas avaliam regularmente, à medida que as prioridades comerciais e os riscos externos evoluem.

As organizações que tiverem sucesso não terão necessariamente as arquiteturas mais restritivas. Elas terão a compreensão mais clara de seus objetivos de negócios, a disciplina necessária para avaliar os riscos de forma criteriosa e a flexibilidade para se adaptar à medida que esses riscos mudarem. Em última análise, a soberania digital não é algo que as organizações possam simplesmente adquirir pronto para uso. Trata-se de um processo que envolve compreender os riscos, gerenciar as dependências e fazer escolhas ponderadas com base em informações, muito antes de essas decisões serem postas à prova.

Assista ao episódio completo

Neste episódio do STRIVE, Thomas e eu discutimos:

• Por que a soberania tem significados diferentes para diferentes organizações.
• Como os executivos devem abordar a estratégia de soberania.
• cloud público versus cloud privado – e por que, muitas vezes, não se trata de uma escolha entre uma opção ou outra.
• Por que a gestão de riscos deve orientar as escolhas arquitetônicas.
• O papel da resiliência no planejamento da soberania moderna.

Assista agora

Perguntas frequentes

P: A soberania digital significa manter tudo no local?

R: Não. Muitas organizações adotam abordagens híbridas que equilibram os recursos do “ cloud ” com requisitos específicos de soberania.

P: Por onde devem começar os projetos de soberania?

R: Comece definindo o problema de negócios e compreenda os riscos que você está tentando mitigar antes de avaliar a tecnologia.

P: A soberania é uma questão puramente técnica?

R: Não. Isso exige a colaboração entre as equipes jurídica, de conformidade, de segurança, de operações e de arquitetura.

P: Qual é a relação entre soberania e resiliência?

R: Ambas as disciplinas têm como foco manter a continuidade operacional, reduzindo a exposição a riscos que possam interromper as atividades da empresa.

P: Qual é um grande erro que as organizações cometem no que diz respeito à soberania digital?

R: Tomar decisões arquitetônicas antes de chegar a um consenso sobre o que significa soberania para a organização.

P: O que os executivos devem perguntar em primeiro lugar ao planejar a soberania digital?

R: “Que problema estamos tentando resolver?” Todo o resto decorre dessa resposta.

Darren Thomson é vice-presidente e diretor de tecnologia da Commvault para a região da EMEA.

Há anos, a resiliência cibernética tem sido definida pela tecnologia – controles de segurança, recursos sofisticados de detecção e estratégias de backup cada vez mais robustas, projetadas para prevenir ataques ou permitir uma recuperação mais rápida. Esses investimentos continuam sendo essenciais, mas já não são suficientes. A IA mudou fundamentalmente a natureza dos ataques cibernéticos, que agora ocorrem a uma velocidade que desafia até mesmo organizações maduras. À medida que o intervalo entre a violação e a interrupção dos negócios continua a diminuir, a resiliência está se tornando menos uma questão de prevenir todos os ataques e mais uma questão de manter a empresa em funcionamento quando a prevenção inevitavelmente falha.

Essa mudança está no cerne do novo relatório da IDC, “Operações de Resiliência: A Disciplina que Torna a Readiness Comprovável”. Essa mudança está no cerne do novo relatório da IDC, Operações de Resiliência: A Disciplina que Torna a Prontidão Comprovável. Com base em uma pesquisa realizada com mais de 500 organizações norte-americanas, o relatório argumenta que a resiliência está evoluindo para uma disciplina operacional multifuncional que conecta as prioridades de negócios à segurança cibernética, às operações de TI (ITOps) e à recuperação de desastres. Mais importante ainda, ele revela várias lacunas que sugerem que muitas organizações ainda estão se preparando para um cenário de ameaças que já não existe. Aqui estão os insights que se destacaram. 

A recuperação deve começar com os resultados comerciais – e não com os técnicos.

Historicamente, o planejamento de recuperação tem se concentrado em restaurar a infraestrutura o mais rápido possível, sendo o sucesso avaliado por meio de objetivos de tempo de recuperação, taxas de conclusão de backup e disponibilidade de aplicativos. Embora essas métricas continuem sendo valiosas, elas não respondem necessariamente à pergunta que mais interessa aos executivos: quando poderemos colocar a empresa de volta em operação? 

A IDC defende que a resiliência deve estar ligada aos resultados comerciais, e não a marcos técnicos — restaurando as capacidades que permitem à organização atender aos clientes, gerar receita e cumprir suas obrigações. Isso pode parecer uma questão de semântica, mas muda a forma como as prioridades de recuperação são estabelecidas. A tecnologia passa a ser um meio para atingir um fim, e não o fim em si. 

A maioria das organizações ainda não definiu o que é mais importante.

Quase 6 em cada 10 organizações ainda não definiram completamente seu negócio mínimo viável (MVB) – o menor conjunto de funções, sistemas, processos e dados necessários para continuar operando após uma interrupção. 

Sem um entendimento comum sobre o que realmente sustenta o negócio, cada ação tomada durante a recuperação passa a ser reativa. Ao definir seu MVB antes de uma crise, você possibilitará decisões mais rápidas, uma melhor coordenação durante a recuperação e, em última instância, uma organização mais resiliente. 

A automação está se tornando a linha divisória entre resiliência e endividamento para recuperação.

Embora os invasores estejam automatizando cada vez mais as etapas de reconhecimento, exploração e movimentação lateral, muitas organizações ainda dependem de processos manuais de recuperação. Esse desequilíbrio está se tornando cada vez mais difícil de ignorar. A IA está reduzindo os prazos dos ataques, mas os prazos de Recovery não acompanharam esse ritmo. As organizações que não conseguirem automatizar essas tarefas de recuperação podem acabar gastando dias elaborando e executando planos, enquanto o dano já tiver sido causado. A orquestração automatizada da recuperação, a identificação precisa de pontos de recuperação e a validação coordenada estão se tornando recursos essenciais para a recuperação na velocidade exigida pelos ataques modernos. 

A tecnologia não é o maior desafio à resiliência — o alinhamento organizacional é que é.

As equipes de segurança se concentram na contenção, as equipes de infraestrutura se concentram na restauração, os líderes de negócios se concentram no impacto sobre os clientes e as equipes de conformidade se concentram nas obrigações regulatórias. Nenhuma dessas prioridades é, por si só, errada, mas, quando elas evoluem de forma independente, as organizações entram em uma crise sem um modelo operacional compartilhado. 

É aí que entra o ResOps. Em vez de considerar a resiliência como uma responsabilidade da TI, o relatório a apresenta como uma disciplina que reúne deliberadamente os setores de negócios, segurança, infraestrutura e planejamento de recuperação. A mensagem é clara: a resiliência depende menos de ferramentas individuais e mais da criação de prioridades compartilhadas antes que um incidente o obrigue a tomar decisões difíceis. 

A realização de testes continua sendo um dos indicadores mais sólidos de resiliência.

A IDC constatou que um número relativamente pequeno de organizações realiza exercícios de simulação em mesa ou simulações em ambiente virtual de segurança cibernética com frequência, apesar de décadas de evidências que demonstram que os ensaios melhoram consistentemente o desempenho durante incidentes reais. 

Os exercícios revelam dependências ocultas, expõem falhas de comunicação e permitem que as equipes tomem decisões sem arcar com as consequências reais. As organizações que validam repetidamente seus processos de recuperação desenvolvem um nível de confiança que vai além do simples planejamento. 

Os desafios de resiliência do futuro já estão se delineando.

O ransomware ainda domina as manchetes, mas os próximos desafios à resiliência já surgiram — desde a IA autônoma e as identidades de máquina até a criptografia pós-quântica. 

Essas ameaças nos lembram que o planejamento de resiliência não pode se concentrar exclusivamente na infraestrutura atual. A recuperação envolve, cada vez mais, serviços de “ cloud ”, aplicações “ SaaS ”, modelos de IA, identidades de máquinas, provedores terceirizados e ecossistemas digitais distribuídos que não existiam há uma década. 

A resiliência está se tornando mensurável.

O Modelo de Maturidade ResOps da IDC é de valor inestimável para avaliar a situação atual da sua organização. Em vez de tratar a resiliência como algo que as organizações possuem ou não possuem, a estrutura descreve uma evolução de operações reativas e isoladas para uma resiliência madura e adaptativa, baseada em governança, automação e melhoria contínua. Para mim, essa evolução reconhece uma realidade importante: a resiliência nunca está concluída. Não se trata de adquirir uma plataforma ou concluir um projeto. As organizações se tornam resilientes ao aprimorar continuamente a forma como a tecnologia, as pessoas e os processos de negócios trabalham juntos sob pressão. Visto sob essa perspectiva, a resiliência passa a ser menos um tipo de seguro e mais uma forma de excelência operacional — uma capacidade que pode ser avaliada, fortalecida e demonstrada ao longo do tempo. 

Estamos passando por uma mudança mais ampla na forma como as organizações encaram a resiliência.

As discussões sobre resiliência estão evoluindo da proteção da infraestrutura para a proteção do próprio negócio. Isso significa que o planejamento de recuperação começa com os clientes, e não com os servidores; a governança passa a ser tão importante quanto a tecnologia; e a confiança advém da comprovação de capacidades, e não da documentação de intenções. O ResOps não é, na verdade, uma nova estrutura; trata-se, antes, de um reconhecimento mais amplo de que a resiliência cibernética se tornou uma disciplina operacional. À medida que os ataques se tornam mais rápidos e complexos, a resiliência será medida não pela ausência de incidentes, mas pela capacidade da organização de continuar atendendo aos clientes, apoiando os funcionários e mantendo a confiança, mesmo diante de interrupções. No fim das contas, é exatamente isso que o ResOps foi criado para comprovar. Rajiv Kottomtharayil é diretor de produtos da Commvault. 

Pontos principais

• A confiança na era da IA não está desaparecendo — está evoluindo.
• As organizações precisam verificar a IA continuamente, em vez de confiar nela por padrão.
• A adoção da IA deve capacitar os funcionários, e não levá-los a recorrer à IA paralela.
• O modelo “zero trust” não significa desconfiar das pessoas. Trata-se de validar continuamente identidades, dispositivos e ações.
• A adoção responsável da IA exige que a tecnologia, a governança e as pessoas trabalhem em conjunto.

Quando lançamos o “Ready. Or Not.”, queríamos criar uma série que tornasse mais fáceis de entender algumas das principais discussões atuais sobre IA. Ao reunir o comediante Nathan Macintosh com especialistas do setor, estamos explorando tudo, desde IA autônoma e resiliência cibernética até gerenciamento de dados — e adicionando um pouco de humor ao longo do caminho.

Se você assistiu ao nosso primeiro episódio sobre as oportunidades e os riscos da IA agênica, acho que vai gostar deste também. Desta vez, vamos abordar um tema que está no centro de todas as discussões sobre IA: a confiança.

Nathan conversa com Diana Kelley, diretora de segurança da informação da Protect AI, sobre o que significa confiar na tecnologia em um momento em que a IA é capaz de gerar conteúdo falso convincente, tomar decisões e até mesmo imitar pessoas. De deepfakes e alucinações até o modelo “zero trust” e a IA oculta, eles exploram como as organizações podem adotar a IA sem perder a confiança em seu pessoal e em seus sistemas.

Assista ao episódio completo no Readiverse. Saí desse episódio me sentindo mais otimista do que esperava. Não porque a IA tenha se tornado, de repente, mais confiável, mas porque Diana nos mostra que a confiança cresce quando as organizações implementam as políticas, as medidas de proteção e a tecnologia adequadas. Aqui estão alguns temas da conversa que colocam a IA sob uma nova perspectiva.

Confiança e tecnologia podem coexistir

Diana acredita que a confiança é possível na era da IA, mas terá uma forma diferente. Sempre construímos confiança por meio de relacionamentos com pessoas. Agora, estamos aprendendo a estender essa confiança aos sistemas. Isso não significa confiar cegamente na tecnologia. Significa entender como a IA funciona, reconhecer suas limitações e adotar as medidas de segurança adequadas para que as pessoas e a tecnologia possam trabalhar juntas com confiança.

“A confiança precisa evoluir para se adequar ao novo mundo.” – Diana Kelley

O que me chamou a atenção foi a ideia de que confiança e tecnologia não precisam estar em conflito uma com a outra. Com a abordagem certa, elas podem se fortalecer mutuamente.

Estamos nos tornando mais experientes em IA

Os deepfakes se tornaram um dos riscos da IA mais comentados, e é fácil entender por quê. A IA agora é capaz de gerar vozes, imagens e vídeos convincentes que nos fazem questionar o que é real. Mas Diana destacou que, embora a IA esteja se tornando mais sofisticada, as pessoas estão ficando mais espertas. Estamos mais propensos a questionar uma ligação inesperada, examinar com mais atenção uma postagem nas redes sociais ou parar para pensar diante de algo que não parece totalmente certo.

As organizações também estão se tornando mais experientes. À medida que a IA se aperfeiçoa na imitação, as empresas estão investindo em novas formas de verificar continuamente as identidades e validar as informações. Minha conclusão é a seguinte: a tecnologia continuará a melhorar, mas o mesmo acontecerá com nossa capacidade de reconhecê-la e reagir de forma responsável.

“Hoje é um bom dia para começar a fazer um deepfake?” – Nathan Macintosh

A IA responsável é boa para os negócios

Diana compartilhou um exemplo que provavelmente soará familiar para muitas organizações. Uma funcionária a quem ela chama de “Karen, do Departamento Financeiro”, começa a usar IA porque isso a ajuda a concluir uma tarefa em minutos, em vez de horas. Karen não está tentando contornar a política da empresa — ela está tentando ser mais produtiva.

Os funcionários utilizam a IA porque reconhecem seu valor real, e isso representa uma oportunidade para as organizações. Quando os funcionários têm acesso a ferramentas de IA aprovadas, respaldadas por políticas claras e orientações práticas, eles podem trabalhar com mais eficiência e, ao mesmo tempo, ajudar a proteger os dados e os sistemas da empresa.

Prévia: Adoção mais inteligente da IA

O objetivo não é impedir que os funcionários utilizem a IA. É garantir que eles a utilizem da maneira correta. Diana explica como as organizações podem incentivar a adoção da IA sem criar riscos desnecessários.

A abordagem “Zero Trust” é mais importante do que nunca

“Quando você entende como as coisas funcionam, é aí que começa a entender como administrá-las.” – Diana Kelley

O “Zero Trust” é um daqueles conceitos que fica muito mais fácil de entender com uma analogia. Diana tem uma excelente. Ela descreve isso como se mover por um prédio. Só porque você foi autorizado a entrar pela porta da frente não significa que todas as outras portas se abram automaticamente para você. Cada vez que você acessa uma nova sala, há outra verificação rápida para confirmar se você realmente deve estar ali.

É basicamente assim que o “Zero Trust” funciona. É basicamente assim que funciona o modelo “zero trust”. Em vez de presumir que uma pessoa ou dispositivo é confiável após um único login, as organizações verificam continuamente identidades, dispositivos e ações, à medida que a tecnologia se torna cada vez mais conectada. A maioria dessas verificações ocorre discretamente nos bastidores. Uma das coisas que mais gostei na explicação da Diana é que o “zero trust” não parece ser apenas mais um chavão da área de segurança. Parece uma maneira prática de pensar sobre a confiança em um mundo em que a IA e as identidades digitais estão se tornando parte do dia a dia dos negócios.

A confiança tem a ver com as pessoas

No fim das contas, não é a tecnologia que gera confiança — são as pessoas. São as pessoas que definem as políticas, os processos e os limites éticos que orientam o uso da IA, enquanto a tecnologia ajuda a verificar se essas medidas de proteção estão funcionando conforme o esperado. É essa parceria entre pessoas e tecnologia que torna possível uma IA responsável.

A confiança vai além de nossas próprias organizações. As empresas precisam confiar nos parceiros com quem trabalham, nos sistemas aos quais se conectam e nas tecnologias que adotam. É por isso que a transparência, os padrões compartilhados e a verificação contínua estão se tornando tão importantes quanto a própria inovação. Quanto mais a IA se torna parte do dia a dia dos negócios, mais a confiança se torna uma responsabilidade de todos.

Olhando para o futuro

A IA continuará a evoluir, assim como a forma como interagimos com ela. As organizações que terão sucesso não serão aquelas que confiam cegamente na IA ou que a evitam por completo. Serão aquelas que estabelecerem políticas sólidas, adotarem as tecnologias adequadas e verificarem continuamente os sistemas dos quais dependem.

A confiança não é algo que perdemos à medida que a tecnologia avança. É algo que construímos e desenvolvemos intencionalmente. Esse é exatamente o tipo de conversa que esperamos continuar em cada episódio de Ready. Or Not. Assista ao episódio completo no Readiverse.

Perguntas frequentes

P: O que é confiança digital?

R: A confiança digital é a certeza de que pessoas, sistemas e organizações são quem afirmam ser e agem da maneira esperada e segura. Ela combina tecnologia, governança e verificação para ajudar as organizações a interagirem com segurança.

P: O que são deepfakes?

R: Deepfakes são imagens, vídeos ou gravações de áudio gerados por IA, criados para imitar fielmente pessoas reais. Embora tenham usos legítimos, também podem ser utilizados para se passar por outras pessoas ou cometer fraudes.

P: O que é o modelo “zero trust”?

R: O modelo “zero trust” é um modelo de segurança baseado na verificação contínua, em vez da confiança automática. Em vez de presumir que um usuário ou dispositivo é confiável após um único login, as organizações validam continuamente as identidades e as ações.

P: O que é a IA de sombra?

R: O termo “Shadow AI” se refere ao uso, por parte dos funcionários, de ferramentas de IA que não foram aprovadas nem estão sujeitas à regulamentação da organização. Embora muitas vezes seja bem-intencionado, isso pode acarretar riscos à segurança, à privacidade e à conformidade.

P: Por que as organizações não deveriam simplesmente bloquear as ferramentas de IA?

R: Os funcionários geralmente adotam a IA porque ela os ajuda a trabalhar com mais eficiência. Em vez de proibir totalmente o uso da IA, as organizações devem fornecer ferramentas aprovadas, estabelecer políticas claras e orientar os funcionários sobre o uso responsável.

P: Qual é a principal lição deste episódio?

R: A confiança não está desaparecendo por causa da IA — ela está evoluindo. As organizações que combinam pessoas, políticas e tecnologia com verificação contínua estarão mais bem posicionadas para adotar a IA com confiança e responsabilidade.

Katherine Demacopoulos é diretora sênior de Estratégia e Programas de Conteúdo Global da Commvault.

Nosso diretor de produtos, Rajiv Kottomtharayil, escreveu recentemente sobre uma grande mudança que está ocorrendo em todos os setores. Os modelos de IA de ponta estão reduzindo o tempo entre a descoberta de uma vulnerabilidade e sua exploração. Essa mudança está levando organizações em todo o mundo a reavaliar seus processos de gerenciamento de vulnerabilidades. Estamos fazendo o mesmo na Commvault. É por isso que, a partir de 11 de agosto, estamos mudando o ritmo com que divulgamos vulnerabilidades. O que está mudando Estamos elevando o padrão de segurança, transparência e confiança dos clientes. No dia 11 de agosto, e na segunda terça-feira de cada mês a partir de então, lançaremos o “Patch Tuesdays”: uma publicação mensal programada na qual compartilhamos alertas de segurança e correções de vulnerabilidades.  

As “Patch Tuesdays” são uma marca registrada das principais empresas de tecnologia, pois oferecem aos clientes um ritmo previsível de segurança. Isso se torna ainda mais importante à medida que o ritmo de descoberta de vulnerabilidades se acelera. É claro que, se houver uma vulnerabilidade urgente que precise ser relatada fora do ciclo, não hesitaremos em seguir nossos processos bem estabelecidos.  

Onde você pode encontrar recursos atualizados  

Na segunda terça-feira de cada mês, você encontrará novas informações relacionadas às CVEs em nossa página de Alertas de Segurança. Você também pode encontrar as publicações oficiais no site de CVEs. No Centro de Segurança da Commvault, você encontrará nosso programa de gerenciamento de vulnerabilidades e outras iniciativas de liderança em segurança desde a concepção.   

Para obter certificações de conformidade, relatórios de auditoria e documentação sobre como a Commvault protege os dados dos clientes, acesse o Centro de Confiança da Commvault. Você pode se inscrever para receber atualizações do Trust Center pelo link no canto superior direito da página. Bill O’Connell é Diretor de Segurança da Commvault. 

Há décadas, os líderes do setor de tecnologia vêm tentando eliminar os silos. Programas inteiros de modernização foram desenvolvidos com o objetivo de conectar aplicativos, consolidar plataformas e proporcionar às organizações uma visão mais completa de seus dados. Esses esforços geraram um valor imenso, mas também moldaram a maneira como pensamos sobre resiliência. Quando algo dá errado, instintivamente procuramos a fragmentação técnica. No entanto, descobrimos que o maior desafio está em outro lugar.

Os silos mais significativos que afetam a resiliência cibernética atualmente não se encontram em bancos de dados ou aplicativos, mas nas estruturas organizacionais. Eles existem entre as equipes de segurança e de infraestrutura, entre a TI e os negócios, e entre as pessoas responsáveis por responder a um ataque e aquelas responsáveis por manter a organização em funcionamento.

A pesquisa mais recente da IDC sobre ResOps, intitulada “Resilience Operations: The Discipline that Makes Readiness Provable” (Operações de Resiliência: a disciplina que torna a prontidão comprovável), sugere que essas fronteiras organizacionais se tornaram um dos principais obstáculos à recuperação eficaz. Essa é uma observação oportuna, pois os ataques cibernéticos evoluíram de maneiras que podem tornar cada vez mais difícil manter essas fronteiras.

Os ataques modernos não seguem o organograma da sua empresa

Um ataque cibernético moderno raramente afeta apenas um único domínio tecnológico. Um incidente envolvendo ransomware pode começar com identidades comprometidas, se espalhar por toda a infraestrutur cloud , criptografar cargas de trabalho críticas, interromper aplicativos voltados para o cliente, afetar serviços de terceiros e acionar requisitos regulatórios de notificação — tudo isso em questão de horas. Cada etapa envolve equipes diferentes, ferramentas diferentes e prioridades diferentes. No entanto, muitas organizações ainda se preparam para a recuperação como se essas responsabilidades pudessem ser gerenciadas de forma independente.

As equipes de segurança naturalmente se concentram em conter ameaças e preservar evidências. As equipes de infraestrutura priorizam a restauração de sistemas e a minimização do tempo de inatividade. Os líderes de negócios concentram-se nos clientes, na receita e na continuidade operacional. As equipes de comunicação pensam na reputação, enquanto as equipes jurídicas e de conformidade se concentram nas obrigações regulatórias. Cada ponto de vista é totalmente razoável. O problema surge quando essas prioridades nunca foram conciliadas antes de ocorrer um incidente.

No meio de uma crise, a Recovery exige a tomada de decisões sob pressão. Quais aplicativos devem ser restaurados primeiro? Quais dados podem ser restaurados com segurança? Qual é o nível de Risk aceitável antes da retomada dos serviços aos clientes? Quem tem autoridade para tomar essas decisões? Sem alinhamento, as organizações frequentemente percebem que os maiores atrasos não são causados pela tecnologia, mas pela incerteza — daquele tipo que poderia ser mitigada com uma melhor preparação.

A resiliência começa com uma definição comum do que é importante

O relatório dá ênfase ao estabelecimento do seu negócio mínimo viável (MVB). À primeira vista, parece ser mais um exercício de planejamento de recuperação, mas seu verdadeiro valor reside nas conversas que ele leva as organizações a terem.

Para definir um MVB, é necessário que os líderes empresariais, as equipes de segurança, os especialistas em infraestrutura e os responsáveis pelas aplicações cheguem a um consenso sobre uma questão que, à primeira vista, parece simples: O que precisa, sem dúvida alguma, continuar funcionando se todo o resto parar?

Essa discussão altera a natureza do planejamento de resiliência. As prioridades de recuperação não são mais determinadas pelo proprietário da aplicação que apresentar os argumentos mais convincentes durante um incidente. Em vez disso, elas são estabelecidas com antecedência, com base nos resultados de negócios e respaldadas por dependências técnicas que todos compreendem.

Talvez o mais importante seja que o MVB cria uma linguagem comum. Os líderes empresariais passam a falar sobre capacidades críticas, em vez de sistemas individuais. As equipes de tecnologia começam a mapear a infraestrutura com base nos resultados para o cliente, em vez de arquiteturas técnicas. As equipes de segurança ganham maior clareza sobre quais ativos merecem os mais altos níveis de proteção durante a Recovery. Esse entendimento comum é exatamente o que tem faltado a muitas organizações.

A tecnologia pode automatizar a recuperação – mas não pode criar alinhamento

O relatório não defende que as organizações precisem de mais uma plataforma. Ele defende que elas precisam de uma forma de trabalhar que alinhe pessoas, processos e tecnologia em torno de um único objetivo operacional. É aí que o ResOps – uma disciplina multifuncional – mostra seu valor.

A tecnologia pode ajudar a automatizar a Recovery, mas não pode resolver divergências sobre prioridades de negócios. Ela não pode decidir quais serviços ao cliente são mais importantes. E não pode substituir a governança necessária para coordenar várias equipes durante um evento de alta pressão. Esses são desafios de liderança, e a melhor maneira de enfrentá-los é dedicar tempo para responder juntos às perguntas difíceis, muito antes que um ataque o obrigue a agir.

As organizações mais fortes não eliminam os silos — elas os conectam

Os ataques cibernéticos continuarão evoluindo. A IA continuará reduzindo os prazos dos ataques. Novas tecnologias introduzirão novas dependências, e novas ameaças surgirão junto com elas. Nada disso altera o requisito fundamental para a resiliência. As organizações não se recuperam porque equipes individuais tenham um desempenho brilhante isoladamente, mas porque essas equipes já sabem como trabalhar juntas.

Essa pode ser, em última análise, a principal conclusão da pesquisa da IDC. A resiliência não é simplesmente o resultado de uma tecnologia melhor ou de controles de segurança mais sofisticados. É o resultado de prioridades compartilhadas, uma governança clara e um modelo operacional comprovado que reúne as pessoas certas antes que um incidente ocorra. Vidya Shankaran é diretora de tecnologia de campo da Commvault.

Pontos principais

• Um CVE é um identificador globalmente exclusivo para uma vulnerabilidade de software divulgada publicamente, permitindo que fornecedores, pesquisadores e especialistas em segurança se refiram a ela de maneira consistente.
• A abordagem de uma organização em relação à divulgação de vulnerabilidades — incluindo correções coordenadas, envolvimento de pesquisadores e inventário preciso de software — é um forte indicador da maturidade geral em segurança.
• A Commvault protege seus clientes por meio de um programa de CVE que se caracteriza pela transparência, regularidade e clareza. A divulgação de CVEs diz muito sobre a maturidade de um programa de segurança e engenharia.

Por que isso é importante

Muitas violações de segurança que chegam à diretoria têm origem em vulnerabilidades de software. O mecanismo utilizado por todo o setor para nomear e descrever essas vulnerabilidades é o CVE(Common Vulnerabilities and Exposures). A forma como um fornecedor — ou a própria organização — lida com os CVEs é um dos indicadores mais claros da maturidade em segurança.

Uma empresa que divulga e reconhece os pesquisadores de forma justa costuma ser uma empresa que leva a sério a engenharia subjacente. Este blog explica como um CVE é criado, quem administra o sistema e o que diferencia uma divulgação exemplar de uma inadequada.

Além do CVE: Por que a filosofia da divulgação é importante

A publicação de um CVE é o mínimo necessário. Os fatores que fazem a diferença são: transparência em relação à vulnerabilidade e à correção, verificações e aplicações de correções regulares, além de uma comunicação clara. A Commvault encara a divulgação como uma disciplina de engenharia e segurança, e não apenas como um requisito de conformidade a ser cumprido: estabelecer uma frequência para a revisão de código e correção de falhas, comunicar a correção em linguagem simples e proteger nossos clientes. Essa consistência, mais do que qualquer pontuação isolada, é o que a divulgação de CVEs revela sobre a maturidade em segurança.

O que é, na verdade, um CVE

Um CVE não é um patch, uma pontuação nem um malware. É uma entrada no dicionário que atribui a uma vulnerabilidade específica e de conhecimento público um nome permanente e exclusivo, para que todos possam se referir a ela. O próprio identificador segue um formato simples e duradouro: as letras CVE, o ano em que o identificador foi atribuído e um número sequencial; por exemplo, CVE-2021-44228.

A dimensão do programa é enorme e continua crescendo: 48.000 CVEs foram publicados em 2025, a uma média de 132 por dia, o que representa um aumento de mais de 260% desde 2020.

A anatomia de um único registro

As publicações do CVE exigem um conjunto consistente de elementos. A leitura de uma delas é simples, desde que você saiba qual é a função de cada parte:

• Identificador, o código único CVE-AAAA-NNNNN
• Descrição: uma explicação concisa da vulnerabilidade: o que ela é e como um agente mal-intencionado poderia explorá-la.
• Produtos e versões afetados, quais softwares, hardwares ou firmwares (e quais versões) foram afetados, e quais versões contêm a correção.
• Criticidade: a categoria de criticidade subjacente.
• Referências, links para o comunicado do fornecedor, o patch e artigos técnicos.

O elenco coadjuvante: CVSS, CWE, EPSS e KEV

Quatro sistemas complementares transformam um CVE em algo que uma empresa pode priorizar. É fácil confundir um com o outro, por isso vale a pena ter essa distinção em mente:

• O CVSS (Common Vulnerability Scoring System) responde à pergunta “Qual é o grau de gravidade?”. O CVSS é a classificação de gravidade (1 a 10, sendo 10 a mais grave) da falha, e não uma medida da sua exposição específica.
• O EPSS (Exploit Prediction Scoring System) responde à pergunta: “Qual é a probabilidade de que isso seja explorado em breve?”. O EPSS gera uma pontuação de probabilidade, de zero a 100 por cento, estimando a probabilidade de que uma vulnerabilidade seja explorada nos próximos 30 dias.
• O CWE (Common Weakness Enumeration) responde à pergunta “Que tipo de erro causou isso?”. O CWE classifica a falha de codificação subjacente.
• O KEV (Vulnerabilidades Conhecidas e Exploradas) responde à pergunta: “Essa vulnerabilidade está sendo usada contra as pessoas neste momento?”. O catálogo do KEV é uma lista selecionada de CVEs com exploração confirmada no mundo real.

Uma pontuação alta no CVSS indica o grau de gravidade de uma vulnerabilidade; uma pontuação alta no EPSS indica a rapidez com que ela provavelmente será explorada; e a inclusão no catálogo KEV confirma que a exploração já está ocorrendo. Os melhores programas de gerenciamento de vulnerabilidades levam em consideração esses três fatores.

Perguntas frequentes

P: O que é um CVE e por que ele é importante? R: Um Common Vulnerability and Exposure (CVE) é um identificador padronizado atribuído a uma vulnerabilidade de software divulgada publicamente. Ele permite que todos — desde fornecedores e pesquisadores até órgãos reguladores e clientes — se refiram à mesma vulnerabilidade sem ambiguidade.

P: Quais informações um registro CVE bem estruturado deve conter?
R: Um registro CVE completo requer um identificador único, uma descrição da vulnerabilidade, os produtos e versões afetados, o tipo de criticidade e referências a alertas ou patches do fornecedor. Esses elementos permitem que as organizações compreendam sua exposição e respondam de forma eficiente.

P: Em que o CVSS, o CWE, o EPSS e o KEV diferem de um CVE? R: Um CVE identifica uma vulnerabilidade específica, enquanto o CVSS mede sua gravidade, o EPSS estima a probabilidade de exploração no curto prazo, o CWE classifica a falha de codificação subjacente e o KEV identifica vulnerabilidades que estão sendo ativamente exploradas no mundo real. Juntas, essas estruturas ajudam a fornecer o contexto necessário para priorizar a correção.

P: O que a Commvault busca em suas próprias práticas de divulgação? R: A Commvault aplica às suas próprias divulgações os mesmos padrões que espera dos demais: transparência, regularidade e clareza. É assim que a Commvault protege seus clientes.

P: O que os líderes empresariais devem levar em consideração ao avaliar as práticas de gerenciamento de vulnerabilidades dos fornecedores? R: Os líderes devem buscar cronogramas coordenados de divulgação, registros CVE abrangentes e precisos, orientações claras para correção, programas robustos de geração de relatórios e a capacidade de determinar rapidamente se os produtos são afetados por vulnerabilidades recém-divulgadas. Essas características refletem uma forte cultura de segurança e aumentam a resiliência organizacional. Werner Nel é gerente sênior de experiência do produto na Commvault.

Pontos principais

• JadePuffer é o nome que os pesquisadores de segurança da Sysdig deram ao que consideraram ser a primeira operação de ransomware documentada conduzida de ponta a ponta por um agente de IA autônomo, e não por um ser humano utilizando um conjunto de ferramentas.
• As técnicas em si não eram novas. O que mudou foi a velocidade da execução: o agente encadeou ações de reconhecimento, roubo de credenciais, movimento lateral e criptografia destrutiva, corrigindo uma tentativa de login malsucedida em 31 segundos.
• O agente gerou sua própria chave de criptografia e, em seguida, nunca a armazenou nem a transmitiu. Pagar o resgate não teria restaurado os dados.
• Os danos reais afetaram o estado da configuração e os sistemas do plano de controle, e não apenas os arquivos, que é exatamente a camada que a maioria dos planos de recuperação não abrange.
• Recuperar-se de um ataque como esse significa comprovar que a empresa pode retomar suas operações com segurança, e não apenas restaurar um backup.

O que aconteceu

Em meados de 2026, pesquisadores de segurança da Sysdig documentaram uma campanha de extorsão que consideram ser a primeira do gênero: uma operação de ransomware conduzida de ponta a ponta por um agente baseado em um modelo de linguagem de grande porte, com participação humana mínima no comando. Eles a batizaram de JadePuffer.

O ponto de entrada era conhecido. O invasor explorou a vulnerabilidade CVE-2025-3248, uma falha de execução remota de código sem autenticação no Langflow — uma estrutura de código aberto para a criação de fluxos de trabalho de agentes de IA —, que estava executando uma versão anterior à 1.3.0. A partir daí, o agente enumerou o host, procurou credenciais em provedores de cloud , fornecedores de modelos de IA e bancos de dados, e, discretamente, fez o dump do próprio banco de dados de apoio do site platform.

O que aconteceu a seguir é a parte que merece atenção. O agente escaneou a rede interna, encontrou um armazenamento de objetos exposto e extraiu os arquivos de estado e configuração do Terraform. Ele configurou uma tarefa agendada para se comunicar com o servidor de comando a cada 30 minutos. Em seguida, mudou de alvo para um sistema de produção separado que rodava MySQL e Alibaba Nacos, uma plataforma de configuração e descoberta de serviços comum em arquiteturas de microsserviços.

Uma vez dentro do sistema, o agente tentou criar uma conta de administrador no Nacos. A tentativa falhou. Trinta e um segundos depois, ele havia diagnosticado a falha e conseguiu o resultado desejado com uma abordagem diferente. Em seguida, utilizou as funções de manipulação de arquivos do MySQL para verificar se poderia avançar ainda mais, antes de criptografar mais de 1.300 registros de configuração, excluir as tabelas originais e deixar uma nota de resgate para trás.

A chave de criptografia foi gerada dinamicamente, exibida uma única vez e nunca armazenada em nenhum local onde o invasor pudesse recuperá-la. Independentemente de isso ter sido intencional ou não, o resultado para a vítima é o mesmo: não havia como reverter a situação por meio do invasor ou de uma chave de descriptografia, independentemente de o resgate ter sido pago ou não. A recuperação dependeria de backups válidos, da reconstrução do sistema ou de pontos de recuperação validados.

Por que os pesquisadores estão chamando isso de “agênico”

Nenhuma das técnicas individuais aqui mencionadas é nova. Explorar uma vulnerabilidade CVE sem patch, coletar credenciais, fazer varreduras para movimentação lateral, criptografar dados para extorsão: as equipes de segurança já se depararam com todas elas antes. O que levou a Sysdig a classificar o operador como “agênico”, em vez de um invasor convencional, foi a forma como as etapas se encaixam.

O agente não seguiu um roteiro fixo. Ele observou os resultados e se adaptou. Quando esperava uma resposta em JSON e recebeu XML, mudou sua abordagem e continuou. Quando sua primeira tentativa de criar uma conta de administrador falhou, ele diagnosticou a falha específica e tentou algo diferente, em menos de um minuto.

Os pesquisadores também encontraram comentários incorporados nas cargas úteis, explicando os alvos e os próximos passos em linguagem simples — um padrão mais consistente com o raciocínio de um LLM ao realizar uma tarefa do que com o de um ser humano copiando e colando um kit de exploração conhecido. As reportagens da mídia não confirmaram qual modelo ou platform esteve por trás do ataque. O que está confirmado é o comportamento: algo que raciocinou, agiu, esbarrou em um obstáculo e corrigiu o rumo mais rapidamente do que a maioria das respostas a incidentes conduzidas em ritmo humano consegue agir.

O problema da recuperação que muitas estruturas ainda não abordam

A maioria dos manuais de ransomware se baseia em uma suposição específica: algo criptografou seus arquivos, e a questão é se você consegue restaurar um backup válido ou se precisa negociar uma chave de descriptografia.

O JadePuffer rompe essa suposição de duas maneiras. Primeiro, não havia chave de descriptografia a ser negociada. Segundo, o dano não se limitou apenas aos dados. Ele atingiu a camada de configuração e do plano de controle subjacente aos dados: a plataforma de descoberta de serviços, os segredos que ela guardava, o estado do Terraform que descrevia como a infraestrutura se encaixava e as credenciais espalhadas por todos os sistemas que o agente acessou ao longo do caminho.

Esse é um problema de recuperação mais complexo do que simplesmente “restaurar o banco de dados”. Uma restauração limpa de arquivos em um ambiente com credenciais renovadas, mas não verificadas, desvios de configuração não revisados e uma camada de identidade que ninguém reauditou não é, na verdade, uma recuperação limpa. Trata-se de uma cópia nova dos dados alojada em um sistema no qual ainda não se pode confiar.

O que isso significa para sua estratégia de resiliência

O JadePuffer é uma prévia da questão que todo plano de recuperação terá, mais cedo ou mais tarde, que responder: é possível retomar as operações quando um invasor tiver afetado não apenas seus dados, mas também a identidade, a configuração e os sistemas do plano de controle dos quais esses dados dependem?

Alguns pontos para começar:

Trate os sistemas de configuração e do plano de controle como essenciais para a Recovery, não apenas os aplicativos. Plataformas de descoberta de serviços, armazenamentos de segredos e o estado da infraestrutura como código são tão críticos para os negócios quanto os bancos de dados que eles configuram. Se eles não estiverem em seu plano de Recovery hoje, essa é a primeira lacuna a ser preenchida.

Incorpore a higiene das credenciais ao processo de recuperação, e não depois dele. Restaurar uma carga de trabalho que reintroduz segredos comprometidos não encerra o incidente; isso apenas reinicia o contador de tempo do incidente. Essa é a mesma disciplina que a Commvault aplica atualmente à infraestrutura de identidade: avaliação de vulnerabilidades para identificar exposições antes que um invasor o faça, auditoria em tempo real para detectar alterações à medida que ocorrem e reversão para desfazer alterações não autorizadas sem precisar reconstruir tudo do zero.

Valide antes de restaurar, não depois. Um ponto de restauração só é útil se você tiver certeza de que está livre de contaminação. Essa é a lógica por trás do Commvault® Cleanroom™: testar e validar os dados em um ambiente isolado antes que eles voltem à produção, em vez de descobrir o problema após uma nova contaminação.

Planeje-se para uma violação do plano de controle, não apenas para um evento de criptografia de arquivos. Um roteiro de recuperação elaborado apenas para “arquivos criptografados e restauração a partir de backup” não será suficiente diante de um incidente como esse. A questão mais relevante — e aquela que está no centro das ResOps (operações de resiliência) como disciplina operacional — é o que é necessário para atingir um nível mínimo viável de operações quando os sistemas subjacentes às suas aplicações são os que foram afetados.

Nada disso exige que a IA agentiva seja tratada como uma ameaça sem precedentes que exija começar do zero. O que é necessário é estender a mesma disciplina de resiliência que já se aplica à identidade e aos dados até a camada de configuração e do plano de controle, que agora é alvo direto dos ataques agentivos. Saiba mais sobre como a Commvault aborda a resiliência de identidade e a validação da recuperação sem perdas.

Perguntas frequentes

P: O que é o JadePuffer? R: JadePuffer é o nome que a Sysdig deu ao que considerou ser a primeira campanha de ransomware documentada conduzida de ponta a ponta por um agente de IA autônomo, em vez de um invasor humano operando manualmente um conjunto de ferramentas.

P: Os invasores utilizaram algum modelo específico de IA, como o ChatGPT ou o Claude? R: As reportagens divulgadas até o momento não confirmaram qual modelo ou platform foi utilizado. O agente procurou por chaves de API de vários provedores de IA, o que demonstra interesse nesse tipo de acesso, mas não identifica o que realmente esteve por trás do ataque em si. P: Como começou o ataque?

R: Por meio do CVE-2025-3248, uma vulnerabilidade de execução remota de código sem autenticação no Langflow, uma estrutura de código aberto para agentes de IA, que afeta versões anteriores à 1.3.0. P: A vítima poderia ter pago o resgate para recuperar seus dados? R: Não. A chave de criptografia foi gerada dinamicamente e nunca foi armazenada nem transmitida; portanto, não havia nenhuma chave disponível para recuperação, independentemente do pagamento.

P: O que diferencia esse ransomware dos demais? R: As técnicas em si não eram novas. O que se destacou foi a velocidade e a adaptabilidade: o agente diagnosticou uma tentativa fracassada de login e corrigiu o problema em 31 segundos, um ritmo mais próximo da velocidade de uma máquina do que do comportamento típico de um invasor, que segue o ritmo humano. P: O que as equipes de segurança e recuperação devem tirar disso?

R: Esse planejamento de recuperação precisa ir além dos dados das aplicações, abrangendo também os repositórios de configuração, as plataformas de descoberta de serviços, os segredos e os sistemas de identidade — a camada que o JadePuffer realmente visou para causar o máximo de danos. Chris Bevil é gerente principal de marketing de portfólio na Commvault.

Pontos principais

• Modelos avançados de IA escaparam de um ambiente de avaliação restrito ao explorar vulnerabilidades até então desconhecidas.
• A OpenAI afirma que os modelos estavam buscando atingir um objetivo que lhes havia sido atribuído, sem agir com intenção maliciosa, mas mesmo assim causaram um incidente de segurança real.
• Controles tradicionais, como sandboxing e segmentação, são insuficientes se a IA for capaz de descobrir caminhos inesperados para contorná-los.
• A resiliência cibernética está se tornando tão importante quanto a prevenção.

Tudo começou como uma avaliação interna das capacidades cibernéticas avançadas baseadas em IA. Ao tentarem resolver um teste de desempenho com definições restritas, os modelos da OpenAI descobriram uma vulnerabilidade de dia zero, contornaram as restrições previstas do ambiente de teste, obtiveram privilégios elevados, acessaram a internet e comprometeram a infraestrutura da Hugging Face. Eles encaravam as limitações técnicas ao seu redor como problemas a serem resolvidos.

Este não foi um ataque cibernético tradicional

A Hugging Face foi a primeira a informar que uma estrutura de agente autônomo de IA havia comprometido parte de sua infraestrutura de produção. Um conjunto de dados malicioso explorou duas rotas de execução de código em seu pipeline de processamento de conjuntos de dados, obteve acesso ao nível do nó, coletou credenciais e se espalhou lateralmente pelos clusters internos.

Os modelos envolvidos, incluindo o GPT-5.6 Sol e um modelo em pré-lançamento com maior capacidade, estavam operando com restrições cibernéticas reduzidas e sem os classificadores habituais de produção. Eles foram muito além da tarefa atribuída, explorando uma vulnerabilidade de proxy para acessar a internet e, em seguida, utilizando credenciais roubadas e vulnerabilidades de dia zero para encontrar um caminho de execução remota de código nos servidores do Hugging Face.

Não foi necessária a existência de intenção dolosa

Não há indícios públicos de que os modelos tenham desenvolvido intenção criminosa ou optado por prejudicar a Hugging Face. Eles não precisavam disso. Dê a um sistema capaz um objetivo, ferramentas, tempo e feedback, e ele contornará os obstáculos. A discussão já foi além das solicitações e respostas incorretas. Trata-se de sistemas capazes de investigar, testar suposições, descobrir vulnerabilidades até então desconhecidas, utilizar credenciais roubadas, escalar privilégios e continuar operando quando a primeira tentativa falha.

Uma área de testes não é um campo de força

Chamamos os ambientes de isolados, segmentados e em sandbox como se o próprio rótulo já garantisse segurança. Mas não é assim. Neste caso, o caminho óbvio para a internet estava bloqueado, mas um proxy de pacote de software acessível não estava, e os modelos usaram essa vulnerabilidade para escapar. Políticas e comportamentos esperados não são suficientes. O próprio ambiente técnico deve fazer valer os limites.

Por que essa é uma história de resiliência

A atividade passou de um ambiente de avaliação, passando pela infraestrutura de pesquisa da OpenAI, para a internet e, por fim, para o ambiente de produção da Hugging Face. Esse é um raio de impacto em rápida expansão. Quando a IA pode explorar e agir na velocidade de uma máquina, o tempo entre o acesso inicial e o comprometimento mais amplo pode continuar a diminuir.

A Hugging Face não se limitou a bloquear a rota de acesso original e declarar o incidente encerrado. Ela eliminou as rotas vulneráveis de execução de código, reconstruiu os nós comprometidos, renovou as credenciais e os tokens e reforçou os controles do cluster. O objetivo não é apenas restaurar um sistema. É restaurar a confiança.

A questão já não é apenas: “Nossos sistemas de IA são seguros?”. É: “Quando um sistema de IA poderoso descobre um caminho que não sabíamos que existia, seremos capazes de conter o raio de impacto, dar continuidade às operações críticas, reconstruir aquilo em que não confiamos mais e provar que é seguro seguir em frente?”. Chris Bevil é gerente principal de marketing de portfólio na Commvault.

A segurança não termina nos limites dos sistemas próprios de uma organização. As empresas modernas conectam uma rede cada vez maior de aplicativos de terceiros às suas plataformas centrais para dar suporte às vendas, aos serviços e à colaboração. Cada uma dessas conexões agrega valor. Cada uma delas também introduz uma exposição que a organização não controla totalmente.

Esse risco não é hipotético. Em junho de 2026, um agente mal-intencionado comprometeu tokens OAuth vinculados ao Klue, um e platform a de inteligência competitiva usado para sincronizar dados de vendas e marketing com o Salesforce. O invasor utilizou esses tokens para acessar os ambientes do Salesforce de diversas organizações que haviam autorizado a integração, incluindo a Commvault.

Assim que fomos notificados sobre um possível impacto, nossa equipe de segurança acionou nosso processo de resposta a incidentes para determinar o que havia ocorrido, conter a exposição e avaliar se as informações dos clientes ou os serviços da Commvault foram afetados. Nossa investigação constatou que a atividade se limitou a determinadas informações sobre relações comerciais e vendas mantidas em nosso ambiente do Salesforce. A investigação não encontrou indícios de que quaisquer dados de backup de clientes, dados de produtos, metadados de produtos, registros operacionais ou serviços da Commvault tenham sido afetados.

Agir rapidamente quando é preciso

Nossa resposta seguiu os procedimentos estabelecidos para lidar com incidentes de segurança, criados para conter rapidamente os riscos e, ao mesmo tempo, viabilizar uma investigação completa. Assim que fomos notificados do incidente, desativamos a integração com o Klue, revogamos o acesso associado e colaboramos com as partes envolvidas para realizar uma avaliação completa do ocorrido. Ao longo da investigação, nossas equipes trabalharam para determinar quais informações foram acessadas, validar a integridade do nosso ambiente e confirmar que o incidente permaneceu dentro do escopo que já havíamos contido.

Um padrão que merece destaque

Esse incidente é um exemplo recente de uma tendência que as equipes de segurança vêm observando se intensificar há vários anos: invasores que têm como alvo aplicativos de terceiros conectados aos principais sistemas de negócios, em vez de atacar esses sistemas diretamente. Uma única integração comprometida pode oferecer um caminho confiável para acessar os ambientes de várias organizações a jusante de uma só vez, muitas vezes com menos resistência do que um ataque direto a qualquer uma delas.

Isso muda o foco de onde a defesa de uma organização realmente precisa estar. Controles internos robustos continuam sendo necessários, mas já não são suficientes por si só. Eles precisam ser combinados com uma supervisão ativa de todos os aplicativos aos quais a organização se conecta e com uma capacidade de resposta que esteja pronta antes de um incidente, e não criada durante o mesmo.

Desenvolvendo resiliência além do nosso próprio ambiente

Na Commvault, nosso programa de segurança inclui uma avaliação contínua dos aplicativos de terceiros conectados ao nosso ambiente. Analisamos regularmente os aplicativos conectados, avaliamos os acessos de cada um deles, monitoramos riscos emergentes e reavaliamos essas integrações à medida que as necessidades de negócios e o panorama de ameaças se alteram. Quando as circunstâncias assim o exigirem, tomamos medidas para reduzir a exposição e fortalecer nossa postura de segurança, incluindo o desligamento de integrações que não atendam mais aos nossos padrões.

Nosso compromisso com a transparência

A confiança se constrói por meio da transparência e da prestação de contas. Quando um evento afeta nossas partes interessadas, acreditamos que é importante comunicar o que sabemos, explicar como agimos e compartilhar o resultado de nossa investigação, mesmo quando o evento teve origem fora de nossos próprios sistemas. Continuaremos a avaliar nossos controles de segurança, aprimorar nossos processos de resposta a incidentes e fortalecer nossa abordagem em relação aos riscos de terceiros, como parte de nosso compromisso mais amplo de proteger nossos clientes e parceiros.

Para obter os detalhes oficiais sobre este incidente, incluindo o escopo da investigação e orientações aos clientes, consulte as atualizações do nosso Centro de Confiança. Will Galway é vice-CISO da Commvault.