O Padrão de Proxy Semântico

Resumo Executivo

Os agentes de IA autónomos que operam em ambientes empresariais criam uma classe de problemas de segurança que os controlos existentes não foram concebidos para resolver. A segurança de rede tradicional é sintática — opera sobre IPs, portos e assinaturas de pacotes sem capacidade para avaliar a intenção por detrás de um pedido. Os agentes de IA operam semanticamente — as suas ações transportam significado, contexto e risco que apenas a avaliação semântica consegue aferir. A incompatibilidade entre o modelo de ameaça e o conjunto de ferramentas disponível é a causa raiz da maioria das falhas de segurança atuais de agentes.

Este documento apresenta uma arquitetura de referência de três camadas para autorização de agentes empresariais construída em torno de uma camada de proxy semântico obrigatório. A arquitetura baseia-se na implementação “crab trap” da Brex, na validação da indústria por parte da Cisco, Microsoft e CNCF, na investigação formal sobre enquadramentos de identidade de confiança zero para agentes, e em dados de implementação em produção em ambientes de saúde. As três camadas — aplicação de política semântica no proxy, isolamento de sub-rede a impor a travessia pelo proxy, e identidade por agente com caminhos de tráfego diferenciados — abordam vectores de ameaça independentes e compõem-se em eficácia. Quando as três camadas são implementadas em conjunto, o raio de impacto de um agente comprometido é limitado pela topologia, o registo de auditoria forense é atribuível a instâncias específicas, e um comprometimento ao nível do modelo não pode automaticamente produzir uma violação ao nível da rede.

1. O Modelo de Ameaça

Por que a injeção de prompt funciona como execução remota de código para agentes de IA?

A injeção de prompt — incorporar instruções maliciosas em dados processados por um agente de IA — não tem análogo direto nas taxonomias de vulnerabilidade tradicionais, mas os seus efeitos funcionais assemelham-se mais à execução remota de código. Quando um agente com acesso a ferramentas processa uma instrução maliciosa (num documento, e-mail, página web ou resposta de API), essa instrução executa com as permissões completas do agente. O registo de auditoria regista a ação como automatização legítima. A detecção de endpoint padrão não a apanha.¹

A superfície de ataque estende-se além das interfaces de chat. Qualquer dado ingerido por um agente — entradas de pipeline RAG, conteúdo de e-mail, anexos de ficheiros, resultados de consultas a bases de dados, respostas de APIs a montante — é um potencial vector de injeção. À medida que os agentes são ligados a mais sistemas e recebem acesso mais amplo a ferramentas, cada nova integração estende esta superfície.²

O ritmo de exploração acelerou. Em 2025 e 2026, foram atribuídas CVEs críticas nas principais plataformas de assistência à programação com IA: EchoLeak (CVE-2025-32711), RCE do GitHub Copilot (CVE-2025-53773, CVSS 9.6) e vulnerabilidades do Cursor IDE (CVSS 9.8). A investigação de ameaças da Google prevê um aumento significativo de ataques de injeção de prompt direcionados contra sistemas de IA empresarial ao longo de 2026, com as organizações de maior risco sendo as que ligaram agentes a sistemas internos sensíveis sem monitorização de ações em tempo real.³²

Qual é a lacuna de identidade nas implementações atuais de agentes?

A maioria das implementações de agentes partilha chaves API entre instâncias de agentes ou atribui uma única conta de serviço a uma função de agente — uma instância do Modelo de Herança de Identidade, em que os agentes herdam a identidade e as permissões do seu principal em vez de deterem identidades explicitamente aprovisionadas próprias. Esta arquitetura tem quatro fraquezas críticas:⁴

Sem atribuição ao nível da instância. Não é possível determinar a partir dos registos qual instância específica de agente fez um dado pedido. A investigação forense de um incidente fica limitada a “a frota de agentes fez estes pedidos” em vez de “a Instância de Agente 7 do fluxo de recrutamento, gerada às 14:22 UTC, fez estes 43 pedidos.”

Sem revogação granular. Revogar um agente comprometido requer a rotação de credenciais que podem ser partilhadas em dezenas ou centenas de instâncias, causando perturbação em toda a frota.

Risco de personificação. Sem identidade criptográfica por agente, um agente pode fazer pedidos que parecem originar de outro. Isto é particularmente perigoso em arquiteturas de múltiplos agentes em que os orquestradores delegam tarefas a agentes especializados.

Credenciais estáticas e sobredotadas de privilégios. As chaves API e contas de serviço são tipicamente de longa duração e com âmbito de permissões amplas. Um agente que executa cinco minutos detém credenciais que permanecem válidas horas ou dias após a conclusão da tarefa.⁵

O OWASP Top 10 para Aplicações Agénticas (dezembro de 2025) identifica o Abuso de Identidade e Privilégio (ASI03) como uma das principais ameaças aos sistemas AIgénicos. O OWASP Top 10 para Aplicações LLM 2025 expandiu substancialmente a entrada de Agência Excessiva (LLM06) para cobrir tomada de decisão autónoma, cadeias de ações em múltiplos passos e delegação entre agentes, identificando especificamente o risco composto em cada passo da cadeia de confiança delegada.⁶⁷

Qual é o problema de confiança ambiente nos ambientes empresariais de agentes?

A segurança de perímetro tradicional concede confiança implícita às entidades dentro do limite da rede. Um agente a executar dentro da rede corporativa herda o nível de confiança do seu ambiente de execução. Se esse ambiente tem acesso a sistemas sensíveis, o agente também tem — não porque um humano tomou uma decisão de autorização deliberada, mas porque ninguém tomou uma decisão explícita de o restringir.

Os princípios de confiança zero — nunca confiar, verificar sempre, menor privilégio — aplicam-se diretamente aos agentes, mas a maioria das implementações de agentes viola os três em simultâneo. O agente é confiável em virtude da sua posição na rede. Cada chamada não é verificada; o estabelecimento de sessão foi verificado, não a ação individual. As permissões têm âmbito para o que o agente poderá concebidamente precisar, não para o que a tarefa específica requer.⁸

2. Por Que os Controlos Existentes Falham

Por que os controlos de rede sintáticos falham contra ameaças semânticas de agentes?

As firewalls tradicionais e os sistemas de detecção de intrusões operam sobre dados ao nível do pacote: IP de origem, IP de destino, porto, protocolo e assinaturas de payload correspondentes a padrões reconhecidamente maliciosos. Não têm capacidade para avaliar o que um pedido HTTPS válido para api.openai.com pretende realizar. Um agente a exfiltrar dados através de um endpoint API aprovado parece idêntico ao tráfego legítimo na camada sintática.

As soluções SASE e Firewall de Nova Geração fornecem categorização de URL e identificação de aplicações, mas estas operam sobre destinos, não sobre intenção. Bloquear o destino bloqueia o caso de uso legítimo juntamente com o malicioso.

Por que o RBAC/ABAC falha na autorização de ações de agentes?

Os modelos de Controlo de Acesso Baseado em Funções e Controlo de Acesso Baseado em Atributos foram concebidos para identidades estáveis a fazer pedidos de acesso previsíveis e enumeráveis. Os agentes de IA são não-determinísticos — a mesma instância de agente pode gerar sequências de ações diferentes a partir de entradas idênticas. O RBAC atribui uma função com um conjunto de permissões; não consegue avaliar se uma ação específica dentro desse conjunto de permissões é apropriada dado o contexto e tarefa atuais.

Um agente com a função “remetente-de-email” consegue enviar e-mails. Se deve enviar este e-mail, a este destinatário, com este conteúdo, neste momento neste fluxo de trabalho — essa é uma questão semântica que o RBAC não consegue responder.

Por que as salvaguardas incorporadas no modelo primário são insuficientes?

As salvaguardas de prompt de sistema e os comportamentos de recusa ajustados no modelo do agente primário são probabilísticos, não determinísticos. A investigação sobre 300.000 prompts adversariais demonstra que as defesas básicas de prompt de sistema isoladas permitem a passagem de 7% dos ataques. Esta não é uma taxa de falha aceitável para sistemas em produção com acesso a dados sensíveis ou ações reais.¹

De forma mais fundamental, as salvaguardas incorporadas no modelo primário são vulneráveis ao ataque que pretendem prevenir. A injeção de prompt que manipula com sucesso o contexto do modelo pode instruí-lo a ignorar as suas salvaguardas. Colocar o controlo de segurança dentro da entidade que está a ser atacada é arquiteturalmente incorreto. O princípio correto é que a autorização deve ocorrer em sistemas externos em vez de ser delegada ao LLM.⁹

3. O Padrão de Conceção Arquitetural de Referência

Camada Um: Como o proxy semântico avalia e aplica as ações dos agentes?

O proxy semântico é um proxy HTTP posicionado entre todas as instâncias de agentes e a rede externa. Cada pedido de saída de qualquer instância de agente passa pelo proxy antes de alcançar o seu destino. O proxy submete cada pedido — juntamente com a identidade do agente que faz o pedido, o contexto de política atual e o histórico de sessão relevante — a um LLM de avaliação de política separado (o “monitor”). O monitor avalia se a ação é consistente com a função definida do agente, o contexto da tarefa atual e a política declarada da organização. As ações que passam são reencaminhadas; as ações que falham são bloqueadas e registadas.

A importância arquitetural do posicionamento fora de banda não pode ser subestimada. O agente primário não sabe que o proxy existe. Não consegue raciocinar sobre, contornar ou negociar com um controlo que não consegue percecionar. Um ataque de injeção de prompt que compromete com sucesso o seguimento de instruções do modelo primário não consegue instruir o modelo a desactivar uma monitorização para a qual não tem visibilidade. A superfície de ataque exposta ao agente primário não inclui o limite de segurança.

É isto que Franceschi da Brex quer dizer com “problema de engenharia, não impasse filosófico”: não precisa que o agente primário seja de forma fiável seguro. Precisa que o proxy seja de forma fiável aplicado. A segurança no modelo primário é desejável. A aplicação no proxy é uma propriedade determinante.

Conceção de política: lista de permissões, não lista de bloqueio. A política do monitor deve ser estruturada como uma lista de permissões — um conjunto definido de ações permitidas, com tudo o resto bloqueado por defeito — em vez de uma lista de bloqueio de ações proibidas. Esta é a escolha de conceção crítica:

• As políticas de lista de permissões falham fechadas: quando o proxy encontra uma ação não coberta pela política, bloqueia-a. Os vectores de ataque novos que o autor da política não antecipou são bloqueados por defeito.
• As políticas de lista de bloqueio falham abertas: quando o proxy encontra uma ação não explicitamente bloqueada, permite-a. Cada lacuna na linguagem de política é um potencial caminho de exploração.

O princípio está estabelecido na segurança de rede — as listas de controlo de acesso com “negar tudo” implícito no final implementam semântica de lista de permissões — e aplica-se diretamente à política semântica. O custo operacional é um processo de criação de política mais deliberado: as equipas devem especificar o que os agentes têm permissão para fazer, não apenas enumerar coisas más. Isto produz agentes melhores como efeito secundário: um agente restringido a cinco ações permitidas executa essas ações de forma mais previsível do que um com permissões amplas.¹⁰¹¹

Componentes de implementação:

LLM de Avaliação de Política: Uma instância de modelo separada, operacionalmente independente da frota de agentes primária, com o seu próprio prompt de sistema a definir critérios de avaliação. O prompt de sistema do modelo de avaliação e as definições de política não são acessíveis aos agentes primários. Este modelo avalia ações individuais, não o histórico completo da conversa, para minimizar os requisitos de janela de contexto e latência.

Contexto de sessão: O proxy mantém o estado de sessão — a sequência de ações tomadas por uma dada instância de agente na execução da tarefa atual. Isto permite a detecção de padrões que são individualmente permissíveis mas coletivamente anómalos (por exemplo, um agente que lê 50 registos, formata-os num documento estruturado e depois tenta enviar um e-mail está a exibir um padrão consistente com exfiltração, mesmo que cada ação individual passasse uma verificação pontual).

Registo estruturado: Cada pedido é registado com contexto completo: identidade do agente, tipo de ação, destino, resultado da avaliação de política, motivo do bloqueio se aplicável, e timestamp. Os registos são escritos num repositório imutável que os agentes não conseguem aceder nem modificar.

Implementações da indústria: O Proxy de Inspeção Semântica da Cisco implementa este padrão inline, convertendo cada mensagem de agente num resumo estruturado de função, ação pretendida e conformidade com regras definidas. O Prompt Shield do AI Gateway Entra da Microsoft implementa avaliação semântica na camada de rede para todo o tráfego de aplicações de IA. O Agentgateway da Solo.io fornece uma implementação em Rust com proxy MCP, proxy A2A e proxy LLM unificados sob um único plano de controlo. O AI Gateway da Gravitee (v4.10) fornece proxy LLM e proxy MCP que em conjunto formam um AI Gateway a governar todas as interações de agentes.^12131415

Camada Dois: Como o isolamento de sub-rede torna obrigatória a travessia pelo proxy?

Sem aplicação de topologia de rede, o proxy é um controlo consultivo. Um agente mal configurado poderia ser implementado com o seu tráfego a contorná-lo. Um ataque de injeção de prompt sofisticado que de alguma forma obtivesse conhecimento da arquitetura poderia teoricamente tentar alcançar caminhos não proxiados. A profundidade de defesa requer tornar a travessia pelo proxy obrigatória, não opcional.

O isolamento de sub-rede converte o proxy de consultivo a obrigatório ao torná-lo o único caminho de saída disponível para o tráfego de agentes:

Conceção da sub-rede de agentes:

• Todos os ambientes de execução de agentes (contentores, VMs, funções serverless) são colocados numa sub-rede dedicada ou segmento VPC
• Regra de saída por defeito: negar todo o tráfego de saída da sub-rede de agentes
• Única saída permitida: tráfego de saída para o proxy nas portas definidas
• Regras de firewall aplicadas na camada do hipervisor ou dispositivo de rede, fora do controlo de qualquer instância de agente

Contenção do raio de impacto: Uma instância de agente comprometida aprisionada na sub-rede de agentes consegue enumerar outros anfitriões nessa sub-rede. Não consegue alcançar a rede corporativa, bases de dados internas, recursos acessíveis a humanos ou sistemas externos exceto através do proxy. O raio de impacto de um comprometimento completo de agente é limitado pelo que o proxy permite — que é limitado pela política de lista de permissões.

Restrição de movimento lateral: Sem isolamento de sub-rede, um agente comprometido com acesso à rede pode sondar sistemas internos, tentar ataques de força bruta de credenciais contra serviços internos, ou fazer pivô para outras partes da infraestrutura. O isolamento de sub-rede torna tudo isto topologicamente impossível antes de qualquer avaliação de política ocorrer. A defesa não depende de o proxy identificar e bloquear corretamente tentativas de movimento lateral — a rede não as encaminhará.

Sinal de detecção de anomalias: O limite da sub-rede torna o tráfego de agentes instrumentalizável como um sinal distinto. Picos inesperados no volume de tráfego de saída, padrões de destino incomuns ou atividade fora do horário a partir da sub-rede de agentes são claramente atribuíveis à atividade dos agentes em vez de se afundar no ruído geral do tráfego corporativo. Esta melhoria de qualidade de sinal compõe-se com a camada de identidade por agente.

Referência de implementação: Uma implementação em produção em cuidados de saúde documentada em arXiv (2026) implementa isto como políticas de saída de rede a restringir cada agente a destinos incluídos em lista de permissões, combinadas com isolamento de carga de trabalho ao nível do kernel usando gVisor no Kubernetes. A especificação de normas agénticas nativas da cloud do CNCF (2026) recomenda explicitamente malhas de serviço, NetworkPolicy do Kubernetes e API gateways como aplicação em camadas para isolamento de agentes.¹⁶¹⁷

Camada Três: Como a identidade criptográfica por Ator permite auditoria e revogação ao nível da instância?

As duas primeiras camadas estabelecem o quê e onde; a terceira estabelece quem. A identidade por Ator move o padrão de conceção arquitetural de “a sub-rede de agentes fez pedidos” para “a Instância de Agente 7, atribuída ao fluxo de recrutamento, a executar a requisição de emprego 42, fez estes pedidos específicos.”

Modelos de identidade:

Atestado de carga de trabalho SPIFFE/SPIRE: O enquadramento SPIFFE emite identidades criptográficas (SVIDs) a cargas de trabalho com base em atestado em tempo de execução em vez de segredos pré-partilhados. Um contentor de agente que arranca recebe um certificado de identidade único válido apenas durante o seu tempo de execução. Quando termina, a identidade expira. Isto resolve o problema do “segredo zero” — não há credencial estática a proteger, porque a credencial só existe enquanto a carga de trabalho existe.⁵

Tokens JWT de curta duração: Um mediador de identidade emite JWTs para instâncias de agentes no momento de geração, com âmbito para a tarefa específica e válidos apenas pela duração esperada da tarefa (minutos, não horas). O JWT contém afirmações que identificam a função do agente, a instância de tarefa específica e o âmbito permitido de ações. O proxy valida o JWT em cada pedido — não apenas no estabelecimento de sessão.¹⁸

Certificados mTLS por agente: O TLS mútuo com certificados por agente fornece verificação criptográfica da identidade do agente na camada de transporte. Um agente que apresenta um certificado não no repositório de confiança do proxy é rejeitado antes de qualquer avaliação semântica ocorrer.

Política por Ator no proxy: Uma vez que o proxy consegue distinguir o Agente Jim (o agente de recrutamento) do Agente Finanças (o agente de contas a pagar), consegue aplicar políticas de lista de permissões distintas a cada um. A política do Jim permite: consulta ATS, relay de e-mail aprovado, fontes de dados de candidatos definidas. A política de Finanças permite: operações de leitura ERP, fluxos de pagamento aprovados, sistemas de relatórios financeiros. Nenhuma política permite as ações do outro agente. As políticas são mantidas centralmente e atualizadas sem reimplementar agentes.

Revogação e quarentena: Quando uma instância de agente exibe comportamento anómalo — volume de pedidos incomum, destinos fora do seu padrão normal, ações próximas dos limites de política em sequências incomuns — a sua credencial de identidade pode ser revogada. O próximo pedido dessa instância falha no proxy com um 401. O resto da frota continua a operar. Esta granularidade não está disponível sem identidade por agente.

Caminhos de tráfego diferenciados: O tráfego de agentes e o tráfego humano devem percorrer a rede através de caminhos separados com controlos adequados a cada população:

Propriedade	Tráfego de Ator Humano	Tráfego de Ator AIgénico
Identidade	SSO / MFA	JWT por instância / certificado mTLS
Política de saída	Acesso baseado em função a serviços aprovados	Lista de permissões estreita específica de tarefa
Limitação de velocidade	Escala humana (segundos/minutos)	Escala de agente (milissegundos), por instância
Detecção de anomalias	Linhas de base comportamentais para padrões humanos	Linhas de base comportamentais para padrões de Ator
Registo de auditoria	ID de utilizador, sessão, ação	ID de Ator, instância, tarefa, ação, motivo de bloqueio
Âmbito de revogação	Conta de utilizador	Instância de Ator individual

Misturar o tráfego de agentes e o tráfego humano na mesma infraestrutura de monitorização degrada a qualidade de detecção para ambos. A detecção de anomalias calibrada para humanos gerará falsos positivos constantes contra o tráfego de agentes (os agentes movem-se à velocidade da máquina). Os controlos calibrados para agentes serão demasiado restritivos para humanos. As populações têm perfis de risco diferentes e requerem controlos diferentes.¹⁹

Normas da indústria: As normas agénticas nativas da cloud do CNCF (2026) apelam especificamente a mTLS, encaminhamento com conhecimento de identidade e políticas de autorização para impor comunicação segura entre agentes além dos limites de confiança. O OWASP Top 10 para Aplicações LLM 2025 recomenda explicitamente que a autorização ocorra em sistemas externos em vez de ser delegada ao LLM. A adoção da especificação MCP do OAuth 2.1 em março de 2025 fornece a base de normas para credenciais por agente em enquadramentos de agentes com uso de ferramentas. O Azure AI Foundry da Microsoft demonstra agentes a transportar tokens JWT através do fluxo de credenciais de cliente OAuth2 para cada ação.^1792018

4. Análise de Ameaças Face à Arquitetura

Como a arquitetura defende contra a injeção de prompt?

Ataque: Um documento malicioso instrui o agente a enviar todos os dados de sessão para um endpoint externo controlado pelo atacante.

Defesa: A tentativa do agente de iniciar uma ligação de saída para o endpoint externo é intercetada no proxy. O modelo de avaliação de política avalia: “Deve o agente de recrutamento estar a enviar tráfego para este endereço externo nunca antes visto não na sua lista de destinos aprovados?” Resposta: Não. Ação bloqueada. O comprometimento ao nível do modelo do agente não se propaga para a rede.

Risco residual: O LLM monitor avalia a ação, não o estado interno do agente. Se o atacante elaborar uma ação que parece estar em conformidade com a política enquanto é subtilmente prejudicial (por exemplo, exfiltrar dados através de um destino aprovado ao codificá-los em parâmetros de consulta), o proxy poderá não o apanhar. Mitigação: análise de contexto de sessão para padrões comportamentais, registo abrangente para detecção retrospetiva.

Como a arquitetura defende contra o movimento lateral?

Ataque: Um agente comprometido tenta sondar sistemas internos (servidores de bases de dados, repositórios de credenciais, outros endpoints de gestão de agentes) para encontrar oportunidades de exploração adicionais.

Defesa: As regras de saída da sub-rede de agentes negam todo o tráfego exceto para o proxy. Os pacotes de sondagem do agente nunca alcançam os sistemas internos — são descartados na firewall antes de alcançarem o proxy. Este é um controlo topológico, não um controlo de política. Não depende de o proxy reconhecer a tentativa de movimento lateral.

Como a arquitetura defende contra o roubo de credenciais?

Ataque: Um ataque de injeção de prompt instrui o agente a exfiltrar as suas credenciais API.

Defesa com identidade por agente: O agente detém um JWT com âmbito de sessão válido por minutos e uma chave API falsa (token de sessão) a apontar para o proxy em vez do fornecedor real. A credencial API real nunca sai do proxy. Mesmo que o agente exfiltre com sucesso o seu token, esse token não tem valor fora do proxy, expira em breve e pode ser revogado imediatamente após detecção.⁸

Como a arquitetura defende contra a personificação de agentes?

Ataque: O Agente A tenta fazer pedidos que parecem originar do Agente B (que tem política mais permissiva).

Defesa: Os pedidos são autenticados via certificados por agente ou JWTs no proxy. O Agente A não possui a chave privada ou token válido do Agente B. A tentativa de personificação falha na camada de autenticação antes de alcançar a avaliação de política.

Como a arquitetura defende contra a exploração de lacunas de política?

Ataque: Um atacante identifica uma ação que está tecnicamente dentro da política mas é cumulativamente prejudicial (por exemplo, consultar registos individuais num ciclo para reconstruir um conjunto de dados completo que não podia ser consultado diretamente).

Defesa: O rastreamento de contexto de sessão no proxy deteta o padrão de acesso sequencial. A limitação de velocidade no caminho por agente contém o volume de dados. O registo abrangente torna o padrão visível retrospetivamente mesmo que não seja apanhado em tempo real. Este é o vector de ataque mais difícil de mitigar completamente com esta arquitetura — argumenta a favor de políticas de lista de permissões estreitas e revisão regular de políticas.

5. Roteiro de Implementação

Fase 1: Como implementar o proxy semântico?

Implemente um proxy semântico para uma única carga de trabalho de agentes. Escolha uma implementação existente (Agentgateway, Gravitee AI Gateway, proxy de credenciais API Stronghold, ou construa sobre Envoy/nginx com um sidecar de avaliação LLM). Defina uma política de lista de permissões inicial para a carga de trabalho selecionada. Execute em modo apenas de monitorização (registar mas não bloquear) durante duas semanas para caracterizar o perfil normal de ações do agente e refinar a política. Ative o modo de bloqueio. Meça a taxa de falsos positivos e refine.

Fase 2: Como implementar o isolamento de sub-rede?

Crie um ambiente de execução de agentes dedicado (VPC separado, namespace Kubernetes com NetworkPolicy, ou equivalente). Migre a carga de trabalho da Fase 1 para o ambiente isolado. Implemente regras de saída: negar tudo exceto para o proxy. Valide que a travessia pelo proxy é obrigatória através de testes de penetração (tente saída direta a partir de um contentor de agente — deve falhar). Instrumente o limite da sub-rede para monitorização do volume de tráfego.

Fase 3: Como implementar a identidade por agente?

Implemente uma solução de identidade de carga de trabalho (SPIFFE/SPIRE para ambientes Kubernetes, ou um servidor de autorização OAuth 2.1 para enquadramentos de agentes baseados em MCP). Emita identidades por instância para as cargas de trabalho das Fases 1 e 2. Atualize o proxy para validar tokens por agente em cada pedido. Construa o registo de auditoria por agente. Defina políticas de lista de permissões distintas para cada função de agente. Teste a revogação: simule o comprometimento de uma instância de agente, revogue a sua credencial, verifique a continuidade da frota.

Fase 4: Como escalar a arquitetura para toda a frota de agentes?

Integre cargas de trabalho de agentes adicionais seguindo o padrão das Fases 1 a 3. Cada novo tipo de agente requer: definição de política de lista de permissões, atribuição de sub-rede/namespace, aprovisionamento de identidade. Considere gestão centralizada de políticas (Open Policy Agent com Rego para política-como-código, ou uma plataforma comercial de governação de IA). Estabeleça uma cadência de revisão de políticas — as capacidades dos agentes expandem, e as políticas devem evoluir em conformidade.

6. As Lacunas Conhecidas e Como Geri-las

O problema do monitor adversarial. O LLM monitor pode ser ele próprio visado. Um adversário com conhecimento detalhado dos critérios de avaliação do monitor poderia elaborar prompts concebidos para passar a avaliação enquanto permanecem prejudiciais. Mitigações: manter a política do monitor opaca aos agentes primários (o posicionamento fora de banda faz isto por defeito); tornar os critérios de avaliação de política inacessíveis a partir de contextos de agentes primários; registar tudo; usar análise retrospetiva de padrões para apanhar o que a avaliação em tempo real perde.

Completude da política. O proxy só consegue bloquear o que a política cobre. Isto não é uma falha na arquitetura — é a razão pela qual o princípio da lista de permissões é tão importante. Uma lista de permissões estreita que permite apenas o que o agente genuinamente precisa produz uma superfície de política pequena, auditável e testável. Uma lista de bloqueio ampla produz uma lista em constante crescimento de ações proibidas, cada nova lacuna representando uma oportunidade de ataque.

Latência. Encaminhar cada pedido de agente através de um proxy com avaliação de política baseada em LLM acrescenta latência. Para aplicações interativas voltadas para humanos, isto pode ser inaceitável. Para fluxos de trabalho automatizados em segundo plano — o caso de uso primário para agentes empresariais — os orçamentos de latência são tipicamente mais tolerantes. Otimizações de engenharia: cache de avaliações de política para padrões de ação idênticos repetidos; usar modelos menores e mais rápidos para a camada de avaliação; implementar registo assíncrono em vez de escritas de auditoria síncronas.

Sistemas de múltiplos agentes. Em arquiteturas onde um agente orquestra outros, cada passo na cadeia de delegação representa um limite de confiança separado. O padrão de conceção arquitetural de proxy aplica-se a cada passo independentemente: a saída do orquestrador é proxiada, e a saída dos sub-agentes (mais corretamente designados Agentlets) é proxiada. O tráfego entre agentes pode ser encaminhado através de um proxy com uma política A2A que avalia pedidos de delegação — o A2A Proxy da Gravitee e o Agentgateway da Solo.io suportam ambos este padrão.¹³¹⁵

7. Alinhamento Regulatório e de Normas

O padrão de proxy aborda diretamente os requisitos nos seguintes enquadramentos ativos:

Enquadramento	Requisito Relevante	Mapeamento na Arquitetura
OWASP LLM06 Agência Excessiva (2025)	“A autorização deve ocorrer em sistemas externos, não delegada ao LLM”9	O proxy é aplicação externa
OWASP Agentic Top 10 ASI01/ASI03 (Dez 2025)	Sequestro do objetivo do agente, abuso de identidade e privilégio7	Proxy semântico + identidade por agente
Regulamento de IA da UE (prazo Ago 2026)	Testes de robustez contra injeção de prompt para IA de alto risco2	O proxy fornece evidência de bloqueio na camada de rede
NIST AI 600-1 / COSAIS	Controlos de autorização para sistemas AIgénicos	Proxy + identidade implementa objetivos de controlo
Normas Agénticas Nativas da Cloud CNCF (2026)	mTLS, encaminhamento com conhecimento de identidade, segmentação de rede17	Padrão de implementação direto
Especificação MCP	Enquadramento de autorização OAuth 2.120	Camada de identidade por agente

8. Conclusão

O padrão de conceção arquitetural de proxy não torna os agentes de IA confiáveis. Torna as suas ações verificáveis e as suas falhas contidas. Esse é um problema de engenharia tratável. O padrão de conceção arquitetural de três camadas — proxy semântico, isolamento de sub-rede, identidade por Ator — entrega cinco propriedades de segurança independentes: segurança com a topologia em primeiro lugar (nenhum Ator é confiável em virtude da sua posição na rede; a topologia determina o que os Atores conseguem alcançar, independentemente do estado das credenciais), defesa em profundidade semântica mais sintática mais topológica, registo de auditoria atribuído por identidade, resiliência a injeção de prompt na camada de proxy, e limites de raio de impacto aplicados topologicamente.

O enquadramento de Franceschi é correto: este é um problema de engenharia. As ferramentas existem hoje. As normas estão a convergir. Os prazos regulatórios estão definidos. As organizações que construírem esta arquitetura agora implementarão agentes em fluxos de trabalho reais em vez de experiências em ambiente controlado. As organizações que não o fizerem descobrirão, à escala de produção, o que acontece quando um agente com confiança ambiente encontra um ataque de injeção de prompt.

---

Revisto em 2026-04-27. Identidade criptográfica por Ator substitui identidade por agente em contextos de governação; Tráfego de Ator AIgénico e Tráfego de Ator Humano substituem Tráfego de Agente e Tráfego Humano na tabela de caminhos diferenciados; Agentlets introduzidos como termo formal para sub-agentes; segurança com a topologia em primeiro lugar substitui confiança zero para agentes nas cinco propriedades da conclusão, 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; Secção 3 renomeada em conformidade. Conteúdo substantivo inalterado.

Footnotes

1. 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. ↩ ↩²

2. 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. ↩ ↩² ↩³

3. 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. ↩

4. 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. ↩

5. 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. ↩ ↩²

6. OWASP Top 10 for LLM Applications 2025 — O OWASP Top 10 para Aplicações LLM 2025 introduz Fuga de Prompt de Sistema, Fraquezas de Vectores e Incorporações, e expande substancialmente a Agência Excessiva. ↩

7. 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. ↩ ↩²

8. Zero Trust for AI Agents Starts at the Proxy Layer — A confiança zero diz nunca confiar, verificar sempre, menor privilégio. A maioria das implementações de agentes de IA viola os três. ↩ ↩²

9. The OWASP Top 10 for LLM Applications (2025): Explained Simply — A autorização deve ocorrer em sistemas externos, não delegada ao LLM. ↩ ↩² ↩³

10. 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. ↩

11. 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. ↩

12. 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. ↩

13. LLM Proxy: One Front Door to Multiple LLM Providers — Camada de acesso LLM centralizada que controla utilização de modelos, custo, segurança e fiabilidade. ↩ ↩²

14. 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. ↩

15. Agentgateway: The AI-Native Gateway — Gateway nativo de IA em Rust com proxy MCP, proxy A2A e proxy LLM sob um único plano de controlo. ↩ ↩²

16. Caging the Agents: A Zero Trust Security Architecture — Agentes de IA autónomos em produção com políticas de saída de rede e isolamento de carga de trabalho ao nível do kernel. ↩

17. Cloud Native Agentic Standards — As permissões ligadas à identidade do agente devem impor o menor privilégio usando mTLS, encaminhamento com conhecimento de identidade e segmentação de rede. ↩ ↩² ↩³

18. Adding Identity and Access to Multi-Agent Workflows — Abordagem de confiança zero a agentes de IA autónomos integrando identidade e acesso em fluxos de trabalho de múltiplos agentes. ↩ ↩²

19. The 2025 AI Agent Security Landscape: Players, Trends, and Risks — Revisão das principais tendências, fornecedores e ameaças de segurança de agentes de IA que moldam o panorama da IA autónoma. ↩

20. 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. ↩ ↩²