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

Os sistemas de IA agêntica se tornaram 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, embora existam proteções baseadas em hardware, como máquinas virtuais confidenciais e enclaves seguros, 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 foi superfícies de ataque tradicionais para uma interface moderna.

O perigo representado por essas 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 avisando que os sistemas de IA com acesso a ferramentas podem ser subvertidos para realizar o roubo de dados se as salvaguardas não forem arquitetonicamente impostas.

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 cenário 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 instruções confiáveis de 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 usar 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, dado que eles são executores dinâmicos e de raciocínio 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 de Confiança Tem uma Falha Crítica

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 transação, esses dados são normalmente 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-tenants, 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 se passem por outro usuário, roubem o histórico de conversa 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, o código espiou 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 é tão importante quanto a confidencialidade. De acordo com um relatório recente da Informatica relatório, o “paradoxo de 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 endurecer erros ou viés diretamente em processos principais, operando à velocidade da máquina.

Computação Confidencial e o Caso para Isolamento

Reparos incrementais não resolverão o problema em questão, embora controles de acesso mais rigorosos e uma melhor monitorização possam ajudar. No entanto, nem um nem outro podem alterar o problema subjacente. O problema é arquitetônico, e desde que a computação 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 baseados em hardware (TEEs), aborda diretamente a falha fundamental.

Para os agentes de IA, esse isolamento de nível de 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 processam 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 em que 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 juntamente 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 ou ID de transação exclusivo, e o registro de atestação do TEE é vinculado a esse identificador. A atestação confirma que a computação foi executada dentro de um ambiente confiável sem divulgar seu conteúdo.

A configuração cria uma nova base para conformidade e auditoria, permitindo que as ações de um agente sejam vinculadas a uma versão específica de código que foi atestada 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, por exemplo, 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 tempo de execução. No entanto, isso não altera 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 fizerem isso puder levar a problemas regulamentares ou à perda de dados importantes.

Os construtores sérios reconhecem que as correções de camada de aplicativo sozinhas 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 roubáveis e sua lógica maleável. O tamanho das violações de dados modernas mostra exatamente para onde leva esse caminho.

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