Black Kite identificou vulnerabilidades críticas em 34,2% das empresas de IA avaliadas

Uma equipe conecta um assistente de IA a um repositório para analisar erros e sugerir correções. O assistente recebe um token de acesso, lê código e, às vezes, executa comandos. Agora, a segurança do projeto também depende de como o fornecedor armazena esse token e protege sua própria infraestrutura. Boas respostas do modelo não dizem nada sobre isso.

Uma matéria da ZDNet de 10 de novembro apresenta os resultados de um relatório da Black Kite sobre fornecedores de IA. Das 18 160 empresas avaliadas, 34,2% tinham pelo menos uma vulnerabilidade crítica sem correção. Para desenvolvedores e fundadores, é um motivo para verificar quais portas já estão abertas a serviços externos: da leitura de solicitações de clientes à alteração de código e ao acesso à infraestrutura de produção.

O que os pesquisadores encontraram

A amostra abrange empresas de diferentes portes, de pequenas equipes a organizações com mais de mil funcionários. Inclui desenvolvedores de aplicativos, empresas que executam projetos de implementação de IA, serviços especializados por setor e fornecedores de dados, capacidade computacional e modelos. Foram excluídas as empresas que usam IA apenas ocasionalmente.

Além das vulnerabilidades críticas, os pesquisadores identificaram problemas com DMARC em 61,7% das empresas e fragilidades no DKIM em 37,3%. Esses são mecanismos de autenticação de e-mail. Erros de configuração podem facilitar a falsificação de mensagens e o phishing: por exemplo, quando um funcionário recebe uma suposta solicitação interna para autorizar novamente uma integração.

Outras 29,7% das empresas receberam uma classificação de alta suscetibilidade a ataques de ransomware pelo índice da Black Kite. É importante interpretar esse número corretamente: trata-se de uma avaliação de risco, e não da proporção de organizações cujos sistemas já foram criptografados por criminosos. Da mesma forma, a existência de uma vulnerabilidade crítica não prova, por si só, que ela permita acessar os dados de um cliente específico.

O resumo também informa que credenciais corporativas roubadas estavam associadas a 6,8% dos fornecedores da amostra. Uma descoberta assim exige verificar se as senhas continuam válidas, revisar as sessões ativas e conferir a autenticação multifator. Ela não equivale à confirmação de que todos os sistemas dos clientes foram comprometidos.

Como o problema do fornecedor se torna seu

Imagine um assistente de suporte conectado ao CRM. Para preparar um rascunho de resposta, ele precisa do texto da solicitação e de alguns campos do cadastro do cliente. Durante a configuração, porém, a equipe concede ao serviço permissão para exportar toda a base de dados e alterar registros, pois isso acelera o lançamento do piloto.

Se um invasor conseguir acesso ao fornecedor, as consequências dependerão dessas permissões. Ler solicitações individuais e exportar a base de clientes representam danos potenciais de escalas diferentes. Por isso, vale avaliar a integração com uma pergunta concreta: o que alguém poderia fazer se obtivesse seu token?

Uma análise separada de componentes MCP mencionada pela ZDNet reúne 1 732 achados de segurança. Desses, 48,8% foram classificados como de gravidade alta ou crítica, incluindo possibilidades de injeção de código e de comandos. Essa é a proporção de achados em uma análise separada. Ela não permite concluir que 48,8% de todos os servidores MCP ou das empresas sejam vulneráveis.

O MCP ajuda a conectar aplicações de IA a ferramentas e sistemas empresariais. A verificação prática deve se concentrar na implementação: quem pode acionar uma ferramenta, quais argumentos ela aceita e com quais permissões a ação é executada.

O que verificar antes da próxima conexão

Comece por uma lista dos serviços de IA que já receberam acesso. Para cada um, registre o responsável dentro da equipe, os dados acessíveis, as ações permitidas e uma forma de desativar rapidamente a integração. Essa lista transforma a discussão sobre segurança em uma tarefa de engenharia concreta.

Em seguida, reduza as permissões às necessárias para o fluxo de trabalho. Para um assistente que prepara rascunhos, cada permissão para enviar mensagens, alterar registros ou executar comandos deve ter uma justificativa específica. Para ações perigosas, vale prever a confirmação de uma pessoa e um registro de operações.

Pergunte ao fornecedor como ele corrige vulnerabilidades críticas, protege as contas e comunica incidentes. Repetir a revisão é especialmente útil quando o acesso é ampliado: ontem o serviço lia a documentação; hoje pode escrever no repositório.

O relatório tem limitações: o resumo apresentado não permite comparar o risco das empresas de IA com o de fornecedores SaaS convencionais nem avaliar a segurança de um produto específico. Ainda assim, oferece um motivo concreto para revisar as permissões. Antes de ampliar um piloto, verifique se o acesso do serviço corresponde à tarefa para a qual ele foi conectado.