Os agentes de IA estão a deixar de ser interlocutores para se tornarem operadores. Quando passam a deter credenciais, contexto e autonomia, o perímetro de segurança já não se declara — comprova-se.

Um cenário cada vez mais comum

Um survey recente publicado por investigadores do Imperial College London — When Agents Handle Secrets: A Survey of Confidential Computing for Agentic AI, de Forough, Kogias e Haddadi (Maio de 2026) — sistematiza este problema e propõe um caminho. A tese central é que a superfície de ameaça da IA agêntica difere materialmente da chamada isolada a um modelo, e que as defesas atuais, focadas no software, podem ser contornadas por um adversário com privilégios suficientes — por exemplo, um operador de cloud comprometido.

Neste texto, proponho-me descodificar as conclusões deste estudo e cruzar a teoria com a minha experiência e perspetiva técnica sobre este assunto.

Imagine-se a seguinte situação: um agente de IA recebe acesso ao sistema de gestão empresarial, à caixa de correio corporativa e a uma pasta partilhada com informação financeira. O objetivo é legítimo — automatizar conciliações, redigir respostas a fornecedores, preparar relatórios, etc. O agente cumpre. Os resultados aparecem.

Raramente se coloca a pergunta mais importante: quem controla, na realidade, o ambiente onde esse agente está a correr?

A resposta honesta, na maioria dos casos, é desconfortável. O agente corre num datacenter de terceiros, sobre um sistema operativo que ninguém da organização auditou. As defesas em que se confia — encriptação, autenticação multifactor, controlo de acessos — operam todas na camada de software. E essa camada pode ser silenciosamente comprometida por quem tenha controlo privilegiado sobre o que está por baixo.

De interlocutor a operador: o salto qualitativo

É importante estabelecer uma distinção que costuma passar despercebida.

Nas chamadas isoladas aos modelos — o uso clássico de LLM — o ciclo é fechado: faz-se uma pergunta, recebe-se uma resposta, encerra-se a sessão. A superfície de ataque é contida.

Na IA agêntica, o ciclo abre-se. O agente planeia, invoca ferramentas externas, mantém memória persistente entre sessões e delega tarefas a outros agentes através de protocolos como MCP (Model Context Protocol) e A2A (Agent-to-Agent). Acumula contexto sensível ao longo do tempo, detém credenciais para aceder a sistemas, e opera em meios distribuídos que nenhuma das partes envolvidas controla na totalidade. Falta um maestro.

Esta diferença não é gradual, é qualitativa. Um agente que retém memória entre sessões deixa de ser uma ferramenta para se tornar um ator — e a auditabilidade de um ator autónomo coloca exigências diferentes das que se aplicam a uma ferramenta: não é só examinar como foi construído, mas reconstruir o que decidiu fazer, quando, e com que informação. Como consequência o modelo de ameaça muda.

Cinco vetores que alteram o jogo

O referido survey do Imperial College London identifica um conjunto de vetores de ataque que merecem atenção particular por parte de quem decide e gere as arquiteturas de IA empresarial.

1. Injeção de instruções (prompt injection). Manipulação do raciocínio do agente através de entradas não confiáveis — um documento, um e-mail, uma página web — que contêm instruções dissimuladas. Quando o agente tem capacidade de ação sobre sistemas reais, o impacto deixa de ser apenas conversacional e passa a ser operacional.

2. Exfiltração de contexto. Fuga da informação persistente que o agente acumulou ao longo de sessões anteriores. Pode incluir excertos de documentos, identificadores de clientes, decisões internas — tudo o que ficou em memória para sustentar o trabalho continuado.

3. Roubo de credenciais. Um agente que detém acessos a sistemas críticos — ERP, e-mail, bases de dados, APIs — torna-se um alvo de elevado valor. Comprometer um agente pode dar acesso lateral a múltiplos sistemas, sem necessidade de comprometer cada um isoladamente.

4. Envenenamento de mensagens entre agentes. Quando agentes comunicam entre si como pares (peer-to-peer) via MCP ou A2A, a cadeia de confiança torna-se difícil de auditar. Uma mensagem maliciosa introduzida algures na cadeia pode propagar-se e influenciar decisões posteriores sem deixar rasto nos logs tradicionais.

5. Operador de infraestrutura comprometido. O cenário mais incómodo. Um administrador da plataforma cloud, ou um ator que tenha comprometido o hypervisor, ou o sistema operativo host, pode aceder à memória do agente em execução. Nenhuma defesa de software pode impedir este tipo de ataque, porque opera abaixo da camada onde as defesas vivem.

Os primeiros quatro vetores já estão documentados em incidentes públicos. O quinto era, até há pouco tempo, tratado como hipótese teórica. Deixou de o ser no momento em que se entrega a um agente o acesso a dados regulados.

A solução proposta: computação confidencial

A computação confidencial (confidential computing) propõe deslocar o perímetro de confiança da camada de software para a camada de hardware. Assenta em duas peças complementares.

A primeira são os TEEs (Trusted Execution Environments), ambientes de execução isolados ao nível do processador. O código e os dados que correm dentro de um TEE ficam protegidos não só de outros processos, mas também do próprio sistema operativo, do hypervisor e de quem administra a máquina física. Mesmo um operador com privilégios de root não consegue ler a memória protegida pelo TEE.

A segunda é a prova de integridade remota (remote attestation). Um mecanismo criptográfico que permite a uma entidade externa verificar se o ambiente de execução do agente corresponde, de facto, ao anunciado — mesma versão de código, mesma configuração, mesmo hardware. Sem esta prova de integridade, o isolamento perde a maior parte do valor.

O survey compara seis plataformas de TEE com maturidade comercial: Intel SGX, Intel TDX, AMD SEV-SNP, ARM TrustZone, ARM CCA e NVIDIA H100 CC. Este último, que não pode ser vendido livremente à China, merece nota particular: é a primeira oferta de TEE em GPU (Graphics Processing Unit) com escala suficiente para correr inferência de modelos de linguagem de grande dimensão, o que abre a porta a cenários antes impossíveis — proteger não apenas o estado do agente, mas também o próprio modelo e os dados em processamento.

O que ainda está por resolver

Seria precipitado tratar a computação confidencial como uma solução fechada. O survey é explícito quanto aos desafios que permanecem em aberto, e três deles podem influenciar decisões de arquitetura nos próximos meses.

O primeiro é a prova de integridade composta (compound attestation) em cadeias de agentes com múltiplos saltos. Provar a integridade de um ambiente protegido isolado é problema resolvido; fazer o mesmo numa cadeia de cinco agentes que se invocam mutuamente, alguns em plataformas diferentes, é ainda matéria de investigação ativa.

O segundo é o desempenho de TEEs em GPU à escala dos LLMs (Large Language Models). As penalizações de desempenho podem ser proibitivas para casos de uso produtivos com latência exigente, e a relação custo/benefício precisa de ser avaliada caso a caso.

O terceiro é mais estrutural: não existe ainda uma framework completa e consolidada, que ligue estas peças de hardware numa infraestrutura de segurança coerente para IA agêntica em produção. Não há ainda um produto integrado pronto a adotar.

Impacto para quem decide

Três pontos merecem reflexão para quem define arquiteturas de IA empresarial.

Em primeiro lugar, princípios consolidados em ambientes financeiros e em sistemas críticos — segregação de funções, princípio do menor privilégio, auditabilidade — precisam de ser repensados quando o ator em causa é um agente autónomo com credenciais persistentes. Os controlos desenhados para utilizadores humanos não podem ser transpostos de forma automática.

Em segundo lugar, o modelo de ameaça do operador de infraestrutura comprometido pode deixar de ser hipótese aceitável a partir do momento em que se confia a um agente o tratamento de dados pessoais, informação financeira, matéria sujeita a sigilo profissional ou assuntos de defesa. Não é alarmismo; é alinhamento com obrigações regulatórias existentes.

Em terceiro lugar, a pergunta sobre que arquitetura adotar. Onde antes bastava escolher o modelo e definir os dados a processar, passa a ser necessário responder também a em que hardware corre o agente, e como se comprova essa execução a um auditor. A resposta a esta última pergunta deixou de ser opcional para certas classes de aplicação.

A computação confidencial, de forma isolada, não resolve o desafio da IA agêntica segura. Resolve uma classe específica e importante de problemas — aquela em que o software, por mais bem desenhado que esteja, simplesmente não chega. Para o resto, continua a ser necessária maturidade nos processos, clareza nos modelos de ameaça, e disciplina nas decisões de adoção.

A pergunta que fica em aberto, e que talvez valha a pena discutir em comentário: quantas organizações que estão a integrar agentes nos seus sistemas têm conhecimentos para discutir esta classe de risco com os seus auditores?

Para discutir, comente o post no LinkedIn ou contacte-me diretamente.

Glossário de acrónimos

• A2A — Agent-to-Agent. Protocolo de comunicação entre agentes de IA pares.
• AMD SEV-SNP — Secure Encrypted Virtualization — Secure Nested Paging. Plataforma de computação confidencial da AMD, baseada em encriptação de memória ao nível da máquina virtual.
• API — Application Programming Interface. Interface programática para integração entre sistemas.
• ARM CCA / TrustZone — Confidential Compute Architecture (orientada a servidores) e TrustZone (isolamento de execução predominante em dispositivos móveis e sistemas embebidos). Plataformas de computação confidencial da ARM.
• CC — Confidential Computing. Computação confidencial.
• ERP — Enterprise Resource Planning. Sistema de gestão empresarial integrado.
• GPU — Graphics Processing Unit. Unidade de processamento gráfico, hoje usada extensivamente para cargas de IA.
• IA — Inteligência Artificial.
• Intel SGX / TDX — Software Guard Extensions (enclaves seguros ao nível da aplicação) e Trust Domain Extensions (computação confidencial ao nível da máquina virtual). Plataformas de computação confidencial da Intel.
• LLM — Large Language Model. Modelo de linguagem de grande dimensão.
• MCP — Model Context Protocol. Protocolo de comunicação entre agentes de IA e ferramentas externas.
• NVIDIA H100 CC — Confidential Computing na arquitetura H100. Primeira oferta de computação confidencial em GPU com escala adequada a cargas de LLM.
• TEE — Trusted Execution Environment. Ambiente de execução isolado ao nível do processador.

Reference: Forough, J., Kogias, M., & Haddadi, H. (2026). When Agents Handle Secrets: A Survey of Confidential Computing for Agentic AI. arXiv:2605.03213. https://arxiv.org/abs/2605.03213 — PDF: 2605.03213v2.pdf