Notarized Agents: Receiver-Attested Confidential Receipts for AI Agent Actions

Resumo Técnico: Agentes Notarizados: Recibos Confidenciais Atestatados pelo Receptor para Ações de Agentes de IA

Declaração do Problema

A observabilidade atual de agentes de IA é estruturalmente comprometida porque a entidade que produz o log de atividade é a mesma entidade cuja atividade está sendo registrada. No modelo dominante (ex: Langfuse, LangSmith), os rastros (traces) são coletados de dentro do processo do agente ou da infraestrutura do operador. Isso cria um ponto único de falha: se um agente for comprometido (via injeção de prompt, envenenamento de contexto ou código defeituoso) ou se o operador tiver incentivos desalinhados, os rastros podem ser omitidos, alterados ou fabricados. O agente não pode ser um narrador confiável de suas próprias ações, e o proprietário não tem uma forma independente de detectar manipulações.

As soluções existentes falham em atender a um modelo de ameaça onde o adversário controla tanto o agente quanto seu operador. Um registro robusto das ações do agente deve ser:

1. Inforjável pelo agente ou pelo operador.
2. Independentemente verificável pelo proprietário usando infraestrutura pública.
3. Confidencial para os operadores de infraestrutura pública.
4. Atribuível a uma parte estruturalmente separada presente no evento.
5. Recuperável mesmo se o agente estiver indisponível.

Nenhum sistema pesquisado entrega todas as cinco propriedades.

Metodologia: O Protocolo Sello

O artigo propõe "Agentes Notarizados", uma inversão arquitetônica inspirada na notariação histórica e em sistemas modernos como a rede Find My da Apple. Em vez de o agente reportar suas ações, os serviços que o agente chama atuam como testemunhas independentes.

Os autores instanciam esta classe de protocolos como Sello, que combina quatro propriedades definidoras:

• P1: Assinatura do lado do receptor: O serviço que recebe a chamada do agente assina o recibo usando sua própria chave privada, não a do agente ou do operador.
• P2: Criptografia HPKE para uma chave vinculada ao proprietário: O recibo é criptografado para a chave pública do proprietário do agente. Crucialmente, esta chave pública é criptograficamente vinculada ao token de autorização do agente via uma declaração (claim) JWS, prevenindo ataques de substituição.
• P3: Publicação em um log de Merkle cosignado por testemunhas: Os recibos são anexados a um log de transparência público (ex: Sigstore Rekor) com cosignatura de testemunhas para garantir a evidência de violação (tamper-evidence).
• P4: Descoberta do lado do proprietário: O proprietário consulta o log usando uma referência derivada do token, descriptografa os recibos localmente e verifica as assinaturas contra um registro de identidade de serviço.

Fluxo do Protocolo

1. Vinculação de Token: O agente apresenta um token de autorização JWS contendo uma declaração com a chave pública HPKE do proprietário (owner_hpke_pk).
2. Geração de Ação e Recibo: Ao receber uma chamada, o serviço verifica o token, realiza a ação e constrói um corpo de recibo (contendo hashes de ação, status e carimbos de data/hora).
3. Criptografia e Assinatura: O serviço criptografa o corpo para o owner_hpke_pk usando HPKE (X25519/KEM, ChaCha20-Poly1305). Em seguida, assina o envelope criptografado usando COSE_Sign1 (Ed25519).
4. Registro (Logging): O envelope assinado é enviado para um log de transparência. O log retorna uma prova de inclusão de Merkle.
5. Verificação: O proprietário consulta o log usando SHA-256(token-bytes). Eles verificam a prova de Merkle, resolvem a chave pública do serviço via um registro, verificam a assinatura COSE e descriptografam o payload.

Mecanismos de Segurança

• Revogação: O protocolo vincula as decisões de revogação ao tempo integrado do log de transparência em vez do carimbo de data/hora autoafirmado pelo serviço. Isso evita que um serviço comprometido retroceda a data dos recibos para evitar a revogação.
• Proteção contra Replay: Uma regra de deduplicação do lado do proprietário baseada em uma tupla de (kid, token_ref, timestamp, action hashes) detecta eventos repetidos.
• Confidencialidade: O conteúdo do recibo é ocultado dos operadores do log e observadores de rede via HPKE; apenas os metadados (ID do serviço, referência do token) são visíveis.

Contribuições Principais

O artigo apresenta quatro contribuições específicas:

1. Inversão Arquitetônica: Identificar a assinatura do lado do receptor como a correção estrutural para a observabilidade de agentes e definir as quatro propriedades criptográficas (P1–P4) que distinguem os protocolos notarizados.
2. Especificação Sello: Um protocolo concreto usando primitivas padrão (COSE_Sign1, HPKE, Ed25519, logs de Merkle) e um perfil de token JWS inovador que vincula a chave de criptografia do proprietário ao token de autorização.
3. Inovação de Vinculação de Tempo: Propor o uso do tempo integrado do log de transparência para decisões de revogação de chaves, separando-o do carimbo de data/ hora do recibo para mitigar ataques de retrocesso de data (backdating).
4. Análise Comparativa: Uma comparação propriedade por propriedade mostrando que nenhum sistema existente (Signet, AgentROA, Agent Passport System, etc.) combina todas as quatro propriedades.

Resultados e Avaliação

Os autores fornecem microbenchmarks das operações criptográficas usando uma implementação de referência em um Apple M2.

• Sobrecarga (Overhead): Um serviço compatível com Sello adiciona aproximadamente 0,45 ms de trabalho de CPU mediana por chamada de agente (selo HPKE + assinatura + anexo ao log).
• Verificação: Um proprietário reconstruindo a atividade realiza aproximadamente 0,28 ms de trabalho de CPU mediana por recibo (verificação de prova, verificação de assinatura, descriptografia).
• Tamanho do Payload: Um envelope Sello completo possui aproximadamente 467 bytes (independente do tamanho da ação, pois as entradas/saídas são transformadas em hash).
• Escalabilidade: Um serviço lidando com 1.000 chamadas/segundo gastaria ~0,45 segundos de CPU por segundo em recibos. Um proprietário pode reconstruir um dia de atividade (100.000 recibos) em ~32 segundos de tempo de CPU usando verificação em lote.

O artigo observa que a latência de rede para o envio ao log está excluída dessas medições e depende do operador específico do log.

Limitações e Alegações

O artigo é explícito sobre o que o Sello não resolve:

• Ataque de Supressão: Se o agente simplesmente não chamar os serviços, nenhum recibo é gerado. O proprietário não consegue distinguir entre "nenhuma ação" e "ação suprimida".
• Colusão de Serviço: Se um serviço coludir com o operador para emitir recibos falsos, o Sello não pode detectar isso a partir de um único recibo.
• Incentivo de Adoção: Os serviços atualmente não têm razão para emitir recibos. O artigo postula que a adoção requer mandatos regulatórios (ex: Lei de IA da UE), acoplamento de liquidação ou prêmios de confiança de mercado.
• Completude do Conjunto: O Sello fornece verificabilidade por recibo, mas não completude de conjunto criptográfica. Um operador de log poderia teoricamente omitir recibos correspondentes sem detecção, a menos que mecanismos de completude específicos (como resultados de consulta autenticados ou auditorias completas de log) sejam implantados.

Significância

O artigo argumenta que a significância do Sello reside não em novas primitivas criptográficas, mas na composição arquitetônica das existentes para inverter a fronteira de confiança. Ao deslocar a fonte da verdade do agente para os serviços independentes que ele toca, o Sello fornece um rastro que é à prova de violação, confidencial e verificável pelo proprietário, que sobrevive ao comprometimento do agente.

Os autores concluem que, embora o problema do incentivo de adoção permaneça não resolvido, o protocolo fornece a precondição necessária para uma auditoria rigorosa de IA. A tese central é que "o agente não é o narrador correto de suas próprias ações; os serviços que ele toca são".