Os agentes de IA estão ficando mais inteligentes, e sua superfície de ataque está aumentando

No momento em que os agentes de IA começaram a agendar reuniões, executar código e navegar na web em seu nome, a conversa sobre segurança cibernética mudou. Não gradualmente, mas sim de uma hora para outra.

O que costumava ser um sistema de software delimitado e previsível se tornou algo que raciocina, planeja e age por meio de ferramentas e APIs cuja existência mal conhecia um ano antes.

Isso é genuinamente emocionante, e também é genuinamente aterrorizante, porque a superfície de ataque que vem com essa autonomia é enorme, e a maioria das organizações está apenas começando a entender o que significa deixar agentes entrarem em sua infraestrutura.

De chatbots a operadores

A promessa original da IA era simples: faça uma pergunta, obtenha uma resposta. Isso ainda é verdade para a maioria das interações de consumidores, mas não é o que está acontecendo nas implantações de empresas. Hoje, os agentes estão recebendo credenciais, chaves de API e a capacidade de excluir, criar e anotar dados, bem como realizar ações reais dentro de sistemas que têm consequências reais.

A mudança aconteceu rapidamente. Em menos de dois anos, os agentes de IA passaram de geradores de texto para permitir a operação de sistemas multiagentes que funcionam de forma integrada. Eles estão lendo e-mails, acionando fluxos de trabalho, consultando bancos de dados e, em alguns casos, gerenciando agentes subordinados. Esse nível de acesso costumava exigir um processo de aquisição longo e participação humana no processo. Agora é um arquivo de configuração e algumas chamadas de API.

Mais acesso significa maior exposição

Os ataques de software tradicionais têm um perfil mais ou menos previsível. Há um ponto de entrada conhecido, uma vulnerabilidade conhecida, um patch conhecido. Os agentes de IA quebram esse modelo porque são projetados para ser dinâmicos. Eles não seguem um caminho de código estático. Eles raciocinam sobre o que fazer em seguida, o que significa que seu comportamento é mais difícil de prever e muito mais difícil de auditar posteriormente.

Essa imprevisibilidade é útil para realizar o trabalho. É também uma vantagem para qualquer um que tente explorar o sistema. Quando um agente pode decidir, no meio de uma tarefa, chamar uma API externa ou trazer uma ferramenta de terceiros, não há um perímetro bem definido para defender.

As equipes de segurança estão acostumadas a proteger superfícies conhecidas e monitorar os custos do Kubernetes. Os agentes continuam descobrindo novas superfícies de ataque e formas de explorar vulnerabilidades, e ninguém está mapeando-os em tempo real. Antes que você perceba, alguém pode sequestrar as credenciais e obter controle sobre todo o seu “organismo” de IA com um único movimento.

A injeção de prompt é a nova injeção de SQL

Se há um vetor de ataque que os pesquisadores de segurança continuam a mencionar, é a injeção de prompt. A ideia é simples: em vez de explorar uma vulnerabilidade de código, um atacante manipula as instruções que um agente recebe por meio de suas entradas. Uma instrução maliciosa incorporada em uma página da web, um documento ou até mesmo um e-mail pode redirecionar o que o agente fará em seguida.

O que torna isso particularmente grave é que os agentes frequentemente estão fazendo exatamente o que lhes é dito. Eles estão processando conteúdo da web, de mensagens de usuário, de ferramentas de terceiros. Qualquer um desses conteúdos é uma superfície de injeção potencial. Um agente que lê um documento comprometido e, em seguida, faz chamadas de API com base em seu conteúdo foi sequestrado, e provavelmente não registrará nada que torne a cadeia de causalidade óbvia.

As defesas aqui são reais, mas incompletas. Isolar as ações do agente, restringir quais ferramentas um agente pode chamar em certos contextos e construir pontos de verificação humanos em fluxos de trabalho de alto risco reduzem o risco. Essas medidas não o eliminam. E a maioria das organizações ainda não implementou nem mesmo as medidas básicas.

O problema de confiança nos sistemas multiagentes

Os sistemas multiagentes introduzem uma camada de complexidade que é fácil de subestimar. Quando um agente está orquestrando vários outros, há uma hierarquia de confiança em jogo. O orquestrador repassa instruções aos subordinados, e os subagentes seguem-nas. Se esse orquestrador for comprometido, cada agente abaixo dele é efetivamente comprometido também, e o alcance do impacto cresce muito rapidamente.

Há também a questão da concessão excessiva de permissões. Os agentes frequentemente recebem mais acesso do que precisam porque é mais fácil conceder permissões amplas inicialmente do que refiná-las iterativamente. Um agente de pesquisa não precisa de acesso de gravação a um banco de dados de produção.

Um agente de agendamento não precisa de acesso a registros financeiros. Sim, é reconfortante ter tudo interligado, mas o risco é simplesmente alto demais para manter os benefícios sem que diminuam. Mas as linhas ficam turvas na prática, e os princípios de permissão mínima que funcionam bem na teoria são abandonados silenciosamente na pressa de lançar o produto.

Como deve ser uma segurança razoável nesse contexto

Não há uma solução única que torne as implantações de agentes seguras. É um problema em camadas e precisa de uma resposta em camadas. As organizações que fazem isso bem tendem a começar com controles de acesso: dar a cada agente um escopo definido e estreito e incorporar etapas de revisão a qualquer ação que envolva sistemas sensíveis ou serviços externos.

A observabilidade é tão importante quanto a prevenção. Se um agente fizer algo inesperado, as equipes precisam de um rastreamento completo das instruções que ele recebeu, quais ferramentas ele chamou e o que ele retornou. A maioria das configurações de registro não é projetada com esse nível de granularidade em mente, e acrescentá-lo posteriormente é trabalhoso. Vale a pena enfrentar as dificuldades de incluí-lo desde o início.

O teste adversarial também é subutilizado. Submeter os agentes a testes de red team, tentando injetar instruções maliciosas e observando o que acontece, revela vulnerabilidades que a revisão de código estático nunca capturará. É desconfortável pensar sobre isso, mas as pessoas que eventualmente tentarão explorar esses sistemas já estão realizando esses testes. Antecipar-se a elas é a única atitude sensata.

Considerações finais

Os agentes de IA vão se tornar uma parte maior do modo como as organizações operam, e essa mudança já está bem em andamento. A conversa sobre segurança precisa se atualizar, e rápido. Os riscos são reais, os vetores de ataque são novos, e a janela para se antecipar a eles está se fechando.

Entender o cenário de ameaças para os sistemas de IA autônomos não é mais opcional. É uma das coisas mais importantes que as equipes de segurança e engenharia podem estar fazendo agora, e o relógio para acertar já começou.