Relatório de Violações de 2026 da IBM aponta uma lacuna de 92% no controle de acesso à IA

O relatório de violações de 2026 da IBM chegou ao Google News com um contraste contundente: 92% das organizações atingidas por meio de sistemas de IA supostamente não dispunham de controles de acesso adequados.

Esse número importa porque as empresas não usam mais a IA apenas para redigir textos ou resumir documentos. Modelos e agentes estão cada vez mais conectados a dados corporativos, serviços em nuvem, ferramentas de software e fluxos de trabalho de produção. Erros de acesso podem, portanto, expor informações ou autorizar ações em diversos sistemas.

A manchete também captura uma mudança mais ampla na IA empresarial. As empresas adotaram IA para melhorar a produtividade e reforçar a segurança, mas muitas a implementaram sem as salvaguardas de identidade exigidas rotineiramente para funcionários e aplicações convencionais. As conclusões da IBM sugerem que os atacantes perceberam essa lacuna.

A manchete da IBM no Google News aponta para uma mudança mais ampla na segurança de IA

A estatística sobre controle de acesso é alarmante, mas as conclusões mais amplas da IBM mostram que a IA agora afeta os dois lados de uma violação de dados.

A IBM lançou seu Relatório de Custo de uma Violação de Dados de 2026 em 29 de julho. A pesquisa foi conduzida pelo Ponemon Institute, depois patrocinada e analisada pela IBM. Ela examinou violações sofridas por 602 organizações de 17 setores entre março de 2025 e fevereiro de 2026.

O número informado de 92% diz respeito a organizações que sofreram ataques envolvendo seus modelos ou aplicações de IA. Na prática, essas organizações não contavam com controles capazes de limitar de forma confiável quem ou o que acessava os sistemas de IA afetados.

O controle de acesso determina se uma pessoa, aplicação ou identidade de máquina pode alcançar um recurso. Ele também define quais ações essa identidade pode executar. Para um agente de IA, essas permissões podem incluir ler registros de clientes, chamar uma interface de programação de aplicações, modificar um ticket ou acionar um fluxo de trabalho automatizado.

A estatística não deve ser interpretada como prova de que 92% de todas as empresas não têm controles de acesso para IA. A IBM estudou organizações que haviam sofrido violações, e o número se aplica a um grupo mais restrito com incidentes relacionados à IA. Essa distinção é importante ao avaliar a prevalência do problema.

Mesmo dentro desse grupo mais restrito, a conclusão descreve uma grave falha de controle. Mais de 20% das organizações da amostra da IBM relataram uma violação direcionada a modelos ou aplicações de IA. APIs, aplicações ou plug-ins comprometidos responderam por 27% das causas citadas. Configurações incorretas de nuvem que afetavam cargas de trabalho de IA representaram outros 27%.

Essas conclusões desviam a atenção de cenários dramáticos em que um modelo derrota espontaneamente a segurança. As fragilidades mais imediatas geralmente estão ao redor do modelo. Atacantes podem explorar interfaces expostas, contas de serviço com privilégios excessivos, plug-ins vulneráveis e recursos de nuvem mal configurados.

O relatório de violações de 2026 da IBM também contextualiza os riscos financeiros. O custo médio global de uma violação chegou a US$ 4,99 milhões, representando um aumento anual de 12%. A IBM descreveu esse valor como um recorde.

Os incidentes relacionados à IA alteraram ainda mais essa equação econômica. A IBM relatou que uma em cada quatro violações maliciosas foi viabilizada por IA, alta de 56% em relação ao ano anterior. Esses incidentes custaram às organizações, em média, US$ 6 milhões, cerca de US$ 1 milhão acima da média global.

Isso não significa que todo ataque viabilizado por IA tenha visado diretamente um modelo de IA. A IBM usa essa categoria para incluir ataques em que agentes de ameaça empregaram IA, incluindo personificação por deepfake e malware auxiliado por IA. A distinção separa ataques que usam IA de ataques contra sistemas de IA.

Em conjunto, as categorias descrevem um risco de dois lados. Atacantes podem usar IA para aumentar a velocidade ou a escala de táticas já estabelecidas. Também podem visar os modelos, agentes, repositórios de dados e interfaces que as empresas estão adicionando rapidamente à sua infraestrutura.

É por isso que a abordagem do Google News não deve ser reduzida a uma única porcentagem sensacionalista. O evento subjacente é uma mudança na superfície de ataque empresarial, com a IA se tornando tanto uma ferramenta do atacante quanto um alvo.

O verdadeiro ponto fraco está ao redor do modelo

Os números da IBM indicam que falhas comuns de identidade, API e nuvem continuam centrais em violações de IA supostamente novas.

As discussões sobre segurança de IA frequentemente se concentram no comportamento do modelo, como alucinações, resultados prejudiciais ou injeção de prompt. Esses riscos continuam relevantes, mas os dados da IBM apontam para um problema menos exótico. As organizações estão conectando IA a recursos valiosos sem aplicar de forma consistente controles de segurança já estabelecidos.

Um modelo, por si só, normalmente não consegue acessar um banco de dados de clientes nem implantar software. Ele obtém esse alcance por meio dos componentes ao seu redor. Eles incluem plug-ins, credenciais de API, sistemas de recuperação, funções de nuvem, contas de serviço e camadas de orquestração de agentes.

Cada conexão amplia o número de decisões que uma organização precisa governar. Quais documentos o sistema pode recuperar? Ele pode ver registros de todos os clientes? Pode chamar um serviço externo? Pode gravar dados ou apenas lê-los? Seu acesso expira quando uma tarefa termina?

Uma identidade de agente é a identidade digital atribuída a um agente de IA que atua em sistemas conectados. Os programas tradicionais de identidade normalmente se concentram em funcionários, contratados, dispositivos e cargas de trabalho de software. Os agentes introduzem outra categoria capaz de tomar decisões e invocar ferramentas com participação humana limitada.

A IBM recomenda controles dinâmicos baseados em identidade para esses agentes. Também defende permissões estritamente delimitadas, aplicação de políticas em tempo de execução, atribuição humana e atividade auditável. A aplicação em tempo de execução significa verificar permissões enquanto um agente opera, em vez de aprovar acesso amplo uma única vez durante a implantação.

Essa abordagem trata de uma incompatibilidade fundamental. Um funcionário normalmente se autentica por meio de uma conta conhecida, enquanto um agente pode agir por várias credenciais compartilhadas. Se os registros guardarem apenas a conta de serviço compartilhada, os investigadores poderão ter dificuldade para identificar qual agente iniciou uma ação ou qual funcionário solicitou o procedimento.

O resultado é uma lacuna de responsabilização. Uma empresa pode saber que um token de API acessou dados sensíveis sem saber qual modelo, fluxo de trabalho ou usuário causou a solicitação. Isso torna mais difícil interromper atividades inadequadas e reconstruir uma violação posteriormente.

O princípio do menor privilégio oferece uma resposta conhecida. Ele concede a cada identidade apenas o acesso necessário para uma tarefa definida. Ainda assim, aplicá-lo à IA pode ser difícil, pois agentes frequentemente executam trabalhos mutáveis e em várias etapas.

Permissões amplas tornam um agente mais útil em mais situações. Elas também ampliam o dano potencial de um prompt manipulado, credencial roubada, decisão defeituosa ou integração comprometida. O mesmo acesso que permite a automação pode aumentar o raio de impacto da violação.

Considere um assistente interno de pesquisa conectado a documentos, e-mail, registros de clientes e sistemas de projetos. Uma configuração restrita pode permitir que ele recupere arquivos aprovados para uma equipe. Uma configuração ampla pode expor informações em repositórios jurídicos, financeiros, de engenharia e vendas.

A diferença de segurança não está na capacidade de escrita do modelo. Está na qualidade da fronteira de identidade ao redor de seus dados e ferramentas.

O acesso ao conhecimento também merece atenção especial. As organizações querem que os assistentes encontrem contexto relevante sem expor todas as fontes a todos os usuários. Uma base de conhecimento de IA cuidadosamente projetada deve preservar as permissões das fontes, em vez de criar um novo caminho para contorná-las.

A mesma questão aparece em fluxos de trabalho autônomos. Um agente que lida com solicitações de suporte pode precisar ler o perfil de um cliente e propor uma resposta. Ele não precisa automaticamente de permissão para exportar o banco de dados de clientes, alterar dados de cobrança ou desativar configurações de segurança.

A IA pode borrar essas fronteiras porque o contexto útil costuma ser tratado como um único conjunto. Quando as permissões desaparecem durante a indexação, a recuperação ou a execução do agente, o sistema pode revelar informações às quais o usuário solicitante não poderia acessar diretamente.

O envenenamento de contexto cria outro risco. Isso ocorre quando informações enganosas ou maliciosas entram no material que uma IA usa para tomar decisões. Um atacante pode inserir instruções em um documento que um agente recuperará mais tarde.

A filtragem tradicional de resultados não aborda completamente esse cenário. A organização deve controlar em quais fontes o agente confia, quais ferramentas pode invocar e se ações sensíveis exigem aprovação. Os registros também precisam preservar contexto suficiente para explicar a decisão.

As proteções de um modelo e os controles de acesso de uma empresa têm propósitos distintos. As proteções podem influenciar o conteúdo que um modelo produz. Os controles de acesso decidem se ele pode alcançar um sistema de folha de pagamento, repositório de código-fonte ou console de produção.

Confundir os dois pode criar uma falsa sensação de segurança. Um modelo bem-comportado com permissões excessivas continua perigoso se suas credenciais forem roubadas ou suas entradas forem manipuladas. Por outro lado, um acesso estritamente delimitado pode limitar os danos mesmo quando um modelo se comporta de modo inesperado.

Portanto, o relatório da IBM desafia a ideia de que a segurança de IA exige um universo de segurança inteiramente separado. Muitas falhas ainda envolvem descoberta de ativos, gestão de credenciais, configuração de nuvem, monitoramento e resposta a incidentes. A nova dificuldade está em aplicar esses controles a sistemas que atuam com maior autonomia.

A adoção de IA prometia velocidade, mas as equipes de segurança herdaram o risco

O conflito principal está entre a rápida implementação de IA e o trabalho mais lento de definir identidades, permissões, propriedade e evidências.

As equipes empresariais enfrentam fortes incentivos para implementar IA rapidamente. Funcionários já usam assistentes de consumo, extensões de navegador, serviços de transcrição e recursos de IA incorporados a softwares empresariais. As unidades de negócio muitas vezes podem ativar esses serviços antes que as equipes de segurança os tenham inventariado.

Esse comportamento produz IA sombra, isto é, ferramentas ou modelos de IA usados sem aprovação formal ou governança. Ele se assemelha à TI sombra, mas a exposição pode ir além do armazenamento ou da aquisição de software. Um modelo não autorizado pode processar dados sensíveis, reter prompts, chamar ferramentas ou influenciar decisões de negócio.

A pesquisa de 2025 da IBM estabeleceu uma base importante. Naquele momento, 13% das organizações estudadas relataram violações envolvendo modelos ou aplicações de IA. Entre essas organizações, 97% afirmaram não ter controles de acesso adequados para IA.

As conclusões de 2025 também constataram que 63% das organizações violadas não tinham uma política de governança de IA ou ainda estavam desenvolvendo uma. Apenas 34% das organizações com uma política realizavam auditorias regulares em busca de IA não autorizada.

Uma em cada cinco organizações nesse estudo relatou uma violação envolvendo IA sombra. Organizações com uso elevado de IA sombra tiveram custos médios de violação US$ 670.000 acima das que tinham uso baixo ou nenhum uso de IA sombra.

A passagem de 97% no subgrupo violado de 2025 para os 92% reportados em 2026 sugere melhoria limitada, não um problema resolvido. As amostras e as definições precisas de incidentes podem diferir, portanto as porcentagens não devem ser tratadas como uma medição limpa de um ano para o outro.

Ainda assim, ambos os números apontam na mesma direção. Quase todas as organizações afetadas nos grupos relevantes não tinham controles adequados sobre o acesso à IA. Essa consistência é mais significativa do que a diferença de cinco pontos.

As equipes de segurança sofrem pressão de várias direções ao mesmo tempo. Elas precisam descobrir usos de IA autorizados e não autorizados, atribuir responsáveis, classificar dados conectados, governar identidades não humanas, inspecionar plug-ins e monitorar ações em tempo de execução.

Enquanto isso, as equipes de produto estão ampliando o que os agentes podem fazer. Um assistente que apenas redige textos tem autoridade operacional limitada. Um agente que atualiza registros de clientes, integra código, agenda pagamentos ou altera recursos de nuvem entra em outra categoria de risco.

Isso cria uma defasagem de governança. A área de compras pode aprovar o software, enquanto as equipes de identidade continuam sem saber de suas contas de serviço. Um desenvolvedor pode conectar um agente a dados de produção antes que a equipe de privacidade avalie o fluxo.

A organização pode acabar com várias visões incompletas. A segurança vê o tráfego de API, a TI vê licenças, o jurídico vê contratos de fornecedores e as equipes de negócio veem produtividade. Ninguém mantém um inventário completo do agente, de seus dados, de suas credenciais e de suas ações permitidas.

Políticas, por si só, não conseguem fechar essa lacuna. Um documento pode proibir funcionários de enviar informações confidenciais a modelos públicos. Ele não consegue impedir a atividade se a empresa não puder detectar a ferramenta, classificar os dados e aplicar a restrição.

Controles técnicos isolados também não bastam sem responsabilidade definida. Uma plataforma de segurança pode sinalizar acessos incomuns, mas alguém precisa decidir como é a atividade normal para cada agente. O responsável deve saber de quais ferramentas ele precisa e quais ações devem exigir a aprovação de uma pessoa.

A tensão se intensifica quando executivos exigem uma adoção de IA mensurável. As equipes podem contar licenças habilitadas, tarefas automatizadas ou uso por funcionários como progresso. Essas métricas recompensam alcance e velocidade, enquanto revisões de permissões e preparação para auditorias parecem atrasar a implantação.

A pesquisa da IBM sugere que o custo oculto surge após a implantação. A ausência de responsáveis torna os incidentes mais difíceis de conter. Credenciais compartilhadas dificultam atribuir ações. O acesso excessivo permite que um único componente comprometido alcance mais dados.

As organizações sob maior pressão incluem empresas de serviços financeiros e de energia. A IBM constatou que os setores de infraestrutura crítica representaram 62% dos ataques impulsionados por IA relatados. Violações em serviços financeiros tiveram custo médio de US$ 6,3 milhões, enquanto violações no setor de energia tiveram média de US$ 5,2 milhões.

Esses setores operam sistemas interconectados nos quais interrupções podem afetar clientes, cadeias de suprimentos ou serviços essenciais. Eles também mantêm dados valiosos financeiros, de identidade, operacionais e de propriedade intelectual. Integrações de IA podem criar novas rotas para esses ambientes.

Os desenvolvedores também herdam consequências práticas. Revisões de segurança precisam cada vez mais de diagramas de arquitetura, inventários de fluxo de dados, documentação de modelos, propriedade de credenciais e evidências de teste. Uma equipe que não consegue explicar o acesso de um agente terá dificuldade para provar que a implantação está contida.

Por isso, compradores corporativos devem olhar além de saber se um produto oferece login único. Eles precisam saber se ele preserva permissões no nível da fonte, oferece suporte a funções granulares, separa locatários, registra chamadas de ferramentas e permite a revogação rápida de credenciais.

Uma caixa de seleção de compras pode confirmar que um controle existe. Ela não pode estabelecer que todos os agentes usam o controle corretamente. O verdadeiro teste é saber se uma organização consegue rastrear uma ação sensível, da pessoa que a solicita, passando pelo modelo, até o sistema de destino.

A IA Está Elevando e Reduzindo os Custos de Violações

A principal inversão apontada pela IBM é que a IA amplifica os ataques, enquanto a automação de segurança pode reduzir substancialmente o custo resultante.

O relatório de 2026 não apresenta a IA como algo uniformemente prejudicial. Organizações que usaram IA e automação de forma ampla em operações de segurança economizaram, em média, US$ 1,93 milhão em comparação com organizações que não usaram nenhuma das duas.

Essa descoberta cria a principal contrapartida do relatório. Recusar o uso de IA não elimina atacantes assistidos por IA nem serviços vulneráveis de terceiros. Implantá-la sem cuidado, porém, pode adicionar identidades e caminhos de dados não gerenciados.

A IBM afirma que os ataques habilitados por IA cresceram 56% ano a ano. A personificação por deepfake representou a categoria mais comum em reportagens secundárias, citada por 45% dos respondentes. Malware e phishing habilitados por IA também contribuíram para o aumento.

Essas ferramentas reduzem o custo de produzir mensagens personalizadas, personificar pessoas confiáveis e modificar código malicioso. Elas não eliminam a necessidade de um ponto de entrada. Credenciais roubadas, serviços expostos, software vulnerável e engano humano continuam sendo partes essenciais de muitos ataques.

A IA também pode ajudar os defensores a organizar alertas, detectar comportamentos incomuns, correlacionar eventos e conter incidentes. A automação importa porque os custos de violações aumentam quando as organizações levam mais tempo para descobrir e corrigir sistemas comprometidos.

A executiva de segurança da IBM, Suja Viswesan, apresentou a questão como um desequilíbrio econômico. Atacantes podem lançar operações com maior rapidez e menor custo, enquanto as vítimas gastam milhões para encontrar, conter e se recuperar de uma violação.

A recomendação dela se concentra em reduzir o atraso entre a descoberta e a correção. Isso inclui integrar correções aos fluxos de desenvolvimento, proteger identidades durante a operação e tratar fraquezas na velocidade com que os atacantes as exploram.

A adoção continua desigual. Uma em cada quatro organizações no estudo da IBM não havia introduzido IA e automação nas operações de segurança. Mais da metade usava agentes para detecção e contenção de ameaças, mas apenas 18% os aplicava à gestão de vulnerabilidades.

Essa lacuna importa porque a detecção ocorre depois que a atividade suspeita aparece. A gestão de vulnerabilidades trata fraquezas conhecidas antes que um atacante as explore. A detecção rápida não pode compensar sistemas expostos que permanecem sem correção ou mal configurados.

O estudo da IBM também constatou que 85% dos respondentes em pesquisas complementares planejavam aumentar os gastos com segurança após conhecerem capacidades avançadas de modelos de fronteira. Apenas 64% haviam planejado aumentar os gastos após vivenciar uma violação na pesquisa inicial.

Esse resultado sugere que as organizações estão começando a responder a capacidades previstas, e não apenas a incidentes concluídos. No entanto, a intenção de gasto não estabelece se os investimentos melhorarão os controles de identidade ou apenas adicionarão mais produtos de detecção.

A metodologia do relatório também merece escrutínio. A IBM e a Ponemon estudaram organizações que sofreram violações, não uma amostra representativa de todas as empresas. As estimativas de custo combinam várias categorias, incluindo detecção, escalonamento, perda de negócios, notificação e resposta pós-violação.

O relatório pode identificar padrões dentro de sua amostra. Ele não pode provar que adicionar um produto de segurança produzirá a economia média citada em todas as organizações. Grandes empresas, setores regulamentados e incidentes complexos podem ter estruturas de custo muito diferentes.

Os incentivos do fornecedor também devem permanecer visíveis. A IBM vende software e serviços de segurança relacionados a identidade, proteção de dados, gestão de nuvem e resposta a incidentes. Seu relatório pode conter pesquisas valiosas e, ao mesmo tempo, apoiar uma narrativa comercial.

Isso não invalida os dados. Significa que os leitores devem separar descobertas mensuradas de alegações prescritivas. A amostra mostra associações entre automação extensiva de segurança e custos médios mais baixos, mas a maturidade organizacional pode contribuir para ambos.

Um programa de segurança maduro tem mais probabilidade de adotar automação de forma eficaz. Ele também pode ter melhores inventários, equipe treinada, planos de resposta testados e apoio executivo. Esses fatores podem reduzir os custos de violações independentemente das ferramentas.

A descoberta de 92% sobre controle de acesso exige cuidado semelhante. A porcentagem não mostra que controles ausentes causaram todos os incidentes. Ela demonstra uma forte sobreposição entre violações relacionadas à IA e controles inadequados no grupo afetado.

APIs comprometidas e configurações incorretas de nuvem fornecem um mecanismo plausível para conectar controles fracos a incidentes. Ainda assim, a causalidade pode variar. Um atacante pode explorar uma vulnerabilidade de software mesmo quando existem políticas de identidade, ou roubar uma credencial legitimamente privilegiada.

A cobertura independente destacou a mesma ameaça dupla. Uma análise do setor observou que criminosos estão tanto mirando sistemas de IA quanto usando IA para acelerar ataques já estabelecidos. Esse enquadramento reflete melhor o relatório do que uma simples alegação de que modelos estão causando violações.

A conclusão prática não é escolher entre IA ou segurança. As empresas devem governar implantações de IA e, ao mesmo tempo, usar automação onde ela melhora a defesa. O resultado depende de as organizações conectarem capacidade a autoridade estritamente definida.

O Que o Número de 92% Não Comprova

A manchete identifica uma crise de controles, mas não revela a qualidade dos controles de cada organização nem estabelece uma taxa universal de incidentes.

Percentuais podem circular pelo Google News mais rápido do que suas definições. Leitores podem encontrar o número de 92% sem ver os limites da amostra, o período da pesquisa ou a distinção entre ataques habilitados por IA e ataques direcionados à IA.

A primeira incerteza diz respeito à terminologia. “Controles adequados de acesso à IA” podem abranger várias práticas, incluindo autenticação, desenho de funções, rotação de credenciais, permissões de fonte, políticas em tempo de execução e registros de auditoria. Uma medida binária pode ocultar grandes diferenças de maturidade.

Uma organização pode não ter controles dedicados. Outra pode usar sistemas de identidade estabelecidos, mas deixar de aplicá-los a um plug-in. Ambas podem aparecer na mesma categoria de controle inadequado, embora suas posturas de segurança sejam diferentes.

A segunda incerteza diz respeito à detecção. Organizações não podem relatar incidentes que nunca descobrem. Empresas com monitoramento mais forte podem identificar mais atividade relacionada à IA do que organizações com visibilidade limitada, criando um aumento aparente que reflete parcialmente uma observação melhor.

Oito por cento das organizações no estudo de 2025 da IBM disseram não saber se modelos ou aplicações de IA haviam sido comprometidos. Essa incerteza ilustra o problema de inventário. Uma empresa não pode avaliar um modelo cuja existência desconhece.

A terceira incerteza diz respeito ao significado de uma violação relacionada à IA. Um atacante pode mirar um endpoint de modelo, roubar dados de treinamento, explorar uma API associada ou usar phishing gerado por IA contra um funcionário. Esses eventos têm mecanismos diferentes e exigem defesas diferentes.

A inversão de modelo, por exemplo, tenta inferir informações sensíveis a partir das saídas de um modelo. A IBM relatou um custo médio global de US$ 6 milhões para violações envolvendo esse tipo de ataque. Esse cenário difere de um bucket de armazenamento em nuvem exposto por meio de uma aplicação de IA mal configurada.

A personificação por deepfake é diferente mais uma vez. Ela usa mídia sintética para imitar uma pessoa confiável, muitas vezes para manipular um funcionário ou processo de negócios. Controles de acesso podem limitar o dano resultante, mas a verificação de identidade e os controles de processo também são importantes.

A quarta incerteza diz respeito às comparações de tendência. O relatório de 2025 da IBM estudou 600 organizações com violações de março de 2024 a fevereiro de 2025. O relatório de 2026 estudou 602 organizações durante os 12 meses seguintes.

Essas amostras de tamanho semelhante permitem uma comparação ampla, mas as organizações participantes e a composição dos incidentes podem mudar. Os leitores não devem tratar cada variação como uma medida precisa da taxa global de violações.

A quinta incerteza envolve médias de custo. Um pequeno número de incidentes caros pode elevar uma média. Setor, tamanho da empresa, regulamentação, interrupção operacional e tempo de recuperação afetam o valor final.

A média global da IBM subiu de US$ 4,44 milhões em 2025 para US$ 4,99 milhões em 2026. O aumento é notável, mas não significa que toda empresa deva esperar que um incidente custe exatamente esse valor.

Uma abordagem mais útil é interpretar as conclusões como evidência direcional. Os sistemas de IA estão se tornando partes relevantes da infraestrutura empresarial. Os invasores estão interagindo com esses sistemas, e muitas organizações afetadas não estenderam a eles controles básicos.

Os líderes de segurança devem testar se a manchete corresponde ao seu próprio ambiente. Eles conseguem listar todos os modelos e agentes? Conseguem identificar o responsável? Conseguem ver quais fontes de dados cada sistema acessa? Conseguem revogar suas credenciais sem desativar uma plataforma inteira?

Eles também devem perguntar se os logs preservam a atribuição humana. Se um funcionário orienta um agente a atualizar o registro de um cliente, a trilha de auditoria deve conectar o funcionário, o agente, a credencial, a chamada de ferramenta e a alteração final.

O monitoramento contínuo é importante porque o comportamento de um agente pode mudar conforme seu contexto. Novas ferramentas, prompts, fontes de dados e versões de modelo podem alterar o que ele faz, mesmo quando suas permissões formais permanecem constantes.

Análises externas sobre segurança de agentes têm enfatizado identidades, acesso rigidamente controlado, ações auditáveis, caminhos de escalonamento e mecanismos de interrupção. Essas medidas tratam a autonomia como um risco operacional, e não apenas como um problema de qualidade do modelo.

Um mecanismo de interrupção é um recurso que para um agente ou revoga sua capacidade de agir. Ele deve funcionar de forma rápida e previsível, especialmente quando um agente pode acessar sistemas financeiros, de produção ou de clientes.

A aprovação humana também continua útil para ações de alto impacto. Um agente pode preparar um pagamento, uma alteração de código ou uma modificação de conta sem receber autoridade para finalizá-la. Essa separação preserva a automação e limita resultados irreversíveis.

Os controles devem corresponder ao risco. Um assistente que resume documentos públicos precisa de menos restrições do que um agente que acessa informações de pacientes ou infraestrutura de produção. Aplicar a mesma política a ambos pode gerar fricção excessiva ou proteção inadequada.

O valor da manchete, portanto, está em estimular perguntas concretas. Sua limitação é não poder responder a essas perguntas para todas as organizações.

Três Sinais a Observar Após o Relatório da IBM de 2026

O próximo teste é verificar se as empresas transformam a preocupação em controles de identidade mensuráveis, correção de vulnerabilidades e resultados verificáveis de forma independente.

O primeiro sinal é a adoção de controles de identidade específicos para agentes. As organizações devem ir além de chaves de API compartilhadas e atribuir identidades distintas a agentes, cargas de trabalho e fluxos de trabalho.

Evidências de progresso incluiriam credenciais de curta duração, permissões por tarefa, atribuição humana e logs que cubram todas as chamadas de ferramentas. É provável que fornecedores de segurança ampliem seus produtos nessa área, mas as métricas de adoção importam mais do que anúncios de recursos.

Se as organizações conseguirem inventariar identidades de agentes e revogá-las individualmente, o alerta central da IBM começará a perder força. Se os agentes continuarem a herdar contas de serviço amplas, a manchete dos 92% continuará relevante.

O segundo sinal é se as equipes de segurança aplicam automação à gestão de vulnerabilidades. A IBM constatou que mais da metade das organizações usava agentes para detecção e contenção de ameaças, enquanto apenas 18% os utilizavam para gestão de vulnerabilidades.

Esse desequilíbrio favorece a reação em detrimento da prevenção. O progresso significaria conectar inventários de ativos, dados de exposição, propriedade do código e fluxos de correção para que falhas conhecidas cheguem rapidamente à equipe responsável.

A métrica a observar não é o número de alertas de IA. É o tempo entre a descoberta de uma falha explorável e a implantação de uma correção verificada. Tempos de correção menores reforçariam o argumento da IBM de que defensores podem combater ataques mais rápidos com automação.

O terceiro sinal é a existência de evidências independentes sobre frequência e custos de violações. O relatório anual da IBM fornece uma referência amplamente citada, mas os compradores devem compará-lo com divulgações regulatórias, dados de seguros, conclusões de resposta a incidentes e pesquisas revisadas por pares.

Resultados consistentes entre essas fontes fortaleceriam a conclusão de que controles fracos de acesso à IA estão gerando perdas materiais. Grandes discrepâncias sugeririam que definições, amostragem ou práticas de detecção explicam parte da tendência.

As empresas também devem observar como o índice relatado de 92% muda no próximo estudo da IBM. Uma queda significativa, acompanhada por resultados mais sólidos de inventário e auditoria, indicaria que a governança está alcançando o ritmo necessário.

Uma porcentagem menor, por si só, não seria suficiente. As organizações poderiam simplesmente detectar menos incidentes ou redefinir o que se qualifica como um sistema de IA. Uma melhora crível exige evidências de que os controles são implantados, testados e aplicados durante a operação.

A questão mais ampla é se a IA empresarial pode amadurecer, passando da experimentação para uma infraestrutura com responsabilização. Modelos e agentes agora interagem com documentos, dados de clientes, código, comunicações e processos de negócios. A segurança deve acompanhar essas conexões.

O Google News pode amplificar a estatística, mas conselhos de administração e equipes técnicas precisam traduzi-la em perguntas no nível do sistema. Quais identidades existem, o que elas podem acessar e quem continua responsável quando um agente age?

As conclusões da IBM oferecem um alerta, não um veredito final. Os próximos três meses devem mostrar se as empresas tratam o acesso à IA como um problema central de identidade ou como mais um documento de política à espera de implementação.

Revise cada agente de IA que possa acessar dados sensíveis ou acionar uma ação externa. Dê a ele um responsável nomeado, uma identidade distinta, permissões estritamente delimitadas e um caminho auditável de volta à pessoa solicitante. Em seguida, teste se a organização consegue interrompê-lo rapidamente.

Esse trabalho é menos dramático do que uma manchete no Google News. Também é onde o próximo incidente caro de IA tem maior probabilidade de ser evitado.