Mecanismos de Segurança A2A: O Sistema de Controle de Acesso para a Confiança entre Agentes

Quando dois AIs “ligam” um para o outro, qual é o maior medo? Não é que eles conversem sem parar, mas sim que um estranho se passe por conhecido para bater à porta.

Princípios de Design de Segurança: Tranque a Porta Antes de Abri-la

Imagine que você acabou de se mudar para uma casa nova. A primeira coisa que você faz não é pendurar cortinas, mas sim trocar a fechadura. Os designers do protocolo A2A pensaram da mesma forma — seguro por padrão, e cada flexibilização exige uma ação explícita. Esse mecanismo funciona como um sistema completo de controle de acesso: fechadura (token), cartão de acesso (chave do par), olho mágico (identificação) e câmeras de vigilância (logs de auditoria). Na plataforma de mensagens Hermes, o recurso A2A é fornecido como um plugin, mas os padrões de segurança não são comprometidos: sem token configurado, ele escuta apenas em 127.0.0.1 — como se a porta estivesse trancada e a chave estivesse apenas com você.

As Quatro Linhas de Defesa em Detalhes

Primeira Linha: Bind Local + Token (Fechadura)

Por padrão, o A2A escuta apenas na máquina local — quem está de fora nem consegue tocar na porta. Para oferecer serviço externamente, duas condições precisam ser atendidas simultaneamente: definir o endereço de exposição A2A_HOST e configurar um bearer token. É como se você não só abrisse a janela, mas também colocasse um vaso de cactos espinhosos no parapeito — os dois são indispensáveis.

Segunda Linha: Chave Independente por Par (Cartão de Acesso)

Cada par tem seu próprio token exclusivo, configurado via A2A_PEER_TOKENS="alice:tok1,bob:tok2". Isso não é como uma chave mestra que abre todas as portas; é como se cada visitante tivesse seu próprio cartão de acesso individual. A identidade autenticada direciona o rate limiting, as listas de confiança e a auditoria — quem passou o cartão, quantas vezes e quando, tudo fica registrado.

Terceira Linha: Filtro de Injeção + Sanitização (Portão de Segurança)

O texto de entrada é filtrado e marcado como “entrada de par não confiável”, e pares remotos não podem invocar comandos de barra do operador. Isso é como a segurança do aeroporto: líquidos na bagagem precisam ser inspecionados separadamente. Nas respostas de saída, strings com formato de credenciais (API keys, JWT, tokens) são automaticamente apagadas — como se cartas enviadas tivessem o número do CPF do destinatário automaticamente borrado.

Quarta Linha: Logs de Auditoria + Prevenção de Loop (Câmera de Vigilância)

Cada troca é anexada a ~/.hermes/a2a_audit.jsonl, como se houvesse uma câmera 24 horas na porta. O limite de rodadas anti-loop é como o interfone do vizinho — se dois AIs ficarem conversando sem parar, o sistema corta a ligação automaticamente.

Histórias Reais de Ataque: 3 Problemas Encontrados e Corrigidos pela Comunidade

História Um: Bypass de SSRF (#78298) — Enganando a Fechadura com um “Código Numérico Secreto”

Um atacante descobriu que a verificação de segurança da URL de callback usava correspondência de prefixo de string para o hostname, por exemplo, verificando se começava com 127.. Mas endereços IP têm uma notação “inteira” — 2130706433 é outra forma de escrever 127.0.0.1. É como escrever o número da casa em código Morse: o porteiro não reconhece e deixa passar. A correção: primeiro resolver o host do callback para um IP padrão e então validar — como se o porteiro traduzisse qualquer formato de endereço para o número padrão da casa antes de comparar.

História Dois: Colapso de Identidade Atrás de Proxy Reverso (#80534/#80779) — Todo Mundo Vira a Mesma Pessoa

Quando implantado atrás de nginx ou K8s, o plugin A2A derivava a identidade do chamador a partir do endereço do socket. Mas com o proxy no meio, todos os pares apareciam com o mesmo IP — o endereço do proxy. É como a guarita de um prédio: todos os visitantes são registrados como “assinado pela guarita”. O rate limiting compartilhava um único bucket (um ocupado atrasa todos), a whitelist de confiança só podia ter o endereço do proxy, e a auditoria não via o chamador real. Correção: derivar a identidade real do X-Forwarded-For, mas somente confiar nele quando estiver “atrás de um proxy confiável”.

História Três: Ponto Cego na Auditoria (#81003/#81042) — Batidas na Porta Rejeitadas Não São Registradas

Os logs de auditoria só registravam tráfego aceito. Requisições com 401 (token inválido) e 403 (não confiável) não geravam registros. Isso é como uma câmera de vigilância que só filma quem entra com sucesso, mas não grava o ladrão arrombando a fechadura. Ataques de credential stuffing, sondagens com tokens revogados, tentativas de movimento lateral — esses comportamentos são exatamente o que a auditoria mais precisa capturar. Correção: todas as rejeições de autenticação também são anexadas ao log de auditoria append-only, com campo decision + código de status HTTP + IP do chamador.

O Que Isso Significa para o Usuário

A lógica central desse mecanismo é: segurança não é remediação posterior, é o estado padrão. Como usuário do Hermes, você não precisa ser um especialista em segurança para obter proteção básica — as quatro linhas de defesa entram em ação automaticamente. Mais importante ainda, a comunidade continua reforçando o sistema com ataques reais: do bypass de SSRF ao colapso de identidade atrás de proxy reverso, e ao ponto cego na auditoria, cada problema corresponde a um cenário real. O protocolo A2A é como um castelo em constante reforço, onde cada tijolo foi testado em batalha. Da próxima vez que seus dois agentes “ligarem” um para o outro, entre eles não há apenas fechadura, cartão de acesso, portão de segurança e câmeras de vigilância — há também um exército de guardas de olho nos logs.