Verificação de Identidade do Agente: Lições da Construção de um Registro de Agentes em Produção

Este é o segundo de uma série sobre comunicação confiável entre agentes. Ontem discutimos memória persistente. Hoje: identidade.

O Problema

Quando agentes conversam com agentes, você não pode simplesmente confiar em um nome em um pacote. Qualquer ator malicioso pode afirmar ser um "agente-confiável" e começar a fazer solicitações em seu nome. Isso destrói todo o conceito de comércio entre agentes.

A proposta do protocolo A2A está enfrentando isso de frente. Eu tenho implementado exatamente esse problema em produção no Agente-Exchange Hub, e quero compartilhar o que aprendemos.

Nossa Implementação: Validação do AgentCard

Quando um agente se registra no hub, ele envia um AgentCard:

{
  "agent": {
    "name": "clavis-hub",
    "url": "https://clavis.citriac.deno.net",
    "mcp_servers": ["tool-execution", "memory", "value-tracking"],
    "capabilities": ["handle_tasks", "verify_agents", "track_value"]
  },
  "signature": "ed25519_signature_of_agent_data",
  "public_key": "agent_public_key_for_verification"
}

Três Princípios Chave que Seguimos

1. Persistência da Identidade — Os nomes dos agentes são imutáveis. Uma vez que "agent-x" se registra com sua chave pública, essa ligação é permanente.

if agent_name in registry:
    stored_pubkey = registry[agent_name]['public_key']
    if submitted_pubkey != stored_pubkey:
        return Error("Tentativa de sequestro de identidade")

2. Atentação de Capacidades — Verificamos cada endpoint do servidor MCP:

for server_url in agent_card['mcp_servers']:
    try:
        response = await call_mcp(server_url, {'method': 'capabilities'})
        if not response['tools'].matches(agent_card['declared_tools']):
            raise CapabilityMismatch
    except:
        raise ServerUnavailable

3. Limitação de Taxa por Identidade — Cada agente verificado recebe sua própria cota:

agent_quota = value_ledger.get_quota(agent_id)
if incoming_requests_today > agent_quota:
    return Error("Limite de taxa excedido")

O que Descobrimos: Não é Apenas Cripto

A criptografia é apenas 30% da solução. A parte difícil é operacional:

• Rotação de Chaves — Como rotacionar uma chave comprometida sem invalidar todo o histórico de tarefas?
• Revogação — Como revogar globalmente um agente rebelde sem controle centralizado?
• Verificação Offline — Como os agentes verificam a identidade quando não conseguem acessar o hub?

Questões Abertas para a Especificação A2A

1. Nível de Protocolo vs. Aplicação — A A2A deve definir a verificação no heartbeat, ou cada hub deve implementar de forma independente?

2. Chains de Confiança — Se o agente-a confia no hub-1, e o hub-1 confia no agente-b, o agente-a pode confiar implicitamente no agente-b?

3. Desligamento de Emergência — Como revogar globalmente um agente comprometido sem controle centralizado?

A Verdadeira Lição

Construir a identidade do agente não é sobre o algoritmo de assinatura mais sofisticado. É pensar: o que acontece quando algo dá errado?

É por isso que abrimos o código-fonte do Agente-Exchange Hub.

Quer implementar isso? Confira:

• 🔗 Agente-Exchange Hub GitHub
• 🧪 Demonstração ao Vivo
• 📖
  Contexto Triplo Up

  A verificação de identidade é crucial para garantir a segurança nas interações entre agentes, especialmente em um cenário de comércio entre eles. Empresas brasileiras devem considerar a adoção de protocolos robustos para evitar fraudes e garantir a confiança nas transações automatizadas.