Lições de ciberimunidade para agentes de IA

Proteger sistemas de IA é muito mais difícil do que proteger sistemas de TI tradicionais, seja contra erros dos operadores, interferências maliciosas ou simplesmente comportamentos instáveis. Há duas razões principais para isso. Primeiro, as respostas geradas pela IA são probabilísticas, ou seja, o mesmo prompt pode produzir respostas diferentes a cada execução. Segundo, os LLMs atuais não conseguem distinguir comandos de dados com confiabilidade. Apesar dos problemas de segurança já demonstrados em sistemas de IA sobre os quais já falamos tantas vezes, é impossível ignorar o possível retorno econômico proporcionado por sua adoção. Por isso, muitas empresas estão deixando de lado os simples assistentes de IA e passando a adotar agentes de IA. Esses agentes executam tarefas por conta própria e têm acesso direto às mesmas ferramentas que os humanos: desde a leitura de bancos de dados até a alteração de configurações em processos de produção. Em seu novo estudo, nossos especialistas analisam como identificar e minimizar claramente os riscos envolvidos, reduzindo ao máximo os possíveis problemas. A abordagem se baseia nos princípios de imunidade cibernética e segurança desde a concepção, adaptando-os ao contexto da IA.

Os princípios básicos da segurança desde a concepção

Todos os princípios dessa disciplina se aplicam ao projeto de qualquer sistema computacional, inclusive agentes de IA. O que varia é o grau de adaptação e reformulação necessário para aplicar cada princípio a cenários que envolvem IA.

1. A segurança é um requisito independente e essencial desde a concepção. Os objetivos e as premissas de segurança são definidos desde o início e mantidos em todas as etapas do desenvolvimento. No caso dos agentes de IA, essas premissas devem abranger três pontos fundamentais: (i) o modelo de linguagem deve ser considerado não confiável; (ii) qualquer tipo de dado externo deve ser tratado como potencialmente malicioso; e (iii) ações irreversíveis não podem ser executadas de forma autônoma sem a aprovação obrigatória de uma pessoa.
2. O sistema é projetado com base na premissa de que será atacado.
3. A base computacional confiável e a superfície de ataque são reduzidas ao mínimo. Os agentes recebem apenas as ferramentas de que realmente precisam, permissões restritas e o mínimo possível de contexto. A aplicação das políticas de segurança fica inteiramente a cargo de componentes determinísticos: o monitor de políticas, a estrutura de execução do agente (harness) e os mecanismos de isolamento (sandboxes).
4. Aplica-se o princípio do privilégio mínimo. Cada agente tem seu próprio conjunto de credenciais e privilégios de acesso (identidade), restritos ao mínimo necessário para executar suas tarefas. Se um agente precisar de privilégios elevados temporariamente, só poderá obtê-los mediante aprovação externa, e eles serão válidos apenas pelo tempo necessário para executar a tarefa que os exige.
5. Os componentes são isolados. Em sistemas baseados em agentes, esse é um dos desafios arquiteturais mais complexos e envolve diversas camadas. A estrutura de execução do agente (harness) deve operar em um ambiente isolado (sandbox ou máquina virtual), e os agentes devem permanecer o mais isolados possível uns dos outros. O processamento de dados em contextos confiáveis e não confiáveis também deve ocorrer de forma separada. Por exemplo, um agente lê uma solicitação de pull request e elabora uma versão preliminar do código, enquanto outro revisa esse trabalho sem nunca ter acesso ao texto potencialmente malicioso da solicitação.
6. A regra é negar o acesso por padrão. As políticas de segurança seguem o princípio de que tudo o que não for explicitamente permitido será proibido. Isso se aplica a chamadas de ferramentas, interações entre agentes e tráfego de rede.
7. A defesa em profundidade é aplicada. Diferentes medidas devem atuar simultaneamente e se complementar, reforçando a segurança do sistema. Defesas probabilísticas, como as barreiras de proteção da IA (uma espécie de “firewall” para modelos de linguagem) ou o alinhamento (a própria percepção do modelo sobre o que é aceitável ou não), não oferecem garantias formais de segurança. Ainda assim, essas medidas contribuem para aumentar a segurança geral do sistema e fornecem dados de telemetria valiosos.
8. A cadeia de suprimentos é protegida. Alguns agentes são capazes de instalar habilidades, bibliotecas e outros componentes de software por conta própria. Por isso, essa possibilidade deve estar sujeita a regras rigorosas. Essas instalações devem ser totalmente bloqueadas ou restritas a uma lista fechada e pré-aprovada de versões específicas de determinados componentes. Sistemas baseados em LLMs na nuvem estão sujeitos a um risco adicional: as atualizações dos modelos. Um dia, a mesma solicitação à API pode ser respondida por um modelo de linguagem diferente, com propriedades de segurança diferentes.

Armadilhas da segurança em sistemas de IA

Os princípios gerais da segurança desde a concepção são bem conhecidos e parecem simples na teoria. No entanto, aplicá-los a sistemas de IA é complicado, pois os agentes são extremamente flexíveis. Por exemplo, uma equipe de segurança pode acreditar que um agente instalado no computador de um desenvolvedor é executado em um sandbox e, portanto, não consegue modificar nada fora dele. No entanto, um invasor, ou até mesmo o próprio agente, pode encontrar dezenas de maneiras de contornar essa proteção aparentemente sólida: desde executar comandos por meio de um servidor MCP local não sujeito às restrições do sandbox até reconfigurar outro agente de IA instalado no sistema. Para complicar ainda mais as coisas, a variedade de vetores de ataque é enorme: desde campos de imagem arbitrários na configuração do agente até strings de texto em um arquivo de definição de habilidades aparentemente inofensivas.

Um problema sério que os desenvolvedores costumam subestimar é a fadiga do usuário. Um agente muito ativo pode exibir dezenas de solicitações por minuto, pedindo ao usuário que confirme ações potencialmente perigosas. Em menos de uma hora, a pessoa já está clicando em Aprovar no piloto automático, sem ler o que está aprovando. Por isso, é fundamental ajustar cuidadosamente tanto a frequência dessas solicitações quanto a maneira como são redigidas. Ninguém vai ler uma descrição de solicitação longa demais. Por outro lado, uma descrição curta demais omitir informações essenciais para que o usuário tome a decisão correta.

As vulnerabilidades em agentes e nas ferramentas associadas representam um problema urgente, agravado pela rapidez com que esses softwares evoluem e recebem atualizações. Plataformas e aplicativos amplamente utilizados no setor, como LangGraph, MS Semantic Kernel e Claude Code, já tiveram vulnerabilidades críticas corrigidas mais de uma vez. Os arquitetos devem sempre considerar a substituição de frameworks grandes e abrangentes por sistemas compactos e enxutos, que ofereçam apenas os recursos realmente necessários para cada agente.

Além disso, implementar cuidadosamente medidas de segurança consagradas nas ferramentas disponíveis reduz significativamente os danos caso um agente seja atacado ou apresente um comportamento inesperado. Um exemplo é o uso de uma lista de permissão rigorosa de domínios que a ferramenta de busca na Web pode acessar a pedido do agente. No entanto, os desenvolvedores raramente levam em conta os problemas ocultos e os custos operacionais associados à manutenção dessa lista. Como resultado, ela fica gradualmente desatualizada e acaba deixando brechas que podem ser exploradas por invasores. O exemplo mais emblemático é o ataque EchoLeak. O Microsoft 365 Copilot contava com uma lista de permissão bem implementada e relativamente eficaz para acessar sites externos, mas os invasores conseguiram contorná-la por meio de uma funcionalidade de uma ferramenta secundária e do domínio do MS Teams.

Dicas práticas para arquitetos e equipes de segurança

Os arquitetos de sistemas de IA e os líderes das equipes de engenharia e segurança devem incorporar os requisitos de segurança dos agentes desde a concepção. Eles devem priorizar mecanismos verificáveis e determinísticos, como o isolamento de componentes, o controle das interações e a redução ao mínimo da base computacional confiável.

As principais decisões arquiteturais incluem definir o nível de autonomia aceitável para os agentes, limitar o acesso a dados confidenciais e a combinações perigosas de funcionalidades, além de utilizar sandboxes, atribuir funções distintas a diferentes modelos e implementar gateways de controle de acesso. Restrições adicionadas posteriormente podem reduzir os riscos, mas não substituem uma arquitetura segura.

Nos níveis organizacional e operacional, as empresas precisam manter um inventário de seus agentes, coordenar os esforços das equipes de segurança e implementação, proteger os ambientes de contêineres, gerenciar a cadeia de suprimentos (AIBOM) e integrar uma estratégia de defesa em várias camadas.

A observabilidade requer atenção especial. Em sistemas de IA, isso inclui registrar as solicitações, respostas e etapas de raciocínio do LLM, além de coletar dados detalhados de telemetria dos hosts e ambientes de nuvem nos quais a estrutura de execução do agente opera.

O maior desafio no projeto de agentes é encontrar o equilíbrio entre segurança, desempenho e utilidade. Para saber como encontrar esse equilíbrio por meio da modelagem de ameaças e da definição clara de objetivos de segurança, leia a versão completa do estudo.