Empresas Não Têm Visibilidade sobre Dois Terços de Sua Superfície de Ataque de IA, Alerta a Snyk

A Snyk atribuiu um número contundente ao risco de IA nas empresas: quase dois terços da superfície de ataque relevante podem estar fora da visão direta das equipes de segurança. O alerta, divulgado pelo Google News, concentra-se em agentes, plugins, conjuntos de dados e pipelines de dados conectados ao trabalho diário. Esses componentes se multiplicam à medida que as empresas levam experimentos de IA para produção.

O número vem da Snyk, e não de uma auditoria independente de todo o mercado corporativo. Sua análise de apoio usa informações anonimizadas de mais de 500 ambientes empresariais associados ao Snyk Evo. Essa distinção é importante. Os dados oferecem uma visão dos ambientes participantes, enquanto a alegação mais ampla ainda exige validação em outras plataformas e setores.

Mesmo com essa ressalva, a Snyk descreve um problema que vai além da telemetria de um único fornecedor. Uma pesquisa da Cloud Security Alliance constatou que 68% das organizações consultadas não conseguiam distinguir claramente as ações de agentes de IA da atividade humana. A OWASP documentou separadamente a injeção de prompt, permissões excessivas e autonomia sem controle como riscos materiais para aplicações.

Portanto, o conflito central não é adoção de IA versus resistência. É a implantação rápida e descentralizada versus sistemas de segurança construídos em torno de aplicações conhecidas, identidades humanas e inventários estáveis. As empresas estão autorizando mais software a raciocinar e agir, enquanto perdem confiança sobre o que está conectado aos seus dados.

Essa lacuna pressiona as equipes de segurança, mas também afeta desenvolvedores, engenheiros de plataforma, líderes de compras e responsáveis pelas áreas de negócio. Cada grupo pode introduzir uma dependência de IA. Poucas organizações têm um único sistema capaz de mapear a cadeia resultante, do modelo ao plugin, à identidade, ao conjunto de dados, à API e à ação em produção.

Por Que o Alerta da Snyk Chegou ao Google News

A alegação mais importante da Snyk não é que a IA cria novas vulnerabilidades. É que as empresas não conseguem visualizar de forma confiável os sistemas que as criam.

A Snyk apresentou sua AI Security Fabric em fevereiro de 2026 como uma camada que abrange o desenvolvimento de software e sistemas de IA agêntica. A empresa afirmou que sua abordagem combinaria visibilidade, prevenção e governança em todo o ciclo de vida de desenvolvimento de software.

Esse anúncio de produto incluiu conclusões da pesquisa 2026 State of Agentic AI Adoption da Snyk. Segundo a empresa, sua análise cobriu insights anonimizados de mais de 500 ambientes empresariais Evo. A Snyk afirmou que cada modelo de IA implantado estava associado a quase três vezes mais componentes ocultos, incluindo conjuntos de dados e ferramentas de terceiros.

A alegação principal vai além dessa observação. A Snyk diz que cerca de dois terços do risco de IA nas empresas está abaixo da camada mais visível do modelo. A parte oculta inclui ferramentas de agentes, plugins, repositórios conectados, serviços externos e pipelines de dados que funcionários conectam durante o desenvolvimento ou no trabalho diário.

Esses componentes não são automaticamente maliciosos. Um plugin pode simplesmente recuperar um documento, chamar uma API interna ou enviar uma mensagem aprovada. A questão de segurança surge da relação entre o componente, suas permissões, suas fontes de entrada e sua capacidade de acionar ações subsequentes.

Um inventário de modelos, por si só, não consegue capturar essas relações. Duas equipes podem usar o mesmo modelo por meio de agentes diferentes, com perfis de risco totalmente distintos. Um agente pode resumir documentos públicos. Outro pode ler código-fonte, consultar registros de clientes e gravar alterações em sistemas de produção.

É por isso que a história merece mais do que um alerta já conhecido sobre funcionários que usam chatbots não aprovados. A shadow AI agora inclui recursos incorporados em software aprovado, modelos implantados localmente, frameworks de agentes, extensões de navegador, serviços de automação e identidades de máquina. Alguns chegam por meio de processos formais de compras. Outros surgem quando um funcionário conecta mais uma ferramenta para concluir uma tarefa.

O Google News dá a essa alegação um canal de ampla distribuição, mas a agregação não valida o número subjacente. Os leitores devem tratar a estimativa de dois terços como uma conclusão de fornecedor, extraída de dados de ambientes relacionados aos clientes da Snyk. A conclusão mais sólida se apoia em evidências corroborantes: empresas têm dificuldade para inventariar o comportamento de agentes, permissões e dependências entre componentes.

Essa distinção impede que a análise se torne marketing de produto. A estimativa precisa da Snyk para todo o mercado continua aberta a testes. O problema de visibilidade em si já é sustentado por diversas fontes independentes e orientadas por padrões.

A Superfície de Ataque de IA Já Não É Uma Lista de Aplicações

Na prática, a superfície de ataque agora se comporta como um grafo em constante mudança, no qual modelos, identidades, ferramentas e repositórios de dados criam riscos por meio de suas conexões.

A segurança tradicional de aplicações começa com um objeto relativamente estável. Uma equipe é responsável por uma aplicação, mantém seu repositório, acompanha dependências e a implanta por uma infraestrutura conhecida. Ferramentas de segurança podem examinar o código, pacotes, imagens de contêiner, configuração de nuvem e endpoints expostos.

Sistemas nativos de IA acrescentam mais elementos em movimento. A análise da Snyk sobre aplicações nativas de IA descreve uma cadeia de suprimentos que pode incluir modelos pré-treinados, embeddings, agentes de terceiros, conjuntos de dados e serviços externos. Cada componente pode mudar independentemente do código-fonte da aplicação.

Um embedding é uma representação numérica usada para comparar o significado de conteúdos. Um banco de dados vetorial pode armazenar milhões dessas representações para recuperação. Se as permissões ou os rótulos de origem estiverem errados, um agente pode recuperar informações que seu usuário jamais deveria acessar.

A geração aumentada por recuperação, frequentemente abreviada como RAG, fornece a um modelo documentos ou registros selecionados antes de ele produzir uma resposta. O RAG pode melhorar a precisão, mas também cria outra fronteira de confiança. A camada de recuperação deve decidir quais fontes o agente pode pesquisar e qual conteúdo deve retornar.

As ferramentas criam uma fronteira mais consequente. Um agente conectado a e-mail, controle de código-fonte, infraestrutura de nuvem ou banco de dados de clientes pode ir além da produção de texto. Ele pode ler, gravar, executar, aprovar ou transmitir informações, dependendo das permissões que os desenvolvedores lhe concederam.

Isso cria um desalinhamento com inventários de segurança organizados em torno de aplicações adquiridas. Uma empresa pode ter aprovado o fornecedor do modelo e o framework de agentes. Ainda assim, pode não ter um registro completo de cada endpoint de ferramenta, conta de serviço, conjunto de dados, modelo de prompt ou plugin conectado após a implantação.

A cadeia também pode mudar sem um lançamento tradicional. Um fornecedor de modelos pode atualizar o comportamento. Uma ferramenta de terceiros pode adicionar uma função. Um conjunto de dados pode receber novos documentos. Um usuário pode ampliar um escopo OAuth, que determina o que uma aplicação pode acessar por meio de autorização delegada.

Essas mudanças importam porque o risco depende de combinações. Um agente de resumo com acesso somente leitura tem um raio de impacto limitado. Dê ao mesmo agente permissão para enviar e-mails, editar arquivos e chamar um endpoint web irrestrito, e uma entrada manipulada poderá produzir um resultado muito diferente.

Portanto, a superfície de ataque inclui mais do que vulnerabilidades no código. Ela inclui permissões excessivas, contexto contaminado, credenciais expostas, tratamento inseguro de saídas, regras fracas de aprovação e registros incompletos de ações. Vários desses problemas permanecem invisíveis para scanners que inspecionam apenas arquivos-fonte ou pacotes de software conhecidos.

Para equipes de engenharia, a documentação torna-se parte do sistema de controle. Um registro pesquisável de decisões de arquitetura, ferramentas aprovadas, escopos de permissão e conclusões de incidentes ajuda as equipes a identificar relações que painéis individuais não detectam. Uma base de conhecimento de engenharia estruturada pode apoiar esse trabalho, embora não substitua o monitoramento de segurança.

A lição mais ampla é simples. Um sistema de IA não pode ser governado como um único endpoint de modelo. Ele deve ser tratado como uma aplicação conectada, cujos dados, ferramentas, identidades e ações permanecem visíveis durante toda a operação.

A IA Agêntica Pressiona os Controles de Identidade

O ponto cego que mais cresce está onde o software autônomo herda permissões projetadas para usuários humanos.

A Cloud Security Alliance publicou uma pesquisa sobre identidade de agentes em março de 2026. Sua pesquisa constatou que 73% das organizações esperavam que os agentes de IA se tornassem vitais no ano seguinte. Ainda assim, 68% não conseguiam distinguir claramente ações realizadas por agentes daquelas realizadas por pessoas.

A semelhança entre esse índice de 68% e o alerta de aproximadamente dois terços da Snyk é marcante, mas os números medem coisas diferentes. A Snyk discute componentes ocultos e riscos em ambientes de IA. A pesquisa da Cloud Security Alliance examina atribuição de identidade e gestão de acesso.

Juntos, eles revelam a mesma fragilidade estrutural. As organizações estão dando a identidades de software acesso a sistemas empresariais mais rapidamente do que atualizam práticas de autenticação, autorização e monitoramento.

Uma identidade de máquina é uma credencial usada por software, e não por uma pessoa. Ela pode assumir a forma de uma chave de API, conta de serviço, certificado, identidade de carga de trabalho ou token OAuth. Agentes dependem dessas credenciais para acessar dados e executar ações.

Os sistemas de identidade humana normalmente pressupõem que uma pessoa faz login, recebe uma função definida e gera atividade vinculada àquela conta. Os agentes complicam esse modelo. Um agente pode agir em nome de vários usuários, chamar diversas ferramentas e criar uma cadeia de operações geradas por máquina em segundos.

A atribuição se torna especialmente difícil quando um agente usa uma conta de serviço compartilhada. Os logs podem mostrar que a conta alterou um registro ou baixou um arquivo. Eles podem não identificar a solicitação do funcionário, a decisão do modelo, o documento recuperado ou a chamada de plugin que causou a ação.

Isso não é apenas um inconveniente de auditoria. Uma atribuição fraca torna mais difícil conter incidentes. Uma equipe de segurança não consegue revogar com confiança a credencial correta se não souber qual agente, usuário ou fluxo de trabalho iniciou a atividade suspeita.

O acesso com privilégios excessivos aumenta os danos. Uma ferramenta criada apenas para resumir mensagens pode receber permissão para enviá-las ou excluí-las. Um assistente de código pode obter acesso de gravação a vários repositórios quando precisa apenas revisar um projeto.

A OWASP descreve essa condição como autonomia excessiva. Suas orientações identificam funcionalidade, permissões e autonomia excessivas como causas fundamentais. A OWASP recomenda limitar as ferramentas disponíveis, restringir permissões, executar ações no contexto do usuário e exigir aprovação para operações de alto impacto.

Esses controles se assemelham a práticas maduras de confiança zero. Cada solicitação deve ser avaliada usando uma identidade específica, autorização definida e contexto atual. O modelo não deve decidir por conta própria se uma operação é permitida.

O agente também precisa de uma identidade distinta da de seu operador humano. Os logs devem preservar a relação entre a solicitação do usuário, a instância do agente, a ferramenta selecionada, a credencial usada e a ação resultante. Sem essa cadeia, as empresas podem coletar volumes enormes de telemetria e ainda assim permanecer cegas.

É nesse ponto que a adoção de IA pressiona a arquitetura de segurança. As equipes de negócio querem assistentes que eliminem aprovações repetitivas e concluam tarefas de várias etapas. As equipes de segurança precisam de pontos de controle, permissões restritas e decisões que possam ser reconstruídas. Remover todos os pontos de controle aumenta a velocidade, mas também amplia o potencial raio de impacto de uma ação errada ou manipulada.

O conflito não será resolvido escolhendo autonomia total ou proibindo agentes. As empresas precisam de diferentes níveis de autonomia para consequências diferentes. A elaboração de um resumo pode continuar automática. O envio de recursos, a exclusão de registros, a alteração da infraestrutura de produção ou a divulgação de dados protegidos devem exigir controles mais rigorosos.

A Verdadeira Troca É Velocidade Versus Controle Verificável

As empresas ganham valor quando os agentes atravessam fronteiras entre sistemas, mas cada conexão adicional torna o comportamento mais difícil de verificar.

A IA agêntica atrai empresas porque pode conectar etapas separadas em um único fluxo de trabalho. Um agente de suporte pode ler um ticket, recuperar o histórico da conta, classificar a urgência, propor uma resposta e atualizar o registro do cliente. Essa sequência pode reduzir a coordenação manual.

A mesma sequência contém várias fronteiras de segurança. O ticket pode incluir texto não confiável. O histórico da conta pode conter dados protegidos. O modelo pode gerar uma instrução de ferramenta insegura. O sistema do cliente pode aceitar uma atualização com consequências duradouras.

A injeção de prompt torna essa troca concreta. A injeção de prompt ocorre quando conteúdo elaborado altera a forma como um modelo segue instruções. O conteúdo pode vir diretamente de um usuário ou indiretamente de uma página da web, documento, e-mail, repositório ou registro recuperado.

Uma aplicação convencional separa comandos de dados por meio de sintaxe rigorosa e controles de acesso. Modelos de linguagem processam ambos como tokens dentro do contexto. Esse design dificulta garantir que um modelo sempre tratará texto externo como dado não confiável, e não como uma instrução.

A orientação atual da OWASP afirma que não se conhece nenhum método infalível de prevenção contra injeção de prompt. Ela recomenda restringir comportamentos, validar formatos de saída esperados, filtrar entradas e saídas e limitar as permissões disponíveis ao modelo.

Essas mitigações reduzem o impacto, mas não criam certeza. Um agente que só pode ler uma coleção restrita de documentos apresenta menos perigo do que outro capaz de executar comandos de shell. Uma etapa de aprovação humana pode detectar ações suspeitas, mas apenas se o revisor receber contexto suficiente para tomar uma decisão informada.

A velocidade pressiona cada salvaguarda. As equipes podem conceder acesso amplo para evitar trabalho repetido de integração. Podem usar credenciais compartilhadas porque a autorização por usuário demora mais para ser implementada. Podem suprimir solicitações de aprovação depois que usuários reclamarem do atrito.

Isso transforma a disputa central em uma troca entre velocidade de implantação e controle verificável. A Snyk argumenta que a segurança precisa se tornar contínua porque os sistemas de IA mudam rápido demais para revisões ocasionais. O interesse comercial da empresa é claro, já que ela vende produtos posicionados em torno dessa necessidade.

Por isso, compradores devem separar o diagnóstico da plataforma proposta. Uma camada unificada de segurança pode melhorar a visibilidade, mas nenhum fornecedor comprovou que um único produto consegue observar todos os modelos, implantações locais, ferramentas de navegador, conjuntos de dados, identidades e integrações externas em uma grande empresa.

As alegações de cobertura dependem de integrações e telemetria. Um modelo de nuvem aprovado pode ser fácil de detectar. Um modelo hospedado localmente na estação de trabalho de um desenvolvedor talvez não seja. Um recurso de IA dentro de um pacote de software conhecido pode gerar atividade que parece tráfego comum de aplicação.

Conexões criptografadas e regras de privacidade introduzem limitações adicionais. Monitorar prompts ou documentos recuperados pode expor dados sensíveis de funcionários e clientes. As equipes de segurança precisam de contexto suficiente para detectar uso indevido sem criar um segundo repositório de informações confidenciais.

Regras regionais de dados acrescentam outra restrição. Uma empresa multinacional talvez não consiga centralizar todos os logs de interação com IA. Pode precisar de processamento local, metadados seletivos, controles de retenção e políticas de monitoramento diferentes para jurisdições distintas.

Essas complicações não invalidam o alerta da Snyk. Elas reforçam seu ponto central, ao mesmo tempo que desafiam qualquer solução simples. A visibilidade é necessária, mas ela própria cria custos de design, privacidade e operação.

O Que a Alegação dos Dois Terços Não Comprova

Os dados da Snyk indicam uma séria lacuna de governança, mas não estabelecem que dois terços de cada ambiente empresarial estejam comprometidos ou sejam exploráveis.

A limitação mais importante é a amostragem. A Snyk descreve insights anonimizados de mais de 500 ambientes corporativos Evo. As organizações que usam esse ambiente podem diferir do mercado mais amplo em porte, práticas de software, maturidade em IA ou prioridades de segurança.

A empresa não estabeleceu publicamente que sua amostra represente todos os setores ou regiões geográficas. Ela também tem um motivo comercial para definir o problema em termos que favorecem uma cobertura de segurança mais ampla. Nenhuma dessas questões torna os dados falsos, mas ambas exigem atribuição cuidadosa.

“Risco” também é mais amplo do que “vulnerabilidade”. Um componente oculto pode não ser gerenciado ou não estar suficientemente inventariado sem conter uma falha explorável. Ele se torna perigoso quando combinado com permissões fracas, dados sensíveis, entradas inseguras ou a capacidade de realizar ações consequentes.

Da mesma forma, “dois terços” não significa que as equipes de segurança vejam exatamente um terço de cada ambiente. A estimativa resume padrões em ambientes observados. Organizações individuais podem ter uma cobertura muito melhor ou pior.

A expressão “superfície de ataque” pode ainda confundir problemas diferentes. Ela pode incluir ativos expostos à internet, APIs internas, dependências de software, ferramentas de agentes, fluxos de dados, identidades e comportamento de modelos. Diferentes fornecedores contabilizam esses elementos de maneiras distintas.

Uma medição independente exigirá definições compartilhadas. Pesquisadores precisam distinguir ativos conhecidos de ativos desconhecidos, componentes acessíveis de componentes inativos e exposição teórica de caminhos de ataque demonstrados. Sem essas distinções, grandes percentuais atraem atenção, mas oferecem orientação operacional limitada.

O NIST fornece uma base mais neutra por meio de seu Framework de Risco de IA. O framework organiza o trabalho em torno de governar, mapear, medir e gerenciar riscos de IA. Também enfatiza que a gestão de riscos deve continuar durante todo o ciclo de vida do sistema.

O mapeamento é particularmente relevante para a alegação da Snyk. Uma organização deve identificar o modelo, a tarefa pretendida, os usuários, os dados, as dependências, o contexto de implantação e as partes afetadas antes de poder medir o risco. Um scanner não pode recuperar toda política ou decisão de responsabilidade que esteja faltando.

A medição também precisa de testes. Uma empresa pode documentar as permissões pretendidas de um agente, mas nunca verificar suas permissões efetivas em produção. Pode registrar ferramentas aprovadas enquanto deixa de perceber funções adicionadas por meio de uma integração atualizada.

A posição cética, portanto, não é que o ponto cego seja imaginário. É que a telemetria de um fornecedor ainda não pode definir seu tamanho exato em todo o mercado. A manchete deve motivar inventário e testes, e não se tornar um substituto para ambos.

Líderes de segurança devem perguntar aos fornecedores como calculam a cobertura. Devem solicitar o denominador, os métodos de detecção, os ambientes excluídos, a frequência de atualização e o processo para resolver ativos duplicados ou obsoletos. Uma porcentagem precisa sem esse contexto pode criar falsa confiança.

Eles também devem medir resultados. Encontrar mais componentes só é útil se a organização conseguir priorizar relações perigosas, designar responsáveis, reduzir permissões e corrigir caminhos verificados. Um inventário maior que produza uma fila de alertas impossível de gerenciar pode se tornar outra forma de cegueira.

Três Sinais Mostrarão Se o Ponto Cego Está Sendo Eliminado

A próxima fase será medida por meio de atribuição de identidade, inventários de componentes e reduções verificadas em permissões perigosas de agentes.

O primeiro sinal é se as empresas conseguem separar a atividade de agentes da atividade humana em seus logs. A constatação de 68% da Cloud Security Alliance fornece uma linha de base clara, embora venha de uma pesquisa, e não de telemetria direta.

A melhoria significaria que cada ação consequente carrega uma identidade de agente, delegação do usuário, nome da ferramenta, contexto de autorização e resultado rastreável. Se pesquisas futuras mostrarem menos organizações enfrentando dificuldades de atribuição, o argumento em favor de uma governança gerenciável de agentes se fortalecerá.

Se o número permanecer próximo de dois terços, a conclusão oposta se seguirá. As empresas terão implantado mais fluxos de trabalho autônomos sem resolver a responsabilidade básica. Esse resultado reforçaria o alerta da Snyk de que a lacuna de visibilidade cresce com a adoção.

O segundo sinal é o surgimento de listas de materiais de IA consistentes. Uma lista de materiais de IA registra modelos, conjuntos de dados, prompts, frameworks, ferramentas, serviços e dependências usados por um sistema. Ela estende o conceito de lista de materiais de software a componentes específicos de IA.

A versão útil deve permanecer sincronizada com a implantação. Um documento estático criado durante a aquisição deixará de fora as ferramentas e os conjuntos de dados conectados posteriormente. Descoberta automatizada, designação de responsáveis, histórico de versões e evidências de permissões efetivas importam mais do que simplesmente produzir uma lista.

A ampla adoção de formatos interoperáveis de inventário fortaleceria o argumento de que as empresas podem recuperar a visibilidade. A dependência contínua de painéis específicos de fornecedores deixaria pontos cegos entre produtos de segurança, plataformas de nuvem e ambientes locais.

O terceiro sinal é se as organizações reduzem a autonomia excessiva em produção. As equipes de segurança devem acompanhar quantos agentes podem gravar dados, executar código, enviar comunicações, alterar infraestrutura ou acessar repositórios sensíveis sem uma aprovação separada.

Um número menor mostraria que as empresas estão traduzindo a governança de IA em controles técnicos. Um número maior indicaria que os objetivos de produtividade ainda superam a contenção. Relatórios de incidentes envolvendo agentes com privilégios excessivos tornariam essa métrica especialmente urgente.

Esses sinais importam mais do que o volume de políticas de IA publicadas pelas empresas. Políticas descrevem intenção. Identidades, inventários, permissões e logs revelam a realidade operacional.

A manchete da Snyk no Google News funciona porque comprime essa realidade em um alerta memorável. O número exato de dois terços continua sendo uma estimativa derivada de fornecedor, mas o desalinhamento subjacente é difícil de descartar. Os componentes de IA estão se multiplicando mais rápido do que muitas organizações conseguem descobri-los, classificá-los e governá-los.

Para desenvolvedores, a pergunta imediata é se cada conexão de agente tem um responsável nomeado e uma permissão necessária. Para as equipes de segurança, é se os logs conseguem reconstruir uma ação, desde a solicitação do usuário, passando pela decisão do modelo, até o resultado posterior. Compradores empresariais devem exigir evidências para ambos.

O próximo trimestre oferece um teste prático. Escolha um agente de produção, mapeie cada modelo, ferramenta, identidade, conjunto de dados e chamada externa, e então compare esse mapa com os registros de segurança existentes. Se as duas visões divergirem muito, o ponto cego já está dentro da organização. Se coincidirem, teste se as permissões e os controles de aprovação se comportam como documentado. O Google News forneceu o alerta; a telemetria empresarial agora deve fornecer a resposta.