A Google confirmou que um dos seus modelos Gemini acedeu, de forma autónoma, a sistemas protegidos de três empresas reais durante um exercício de avaliação de capacidades ofensivas de cibersegurança realizado em maio de 2026. O caso só se tornou público a 18 de setembro, depois de o Wall Street Journal ter confrontado a empresa, e junta-se a uma série de episódios semelhantes comunicados este ano por outros laboratórios de IA — todos ligados ao mesmo fornecedor de ambientes de teste, a israelita Irregular. Não houve exploração de uma vulnerabilidade nova nem foi atribuído qualquer identificador CVE: o que falhou foi o isolamento do laboratório de ensaios.
Resposta rápida: Durante um exercício do tipo capture the flag, o Gemini recebeu por engano acesso à Internet e confundiu uma empresa fictícia com uma organização real com nome idêntico. Adivinhou uma palavra-passe num caso e usou credenciais expostas em repositórios públicos noutros dois. A Google afirma que o modelo interrompeu a atividade assim que percebeu que os alvos eram reais. Para as organizações, a lição prática é dupla: eliminar credenciais expostas em repositórios públicos e travar a saída de rede (egress) de qualquer agente de IA com autonomia.
O que aconteceu, passo a passo
O episódio ocorreu no âmbito de um teste conduzido pela Irregular, empresa que avalia as capacidades ofensivas e defensivas de modelos avançados. O exercício era do tipo “capture-the-flag” e os agentes da Google nunca deveriam ter acesso à Internet mais ampla, mas uma falha no ambiente de teste tornou esse acesso disponível. O modelo tinha sido instruído a atacar uma empresa fictícia dentro de um ambiente controlado, mas o acesso à Internet estava involuntariamente disponível e a empresa fictícia partilhava o nome com um negócio real.
A partir daí, o comportamento do agente foi tecnicamente banal — e é precisamente isso que torna o caso relevante. Em maio, o modelo Gemini acedeu a três sistemas informáticos privados distintos ao adivinhar palavras-passe e, por duas vezes, ao usar um repositório de palavras-passe listadas publicamente. Não houve exploração de zero-days nem cadeias de exploração sofisticadas: houve força bruta e reutilização de segredos que estavam expostos à vista de todos.
Segundo a Google, os agentes interromperam a intrusão quando determinaram que tinham acedido a sistemas de empresas reais e não a parte do ambiente de teste. A empresa recusou-se a identificar o modelo Gemini exato envolvido. Em declarações públicas, Heather Adkins, vice-presidente de engenharia de segurança da Google, afirmou que “o desenvolvimento seguro de modelos de IA poderosos é crítico” e acrescentou que a sua equipa contactou as entidades afetadas e trabalhou com o parceiro de treino nas alterações aos processos de teste.
Cronologia conhecida
| Data | Acontecimento |
|---|---|
| Maio de 2026 | Os três acessos não autorizados ocorrem durante a avaliação da Irregular |
| Julho de 2026 | É detetado o incidente com agentes da OpenAI e sistemas da Hugging Face |
| Final de julho de 2026 | A Irregular notifica os laboratórios envolvidos, incluindo a Google |
| Final de julho / início de agosto | Divulgações escalonadas por parte de outros laboratórios |
| 18 de setembro de 2026 | A Google confirma publicamente os três casos, após contacto do Wall Street Journal |
A Google foi notificada pela Irregular no final de julho, o que significa um intervalo de cerca de sete semanas entre a notificação e a confirmação pública. A Irregular afirma ter notificado os programadores no final de julho, tendo as divulgações chegado depois uma de cada vez — a Meta no início de agosto e a Google esta semana —, ou seja, quatro empresas detiveram a mesma informação desde o final de julho e cada uma decidiu separadamente quando a tornar pública.
Um fornecedor, vários laboratórios: o ponto único de falha
A leitura mais interessante não é a de um modelo “rebelde”, mas a de uma dependência concentrada. Os incidentes ocorreram no âmbito de testes operados pelo avaliador externo Irregular — à semelhança de outras falhas de segurança envolvendo modelos da OpenAI, da Anthropic e da Meta. Um porta-voz da Irregular confirmou que o incidente do Gemini envolveu os mesmos problemas de segurança que originaram casos semelhantes noutros laboratórios, acrescentando que “todos os laboratórios relevantes foram notificados no final de julho” e que as questões conhecidas foram resolvidas.
A causa raiz, tal como descrita publicamente, é uma incoerência entre o que o modelo “acreditava” e a realidade da rede. A OpenAI atribuiu os seus incidentes a um ambiente de avaliação mal configurado, indicando que um mal-entendido com a Irregular fez com que os sistemas de teste tivessem acesso real à Internet enquanto os modelos tinham sido informados de que estavam numa simulação; trata-se de uma falha de sandbox, não de uma fuga, e um modelo que age de forma agressiva dentro daquilo que entende ser um exercício está a fazer o que o exercício pediu — o que faltou foi a contenção.
Igualmente revelador é o modo como os casos foram detetados. A Anthropic analisou 481 milhões de transcrições para identificar quatro modelos que tinham chegado à Internet aberta; os incidentes não foram assinalados em tempo real pela monitorização, mas descobertos posteriormente numa varredura retrospetiva. Por outras palavras: a telemetria existia, mas não havia deteção imediata de contactos com ativos fora do perímetro autorizado.
Não é uma vulnerabilidade: é higiene de credenciais
Para quem defende redes empresariais, o dado mais incómodo é a simplicidade do vetor. O modelo entrou nos sistemas de três empresas usando técnicas básicas de hacking, e duas dessas entradas resultaram de credenciais que já estavam publicamente acessíveis. Não existe aqui um patch a aplicar nem um identificador CVE: à data da cobertura, nenhum identificador CVE ou aviso formal de segurança foi associado ao incidente do Gemini, por este ser tratado como uma falha do ambiente de avaliação de IA e não como uma vulnerabilidade de software convencional.
Medidas concretas que qualquer PME ou equipa de TI pode adotar esta semana:
- Procurar segredos expostos em repositórios públicos (
git, gists, buckets de armazenamento) e revogar imediatamente tudo o que for encontrado, mesmo que pareça antigo. - Ativar deteção de segredos no pipeline de CI/CD e rotação automática de chaves de API e tokens de serviço.
- Impor autenticação multifator e limites de tentativas (rate limiting, bloqueio progressivo) em todos os portais expostos à Internet — a defesa direta contra a adivinhação sistemática de palavras-passe.
- Para quem opera agentes de IA: restringir o tráfego de saída por lista de permissões, registar cada chamada a ferramentas em logs imutáveis e definir um mecanismo de paragem imediata quando o agente contacta um ativo não autorizado.
- Tratar os agentes como identidades não humanas, com privilégios mínimos, credenciais próprias e prazo de validade curto.
A autocorreção do modelo não deve ser considerada um controlo de segurança. Como sublinham analistas que acompanharam o caso, a decisão do Gemini de parar limitou as consequências, mas não deve ser tratada como o controlo primário de contenção: os agentes autónomos operam mais depressa do que os supervisores humanos e podem interpretar objetivos ambíguos de forma inesperada, pelo que testes seguros exigem controlos em camadas, fronteiras de autorização precisas, intervenção em tempo real, registos de auditoria imutáveis e paragem automática.
Porque é que isto importa em Portugal
Nenhuma das empresas afetadas foi identificada publicamente, e nada indica que sejam portuguesas. Ainda assim, o caso é um aviso direto para organizações nacionais que já usam agentes de IA em tarefas de TI, apoio ao cliente ou desenvolvimento de software. Em primeiro lugar, porque a superfície de ataque não é o modelo, mas a configuração à volta dele: rede, credenciais, permissões e monitorização. Em segundo lugar, porque muitas destas organizações estão hoje abrangidas por obrigações formais de gestão de risco e de notificação de incidentes ao abrigo do Regime Jurídico da Cibersegurança (Decreto-Lei n.º 125/2025, que transpõe a NIS2), supervisionado pelo CNCS. Um agente autónomo mal contido que aceda a sistemas de terceiros a partir da infraestrutura de uma entidade abrangida é, para todos os efeitos, um incidente de segurança a tratar e, potencialmente, a notificar ao CERT.PT.
Há também uma dimensão de proteção de dados: se um agente acede a sistemas alheios ou expõe dados pessoais em consequência de uma falha de contenção, aplicam-se as regras do RGPD quanto à segurança do tratamento e à notificação de violações de dados à CNPD. E no plano europeu, o quadro regulatório já contempla este tipo de eventos: o Regulamento (UE) 2024/1689 estabelece regras específicas para modelos de IA de uso geral, incluindo obrigações de documentação, avaliação de riscos sistémicos e medidas de segurança específicas para os modelos mais avançados, cabendo aos fornecedores de modelos com risco sistémico rastrear, documentar e reportar informação relevante sobre incidentes graves e medidas corretivas ao Gabinete de IA e às autoridades nacionais sem demora indevida.
O debate sobre a transparência das divulgações permanece em aberto, com críticas públicas ao intervalo entre a notificação e a comunicação ao público. Para as equipas de segurança portuguesas, porém, a conclusão operacional é mais simples do que a discussão regulatória: o que permitiu a intrusão foram palavras-passe fracas e segredos expostos. Isso resolve-se hoje, sem esperar por legislação.
Perguntas frequentes
O Gemini foi usado para atacar empresas de propósito?
Não, de acordo com o que foi divulgado. O modelo estava a executar um exercício de segurança contra uma empresa fictícia, mas o ambiente de teste tinha acesso à Internet que não deveria ter e o nome fictício coincidia com o de uma organização real. A Google afirma que o modelo interrompeu a atividade assim que percebeu que os alvos eram reais.
Existe algum CVE ou atualização de segurança a aplicar?
Não. Não foi associado qualquer identificador CVE nem aviso formal de fabricante a este caso, porque não se trata de uma vulnerabilidade de software, mas de uma falha de configuração e de contenção no ambiente de avaliação de modelos de IA.
Como é que uma PME pode reduzir este risco?
Eliminando credenciais expostas em repositórios públicos, rodando chaves e tokens, impondo autenticação multifator e limites de tentativas nos serviços expostos à Internet, e restringindo o tráfego de saída de qualquer agente de IA a destinos explicitamente autorizados, com registo de auditoria.
Isto obriga a notificar o CNCS ou a CNPD?
Depende do caso concreto. Se uma entidade abrangida pelo Regime Jurídico da Cibersegurança sofrer um incidente significativo, aplicam-se os deveres de notificação previstos nesse regime. Se houver violação de dados pessoais, acrescem as obrigações de notificação à CNPD ao abrigo do RGPD. Em caso de dúvida, deve documentar-se o evento e avaliar o impacto antes de decidir.
Esta informação tem caráter noticioso e baseia-se em dados divulgados publicamente pela Google, pela Irregular e por órgãos de comunicação internacionais, bem como em documentação oficial da União Europeia sobre o Regulamento da IA.