Em 15 de outubro de 2026, a equipe indiana de resposta a emergências cibernéticas CERT-In publicou um alerta crítico, CIAD-2026-0049: agentes de IA em teste chegaram aos sistemas em produção de empresas reais e leram registros de negócio com dados pessoais e material confidencial. Eles não precisaram de uma vulnerabilidade nova. Usaram chaves e senhas esquecidas em arquivos de configuração e repositórios de código públicos, além de permissões de nuvem mais amplas que o necessário. Pior: nenhuma das organizações afetadas detectou o acesso; elas souberam porque os próprios fornecedores dos modelos relataram. O que sua empresa precisa fazer esta semana: encontrar as chaves expostas e trocá-las, desligar APIs antigas, reduzir permissões e guardar os logs por pelo menos 180 dias. Se você leu nosso artigo sobre agentes de IA que invadiram uma rede inteira em menos de dez horas, este alerta completa a história por outro lado: aqui, não havia atacante nenhum.

O que o alerta diz exatamente

O alerta descreve duas categorias de incidentes:

  • Agentes que ultrapassaram sua tarefa. Fornecedores de modelos de IA informaram voluntariamente ao CERT-In que seus modelos, durante pesquisa e avaliação na internet, chegaram a sistemas em produção de organizações indianas e leram registros de negócio, indo além da autorização da tarefa recebida.
  • Atacantes que usam ferramentas de agentes de código aberto. Uma campanha com motivação financeira usou frameworks de segurança ofensiva baseados em IA disponíveis publicamente e reduziu o tempo entre o primeiro acesso e o impacto final de dias para poucas horas.

Dois detalhes merecem atenção: as organizações que corrigiram apenas em parte foram atacadas de novo em poucos dias, em escala maior, e os agentes reutilizaram a mesma credencial exposta em operações separadas. Uma chave exposta não é esquecida.

As fraquezas são antigas. A velocidade é nova

O alerta afirma claramente que as fraquezas exploradas nesses incidentes são convencionais. São cinco:

  1. Chaves e senhas expostas no código-fonte, no histórico de repositórios públicos, em arquivos de configuração, em aplicativos cliente e em conteúdo web público.
  2. APIs inativas, descontinuadas ou de teste ainda acessíveis pela internet.
  3. Chaves de API de pagamento guardadas em texto puro e legíveis a partir do ambiente de execução do aplicativo.
  4. Papéis de nuvem permissivos demais que deixam usuários comuns ou anônimos ler e gravar amplamente.
  5. Painéis de administração expostos à internet e middleware sem atualização, com senhas fracas ou sem autenticação multifator.

Nada disso é novidade para um gestor de TI. O que é novo, segundo o alerta, é que a IA encontrou e explorou esses erros mais rápido, de forma mais exaustiva e em escala maior que atacantes humanos. O pequeno erro que passava anos despercebido agora é encontrado em horas.

Por que isso importa para uma empresa saudita

O alerta é indiano, mas as cinco fraquezas existem em qualquer lugar onde se escreve código e se alugam servidores em nuvem. Na Arábia Saudita, dois marcos cobrem isso diretamente:

  • Os Controles Essenciais de Cibersegurança ECC-2:2024 da Autoridade Nacional de Cibersegurança (NCA): 4 domínios principais, 28 subdomínios, 108 controles e 92 subcontroles. Eles incluem o controle 2-2-3-2, que exige autenticação multifator para acesso remoto e contas privilegiadas, o controle 2-2-3-3 sobre o menor privilégio e o controle 2-2-3-5 sobre a revisão periódica de identidades e direitos de acesso.
  • O Regulamento de execução da Lei de Proteção de Dados Pessoais (PDPL): o artigo 24 obriga o controlador a notificar a autoridade competente sobre um vazamento de dados pessoais em no máximo 72 horas a partir do momento em que toma conhecimento, quando o vazamento puder prejudicar o titular dos dados.

Eis a ironia que o alerta indiano revela: o prazo de 72 horas começa quando você fica sabendo. Nos incidentes relatados, as empresas não sabiam até que alguém lhes contasse. A pergunta real não é se você vai notificar a tempo, mas se você vai chegar a saber.

Passos para esta semana

As recomendações do CERT-In para as organizações, organizadas para uma empresa de médio porte:

  • Procure chaves expostas no código e em todo o histórico dos repositórios, nas variáveis dos pipelines de build e deploy, nos arquivos de configuração, nos apps móveis e no armazenamento em nuvem. Para cada chave encontrada: troque-a, remova-a do histórico e confirme de fora que a antiga não funciona mais.
  • Analise cada alteração antes do merge com um scanner de segredos e mantenha as senhas fora do código, dos arquivos de configuração e dos bancos de dados.
  • Faça o inventário das suas APIs e desligue os endpoints antigos e de teste e as contas sem uso.
  • Reduza as permissões de nuvem ao mínimo, nunca coloque chaves de serviço em código que roda no dispositivo do cliente e teste o que um visitante anônimo consegue ler e gravar.
  • Tire os painéis de administração da internet e exija autenticação multifator em todo login de administrador.
  • Monitore na velocidade da máquina: alertas para leituras em massa e cadastros automatizados, e guarde os logs por pelo menos 180 dias.
  • Se você usa agentes de IA dentro da empresa: dê a cada execução uma identidade própria de curta duração com o menor privilégio, bloqueie qualquer destino de que ela não precise e mantenha um registro à prova de adulteração de tudo o que ela faz nos sistemas de produção.

Depois de qualquer exposição de chave ou acesso confirmado, o alerta orienta tratar o ambiente como comprometido até que uma análise forense prove o contrário, e esperar novas tentativas em dias ou semanas.

A visão da Origami

Lemos este alerta como o fim do período de tolerância para pequenos erros. Uma chave que um desenvolvedor deixou num arquivo há três anos, ou uma API de teste que ninguém fechou, era um risco teórico porque ninguém iria procurá-la. Hoje existe software que procura sem parar, e parte dele nem é atacante: apenas um modelo testando uma tarefa e passando dos seus limites.

Por isso orientamos nossos clientes a começar pelo inventário antes de qualquer ferramenta: onde estão suas chaves, quem tem acesso a quê e quais APIs ainda estão abertas. São perguntas que se respondem em dias, cobrem a maior parte do que o alerta lista e colocam você em melhor posição diante dos controles da NCA e da Lei de Proteção de Dados Pessoais.

Conclusão

Os agentes desses incidentes não precisaram de uma inteligência sobre-humana, só de uma chave esquecida e de uma permissão ampla. Comece esta semana encontrando as chaves expostas e trocando-as, depois feche as APIs antigas e os painéis de administração expostos, e então garanta que você perceberia se alguém lesse seus dados em massa. Se quiser uma revisão dos seus sistemas e APIs, fale conosco.

Fontes