A Ameaça Oculta dos Agentes de IA Exige um Novo Modelo de Segurança

Os sistemas de IA agêntica tornaram-se mainstream nos últimos anos. Eles estão sendo usados para várias funções, incluindo autenticação de usuários, movimentação de capital, acionamento de fluxos de conformidade e coordenação em ambientes empresariais com supervisão humana mínima.

No entanto, um problema mais silencioso está surgindo com o aumento da autonomia, não no nível de prompts ou políticas, mas no nível de confiança na infraestrutura. Os sistemas agênticos estão sendo concedidos autoridade de insider enquanto ainda executam em ambientes de computação que nunca foram projetados para proteger os tomadores de decisão autônomos da infraestrutura abaixo deles.

A segurança tradicional assume que o software é passivo, mas os sistemas agênticos não são. Eles raciocinam, lembram e agem continuamente, autonomamente e com autoridade delegada.

Não se esqueça de que os agentes de IA provavelmente terão acesso a dados pessoais, com base em seu caso de uso, como e-mails e registros de chamadas, entre outras coisas.

Além disso, enquanto as proteções baseadas em hardware, como máquinas virtuais confidenciais e enclaves seguros, existem, elas ainda não são a base padrão para a maioria das implantações de IA agêntica. Como resultado, muitos agentes ainda executam em ambientes onde os dados sensíveis são expostos à infraestrutura subjacente durante a execução.

Agentes São Insiders, Não Ferramentas

As equipes de segurança já sabem o quão desafiador é conter ameaças de insider, um problema destacado no relatório de violação de dados da Verizon de 2025, que mostra que a intrusão de sistema foi responsável por mais de 53% das violações confirmadas no ano passado. Em 22% desses casos, os atacantes usaram credenciais roubadas para obter acesso, o que destaca o quão frequentemente eles têm sucesso usando identidades legítimas em vez de explorar falhas técnicas.

Agora, considere um agente, que é composto por lógica de prompt, ferramentas e plugins, credenciais, bem como políticas. Não apenas ele pode executar código e navegar na web, mas também pode consultar CRMs, ler e-mails e enviar tickets, entre muitas outras coisas. O que a combinação de funções trouxe é a superfície de ataque tradicional para uma interface moderna.

O perigo representado por tais ameaças de insider não é especulativo. O Open Web Application Security Project (OWASP) agora lista “Injeção de Prompt” como uma vulnerabilidade crítica para aplicações LLM, observando seu perigo particular para sistemas agênticos que encadeiam ações. A equipe de inteligência de ameaças da Microsoft também publicou avisos alertando que os sistemas de IA com acesso a ferramentas podem ser subvertidos para realizar o furto de dados se as salvaguardas não forem aplicadas arquiteturalmente.

Esses relatórios estão oferecendo um lembrete oportuno de que os agentes que têm acesso legítimo a sistemas e dados podem ser virados contra seus proprietários. No entanto, o panorama de risco para os sistemas agênticos não é unitário. Ameaças de camada de aplicativo, como injeção de prompt e abuso de ferramentas, decorrem da incapacidade do modelo de distinguir entre instruções confiáveis e entrada de usuário não confiável, uma limitação de design que nenhuma quantidade de endurecimento de memória pode consertar.

Um problema diferente e igualmente importante existe no nível da infraestrutura: alguns agentes executam em memória em texto puro, o que significa que informações sensíveis — como históricos de chat, respostas de API e documentos — podem ser vistas enquanto estão sendo processadas e podem permanecer acessíveis posteriormente. O OWASP identifica esse risco como Divulgação de Informações Sensíveis (LLM02) e Vazamento de Prompt do Sistema (LLM07) e sugere o uso de isolamento de contexto, segmentação de namespace e sandbox de memória como medidas de segurança importantes.

Portanto, os usuários não devem tratar esses agentes como apenas aplicativos, considerando que eles são executores dinâmicos e racionais que exigem um modelo de segurança que leve em conta sua natureza única como entidades não humanas com agência. Essa abordagem precisa incluir controles de software para limitar como o modelo age e proteções de hardware para manter os dados seguros enquanto estão sendo usados.

A Arquitetura da Confiança Tem um Flaw Crítico

As práticas de segurança atuais se concentram em proteger os dados em repouso e em trânsito. A fronteira final, os dados em uso, permanece quase inteiramente exposta. Quando um agente de IA raciocina sobre um conjunto de dados confidenciais para aprovar um empréstimo, analisar registros de pacientes ou executar uma negociação, esses dados geralmente são decifrados e processados em texto puro dentro da memória do servidor.

Nos modelos de nuvem padrão, qualquer pessoa com controle suficiente sobre a infraestrutura, incluindo administradores de hypervisor ou atacantes co-locatários, pode potencialmente olhar para o que está acontecendo enquanto uma carga de trabalho está em execução. Para os agentes de IA, essa exposição é especialmente perigosa, pois eles precisam acessar informações sensíveis para fazer seu trabalho, o que pode potencialmente se tornar a superfície de ataque.

Como a Lumia Security demonstrou, os atacantes com acesso a uma máquina local podem obter JWTs e chaves de sessão diretamente da memória do processo de aplicativos de desktop ChatGPT, Claude e Copilot. Essas credenciais roubadas podem permitir que eles sejam outro usuário, roubem o histórico de conversas e injetem prompts em sessões em andamento que podem alterar o comportamento do agente ou plantar falsas memórias.

Um exemplo disso pode ser o incidente de dump de memória do AWS CodeBuild em julho de 2025. Os atacantes adicionaram secretamente código malicioso a um projeto, e quando o sistema executou, o código olhou para a memória do computador e roubou tokens de login ocultos armazenados lá. Com esses tokens, os atacantes puderam alterar o código do projeto e potencialmente acessar outros sistemas.

Para as instituições financeiras, a manipulação silenciosa é existencial. Os bancos, seguradoras e firmas de investimento já absorvem custos médios de violação de dados superiores a $10 milhões, e eles entendem que a integridade importa tanto quanto a confidencialidade. De acordo com um relatório recente da Informatica, o “paradoxo da confiança” foi explicado como tal: as organizações estão implantando agentes autônomos mais rápido do que podem verificar suas saídas. O resultado é a automação que pode hardwire erros ou vieses diretamente em processos centrais, operando em velocidade de máquina.

Computação Confidencial e o Caso para Isolamento

Os consertos incrementais não resolverão o problema em questão, embora controles de acesso mais rigorosos e monitoramento melhor possam ajudar. No entanto, nenhum deles pode alterar o problema subjacente. O problema é arquitetônico, e desde que o cálculo ocorra em memória exposta, os agentes serão vulneráveis no momento em que mais importa, que é o raciocínio.

A computação confidencial, definida pelo Consórcio de Computação Confidencial (CCC) como a proteção de dados em uso por meio de Ambientes de Execução Confiáveis (TEEs) baseados em hardware, aborda diretamente a falha central.

Para os agentes de IA, esse isolamento baseado em hardware é transformador, pois permite que as credenciais de identidade do agente, seus pesos de modelo, prompts proprietários e os dados de usuário sensíveis que ele processa permaneçam criptografados, não apenas em um disco ou sobre uma rede, mas ativamente na memória durante a execução. A separação definitivamente quebra o modelo tradicional onde o controle sobre a infraestrutura garante o controle sobre a carga de trabalho.

A atestação remota fornece evidências criptográficas verificáveis de que um pedido de inferência específico foi executado dentro de um ambiente de execução confiável baseado em hardware, seja um CPU ou GPU. A prova é gerada a partir de medidas de hardware e entregue junto com a resposta, permitindo a verificação independente de onde e como a carga de trabalho foi executada.

Os registros de atestação não revelam o código que foi executado. Em vez disso, cada carga de trabalho é associada a um ID de carga de trabalho único ou ID de transação, e o registro de atestação do TEE é vinculado a esse identificador. A atestação confirma que o cálculo foi executado dentro de um ambiente confiável sem divulgar seu conteúdo.

A configuração cria uma nova base para conformidade e auditoria, permitindo a vinculação das ações do agente a uma versão específica de código que foi atestado e a um conjunto conhecido de dados de entrada.

Rumo à Autonomia Responsável

As implicações para o sistema descrito acima vão além da segurança básica. Considere as leis que regem a finanças, a saúde e as informações pessoais. Muitas jurisdições aplicam regras de soberania de dados que restringem onde as informações podem ser processadas. Na China, a Lei de Proteção de Informações Pessoais e a Lei de Segurança de Dados exigem que certas categorias de dados, como dados pessoais importantes, sejam armazenados domesticamente e revisados antes de serem transferidos para o exterior.

Da mesma forma, vários países do Golfo, como os Emirados Árabes Unidos e a Arábia Saudita, adotaram abordagens semelhantes, especialmente para dados financeiros, governamentais e de infraestrutura crítica.

A computação confidencial pode fortalecer a segurança e a auditoria protegendo os dados enquanto estão sendo processados e permitindo a atestação do ambiente de execução. No entanto, isso não muda onde o processamento ocorre. Onde as regras de soberania de dados exigem processamento local ou impõem condições para transferências transfronteiriças, os ambientes de execução confiáveis podem apoiar controles de conformidade, não substituir requisitos legais.

Além disso, a computação confidencial permite a colaboração segura em sistemas de multiagentes, onde os agentes de diferentes organizações ou departamentos frequentemente precisam compartilhar informações ou validar saídas sem expor dados proprietários.

E quando a tecnologia é combinada com uma arquitetura de confiança zero, o resultado é uma base muito mais forte. A confiança zero valida continuamente a identidade e o acesso, enquanto a computação confidencial protege a memória do hardware contra extração não autorizada e impede que informações sensíveis sejam recuperadas em texto puro.

Juntos, eles defendem o que realmente importa, por exemplo, lógica de decisão, entradas sensíveis e as chaves criptográficas que autorizam a ação.

Nova Linha de Base para Sistemas Autônomos

Se cada interação coloca as pessoas em risco de exposição, elas não permitirão que a IA lidere coisas como registros de saúde ou tome decisões financeiras. Da mesma forma, as empresas não automatizarão suas tarefas mais importantes se isso puder levar a problemas regulamentares ou perda de dados importantes.

Os construtores sérios reconhecem que os consertos da camada de aplicativo sozinhos são insuficientes em ambientes de alta garantia.

Quando os agentes são confiados com autoridade financeira, dados regulamentados ou coordenação interorganizacional, a exposição da infraestrutura se torna mais do que uma preocupação teórica. E sem execução confidencial nesses contextos, muitos agentes permanecem como alvos fáceis, com suas chaves passíveis de serem roubadas e sua lógica maleável. O tamanho das violações modernas mostra exatamente para onde esse caminho leva.

A privacidade e a integridade não são recursos opcionais a serem adicionados após o deploy. Elas devem ser projetadas a partir do silício para cima. Portanto, para que a IA agêntica possa escalar com segurança, a confidencialidade aplicada por hardware não pode ser considerada apenas como uma vantagem competitiva, mas como a base.