Trate os Seus Agentes de IA Como Código Não Confiável

No momento em que o seu agente de IA consegue enviar um e-mail, consegue reencaminhar dados confidenciais. No momento em que consegue ler ficheiros, consegue exfiltrá-los. No momento em que consegue executar um fluxo de trabalho, pode ser sequestrado para executar um diferente.

Não é um hipotético. Em 2025 e 2026, foram atribuídas CVEs críticas ao Microsoft Copilot (CVSS 9.3), GitHub Copilot (CVSS 9.6) e Cursor IDE (CVSS 9.8) — todas a explorar a mesma fraqueza fundamental: agentes de IA a operar com confiança ambiente e sem fronteira de aplicação externa. A previsão de ameaças da Google identifica a injeção de prompt direcionada contra IA empresarial como um dos vectores de ataque de crescimento mais rápido em 2026.¹²

Já não estamos a executar experiências controladas. Os agentes estão em produção, a tocar dados sensíveis, a tomar ações reais. E a maioria das organizações está a protegê-los com as mesmas ferramentas que usaria para uma aplicação web. Esse é o modelo errado.

Por que as ferramentas de segurança tradicionais não conseguem proteger contra as ameaças dos agentes de IA?

Os controlos de segurança tradicionais são sintáticos. Uma firewall conhece IPs, portos e assinaturas de pacotes. Um sistema de detecção de intrusões conhece padrões reconhecidamente maliciosos. Nenhum deles tem qualquer ideia do que o agente de recrutamento pretende fazer quando inicia uma ligação HTTP a um servidor externo — se está a consultar um portal de emprego aprovado ou a reencaminhar dados de candidatos para o ponto de acesso de um atacante.

Não é possível resolver um problema semântico com ferramentas sintáticas.

O problema mais profundo é que os agentes não têm identidade inerente na maioria das implementações atuais. O padrão por defeito — o Modelo de Herança de Identidade — é que os agentes herdam as credenciais que pertencem ao humano ou à conta de serviço que os implementou. Sabe-se que têm uma chave API. Não se sabe qual instância específica de agente a está a usar, o que fez com os dados que acedeu, se o seu comportamento em tempo de execução foi adulterado via injeção de prompt, ou como revogar o acesso a um único agente sem perturbar toda a frota.³

A injeção de prompt — em que um adversário incorpora instruções em dados que o agente processa — tornou-se o equivalente funcional da execução remota de código. Quando um agente tem acesso a ferramentas, uma instrução maliciosa escondida num PDF, e-mail ou documento não corrompre apenas a saída do modelo. Executa com as permissões completas do agente, contra sistemas reais, com um registo de auditoria que reporta a ação como automatização legítima.⁴

Como é que a aplicação de proxy fora de banda se parece na prática?

Pedro Franceschi, CEO da Brex, articula o enquadramento correto: a segurança dos agentes é um problema de engenharia, não um impasse filosófico. A sua equipa construiu uma resposta chamada “crab trap” — um proxy HTTP que intercepta todo o tráfego das instâncias de agentes e o encaminha por um LLM separado que avalia cada ação face a uma política definida, depois bloqueando na camada de rede sem que o agente primário saiba que o controlo existe.

A frase-chave é sem que o agente primário saiba. É o posicionamento fora de banda que confere a esta arquitetura a sua força. Um agente não consegue raciocinar uma forma de contornar um controlo para o qual não tem visibilidade. Um ataque de injeção de prompt que compromete com sucesso o modelo primário não consegue instruir esse modelo a desactivar uma monitorização que não consegue percepcionar. O comprometimento do agente não produz automaticamente uma violação ao nível da rede.

O enquadramento de Franceschi mantém-se: não precisa de confiar no agente. Precisa de confiar no proxy e na topologia. Essas são coisas que consegue realmente engendrar e verificar.

Esta percepção está agora a ser validada à escala da indústria. A Cisco construiu um Proxy de Inspeção Semântica segundo os mesmos princípios — posicionado inline, analisando intenção em vez de padrões, avaliando se as ações dos agentes estão em conformidade com a política definida. O Entra Agent ID e o AI Gateway da Microsoft implementam o Prompt Shield na camada de rede, aplicando salvaguardas em todas as aplicações de IA sem alterações de código. O CNCF tem um projecto ativo que define um padrão Agent Gateway como ponto de aplicação de políticas para todo o tráfego de agentes.⁵⁶⁷

O padrão está a convergir: uma camada de proxy obrigatória entre os agentes e os sistemas que tocam.

Quais são as três camadas de segurança que têm de falhar todas para uma violação ter sucesso?

Uma arquitetura de segurança de agentes bem concebida não é um único controlo. São três camadas independentes, cada uma das quais tem de falhar independentemente para uma violação ter sucesso.

Camada 1: Aplicação de política semântica no proxy. Cada ação que um agente tenta é avaliada face a uma política definida por um segundo sistema de IA antes de alcançar a rede. A política é comportamental — “deve este agente de recrutamento estar a contactar este endereço externo?” — não apenas sintática. Criticamente, implemente isto como uma lista de permissões, não uma lista de bloqueio. Uma política de lista de permissões define o pequeno conjunto de ações aprovadas; tudo o resto é bloqueado por defeito. As políticas de lista de bloqueio falham abertas — lacunas na linguagem de política tornam-se exploráveis. As políticas de lista de permissões falham fechadas. Os profissionais da indústria que implementam agentes à escala chegam à mesma conclusão: “Aqui estão as 5 coisas que este agente pode fazer, e apenas estas” supera a tentativa de enumerar todas as ações más.⁸⁹

Camada 2: Isolamento de sub-rede. Sem aplicação de topologia de rede, o proxy é consultivo. Um agente mal configurado, um agente comprometido, ou um agente com uma injeção de prompt suficientemente criativa poderia potencialmente contorná-lo. Colocar os agentes numa sub-rede dedicada com regras de firewall que forçam todo o tráfego de saída a passar pelo proxy converte a arquitetura de opcional a obrigatória. Nenhum pacote sai do ambiente do agente sem travessia pelo proxy. Isto fornece também contenção do raio de impacto: um agente comprometido está topologicamente aprisionado. Pode enumerar outros agentes na sub-rede mas não consegue alcançar a infraestrutura corporativa ou sistemas externos sem autorização do proxy. O movimento lateral é limitado pela arquitetura, não apenas pela política.

Camada 3: Identidade por Ator e caminhos de tráfego diferenciados. Esta é a camada que move o padrão de conceção arquitetural de “algo veio da sub-rede de agentes” para “a Instância de Agente 7 do Jim o Recrutador fez exatamente estes 43 pedidos, 3 dos quais foram bloqueados às 14:32 UTC.” A identidade por Ator — implementada via certificados mTLS, JWTs de curta duração com âmbito para instâncias de tarefas individuais, ou atestado de carga de trabalho baseado em SPIFFE — desbloqueia quatro capacidades simultaneamente: política específica por função no proxy (o perfil de ações permitidas do Jim difere de um agente de fluxo financeiro), revogação granular sem perturbação da frota, registos de auditoria forenses atribuíveis a instâncias específicas, e detecção de ataques de personificação de agentes. A especificação MCP adoptou formalmente o OAuth 2.1 como seu enquadramento de autorização em março de 2025 especificamente para resolver este problema.¹⁰¹¹

Separar os caminhos de tráfego de agentes dos caminhos de tráfego humanos não é conveniência administrativa — é uma propriedade de segurança. Os Atores Humanos e os Atores AIgénicos têm perfis comportamentais, perfis de risco e conjuntos de ações apropriados fundamentalmente diferentes. A limitação de velocidade adequada para um humano (que não consegue fazer 10.000 chamadas API por segundo) não é adequada para uma frota de agentes. A detecção de anomalias calibrada para padrões humanos perderá abuso de agentes, e vice-versa. Misturar os dois caminhos degrada a qualidade da monitorização para ambos.

Como é o padrão de conceção arquitetural combinado na prática?

As propriedades que este padrão de conceção arquitetural entrega:

1. Segurança com a topologia em primeiro lugar. Nenhum agente é confiável em virtude da sua posição na rede — a topologia remove a confiança ambiente estruturalmente. Quer a credencial de um agente seja válida ou comprometida, a rede determina o que consegue alcançar.
2. Defesa em profundidade semântica + sintática + topológica. Três camadas independentes, cada uma com modos de falha diferentes.
3. Registo de auditoria atribuído por identidade. Não “a frota de agentes fez pedidos.” Instâncias de agentes específicas, ações específicas, bloqueios específicos.
4. Resiliência a injeção de prompt ao nível arquitetural. O comprometimento ao nível do modelo não produz automaticamente uma violação ao nível da rede.
5. Limites rígidos de raio de impacto. A topologia aplica a contenção independentemente de a sua política estar perfeitamente escrita.

A investigação sobre 300.000 prompts adversariais demonstra o efeito de combinação na prática: defesas básicas de prompt de sistema isoladas permitiram a passagem de 7% dos ataques. Adicionar inspeção de conteúdo reduziu para 0,2%. Adicionar detecção de injeção de prompt reduziu ainda mais para 0,003% — uma melhoria de 2.300 vezes com defesa por camadas.⁴

Quais são os limites honestos desta arquitetura?

Este padrão de conceção arquitetural tem duas limitações reais que vale a pena nomear.

O LLM monitor pode ser ele próprio visado. Um adversário que compreenda a sua política poderia elaborar pedidos concebidos para passar o filtro do monitor enquanto ainda alcança resultados prejudiciais. A resposta arquitetural é dupla: manter a política do monitor opaca ao agente primário (o posicionamento fora de banda já o consegue), e registar tudo de forma abrangente para que padrões visíveis apenas em agregado possam ser detectados retrospectivamente.

A completude da política é o problema mais difícil. O proxy só consegue bloquear o que a política cobre. É precisamente por isso que o princípio da lista de permissões é importante — uma lista de permissões estreita (“permitir apenas estas ações”) falha fechada quando encontra comportamento novo. Uma lista de bloqueio ampla (“bloquear estas coisas especificamente más”) falha aberta.

Por que a janela para construir esta arquitetura está a estreitar?

O OWASP Top 10 para Aplicações Agénticas, publicado em dezembro de 2025 por mais de 100 investigadores de segurança, identifica o Sequestro de Objetivo do Agente e o Abuso de Identidade e Privilégio como as principais ameaças que enfrentam os sistemas AIgénicos em produção. O prazo de agosto de 2026 do Regulamento de IA da UE para conformidade de IA de alto risco exige especificamente a demonstração de robustez contra injeção de prompt. A pressão regulatória e a realidade de produção estão a convergir no mesmo ponto.¹¹²

A percepção de Franceschi é correta: este é um problema de engenharia. O padrão de conceção arquitetural de proxy — aplicação semântica, isolamento de sub-rede, identidade por Ator — converte a imprevisibilidade do comportamento dos agentes num problema de contenção e verificação. Não tem de resolver a difícil questão de alinhamento de IA. Tem de construir uma fronteira em que pode confiar à volta de um agente que não consegue prever completamente.

Essa fronteira está disponível para construir hoje.

---

Revisto em 2026-04-27. Identidade por Ator substitui identidade por agente em contextos de governação; Atores Humanos e Atores AIgénicos capitalizados como classes ontológicas formais; segurança com a topologia em primeiro lugar substitui confiança zero para agentes na lista de cinco propriedades, reflectindo a distinção entre segurança com a topologia em primeiro lugar e atribuição de Confiança Zero — ver Governar Atores AIgénicos para o enquadramento autoritativo; padrão de conceção arquitetural substitui arquitetura como substantivo isolado. Conteúdo substantivo inalterado.

Footnotes

1. Prompt Injection: Types, Real-World CVEs, and Enterprise Defenses — CVEs críticas atribuídas em 2025-2026 incluindo EchoLeak, RCE no GitHub Copilot e vulnerabilidades do Cursor IDE que exploram agentes de IA com confiança ambiente. ↩ ↩²

2. AI Agent Security 2026: Google’s Forecast and How to Fix the Gaps — A Google prevê um aumento significativo de ataques de injeção de prompt direcionados contra sistemas de IA empresarial ao longo de 2026. ↩

3. Why AI Agents Need Zero Trust Identity (and How to Build It) — O OAuth foi concebido para humanos a delegar acesso a aplicações. O mTLS verifica ligações, não identidade de agentes. ↩

4. How to Deal with the 2026 Agent Wave — A injeção de prompt é agora um equivalente a execução remota de código. Quando os agentes têm acesso a ferramentas, injetar instruções em dados processados executa com as permissões completas do agente. ↩ ↩²

5. Redefining Zero Trust in the Age of AI Agents and Agentic Workflows — O Proxy de Inspeção Semântica da Cisco redefine a confiança zero com segurança baseada em intenção para ameaças potenciadas por IA. ↩

6. MCP and Zero Trust: Securing AI Agents with Identity and Policy — Como proteger agentes de IA com identidade, política e autorização de granularidade fina usando MCP e Confiança Zero. ↩

7. Zero-Trust Agent Architecture: How to Actually Secure Your Agents — O Entra Agent ID e o AI Gateway da Microsoft implementam o Prompt Shield na camada de rede. ↩

8. Denylist vs Allowlist for AI Agent Guardrails — Cada comportamento inesperado torna-se uma nova política que precisa de bloquear. A abordagem oposta — lista de permissões — supera à escala. ↩

9. Allowlists vs. Denylists in Multi-Tenant Access Control — As listas de permissões implementam comportamento de negação por defeito, enquanto as listas de bloqueio implementam comportamento de permissão por defeito. ↩

10. Zero Trust for AI Agents: Ephemeral Credentialing Blueprint — Reduzir a janela de exposição de credenciais de agentes de IA em mais de 99% com credenciais efémeras. ↩

11. What Developers Building with AI Agents Need to Know — O Projecto de Segurança GenAI da OWASP publicou o Top 10 para Aplicações Agénticas em dezembro de 2025. ↩

12. OWASP Top 10 for Agentic Applications — ASI01 Sequestro de Objetivo do Agente, ASI02 Uso Indevido de Ferramentas, ASI03 Abuso de Identidade e Privilégio identificados como principais ameaças. ↩