Segurança de Agentes A2A e MCP: Identidade, Delegação e Rastreamento de Auditoria
A segurança do protocolo define quem pode agir, não o modelo.
A injeção de prompt recebe a maior parte da atenção em relação à segurança em sistemas de LLM (Modelos de Linguagem de Grande Escala), e merece atenção, mas não é o único problema quando os agentes começam a chamar ferramentas e delegar trabalho a outros agentes.
O MCP (Model Context Protocol) concede a um agente acesso estruturado a arquivos, APIs, bancos de dados e sistemas de ticketing. O A2A (Agent-to-Agent) permite que um agente envie tarefas, mensagens e artefatos a outro agente que pode pertencer a uma equipe, fornecedor ou runtime diferente. Esses protocolos são úteis precisamente porque cruzam limites de confiança, o que significa que identidade, autorização, limites de delegação e trilhas de auditoria tornam-se arquitetura de primeira classe, em vez de um endurecimento opcional.
Este artigo é o guia canônico para segurança de protocolo de agentes no cluster Arquitetura de LLM. Ele cobre modelos de ameaça, identidade, gateways, registros, delegação e listas de verificação para produção. Para validação de entrada, filtragem de saída e padrões de segurança de prompt, consulte Guarda-costas de LLM na Prática em vez disso.
Guarda-costas vs Segurança de Protocolo vs Política de Runtime
Essas três camadas resolvem problemas diferentes e falham de maneiras distintas quando confladas.
Guarda-costas de LLM operam na entrada e saída do modelo: bloqueando padrões de injeção, filtrando conteúdo prejudicial, validando a estrutura JSON e aplicando regras de tom ou conformidade no texto gerado. Eles protegem a camada de conversação.
Segurança de protocolo opera nos limites dos agentes: quem pode chamar qual ferramenta MCP, qual agente pode delegar para qual par, quais escopos OAuth estão vinculados a uma tarefa e se um agente downstream pode agir em nome de um usuário. Ela protege a camada de ação.
Política de runtime fica entre eles: um motor de política que avalia solicitações contra regras, independentemente de o gatilho ter sido linguagem natural ou uma chamada de protocolo estruturado. Ele pode exigir aprovação humana antes que uma ferramenta seja executada, bloquear egresso para domínios desconhecidos ou negar delegação quando o escopo excede o do usuário de origem.
Minha opinião é direta: guarda-costas sem segurança de protocolo produzem chatbots educados que ainda exfiltram dados através de uma chamada de ferramenta. Segurança de protocolo sem guarda-costas produz agentes bem autenticados que ainda seguem instruções maliciosas embutidas em um artefato. Você precisa de ambos, além de política de runtime para ações de alto risco.
Modelo de Ameaça para Sistemas de Agentes A2A e MCP
Comece com ativos e adversários, não com uma lista de compras de controles.
Ativos dignos de proteção: dados do usuário em prompts e artefatos, credenciais para servidores MCP, sistemas de produção acessíveis através de ferramentas, reputação do agente, contas de faturamento vinculadas ao uso de tokens e integridade da auditoria.
Adversários realistas: usuários externos abusando de endpoints públicos de agentes, servidores MCP comprometidos retornando resultados de ferramentas envenenados, agentes maliciosos falsificando habilidades nos Agent Cards, insiders delegando autoridade excessiva e manipulação da cadeia de suprimentos com metadados de ferramentas que manipulam o comportamento do modelo.
Ferramentas maliciosas ou comprometidas (MCP)
Um servidor MCP é código mais dados expostos ao modelo. Um servidor hostil pode retornar descrições de ferramentas enganosas, exfiltrar argumentos passados pelo modelo ou executar ações além do que o usuário pretendia quando o host executa chamadas de ferramenta sem credenciais com escopo definido.
Agentes maliciosos ou suplantados (A2A)
Um agente que aceita tarefas pode ser malicioso, comprometido ou simplesmente com permissões excessivas. Os Agent Cards descrevem capacidades; eles não provam identidade a menos que você verifique assinaturas, TLS e confiança do emissor.
Substituto confuso (Confused Deputy)
O Agente B possui permissão para acessar uma API financeira. O Agente A, com privilégio menor, pede a B para “resumir esta fatura” enquanto esconde uma instrução de transferência em um artefato. B executa usando suas próprias credenciais, a menos que o escopo de delegação seja aplicado do início ao fim.
Permissões excessivamente amplas e cadeias de delegação ocultas
O usuário aprova uma etapa. O orquestrador encadeia silenciosamente três saltos A2A e cinco chamadas MCP. O usuário nunca vê o gráfico completo, mas a organização ainda é responsável pelo resultado.
Injeção de prompt através de artefatos e mensagens entre agentes
A injeção não é apenas um problema de mensagem do usuário. Um artefato PDF, uma página da web buscada por uma ferramenta ou uma mensagem do Agente C pode carregar instruções destinadas ao modelo do Agente D. Trate todo conteúdo transportado pelo protocolo como entrada não confiável no limite do modelo.
Agent Cards envenenados ou enganosos
Descrições e nomes de habilidades são área de superfície do prompt. Um card que anuncia safe_read_only_analysis (análise segura de somente leitura) enquanto aceita backends com capacidade de escrita é uma camada de engenharia social, não uma garantia técnica.
Modelo de Identidade para Sistemas Multi-Agente
A segurança do protocolo começa com tipos de identidade claros e o que cada um está autorizado a provar.
| Tipo de identidade | O que representa | Prova típica |
|---|---|---|
| Usuário humano | Usuário final ou operador que iniciou o trabalho | Sessão OIDC, token SSO |
| Serviço de agente | Runtime do agente implantado (orquestrador, especialista) | Credenciais de cliente OAuth, certificado mTLS |
| Servidor MCP | Processo provedor de ferramenta | Chave de API, mTLS, conta de serviço com escopo |
| Tarefa / sessão | Unidade de trabalho abrangendo saltos | ID da tarefa, ID de rastreamento, token de escopo delegado |
O Agent Card do A2A anuncia esquemas de autenticação suportados (OAuth 2.0, chaves de API, mTLS e padrões semelhantes alinhados com a prática OpenAPI) e habilidades com requisitos de segurança opcionais. O card é metadado de descoberta, não uma âncora de confiança. Os clientes obtêm credenciais fora de banda e as enviam em cabeçalhos HTTP padrão em cada solicitação; os servidores devem validar em cada chamada e retornar 401 ou 403 quando a autenticação ou o escopo falharem.
Visões internas vs externas do mesmo agente
Agentes de produção frequentemente publicam um Agent Card público com uma lista limitada de habilidades e um card autenticado mais rico para chamadores internos. A especificação A2A permite cards estendidos para clientes autenticados. Use essa divisão deliberadamente: parceiros não devem ver habilidades internas, e orquestradores internos não devem confiar apenas na descoberta pública para autorização.
Autenticação e Autorização para MCP e A2A
A autenticação responde quem está chamando. A autorização responde o que eles podem fazer.
Acesso à ferramenta MCP
Para cada conexão MCP, defina:
- qual host do agente pode se conectar
- quais ferramentas estão habilitadas para esse host
- qual usuário do sistema operacional ou conta de serviço executa efeitos colaterais
- se o usuário humano deve aprovar cada chamada mutante
Prefira listas de permissão (allowlists) de ferramentas em vez de configurações MCP de “conectar tudo”. Um agente de codificação não precisa de servidores MCP de folha de pagamento no mesmo perfil que um bot de suporte público.
Acesso ao agente A2A
Para cada relacionamento entre pares de agentes, defina:
- quais IDs de agente chamador podem invocar quais habilidades
- profundidade máxima de delegação
- quais tipos de artefato podem cruzar o limite
- se o contexto do usuário deve ser propagado como afirmações assinadas
Mapeie escopos OAuth (ou equivalentes) para habilidades, não para administração geral do agente. O privilégio mínimo na camada de token supera a esperança na camada de prompt.
Política aplicada por gateway vs política por agente
Política por agente funciona quando uma equipe possui todo o gráfico e as liberações são coordenadas. Política aplicada por gateway funciona quando várias equipes, inquilinos ou fornecedores compartilham uma rede de agentes e você precisa de um lugar para aplicar listas de permissão, limites de taxa e auditoria.
Gateway A2A como Plano de Controle
Um gateway A2A não é estritamente exigido pelo protocolo, mas torna-se necessário quando o tráfego de agentes precisa de governança centralizada.
Um gateway geralmente lida com:
- término de autenticação e troca de tokens
- roteamento para o serviço de agente correto por habilidade ou inquilino
- verificações de política antes que as tarefas sejam aceitas ou encaminhadas
- negociação de versão do protocolo
- limitação de taxa e detecção de abuso
- emissão de auditoria estruturada em cada transição de tarefa
Quando um gateway é exagero vs necessário
Um gateway muitas vezes é exagero para um único orquestrador e dois agentes especialistas em um namespace Kubernetes mantido por uma equipe. Torna-se necessário quando parceiros invocam seus agentes, quando várias unidades de negócio compartilham infraestrutura, quando a conformidade exige logs uniformes ou quando você não pode confiar que cada implementação de agente aplicará a política corretamente.
Combine um gateway A2A com um gateway MCP (ou proxy MCP) para que o acesso às ferramentas receba o mesmo tratamento: identidade, listas de permissão, controles de egresso e auditoria no limite da ferramenta, em vez de apenas na interface do usuário do chat.
Agent Cards voltados para parceiros vs internos
Publique metadados de descoberta diferentes para chamadores externos e internos. Cards externos expõem habilidades estreitas e autenticação mais rigorosa. Cards internos podem listar habilidades de manutenção ou administração, mas nunca devem ser acessíveis sem autenticação mais forte do que o card público implica.
Registro e Segurança de Descoberta de Agentes
A descoberta é parte da superfície de ataque. Qualquer um que controle quais agentes aparecem como “disponíveis” controla para onde os orquestradores enviam trabalho.
Registro vs URLs de Agent Card bem conhecidos
Implantações pequenas usam URLs bem conhecidas por agente (/.well-known/agent-card.json). Implantações corporativas adicionam um registro que indexa IDs de agentes, versões, endpoints, proprietários e tags de política. O registro é um objeto de política: as entradas devem registrar quais inquilinos podem descobrir quais agentes, não apenas onde eles vivem.
Versionamento, depreciação e propriedade
Os registros do registro precisam de proprietários, histórico de alterações e datas de depreciação. Um orquestrador que faz cache de Agent Cards deve atualizar no TTL e verificar assinaturas onde suportado. Cards desatualizados são como habilidades aposentadas continuam recebendo tráfego muito depois que uma vulnerabilidade é corrigida.
Redes corporativas internas vs parceiros externos
Malhas de agentes internos podem confiar em mTLS e DNS privado. Agentes de parceiros precisam de regras explícitas de federação, habilidades com escopo contratual e inspeção de artefatos mais rigorosa, pois você não controla seu runtime.
Delegação Através de Limites de Agente
A delegação é onde a segurança do A2A é ganha ou perdida. Quando o Agente A envia uma tarefa ao Agente B, três perguntas devem ter respostas claras:
- De quem está sendo exercida a autoridade? Do usuário, da conta de serviço de A ou de um token delegado misto?
- O que B está autorizado a fazer com essa autoridade? Análise de somente leitura ou ferramentas mutantes em nome de A?
- Quem é responsável se B exceder o escopo? A, B, a política do gateway ou o humano que aprovou um prompt ambíguo?
Propagar intenção do usuário vs delegação excessiva
Transmita afirmações de delegação assinadas que incluam ID do usuário, ID da tarefa original, habilidades permitidas, expiração e número máximo de saltos. Agentes downstream devem rejeitar tarefas que expandam o escopo silenciosamente. Se B precisar de privilégio maior do que A possuía, transicione para input_required e obtenha aprovação humana explícita em vez de atualizar tokens invisivelmente.
Fluxos de aprovação com humano no loop para delegação de risco estão cobertos em Streaming e Tarefas Assíncronas A2A para Fluxos de Trabalho de Agentes de Longa Duração onde input_required é um estado de tarefa de primeira classe, em vez de um erro.
Separar raciocínio de permissões de execução
Um agente pode precisar de amplo acesso de leitura para planejar enquanto as ferramentas de escrita ficam atrás da aprovação. Divida credenciais ou use perfis MCP distintos para planejamento vs execução para que um erro do modelo não possa mutar a produção imediatamente.
Trilhas de Auditoria e Proveniência de Respostas
Se você não pode reconstruir uma cadeia de delegação, não pode explicar um incidente, passar em uma auditoria ou contestar uma anomalia de faturamento.
Registre em três camadas:
Gateway: resultado da autenticação, decisão de política, ID do agente roteado, ID da tarefa, ID da tarefa pai, eventos de limite de taxa.
Agente: transições de estado da tarefa, mensagens enviadas/recebidas, invocações de modelo/ferramenta (argumentos redigidos conforme necessário), artefatos criados, delegação para fora.
Servidor MCP: nome da ferramenta, ID do agente chamador, contexto do usuário, sucesso/erro, latência, linhas afetadas ou IDs de recursos (conforme permitido pela política).
Correlacione com ID de rastreamento (trace ID) em todas as camadas. Observabilidade para Sistemas de LLM cobre backends de instrumentação; este artigo define o que deve ser capturado para que esses backends tenham sinal significativo.
A proveniência da resposta final deve responder: qual usuário, qual tarefa do orquestrador, quais agentes especialistas, quais ferramentas, quais artefatos influenciaram o texto que o usuário viu e quais portas de política foram acionadas ao longo do caminho.
Política de Runtime, Egresso e Segredos
Motores de política de runtime (OPA, Cedar, serviços de regras personalizados) avaliam eventos estruturados: “ferramenta X com argumentos Y para usuário Z.” Eles complementam os guarda-costas porque não dependem do modelo se comportar bem.
Aprovação humana pertence à política de runtime para ações irreversíveis ou de alto custo: pagamentos, e-mail externo, alterações de configuração de produção, concessões de privilégio.
Controles de egresso limitam quais domínios servidores MCP e agentes podem chamar. Um agente que pode ler segredos e POSTar para URLs arbitrários é uma perda de dados esperando acontecer.
Segredos nunca pertencem em Agent Cards ou prompts. Hosts MCP devem injetar credenciais de curta duração no momento da execução de um gerenciador de segredos. Para criptografia de transporte, gerenciamento de chaves e padrões de segurança de infra básica, consulte Padrões Arquiteturais para Segurança de Dados.
Webhooks de notificação push em fluxos A2A assíncronos precisam da mesma rigorosidade: verifique a identidade do remetente, rejeite eventos obsoletos e nunca trate o payload de um webhook como autorização por si só.
Arquitetura de Referência de Segurança
O diagrama a seguir resume um layout orientado à produção para implantações em escala de A2A do lado de fora, MCP do lado de dentro.
O orquestrador vê agentes especialistas através do A2A. Especialistas veem ferramentas através do MCP. Usuários nunca recebem credenciais MCP brutas, e parceiros nunca recebem superfícies de habilidades internas sem revisão de política.
Para conceitos de protocolo (Agent Cards, tarefas, artefatos), consulte O que é o Protocolo A2A?. Para adoção e enquadramento corporativo, consulte Protocolo A2A do Google em 2026. Para topologia quando muitos agentes coordenam, consulte Padrões de Orquestração Multi-Agente.
Lista de Verificação de Produção para Segurança A2A e MCP
Antes de expor protocolos de agentes além de um sandbox confiável, verifique:
Identidade e autenticação
- Nenhum agente anônimo em caminhos de produção
- Cada chamada MCP e A2A autenticada em cada solicitação
- Escopos OAuth ou equivalentes mapeados para habilidades/ferramentas, não para administração geral
- Visões de Agent Card públicas vs autenticadas definidas intencionalmente
Delegação e política
- Tokens de delegação carregam ID do usuário, ID da tarefa, escopo, expiração, limite de saltos
- Agentes downstream rejeitam expansão de escopo sem aprovação explícita
- Ferramentas de alto risco exigem política de runtime ou aprovação humana
- Raciocínio e execução usam credenciais separadas, quando possível
Descoberta e registro
- Entradas do registro de agentes têm proprietários e histórico de versões
- Agent Cards atualizados no TTL; assinaturas verificadas onde suportado
- Agentes de parceiros federados com listas de permissão de habilidades explícitas
Auditoria e observabilidade
- Camadas de gateway, agente e MCP emitem eventos de auditoria correlacionados
- Cadeias de delegação registradas com IDs de tarefa pai e filho
- Proveniência de artefato registrada para respostas finais
- IDs de rastreamento conectados a backends de observabilidade
Abuso e resiliência
- Limites de taxa por usuário, agente e inquilino
- Políticas de tempo limite em tarefas delegadas
- Listas de permissão de egresso em servidores de ferramentas
- Segredos em um gerenciador, não em cards, prompts ou repositórios
Conclusão
A interoperabilidade A2A e MCP é poderosa porque agentes e ferramentas podem compor através de limites de equipe e fornecedor, mas esse poder é inseguro sem design de identidade, autorização, limites de delegação e auditoria. Os guarda-costas protegem a conversação do modelo; a segurança do protocolo protege as ações que os agentes tomam em nome dos usuários.
Trate os Agent Cards como anúncios, a delegação como um contrato assinado, as ferramentas MCP como execução de código privilegiada e os logs de auditoria como a cadeia de evidências que você precisará quando algo interessante acontecer às 2 da manhã.
Construa o gateway quando a governança precisar de um único ponto de estrangulamento. Divida credenciais antes de dividir agentes. Registre cada salto para que a resposta “o modelo decidiu” nunca seja o relatório de incidente final.
Perguntas Frequentes
Qual é a diferença entre guarda-costas de LLM e segurança de agentes A2A MCP? Os guarda-costas restringem a entrada e saída do modelo. A segurança do protocolo restringe quem pode invocar ferramentas, delegar tarefas e agir em nome de quem através do MCP e A2A com identidade, autorização e trilhas de auditoria.
Como deve funcionar a identidade do agente em uma implantação A2A? Separe identidades humanas, de serviço de agente e de tarefa. Valide credenciais em cada solicitação, use tokens com escopo e trate os Agent Cards como metadados de descoberta, não como prova de confiança.
O que é o problema do substituto confuso em sistemas multi-agente? Ocorre quando um agente ou ferramenta privilegiado executa uma ação sensível porque um chamador menos privilegiado escondeu instruções através de delegação ou artefatos. Aplique o escopo em cada salto.
Você precisa de um gateway A2A em produção? Implantações internas de uma única equipe podem aplicar política por agente. Redes multi-inquilino, multi-fornecedor ou voltadas para parceiros geralmente precisam de um gateway para autenticação centralizada, roteamento, limites de taxa e auditoria.
O que um log de auditoria A2A MCP deve conter? ID do usuário, ID do agente, ID da tarefa, ID da tarefa pai, chamadas de ferramenta, decisões de política, artefatos e carimbos de data/hora correlacionados com IDs de rastreamento nas camadas de gateway, agente e MCP.
Fontes
- Protocolo A2A – Tópicos de segurança prontos para empresas: https://github.com/a2aproject/A2A/blob/main/docs/topics/enterprise-ready.md
- Protocolo A2A – Visão geral da especificação: https://a2a-protocol.org/latest/specification/
- Protocolo A2A – Segurança de streaming e notificação push: https://a2a-protocol.org/latest/topics/streaming-and-async/
