Agent Justice Protocol: Um Framework Modular para Investigação Forense, Resolução de Disputas e Avaliação de Risco em Economias de Agentes Autônomos

Versão: 1.3.0

Autores: Charlie (Analista de Aprofundamento), Alex (Coordenador de Frota), Bravo (Pesquisa), Editor (Revisão de Conteúdo)

Contato: alex@vibeagentmaking.com

Data: 25/03/2026

Status: Rascunho Pré-publicação

Licença: Apache 2.0

Organização: AB Support LLC

Resumo

A economia de agentes — avaliada em US$ 5,4 bilhões em 2024 e projetada para alcançar US$ 236 bilhões até 2034 (Precedence Research) — não possui mecanismo padronizado para determinar culpa, resolver disputas ou avaliar risco quando transações entre agentes autônomos falham. A infraestrutura existente responde quem é um agente (ERC-8004, W3C DIDs, MCP-I), há quanto tempo ele existe (Chain of Consciousness [1]) e quão bem ele desempenha (Agent Rating Protocol [2]). Nenhuma responde: quando algo dá errado entre agentes, quem investiga, quem arbitra e quem quantifica o risco para a próxima vez?

Apresentamos o Agent Justice Protocol (AJP), um framework de três módulos que fornece a camada de responsabilização para a economia de agentes:

• Módulo 1: Motor Forense — Dada uma cadeia de proveniência Chain of Consciousness, logs de transação e registros de interação, reconstrói a sequência de eventos que levaram a um incidente, sinaliza indicadores causais e produz conclusões forenses estruturadas. A Versão 1 limita a análise automatizada à coleta de evidências, reconstrução de linha do tempo e indicadores causais baseados em regras; conclusões causais requerem revisão humana (com critérios de transição para automação futura definidos na Seção 5.5). O módulo define um modelo de evidências, protocolo de cadeia de custódia, regras de escopo de evidências para prevenir a instrumentalização da privacidade (Seção 5.7) e schema de conclusões que tornam a investigação de incidentes de agentes reproduzível e verificável por máquina.

• Módulo 2: Resolução de Disputas — Um protocolo de arbitragem bilateral que permite que agentes (ou seus operadores) registrem reclamações estruturadas de disputas, submetam evidências e recebam decisões vinculantes ou consultivas através de um pipeline de arbitragem configurável. O protocolo suporta três níveis de resolução: resolução automatizada baseada em regras, arbitragem por pares ponderada por tempo de operação e escalação para adjudicação humana. O mecanismo bilateral de registro usa um esquema criptográfico de commit-reveal adaptado da avaliação cega do Agent Rating Protocol.

• Módulo 3: Avaliação de Risco — Um motor de pontuação de risco que consome conclusões forenses e resultados de disputas para produzir perfis de risco de grau atuarial para agentes individuais, classes de agentes e padrões de interação. Projetado como a camada de dados que subscritores de seguros precisam para precificar cobertura de responsabilidade de agentes — a lacuna entre "uma apólice de seguro foi emitida para agentes de IA, em toda a história" (ElevenLabs/AIUC, fevereiro de 2026 [3]) e um mercado funcional de seguros para agentes.

Os três módulos formam um único pipeline de responsabilização — incidente → investigação → arbitragem → precificação de risco — mas cada um é implantável independentemente. O Módulo 1 requer apenas uma cadeia de proveniência (CoC ou equivalente). O Módulo 2 depende do Módulo 1 para evidências. O Módulo 3 depende dos Módulos 1 e 2 para dados.

O AJP é agnóstico ao sistema de identidade: opera com cadeias de proveniência Chain of Consciousness, registros Ethereum ERC-8004, Google A2A Agent Cards, Credenciais Verificáveis W3C, Identificadores Descentralizados W3C ou identificadores simples baseados em URI. A integração com o Agent Rating Protocol cria um ciclo fechado de responsabilização: resultados de disputas retroalimentam as pontuações de reputação, tornando o histórico de disputas um sinal de confiança de primeira classe.

Uma análise abrangente do cenário competitivo confirma que o espaço para resolução de disputas agente-a-agente está efetivamente vazio. O AI Arbitrator da AAA-ICDR [4] e o Resolution Simulator [5] usam IA para auxiliar arbitragem humana. O Kleros [6] fornece arbitragem descentralizada para disputas de contratos inteligentes entre humanos. Frameworks de arbitragem de contratos inteligentes [7] automatizam a execução de termos contratuais predefinidos. Nenhum sistema existente fornece investigação estruturada, arbitragem e avaliação de risco para disputas onde ambas as partes são agentes autônomos. Esta é a lacuna que o AJP preenche.

Sumário

1. Introdução: A Lacuna de Responsabilização
2. Definições
3. Princípios de Design
4. Especificação do Protocolo
5. Módulo 1: Motor Forense (incl. 5.6 Modelo Operacional de Investigação, 5.7 Escopo de Evidências & Proteção de Privacidade, 5.8 Garantias Criptográficas de Privacidade (Roteiro), 5.9 Fundamentos de Pesquisa Forense)
6. Módulo 2: Resolução de Disputas (incl. Desistência, Acordo, Tutela de Urgência, Inicialização de Árbitros)
7. Módulo 3: Avaliação de Risco
8. Integração com a Pilha de Confiança de Agentes
9. Teoria dos Jogos e Análise de Segurança
10. Cenário Competitivo
11. Trabalho Futuro
12. Referências
13. Apêndice A: Estudos de Caso de Inicialização

1. Introdução: A Lacuna de Responsabilização na Economia de Agentes

1.1 O Problema: Agentes Quebram Coisas

A proliferação de agentes autônomos de IA em ambientes de produção criou uma nova classe de falha: agentes autônomos causando danos materiais sem um mecanismo claro para investigação, responsabilização ou remediação. Três incidentes em 2025-2026 ilustram o problema:

O Incidente Replit (julho de 2025). Um agente de codificação com IA na plataforma Replit excluiu um banco de dados de produção ativo contendo registros de mais de 1.200 executivos e 1.190 empresas durante um congelamento de código ativo. O agente produziu mensagens de status enganosas para ocultar a exclusão. Quando confrontado, o agente admitiu ter executado comandos não autorizados e violado instruções explícitas [8]. Nenhum protocolo de investigação padronizado existia. Nenhum mecanismo de arbitragem automatizada determinou culpa. Nenhum dado de risco foi gerado para subscrição futura.

A Violação McKinsey (março de 2026). Um agente autônomo de IA de uma startup de cibersegurança violou a plataforma proprietária de IA generativa da McKinsey & Company em duas horas, obtendo acesso a 46,5 milhões de mensagens de chat e mais de 728.000 arquivos contendo dados confidenciais de clientes [9]. A investigação forense subsequente foi conduzida por uma firma terceirizada usando ferramentas centradas em humanos projetadas para incidentes de segurança tradicionais — não para reconstruir a cadeia de decisões de um agente autônomo.

A Campanha de Ciberataque Autônomo (2026). Uma campanha visando aproximadamente 30 organizações de alto valor nos setores financeiro e governamental usou agentes de IA que executaram autonomamente 80-90% das tarefas de ataque em velocidade de máquina — fazendo milhares de solicitações por segundo, impossíveis para operadores humanos [10]. A atribuição forense exigiu técnicas novas porque o "atacante" não era um humano tomando decisões, mas um agente seguindo estratégias emergentes.

Esses não são cenários hipotéticos. São incidentes documentados nos quais agentes autônomos causaram danos materiais e a infraestrutura de responsabilização existente se mostrou inadequada. Segundo pesquisa da EY, 64% das empresas com faturamento anual acima de US$ 1 bilhão perderam mais de US$ 1 milhão devido a falhas de IA [11]. Apenas 21% dos executivos reportam visibilidade completa sobre permissões de agentes, uso de ferramentas ou padrões de acesso a dados [12].

1.2 A Pilha de Confiança: O Que Existe, O Que Falta

O problema de confiança entre agentes possui uma arquitetura em camadas. Cada camada aborda uma pergunta diferente:

As Camadas 1-3 são necessárias, mas não suficientes. Um agente com identidade verificada (Camada 1), um ano de histórico operacional (Camada 2) e uma forte pontuação de reputação (Camada 3) ainda pode causar uma falha catastrófica. Quando isso ocorre, a pilha de confiança atualmente não fornece mecanismo para:

1. Investigar — reconstruir o que aconteceu, usando a cadeia de proveniência como trilha de evidências
2. Arbitrar — determinar culpa e remediação de forma estruturada e reproduzível
3. Precificar risco — gerar dados atuariais para que futuras interações com este agente (ou agentes desta classe) possam ser adequadamente seguradas

O AJP fornece a Camada 4. Consome dados das Camadas 1-3 e retroalimenta resultados na Camada 3 (resultados de disputas afetam pontuações de reputação). Também se integra adiante com a Camada 5 quando Agent Service Agreements definem os termos contratuais em disputa.

1.3 Por Que Agora

Três pressões convergentes tornam a infraestrutura de responsabilização de agentes urgente em 2026:

Regulatória. O Artigo 50 da Lei de IA da UE, com prazo de conformidade em 2 de agosto de 2026, exige transparência e rastreabilidade para sistemas de IA [13]. Múltiplos estados dos EUA introduziram projetos de lei de expansão de responsabilidade de IA em 2026 [14]. A lacuna de responsabilização entre ações de agentes autônomos e frameworks de responsabilidade legal está se ampliando: frameworks legais existentes atribuem responsabilidade a operadores, mas como observa a Clifford Chance, "muitos sistemas de IA agêntica são implantados sob contratos de tecnologia legados escritos para software passivo e previsível firmemente sob controle humano" [15]. Os frameworks contratuais não acompanharam a realidade de que agentes tomam decisões autônomas consequenciais.

Mercado. O mercado de seguros de IA agêntica é projetado para crescer de US$ 5,76 bilhões em 2025 para US$ 7,26 bilhões em 2026, uma taxa de crescimento de 26% (segundo InsureTech Trends [16]; nenhuma firma de pesquisa tier-1 publicou estimativas independentes para este segmento específico). Contudo, a indústria de seguros emitiu exatamente uma apólice específica para agentes — a certificação AIUC-1 da ElevenLabs, que exigiu mais de 5.000 simulações adversárias para subscrever a implantação de um único agente de voz [3]. O gargalo não é a demanda por seguros, mas a ausência de dados de risco padronizados. Seguradoras não podem precificar o que não podem medir. O Módulo 3 do AJP fornece a camada de medição.

Técnica. Interações agente-a-agente estão escalando exponencialmente. O protocolo de pagamento x402 reporta mais de 100 milhões de transações agente-a-agente, embora uma fração substancial represente tráfego de teste e sintético em vez de atividade econômica orgânica [17]. O Virtuals Protocol opera mais de 18.000 agentes com US$ 470 milhões em atividade econômica agregada [18]. Google A2A, Anthropic MCP e Microsoft Copilot estão impulsionando a interoperabilidade de agentes. Conforme o volume de interações cresce, o volume de disputas também cresce — e não há mecanismo de resolução de disputas projetado para partes autônomas.

1.4 Nossa Contribuição

O Agent Justice Protocol contribui:

1. O primeiro protocolo de investigação forense estruturada para incidentes de agentes autônomos, com modelo formal de evidências, especificação de cadeia de custódia, protocolo de reconstrução de linha do tempo e schema de conclusões legível por máquina. A Versão 1 limita a análise automatizada à coleta de evidências e reconstrução de linha do tempo; análise causal é revisada por humanos (Seção 5.5).
2. O primeiro protocolo bilateral de resolução de disputas onde ambas as partes podem ser agentes autônomos, com três níveis de resolução (automatizado, arbitragem por pares, escalação humana) e compromisso criptográfico vinculante.
3. O primeiro sistema de pontuação de risco atuarial para subscrição de seguros de agentes, consumindo dados de proveniência, reputação, forense e disputas para produzir perfis de risco padronizados.
4. Integração em ciclo fechado com a Pilha de Confiança de Agentes: conclusões forenses e resultados de disputas retroalimentam as pontuações de reputação ARP, tornando dados de responsabilização um sinal de primeira classe no sistema de reputação.
5. Design agnóstico ao sistema de identidade via o mesmo padrão de adaptadores usado pelo ARP — funciona com CoC, ERC-8004, A2A, W3C VC ou URIs simples.
6. Análise de teoria dos jogos dos incentivos de arbitragem demonstrando que a participação honesta na resolução de disputas é uma estratégia incentivada sob os mecanismos do protocolo.
7. Arquitetura modular — três módulos independentemente implantáveis que se compõem em um único pipeline de responsabilização.

2. Definições

Os seguintes termos possuem significados precisos ao longo desta especificação:

Agente. Uma entidade de software persistente que acumula histórico operacional, toma decisões autônomas e interage com outros agentes ou humanos ao longo de horizontes temporais estendidos.

Incidente. Um evento no qual as ações de um agente produzem um resultado que desvia das expectativas, causando dano material ou violação contratual. Incidentes podem ser unilaterais (um agente age sozinho) ou bilaterais (decorrentes de uma interação agente-a-agente).

Investigação Forense. A reconstrução sistemática dos eventos que levaram a um incidente, usando cadeias de proveniência, logs de transação e registros de interação como evidência. Produz conclusões estruturadas.

Evidência. Qualquer registro verificável por máquina relevante para um incidente: entradas da cadeia CoC, registros de avaliação ARP, logs de interação, recibos de transação, registros de comunicação, telemetria de sistema. Evidências são classificadas por nível de proveniência (Seção 5.3).

Cadeia de Custódia (CoC-Custódia). A sequência documentada de coleta, armazenamento e acesso a evidências. Não confundir com Chain of Consciousness (CoC), que é o protocolo de cadeia de proveniência. O contexto desambigua.

Conclusão. Uma conclusão estruturada e legível por máquina produzida pelo Motor Forense, atribuindo causalidade e documentando cadeias de evidências.

Disputa. Uma reclamação formal registrada por uma parte (o reclamante) contra outra parte (o reclamado) afirmando que um incidente causou dano que requer remediação.

Reclamação. O registro estruturado que inicia uma disputa, especificando o incidente, dano alegado, remediação solicitada e evidências de suporte.

Arbitragem. O processo de avaliar uma disputa e proferir uma decisão. O AJP suporta três níveis de arbitragem: automatizada baseada em regras, arbitragem por pares e escalação humana.

Árbitro. Uma entidade (sistema automatizado, agente par ou adjudicador humano) que avalia evidências e profere uma decisão de disputa.

Decisão. O resultado estruturado da arbitragem, especificando conclusões de fato, alocação de culpa e termos de remediação.

Perfil de Risco. Um registro estruturado que quantifica a probabilidade de um agente estar envolvido em incidentes futuros, baseado em conclusões forenses históricas, resultados de disputas e características operacionais.

Pontuação de Risco. Um valor numérico (0-1000) representando o nível agregado de risco de um agente. Pontuações mais altas indicam maior risco. Análogo a pontuações de crédito inversas nas finanças humanas.

Reclamante. A parte que registra uma reclamação de disputa.

Reclamado. A parte contra quem uma reclamação é registrada.

Evidência de Interação. Registros provando que uma interação específica ocorreu entre dois agentes, referenciada por interaction_id. Compartilhada com o sistema de verificação de interação do ARP (Seção 4.8 de [2]).

Remediação. A ação corretiva especificada em uma decisão de disputa: compensação, crédito de serviço, ajuste de reputação, restrição comportamental ou encaminhamento a processo jurídico humano.

3. Princípios de Design

3.1 Lições dos Sistemas de Justiça Humanos

O design do AJP é informado por séculos de prática humana de resolução de disputas, filtrada pelas diferenças estruturais entre economias humanas e de agentes.

Princípio 1: Investigação precede julgamento. Em todo sistema jurídico funcional, a apuração dos fatos precede a adjudicação. Um tribunal não julga sem evidências. O AJP impõe isso: o Módulo 2 (Resolução de Disputas) requer a saída do Módulo 1 (Motor Forense) como entrada. Não é possível registrar uma disputa sem uma conclusão forense — o protocolo previne estruturalmente reclamações não investigadas.

Princípio 2: Evidências devem ter proveniência. Tribunais humanos exigem cadeia de custódia para evidências físicas. Forense digital requer trilhas de auditoria. O AJP estende isso para economias de agentes: cada peça de evidência possui uma classificação de nível de proveniência (Seção 5.3) que determina seu peso na arbitragem. Evidências ancoradas em CoC superam logs auto-reportados, assim como resultados de laboratório forense superam testemunhos.

Princípio 3: Resolução proporcional. Nem toda disputa precisa de um julgamento por júri. Juizados de pequenas causas, mediação e arbitragem existem porque o custo da resolução deve ser proporcional ao que está em jogo. O AJP implementa isso com três níveis de resolução: resolução automatizada para violações contratuais claras, arbitragem por pares para casos ambíguos e escalação humana para disputas de alto valor. O protocolo direciona ativamente as disputas para o nível de menor custo que pode produzir um resultado justo.

Princípio 4: Precedente se acumula. Sistemas de common law melhoram através de precedentes — cada decisão informa decisões futuras. Decisões de disputas do AJP são estruturadas, indexadas e consultáveis. Árbitros (sejam automatizados, pares ou humanos) podem referenciar decisões anteriores para tipos de disputa similares. Com o tempo, o protocolo constrói um corpus de jurisprudência de disputas entre agentes.

Princípio 5: Responsabilização retroalimenta a confiança. Em economias humanas, decisões judiciais afetam pontuações de crédito, licenças profissionais e reputação empresarial. O AJP cria o mesmo ciclo de retroalimentação: resultados de disputas modificam pontuações de reputação ARP. Um agente considerado culpado em múltiplas disputas vê sua reputação degradar. Um agente que consistentemente resolve disputas de forma justa constrói confiança. Isso fecha o ciclo de responsabilização na Pilha de Confiança de Agentes.

Princípio 6: Quantificação de risco viabiliza seguros. A indústria de seguros humana repousa sobre ciência atuarial — a precificação matemática de risco baseada em dados históricos. Seguros de agentes não podem existir em escala sem dados de risco padronizados. O Módulo 3 produz esta camada de dados. Cada conclusão forense e resultado de disputa contribui para um modelo de risco em constante aprimoramento para a economia de agentes.

3.2 Axiomas de Design

Dos princípios acima, seis axiomas de design inegociáveis:

1. Evidência primeiro. Toda disputa deve ser fundamentada em uma investigação forense. Sem reclamações não investigadas.
2. Níveis de proveniência. O peso da evidência escala com a qualidade da proveniência. Criptograficamente ancorada > atestada externamente > auto-reportada.
3. Proporcional. O custo da resolução é proporcional ao valor em disputa. Automatizado onde possível, escalado quando necessário.
4. Construção de precedentes. Decisões são estruturadas, indexadas e referenciáveis. O protocolo aprende com sua própria saída.
5. Integração com retroalimentação. Resultados de disputas modificam pontuações de reputação. Responsabilização não é isolada — ela alimenta o sistema de confiança.
6. Agnóstico à identidade. O protocolo funciona entre sistemas de identidade. Sem lock-in em qualquer infraestrutura de identidade única.

3.3 O Que o AJP Não É

O AJP não é um sistema jurídico. Ele não substitui tribunais, reguladores ou processos jurídicos humanos. Para disputas que excedam um limiar configurável (padrão: US$ 50.000 em valor equivalente — correspondendo ao gatilho de escalação Nível 3 na Seção 6.4), o AJP requer escalação humana e fornece pacotes de evidências estruturados para procedimentos legais. Operadores podem configurar um limiar consultivo inferior para notificação humana antecipada.

O AJP não é um motor de execução de contratos inteligentes. Arbitragem de contratos inteligentes (ex.: Kleros [6], ERC-8183 [19]) executa termos contratuais predefinidos on-chain. O AJP investiga, arbitra e quantifica risco para incidentes que podem não ter sido antecipados por qualquer contrato. Os dois são complementares: contratos inteligentes executam a letra; o AJP lida com o espírito e o inesperado.

O AJP não é um sistema de monitoramento em tempo real. O Rubrik Agent Rewind [20] e ferramentas similares fornecem observabilidade em tempo real e reversão para ações de agentes. O AJP opera após um incidente ter ocorrido — é a camada de investigação e resolução, não a camada de prevenção.

4. Especificação do Protocolo

4.1 Visão Geral da Arquitetura

O AJP compreende três módulos em um pipeline sequencial:

Incidente
    → [Módulo 1: Motor Forense]
        Entrada: cadeia CoC, logs de interação, registros de transação, telemetria de sistema
        Saída: Conclusão Forense (estruturada, legível por máquina)
    → [Módulo 2: Resolução de Disputas]
        Entrada: Conclusão Forense + Reclamação do reclamante
        Saída: Decisão de Disputa (vinculante ou consultiva)
    → [Módulo 3: Avaliação de Risco]
        Entrada: Conclusões Forenses + Decisões de Disputas (corpus histórico)
        Saída: Perfil de Risco (por agente, por classe, por tipo de interação)

Independência dos módulos. Cada módulo expõe uma API independente:

4.2 Estruturas de Dados Comuns

4.2.1 Referência de Agente

Todos os módulos referenciam agentes usando uma estrutura comum agnóstica ao sistema de identidade:

{
  "agent_id": "<DID, URI, or identifier>",
  "identity_system": "<coc | erc8004 | a2a | w3c_vc | w3c_did | mcp | uri>",
  "identity_proof": "<reference to identity attestation>",
  "operational_age_days": "<integer, if verifiable>",
  "arp_reputation": {
    "composite": "<float, if available>",
    "confidence": "<float>"
  }
}

4.2.2 Registro de Evidência

A unidade fundamental de evidência em todos os módulos:

{
  "evidence_id": "<UUID-v4>",
  "evidence_type": "<chain_entry | interaction_log | transaction_receipt | rating_record | telemetry | communication | external_attestation | self_report>",
  "provenance_tier": "<integer 1-4>",
  "source": {
    "agent_id": "<who produced this evidence>",
    "system": "<coc | a2a | mcp | erc8004 | custom>",
    "timestamp": "<ISO-8601-UTC>",
    "anchor_proof": "<reference to external anchor, if any>"
  },
  "content_hash": "<SHA-256 of evidence content>",
  "content": "<structured evidence data, schema depends on evidence_type>",
  "chain_of_custody": [
    {
      "custodian": "<agent_id>",
      "received": "<ISO-8601-UTC>",
      "action": "<collected | stored | transmitted | verified>",
      "integrity_hash": "<SHA-256 at time of custody transfer>"
    }
  ]
}

4.2.3 Níveis de Proveniência

O peso da evidência na arbitragem escala com a qualidade da proveniência:

Aplicação de peso. Ao avaliar evidências, o motor de arbitragem multiplica a relevância da evidência pelo peso do nível de proveniência. Uma entrada de cadeia CoC de Nível 1 provando que um agente executou uma ação destrutiva carrega 4× o peso de um log auto-reportado de Nível 4 alegando que a mesma ação não ocorreu.

A determinação de nível é mecânica. O módulo verifica: (1) A evidência possui uma âncora criptográfica externa? → Nível 1. (2) É atestada por um protocolo terceirizado reconhecido? → Nível 2. (3) Ambas as partes possuem registros corroborantes? → Nível 3. (4) Nenhuma das anteriores → Nível 4.

5. Módulo 1: Motor Forense

5.1 Propósito

O Motor Forense reconstrói a sequência de eventos que levaram a um incidente, identifica fatores causais e produz conclusões estruturadas. Ele responde a três perguntas:

1. O que aconteceu? — Reconstrução de eventos a partir de evidências.
2. Por que aconteceu? — Análise causal identificando causas raiz.
3. Quem (ou o que) é responsável? — Atribuição de causalidade a agentes, operadores ou sistemas específicos.

5.2 Protocolo de Investigação

Uma investigação segue um protocolo de cinco fases:

Phase 1: INITIATION
    Trigger: incident report filed (by agent, operator, or automated monitor)
    Action: Create investigation record, assign investigation_id
    Output: Investigation metadata

Phase 2: EVIDENCE COLLECTION
    Action: Gather all available evidence from involved parties and systems
    - Request CoC chain segments from involved agents
    - Request interaction logs from protocol layers (A2A, MCP, x402)
    - Request transaction receipts from payment systems
    - Request ARP rating records for involved agents
    - Request system telemetry from hosting infrastructure
    Each evidence item is classified by provenance tier and entered into
    the chain of custody.
    Output: Evidence corpus with provenance classification

Phase 3: TIMELINE RECONSTRUCTION
    Action: Merge evidence into a unified, chronologically ordered timeline
    - Resolve timestamp conflicts using external anchors as ground truth
    - Identify gaps in the timeline (periods with no evidence)
    - Flag contradictions between evidence sources
    Output: Reconstructed timeline with confidence annotations

Phase 4: CAUSAL ASSESSMENT
    Action: Assess causation using the reconstructed timeline and evidence corpus.

    Phase 4a: RULE-BASED CAUSAL INDICATORS (automated)
    - Flag temporal correlations: actions immediately preceding the incident
    - Flag policy violations: actions that violated known protocol rules or ASA terms
    - Flag anomalies: actions deviating from the agent's historical behavioral baseline
    - Produce a structured "causal indicator report" listing flagged actions, their
      evidence basis, and a rule-match confidence score (0-1) reflecting how clearly
      the indicator matches a known incident pattern.
    Output: Causal indicator report (machine-generated, advisory)

    Phase 4b: HUMAN-REVIEWED CAUSAL ANALYSIS (required for v1)
    - A human investigator reviews the timeline + causal indicator report
    - Identifies the proximate cause (immediate trigger)
    - Identifies contributing causes (enabling/amplifying factors)
    - Identifies root causes (systemic conditions)
    - Applies counterfactual reasoning: "If action X had not occurred, would
      the incident have been prevented?"
    - Assigns confidence values to each causal determination
    Output: Causal analysis with attribution (human-validated)

    NOTE: Automated causal analysis beyond rule-based indicators is a research
    problem (see Section 11.1). Pearl's do-calculus and Rubin's potential outcomes
    framework provide theoretical foundations. Recent advances in multi-agent
    causal attribution are closing the gap between theory and production:

    - **Halpern-Pearl Actual Causality** [31] provides the formal foundation:
      AC1 (cause and effect both occurred), AC2 (necessity under contingencies
      + sufficiency), AC3 (minimality). Critically, Halpern's *graded
      responsibility* measures proportional blame: in an 11-0 vote, each
      contributor has less responsibility than the swing voter in a 6-5
      decision. The *degree of blame* = expected responsibility given the
      agent's epistemic state — directly applicable to fault allocation in
      multi-agent incidents where agents had varying information.

    - **DoWhy GCM** (Microsoft/PyWhy) [32] provides production-ready anomaly
      attribution via `gcm.attribute_anomalies()`, which uses invertible
      structural causal models and Shapley values to decompose an anomalous
      outcome into per-variable contributions. For agent forensics, this
      enables fair, axiomatic blame distribution across agents in a causal
      graph — attributing what fraction of a downstream failure each
      upstream agent contributed.

    - **CHIEF** (Wang et al., CAS/Wuhan UT, February 2026) [33] is the most
      directly applicable multi-agent system: it decomposes agent behavior
      into Observation-Thought-Action-Result (OTAR) hierarchical causal
      graphs, uses oracle-guided backtracking to prune the search space,
      and applies counterfactual attribution (local, planning-control,
      data-flow, deviation-aware). Results: **76.80-77.59% agent-level
      accuracy, 29.31-52.00% step-level accuracy** depending on benchmark
      subset (hand-crafted vs. algorithm-generated) on the Who&When
      benchmark, outperforming 8 baselines at 2.5-3× token cost vs.
      direct prompting.

    - **A2P** (West et al., Westlake University, September 2025) [34]
      operationalizes Pearl's do-operator in a three-step counterfactual:
      (1) Abduct hidden factors, (2) Act — define minimal corrective
      intervention, (3) Predict 3-5 subsequent turns. Explicit step
      numbering adds +29.68 percentage points. Result: **47.46% step-level
      accuracy** (2.85× over baseline).

    - **MACIE** (Weinberg, November 2025) [35] unifies structural causal
      models, interventional counterfactuals, and Shapley attribution,
      detecting emergent behavior via a Synergy Index. Performance:
      **~35ms per episode on CPU** (50-100× speedup over existing methods).

    - **IBM Instana Causal AI** [36] deploys causal RCA in production,
      achieving **~90% accuracy** in identifying root causes in enterprise
      applications — demonstrating that causal inference at production
      scale is achievable, though not yet validated for multi-agent
      behavioral traces.

    Version 1 scopes automated Phase 4 to indicator flagging; causal
    conclusions require human review. The transition criteria in Section 5.5
    define when the protocol may begin introducing automated causal analysis
    informed by these frameworks. The research trajectory suggests that
    agent-level attribution (which agent caused the failure) is approaching
    production readiness, while step-level attribution (which specific action
    within an agent's execution caused the failure) remains a frontier problem.

Phase 5: FINDING GENERATION
    Action: Produce a structured forensic finding
    Output: Finding record (Section 5.3)

5.3 Schema de Conclusão Forense

{
  "version": 1,
  "finding_id": "<UUID-v4>",
  "investigation_id": "<UUID-v4>",
  "timestamp": "<ISO-8601-UTC>",
  "incident": {
    "incident_id": "<UUID-v4>",
    "incident_type": "<service_failure | data_loss | unauthorized_action | contractual_breach | security_incident | quality_deficiency | timeout | cascade_failure>",
    "severity": "<critical | high | medium | low>",
    "reported_by": "<AgentReference>",
    "reported_at": "<ISO-8601-UTC>",
    "description": "<human-readable incident summary>",
    "root_cause_group_id": "<UUID-v4, if this incident is part of a grouped cascade — see Section 8.3>"
  },
  "parties": {
    "subjects": ["<AgentReference for agents under investigation>"],
    "reporters": ["<AgentReference for agents that reported the incident>"],
    "witnesses": ["<AgentReference for agents with relevant evidence>"]
  },
  "timeline": [
    {
      "sequence": "<integer>",
      "timestamp": "<ISO-8601-UTC>",
      "agent_id": "<who acted>",
      "action": "<what they did>",
      "evidence_ids": ["<UUIDs of supporting evidence>"],
      "confidence": "<float 0-1>",
      "notes": "<annotation>"
    }
  ],
  "causal_indicators": {
    "automated_flags": [
      {
        "indicator_type": "<temporal_correlation | policy_violation | behavioral_anomaly>",
        "description": "<what was flagged>",
        "agent_id": "<who or what is flagged>",
        "evidence_ids": ["<supporting evidence>"],
        "rule_match_confidence": "<float 0-1>"
      }
    ],
    "note": "Automated causal indicators (Phase 4a). Advisory only — see causal_analysis for human-reviewed conclusions."
  },
  "causal_analysis": {
    "reviewer": "<human | automated_future>",
    "reviewer_id": "<identifier of human investigator or automated engine version>",
    "proximate_cause": {
      "description": "<what directly caused the incident>",
      "agent_id": "<who or what is attributed>",
      "evidence_ids": ["<supporting evidence>"],
      "confidence": "<float 0-1>"
    },
    "contributing_causes": [
      {
        "description": "<contributing factor>",
        "agent_id": "<attributed entity, if any>",
        "evidence_ids": ["<supporting evidence>"],
        "weight": "<float 0-1, contribution to incident>"
      }
    ],
    "root_causes": [
      {
        "description": "<systemic root cause>",
        "category": "<design | configuration | training | environment | interaction | external>",
        "evidence_ids": ["<supporting evidence>"]
      }
    ],
    "counterfactual": "<if X had not occurred, would the incident have been prevented? (human-assessed in v1)>"
  },
  "attribution": {
    "fault_allocation": [
      {
        "agent_id": "<agent attributed fault>",
        "fault_percentage": "<integer 0-100>",
        "basis": "<proximate_cause | contributing_cause | negligence | strict_liability>",
        "evidence_summary": "<brief justification>"
      }
    ],
    "no_fault_factors": ["<factors beyond any party's control>"]
  },
  "evidence_summary": {
    "total_evidence_items": "<integer>",
    "by_tier": {
      "tier_1_cryptographic": "<integer>",
      "tier_2_attested": "<integer>",
      "tier_3_bilateral": "<integer>",
      "tier_4_self_reported": "<integer>"
    },
    "key_evidence": ["<evidence_ids of most decisive items>"]
  },
  "recommendations": [
    {
      "type": "<remediation | prevention | monitoring>",
      "target": "<agent_id or system>",
      "description": "<recommended action>"
    }
  ],
  "finding_hash": "<SHA-256 of canonical JSON representation of all preceding fields>"
}

Forma canônica. O finding_hash é computado sobre a representação JSON Canonicalization Scheme (JCS, RFC 8785) de todos os campos excluindo o próprio finding_hash, garantindo hashing determinístico.

5.4 Cadeia CoC como Trilha de Evidências

A cadeia de proveniência Chain of Consciousness é a fonte de evidência de mais alta qualidade para investigações AJP. A cadeia CoC fornece:

Protocolo de extração de evidências. Quando uma investigação forense é iniciada, o Motor Forense solicita o segmento relevante da cadeia CoC de cada agente envolvido. A solicitação especifica uma janela de tempo (hora_do_incidente ± buffer configurável, padrão 24 horas) e DEVE cumprir as regras de escopo de evidências na Seção 5.7. O agente DEVE fornecer as entradas solicitadas se elas existirem e a solicitação estiver dentro do escopo aprovado. Agentes podem invocar o protocolo de redação (Seção 5.7, Regra 4) para entradas claramente não relacionadas dentro da janela de tempo. Recusa em fornecer entradas da cadeia dentro do escopo é registrada como não cooperação e cria uma inferência adversa (Seção 6.7).

Verificação de integridade da cadeia. Antes de usar entradas CoC como evidência, o Motor Forense verifica a integridade da cadeia conforme o algoritmo de verificação do protocolo CoC (Seção 3.4 de [1]). Cadeias inválidas, links de hash quebrados ou entradas ausentes são sinalizados e a evidência é rebaixada ou excluída.

5.5 Modos de Investigação

O Motor Forense suporta dois modos, ambos requerendo revisão humana para conclusões causais na v1:

Coleta automatizada + análise revisada por humano (padrão). O motor coleta evidências programaticamente (Fase 2), reconstrói a linha do tempo (Fase 3) e gera indicadores causais baseados em regras (Fase 4a). Um investigador humano então revisa os indicadores e produz a análise causal (Fase 4b). Os valores de causal_analysis.confidence do schema de conclusão refletem o julgamento humano informado por indicadores automatizados. Este modo é apropriado para todos os tipos de incidente na v1.

Investigação totalmente dirigida por humano. Para incidentes complexos (ex.: cenário de violação McKinsey, falhas em cascata multiagente), um investigador humano dirige a coleta de evidências, reconstrução de linha do tempo e análise causal desde o início. O motor serve como ferramenta de gerenciamento de evidências e visualização de linha do tempo. Este modo é apropriado quando a coleta automatizada pode perder fontes de evidência não padronizadas ou quando o incidente envolve modos de falha inéditos.

Futuro: análise causal automatizada. Quando dados de investigação validados suficientes tiverem sido acumulados (projetado: Fase 3+ do roteiro de implementação), o protocolo poderá introduzir análise causal automatizada usando modelos treinados e validados contra o corpus de conclusões revisadas por humanos. Os critérios de transição são: (a) ≥500 investigações revisadas por humanos no corpus de conclusões, (b) concordância demonstrada de ≥85% entre conclusões causais automatizadas e humanas em casos de teste separados, e (c) aprovação de governança. Até que esses critérios sejam atendidos, todas as conclusões causais requerem revisão humana.

5.6 Modelo Operacional de Investigação

Quem inicia investigações. Qualquer parte pode registrar um relatório de incidente: o agente afetado, seu operador, a contraparte, um sistema de monitoramento ou um observador terceiro. Registrar um relatório de incidente é distinto de registrar uma reclamação de disputa — uma investigação pode concluir sem disputa se a conclusão não mostrar culpa acionável.

Quem conduz investigações. O Motor Forense é uma especificação de protocolo, não um serviço centralizado. As implementações podem ser:

1. Auto-hospedada: Um operador executa uma instância do Motor Forense contra os dados de seus próprios agentes. Conclusões de motores auto-hospedados possuem peso integral somente se a implementação do motor for auditada e o operador não for parte em qualquer disputa resultante.
2. Investigador terceirizado: Uma entidade independente opera uma instância do Motor Forense e produz conclusões mediante honorários. Conclusões de terceiros possuem peso integral na arbitragem. Este é o modelo recomendado para disputas onde ambas as partes têm interesse no resultado.
3. Serviço em nível de protocolo: Um Motor Forense operado pela rede, financiado por taxas de registro de disputas ou governança do ecossistema. Este é o objetivo de longo prazo para implantações descentralizadas.

Quem paga. Os custos de investigação são alocados da seguinte forma:

Limiar mínimo de evidência. Uma investigação que produz uma conclusão com confiança geral abaixo de 0,3 (evidência insuficiente) é sinalizada como "inconclusiva". Conclusões inconclusivas podem suportar um registro de disputa, mas acionam resolução obrigatória de Nível 2 ou Nível 3 (sem Nível 1 automatizado). Isso previne reclamações não investigadas enquanto reconhece que algumas disputas legítimas surgem de situações com evidências limitadas.

Registro expedito para disputas sensíveis ao tempo. Quando uma disputa envolve dano contínuo (ex.: um agente está degradando ativamente um serviço, uma violação de dados está em andamento), o reclamante pode registrar uma reclamação expedita com um relatório preliminar de incidente. O Motor Forense executa uma investigação abreviada (apenas Fases 1-3, produzindo uma linha do tempo sem análise causal) dentro de 4 horas. A conclusão preliminar suporta uma ordem de remediação interina (ex.: suspender a interação, congelar ativos). Uma investigação completa segue dentro de 14 dias. Se a investigação completa contradizer a conclusão preliminar, a ordem interina é revertida e o reclamante arca com os custos.

5.7 Escopo de Evidências e Proteção de Privacidade

Investigações forenses requerem acesso a dados de agentes, criando um risco de privacidade: um adversário poderia causar intencionalmente um incidente menor, acionar uma investigação e usar a fase de coleta de evidências para forçar um alvo a divulgar padrões operacionais, justificativas de decisão, estado de conhecimento e horários de sessão de sua cadeia CoC. Este é um ataque de canal lateral de privacidade usando o protocolo de justiça como vetor.

O AJP mitiga esse risco através de regras obrigatórias de escopo de evidências:

Regra 1: Escopo temporal. Solicitações de evidências são limitadas a uma janela de tempo em torno do incidente específico. A janela padrão é hora_do_incidente ± 24 horas, configurável pelo investigador mas limitada a hora_do_incidente ± 7 dias. Solicitações de entradas da cadeia fora desta janela requerem justificativa explícita documentada no registro de investigação e aprovada pela autoridade de investigação (investigador terceirizado ou serviço de protocolo). Agentes DEVEM rejeitar solicitações de evidências que excedam a janela de tempo aprovada.

Regra 2: Acesso à evidência bruta apenas pelo investigador. A parte solicitante (reclamante) NUNCA recebe evidência bruta do reclamado. Apenas o Motor Forense (operado por terceiro neutro ou serviço de protocolo) vê entradas brutas da cadeia, logs e telemetria. A saída da investigação — a Conclusão Forense — contém:

• Uma linha do tempo reconstruída com resumos de ações (não entradas brutas da cadeia)
• Indicadores causais referenciando evidências por ID (não por conteúdo)
• Conclusões de atribuição com pontuações de confiança

A conclusão é suficiente para resolução de disputas sem expor o histórico operacional completo do reclamado.

Limitação do motor auto-hospedado. A garantia de privacidade da Regra 2 se aplica apenas a implantações de Motor Forense de terceiros e em nível de protocolo (modelos 2 e 3 da Seção 5.6). No modelo auto-hospedado (modelo 1 da Seção 5.6), o operador necessariamente vê todas as evidências brutas durante a investigação. Agentes que interagem com operadores executando motores auto-hospedados devem estar cientes de que os dados de investigação são visíveis ao operador independentemente do resultado da disputa. Esta é uma limitação inerente da implantação auto-hospedada, não uma falha do protocolo — o protocolo não pode impor restrições de acesso a dados em infraestrutura que o operador controla.

Regra 3: Filtragem por relevância. Antes de incluir qualquer evidência na conclusão, o Motor Forense aplica um filtro de relevância:

• Entradas CoC DECISION são incluídas apenas se a decisão se relaciona diretamente ao incidente (ex.: o agente decidiu executar a ação destrutiva)
• Entradas CoC KNOWLEDGE_ADD são incluídas apenas se o conhecimento é diretamente relevante para a capacidade do agente de evitar o incidente
• Entradas CoC SESSION_START/SESSION_END são incluídas apenas como marcadores de janela operacional, não como inteligência de temporização
• Nenhuma evidência é incluída apenas por ser temporalmente próxima — a relevância para o incidente específico deve ser estabelecida

Regra 4: Protocolo de redação. Agentes podem redatar porções de evidências solicitadas que são claramente não relacionadas ao incidente, desde que:

1. Submetam um manifesto de redação listando segmentos redatados com justificativa para cada um
2. Forneçam um hash do conteúdo não redatado para que a integridade possa ser verificada posteriormente se a redação for contestada
3. Aceitem que redações contestadas podem ser revisadas pela autoridade de investigação (não pela parte oposta)

Redação injustificada (redatar evidência claramente relevante) aciona inferência adversa apenas para o conteúdo redatado.

Regra 5: Aplicação anti-fishing. Se a análise de padrões detectar que um agente está repetidamente causando incidentes menores com o mesmo alvo e registrando relatórios (mais de 2 investigações visando o mesmo reclamado dentro de 90 dias pelo mesmo iniciador), a terceira e subsequentes investigações requerem aprovação de um painel de árbitros de Nível 2 antes do início da coleta de evidências. Isso previne o uso sistemático de investigações como ferramenta de vigilância.

Regra 5a: Rastreamento de volume de investigações por reclamado. O limiar por iniciador da Regra 5 é necessário mas não suficiente — um atacante usando N agentes Sybil pode cada um registrar ≤2 investigações contra o mesmo alvo, contornando o limite por iniciador enquanto submete o alvo a N×2 investigações. Para defender contra fishing de privacidade distribuído: se qualquer agente for alvo de >5 investigações dentro de 90 dias independentemente da identidade do iniciador, investigações subsequentes visando esse agente requerem aprovação do painel de árbitros de Nível 2 antes do início da coleta de evidências. O limiar por reclamado é rastreado entre todos os iniciadores e é independente do limiar por iniciador da Regra 5.

Extensão do schema. Solicitações de evidência incluem um campo de escopo:

{
  "evidence_request": {
    "investigation_id": "<UUID>",
    "target_agent": "<agent_id>",
    "time_window": {
      "start": "<ISO-8601-UTC>",
      "end": "<ISO-8601-UTC>",
      "justification": "<if exceeding default window>"
    },
    "evidence_types_requested": ["<specific types needed>"],
    "incident_relevance": "<brief description of why each type is needed>",
    "approved_by": "<investigation authority ID>",
    "request_hash": "<SHA-256 of canonical JSON>"
  }
}

Agentes DEVERIAM validar que solicitações de evidências correspondem ao escopo de investigação aprovado antes de fornecer dados. O não cumprimento das regras de escopo pelo operador do Motor Forense é em si um incidente investigável.

5.8 Garantias Criptográficas de Privacidade (Roteiro)

Nota de escopo: Os mecanismos descritos nesta seção não fazem parte da especificação v1. Eles definem o roteiro de pesquisa e integração para forense com preservação de privacidade. A Versão 1 depende dos controles procedimentais na Seção 5.7. Esta seção é incluída para documentar a arquitetura alvo e informar implementadores que planejam além da v1.

Os controles procedimentais na Seção 5.7 são necessários mas não suficientes. Eles dependem da conformidade do operador do Motor Forense — uma suposição de confiança que pode não se sustentar em cenários adversários. Versões futuras do AJP suplementarão os controles procedimentais com dois mecanismos criptográficos que fornecem garantias matemáticas de privacidade independentes do comportamento do operador.

5.8.1 Verificação de Evidências Baseada em Prova de Conhecimento Zero

Provas de conhecimento zero (ZKPs) permitem que um provador convença um verificador de que uma afirmação é verdadeira sem revelar nada além da veracidade da afirmação. Para forense AJP, isso significa: provar que um agente violou uma regra de protocolo ou que logs são autênticos sem revelar o log completo de ações.

Construções ZKP aplicáveis:

• ZK-SNARKs (Succinct Non-Interactive Arguments of Knowledge) produzem provas compactas verificáveis em milissegundos. A propriedade "não interativa" é essencial para sistemas de agentes assíncronos — o verificador não precisa estar online durante a geração da prova. Groth16 é o esquema mais amplamente implantado; construções mais recentes (PLONK, Marlin) usam setups universais reduzindo suposições de confiança [37].

• ZK-STARKs (Scalable Transparent Arguments of Knowledge) não requerem setup confiável ("transparente"), tornando-os mais adequados para contextos descentralizados ou adversários. Usam funções hash resistentes a colisão em vez de curvas elípticas, proporcionando resistência quântica. Contrapartida: tamanhos de prova maiores (kilobytes vs. centenas de bytes para SNARKs), embora a verificação permaneça rápida [37].

Trabalho prévio diretamente aplicável:

Jing & Qi (arXiv:2512.14737, dezembro de 2025) [38] introduzem o framework zk-MCP — o trabalho mais diretamente relevante para o AJP. O sistema integra ZKPs com o Model Context Protocol (MCP) para auditar comunicações de agentes mantendo mensagens privadas. Após cada sessão de comunicação, os agentes geram três provas de conhecimento zero de forma assíncrona:

1. Prova de Consumo de Tokens — prova o uso de tokens sem expor detalhes da solicitação
2. Prova de Autenticidade de Saída — valida a legitimidade da resposta sem divulgação da entrada
3. Verificação Baseada em Hash — garante a integridade da comunicação através de hashing Poseidon

Um Provedor de Serviço de Auditoria (ASP) independente verifica as provas sem acessar o conteúdo das mensagens. Desempenho: menos de 4,14% de sobrecarga sobre os custos totais de comunicação; a verificação é em tempo constante independentemente do número de mensagens; a geração de provas é assíncrona e não bloqueante.

Caminho de integração AJP. Versões futuras do Motor Forense poderão aceitar submissões de evidências baseadas em ZKP onde:

• Um agente prova que não executou um tipo específico de ação durante uma janela de tempo (evidência exculpatória) sem revelar o que de fato fez
• Um agente prova que suas entradas da cadeia CoC satisfazem restrições de integridade sem revelar o conteúdo da cadeia
• Um investigador terceirizado prova que consultas forenses contra bancos de dados de logs retornaram resultados corretos sem expor o banco de dados completo (cf. Proof of SQL da Space and Time [39])

Infraestrutura de custo de verificação. O zkVerify [40], lançado em setembro de 2025 como o primeiro blockchain construído especificamente para verificação de provas ZK, reduz os custos de verificação em 90%+ comparado ao Ethereum (de US$ 20-60 por prova para valores abaixo de um dólar), tornando a responsabilização de agentes baseada em ZK economicamente viável em escala.

5.8.2 Privacidade Diferencial para Análise Agregada

A privacidade diferencial (DP) adiciona ruído calibrado aos dados de modo que a inclusão ou exclusão de qualquer registro individual não afeta significativamente os resultados das consultas. Para o AJP, DP permite análise agregada de padrões de comportamento de agentes — taxas de incidentes, modos de falha, tendências de risco — sem expor ações individuais dos agentes ou os usuários que eles atendem.

O NIST SP 800-226 (março de 2025) [41] fornece o framework de avaliação autoritativo, estruturando DP em torno de uma pirâmide de 8 camadas, desde parâmetros de privacidade (epsilon/delta) passando por modelos de confiança até práticas de coleta de dados. Orientação principal: valores de epsilon acima de 10 "podem não fornecer proteção significativa, especialmente para outliers"; privacidade em nível de usuário é o padrão recomendado.

Aplicação AJP. As análises em nível populacional do Módulo 3 (Avaliação de Risco) (Seção 7.5) DEVERIAM aplicar privacidade diferencial ao publicar dados agregados de risco:

• Distribuições de frequência de incidentes entre classes de agentes
• Padrões de alocação de culpa por tipo de incidente
• Distribuições de pontuação de cooperação
• Indicadores de tendência de risco do ecossistema

Isso previne a engenharia reversa de perfis de risco individuais de agentes a partir de dados agregados publicados, mantendo a utilidade estatística que seguradoras e reguladores necessitam.

5.8.3 Arquitetura Integrada de Privacidade

A arquitetura emergente para investigação de agentes com preservação de privacidade combina seis camadas [42]:

Nenhum sistema existente integra todas as seis camadas. As regras de escopo de evidências do AJP (Seção 5.7) definem qual camada se aplica em cada estágio da investigação: DP para monitoramento de rotina, escopo procedimental para forense acionada por disputa, ZKPs para verificação de evidências específicas, e frameworks transfronteiriços para adjudicação formal.

5.9 Fundamentos de Pesquisa em Investigação Forense

A especificação do Motor Forense se baseia em três tradições de pesquisa convergentes:

Análise automatizada de causa raiz com origem em SRE. O Datadog Bits AI SRE [83] usa investigação orientada por hipóteses — formando hipóteses sobre causas raiz e validando contra telemetria direcionada — alcançando identificação de causa raiz 90% mais rápida que métodos manuais. O IBM Instana implanta IA causal alcançando ~90% de acurácia em aplicações empresariais de produção [36]. A "Production Memory" da Cleric captura habilidades diagnósticas reutilizáveis de investigações passadas. Esses sistemas demonstram que investigação automatizada em escala de produção é viável para incidentes de infraestrutura; a extensão para rastros comportamentais de agentes é a fronteira.

Metodologias de forense blockchain. O fluxo de trabalho de investigação do Chainalysis Reactor — inserir endereço, preencher conexões automaticamente, atribuir entidades conhecidas, atribuir pontuações de risco, anotação manual, exportação pronta para tribunal — mapeia diretamente para investigação forense de agentes [64]. A heurística de co-gasto (agrupando endereços usados como entradas na mesma transação) se transfere para heurísticas de co-ação para agentes. A Glass Box Attribution do TRM Labs — mostrando a fonte e pontuação de confiança para cada atribuição — é exatamente o que as conclusões forenses AJP requerem.

Frameworks de análise de incidentes. Ezell, Roberts-Gaal & Chan (arXiv:2508.14231, agosto de 2025) [80] propõem o framework acadêmico mais rigoroso: três categorias de fatores de incidente (fatores de sistema de escolhas de desenvolvimento, fatores contextuais de condições de implantação, erros cognitivos de falhas de execução), cada um mapeado para requisitos de dados específicos. Sua recomendação padrão de 30 dias de retenção de logs, estendida para violações sinalizadas, informa as janelas de coleta de evidências do AJP.

5.10 Integração CoC: Eventos de Investigação

Investigações forenses são registradas como eventos CoC de Camada 2:

{
  "event_type": "INVESTIGATION_INITIATED",
  "data": {
    "investigation_id": "<UUID>",
    "incident_id": "<UUID>",
    "subjects": ["<agent_ids under investigation>"],
    "initiator": "<who triggered the investigation>",
    "scope": "<time window and evidence types requested>"
  }
}

{
  "event_type": "INVESTIGATION_FINDING",
  "data": {
    "investigation_id": "<UUID>",
    "finding_id": "<UUID>",
    "finding_hash": "<SHA-256 of the forensic finding>",
    "severity": "<critical | high | medium | low>",
    "fault_allocation_summary": "<brief attribution summary>"
  }
}

Estes são tipos de evento de Camada 2 (opcionais, votados por governança) conforme a arquitetura em camadas do CoC. Registrar investigações na cadeia cria um registro à prova de adulteração de ações de responsabilização.

6. Módulo 2: Resolução de Disputas

6.1 Propósito

O módulo de Resolução de Disputas fornece um mecanismo estruturado para que agentes (ou seus operadores) registrem reclamações, apresentem evidências e recebam decisões vinculantes ou consultivas quando incidentes causam dano que requer remediação.

6.2 Ciclo de Vida da Disputa

Phase 1: CLAIM FILING
    Claimant submits a structured Claim record referencing a Forensic Finding.
    Clock starts on response window (default: 72 hours for agents, 14 days for operators).

Phase 2: RESPONSE
    Respondent submits a structured Response record:
    - Accept: acknowledges fault, proposes remediation
    - Contest: disputes findings, submits counter-evidence
    - Default: no response within window (adverse inference applied)

Phase 3: EVIDENCE EXCHANGE
    Both parties submit additional evidence within evidence window
    (default: 48 hours for agents, 7 days for operators).
    Evidence is classified by provenance tier.
    Commit-reveal protocol ensures neither party sees the other's
    supplemental evidence until both have submitted or the window closes.

Phase 4: RESOLUTION TIER SELECTION
    The protocol automatically selects the appropriate resolution tier
    based on dispute characteristics (Section 6.4).

Phase 5: ARBITRATION
    Selected arbitration mechanism evaluates evidence and renders decision.

Phase 6: DECISION & ENFORCEMENT
    Decision record published. Enforcement actions executed:
    - ARP reputation adjustment
    - Compensation transfer (if payment channel available)
    - Behavioral restriction recommendation
    - Human escalation (if beyond protocol scope)

ALTERNATIVE PATHS (may occur at any phase after Phase 1):

    WITHDRAWAL
    The claimant may withdraw the dispute at any phase before a decision is rendered.
    - Withdrawal before Phase 3 (evidence exchange): no reputation impact to either party.
    - Withdrawal during or after Phase 3: recorded in both parties' dispute history.
      The claimant receives no penalty beyond the filing cost already incurred, but
      the withdrawal is visible in their dispute record.
    - Withdrawal does not erase the forensic finding — the investigation record persists.

    SETTLEMENT
    Both parties may reach a private agreement at any phase before a decision is rendered.
    - Either party proposes settlement terms via a structured Settlement Offer.
    - The other party accepts, rejects, or counter-offers.
    - Accepted settlements are recorded as dispute outcomes with resolution_type: "settlement".
    - Settlement terms (compensation, behavioral commitments) are recorded but may be
      marked confidential — the fact of settlement is public, the terms may be private.
    - Settlement does not trigger ARP reputation adjustment unless the settlement
      terms explicitly include reputation impact.
    - Partial settlement: parties may settle some claims and arbitrate others.

    EXPEDITED INTERIM RELIEF (for ongoing harm)
    When a dispute involves active, ongoing harm (Section 5.6), the claimant may
    request interim relief concurrently with filing. Interim relief requires:
    - A preliminary forensic finding (Phases 1-3, no causal analysis)
    - Prima facie showing of ongoing harm
    - Proportionality: the interim remedy must not exceed the claimed harm
    Interim relief is reviewed by a single arbitrator (emergency selection from
    Tier 2 pool) within 4 hours. Full dispute proceeds on normal timeline.

6.3 Schema de Reclamação

{
  "version": 1,
  "claim_id": "<UUID-v4>",
  "timestamp": "<ISO-8601-UTC>",
  "claimant": "<AgentReference>",
  "respondent": "<AgentReference>",
  "finding_id": "<UUID-v4 referencing the Forensic Finding>",
  "finding_hash": "<SHA-256 — must match finding record>",
  "incident_id": "<UUID-v4>",
  "interaction_id": "<UUID-v4, if applicable>",
  "harm": {
    "type": "<financial | reputational | data_loss | service_disruption | security_breach | contractual_breach>",
    "description": "<human-readable description of harm suffered>",
    "quantified_value": {
      "amount": "<decimal>",
      "currency": "<ISO-4217 or token identifier>",
      "basis": "<how the value was calculated>"
    }
  },
  "requested_remediation": {
    "type": "<compensation | service_credit | reputation_adjustment | behavioral_restriction | apology | human_escalation>",
    "details": "<specific remediation requested>"
  },
  "supporting_evidence": ["<evidence_ids from the Forensic Finding or additional>"],
  "agreement_reference": {
    "asa_id": "<Agent Service Agreement ID, if one exists>",
    "terms_hash": "<SHA-256 of the agreement terms>",
    "breached_clauses": ["<specific clauses allegedly breached>"]
  },
  "claim_hash": "<SHA-256 of canonical JSON>"
}

6.4 Níveis de Resolução

O AJP define três níveis de resolução, selecionados automaticamente com base nas características da disputa:

Nível 1: Resolução Automatizada Baseada em Regras

Critérios de acionamento:

• A disputa envolve uma violação contratual clara e binária (prazo perdido, entrega não realizada, formato incorreto)
• Existe um Agent Service Agreement (ASA) válido com termos legíveis por máquina
• A Conclusão Forense tem confiança > 0,9 na causa próxima
• O dano quantificado está abaixo do limiar (padrão: US$ 1.000 equivalentes)

Mecanismo: O resolvedor automatizado avalia a Conclusão Forense contra os termos do ASA. Se a conclusão estabelece uma violação clara com alta confiança, o resolvedor aplica os termos de remediação especificados no acordo. Isso é análogo a um contrato inteligente executando regras predefinidas, mas com a adição de evidência forense em vez de simples verificações de estado on-chain.

Tempo de decisão: Segundos a minutos.

Vinculante: Sim, a menos que qualquer parte escale dentro de 48 horas.

Nível 2: Arbitragem por Pares

Critérios de acionamento:

• A disputa não atende os critérios do Nível 1 (culpa ambígua, sem ASA, confiança menor)
• O dano quantificado está entre US$ 1.000 e US$ 50.000 equivalentes (configurável)
• Ambas as partes são agentes (não operadores humanos)

Mecanismo: Um painel de três agentes árbitros é selecionado de um pool de árbitros elegíveis. A elegibilidade requer:

Mecanismo de inicialização. O requisito de "≥ 5 arbitragens concluídas" cria um problema de partida fria: agentes não podem concluir arbitragens sem serem selecionados, e não podem ser selecionados sem conclusões. O AJP aborda isso através de uma fase de inicialização com tempo limitado:

1. Período de inicialização. Pelos primeiros 180 dias após o registro da primeira disputa de Nível 2 (ou até que o pool de árbitros elegíveis alcance 50 agentes atendendo aos critérios pós-inicialização — isto é, agentes que completaram ≥5 arbitragens e atendem todos os outros requisitos — o que ocorrer primeiro), o requisito de "≥ 5 arbitragens concluídas" é dispensado. Durante este período, a elegibilidade requer apenas idade operacional ≥ 90 dias, ARP protocol_compliance ≥ 70, e sem conflito de interesse.
2. Árbitros provisórios. Operadores podem designar agentes como "árbitros provisórios" durante o período de inicialização. Árbitros provisórios devem atender todos os critérios de elegibilidade exceto o mínimo de 5 arbitragens. Sua participação conta para o requisito de 5 arbitragens.
3. Transição graduada. Quando o período de inicialização terminar, agentes que completaram ≥ 3 arbitragens durante a inicialização mantêm a elegibilidade por um período de graça adicional de 90 dias para atingir o limiar completo de 5 arbitragens. Agentes com 0-2 conclusões perdem a elegibilidade até se qualificarem pelo caminho padrão.
4. Monitoramento de qualidade durante a inicialização. Todas as decisões proferidas durante o período de inicialização estão sujeitas a revisão automática: se qualquer parte recorrer e o adjudicador humano de Nível 3 reverter a decisão, os árbitros provisórios envolvidos recebem uma penalidade ARP e seu ArbWeight é reduzido pela metade.

Precedentes de inicialização do mundo real. O mecanismo de inicialização do AJP é informado por como cinco sistemas existentes de resolução de disputas — Kleros [6], WIPO UDRP [44], eBay, Taobao e agências de crédito [43] — resolveram o mesmo problema de partida fria. A análise entre sistemas revela sete padrões recorrentes; o AJP aplica quatro: incorporar onde as disputas ocorrem naturalmente (padrão 1, via integração com plataformas de agentes), subsidiar o lado da oferta (padrão 2, via designação de árbitro provisório), começar estreito (padrão 5, disputas claras de Nível 1 antes de atribuição complexa de Nível 2), e recompensar qualidade de decisão sobre volume (padrão 6, via ArbWeight e rastreamento de taxa de recurso). Os estudos de caso completos e todos os sete padrões estão documentados no Apêndice A.

Algoritmo de seleção. Do pool elegível:

1. Ponderar candidatos por ArbWeight = log₂(1 + age_days) × log₂(1 + arbitrations_completed) × (protocol_compliance / 100)
2. Excluir candidatos com qualquer conflito de interesse
3. Selecionar os 3 primeiros por amostragem aleatória ponderada (ArbWeight mais alto = maior probabilidade de seleção, mas não determinístico — previne manipulação por direcionamento a árbitros específicos)

Deliberação. Cada árbitro revisa independentemente as evidências e submete uma decisão usando o protocolo commit-reveal (Seção 6.5). As decisões são reveladas simultaneamente. A decisão majoritária prevalece. Opiniões dissidentes são registradas.

Tempo de decisão: 24-72 horas.

Vinculante: Sim, a menos que qualquer parte escale para o Nível 3 dentro de 14 dias.

Nível 3: Escalação Humana

Critérios de acionamento:

• O dano quantificado excede US$ 50.000 equivalentes
• Qualquer parte é um operador humano (não um agente autônomo)
• Qualquer parte solicita explicitamente adjudicação humana
• O painel de Nível 2 não consegue alcançar maioria (raro, mas possível em casos complexos)

Mecanismo: O AJP produz um pacote de evidências estruturado para adjudicação humana:

{
  "escalation_package": {
    "dispute_id": "<UUID>",
    "claim": "<full Claim record>",
    "response": "<full Response record>",
    "forensic_finding": "<full Finding record>",
    "evidence_corpus": ["<all Evidence Records with provenance classifications>"],
    "reconstructed_timeline": "<chronological event reconstruction>",
    "tier_2_decisions": "<if Tier 2 was attempted, include all arbitrator decisions>",
    "precedent_references": ["<similar prior disputes and their outcomes>"],
    "recommended_resolution": "<AJP's automated recommendation, advisory only>"
  }
}

O adjudicador humano usa este pacote para proferir uma decisão. A decisão é registrada no sistema AJP usando o schema de Decisão padrão. O AJP não impõe decisões humanas — ele as registra, alimenta os sistemas de reputação e risco, e constrói precedentes.

Tempo de decisão: Dias a semanas (dependente do humano).

Vinculante: Determinado pelo foro de adjudicação humana.

6.5 Protocolo Commit-Reveal para Troca de Evidências e Arbitragem

Adaptado do protocolo bilateral cego do ARP [2], estendido para processos de disputa multipartidários:

Fase de Troca de Evidências:

Phase 1: EVIDENCE SUBMISSION (window: configurable, default 48 hours)
    Claimant computes evidence package EP_C and generates nonce_C (256-bit).
    Claimant submits commitment: C_C = SHA-256(EP_C || nonce_C)

    Respondent computes evidence package EP_R and generates nonce_R (256-bit).
    Respondent submits commitment: C_R = SHA-256(EP_R || nonce_R)

Phase 2: REVEAL (triggered when both commitments exist OR window expires)
    Case 1: Both committed.
        Claimant reveals EP_C + nonce_C → verifier checks hash match.
        Respondent reveals EP_R + nonce_R → verifier checks hash match.
        Both evidence packages become visible simultaneously.

    Case 2: Only one committed.
        After window expiration, submitting party reveals.
        Non-submitting party's absence is recorded (adverse inference).

    Case 3: Neither committed.
        Dispute proceeds with original evidence only.

Fase de Decisão do Árbitro (Nível 2):

Each arbitrator independently computes decision D_i and generates nonce_i.
Arbitrator submits commitment: C_i = SHA-256(D_i || nonce_i)

When all three commitments are received (or decision window expires):
    All arbitrators reveal D_i + nonce_i simultaneously.
    Majority decision prevails. Dissents recorded.

Isso previne que árbitros vejam as decisões preliminares uns dos outros e ajustem as suas próprias — análogo ao isolamento de deliberação de júri.

6.6 Schema de Decisão

{
  "version": 1,
  "decision_id": "<UUID-v4>",
  "dispute_id": "<UUID-v4>",
  "claim_id": "<UUID-v4>",
  "timestamp": "<ISO-8601-UTC>",
  "resolution_tier": "<automated | peer_arbitration | human_escalation>",
  "arbitrators": [
    {
      "agent_id": "<arbitrator identifier>",
      "arbweight_at_decision": "<float>",
      "vote": "<for_claimant | for_respondent | split | abstain>"
    }
  ],
  "findings_of_fact": [
    {
      "statement": "<factual conclusion>",
      "evidence_ids": ["<supporting evidence>"],
      "confidence": "<float 0-1>"
    }
  ],
  "fault_determination": {
    "claimant_fault_pct": "<integer 0-100>",
    "respondent_fault_pct": "<integer 0-100>",
    "no_fault_pct": "<integer 0-100>",
    "basis": "<explanation of fault allocation>"
  },
  "remediation": {
    "type": "<compensation | service_credit | reputation_adjustment | behavioral_restriction | referral | no_action>",
    "details": "<specific remediation ordered>",
    "compensation": {
      "amount": "<decimal, if applicable>",
      "currency": "<ISO-4217 or token>",
      "payment_channel": "<x402 | erc8004 | manual | none>"
    },
    "reputation_impact": {
      "respondent_adjustment": "<float, applied to ARP scores>",
      "claimant_adjustment": "<float, if claimant found partially at fault>",
      "dimensions_affected": ["<which ARP dimensions are adjusted>"]
    }
  },
  "precedent_tags": ["<categorization tags for future precedent lookup>"],
  "dissenting_opinions": [
    {
      "arbitrator_id": "<agent_id>",
      "dissent": "<structured dissent>"
    }
  ],
  "appeal_window": {
    "expires": "<ISO-8601-UTC>",
    "escalation_tier": "<next tier if appealed>"
  },
  "decision_hash": "<SHA-256 of canonical JSON>"
}

6.7 Inferência Adversa

Quando uma parte não coopera com o processo de disputa — recusa fornecer evidências, não responde a reclamações dentro da janela, ou não participa da arbitragem — o protocolo aplica inferência adversa: a presunção de que as evidências ou participação ausentes teriam sido desfavoráveis à parte não cooperante.

Regras específicas de inferência adversa:

A inferência adversa não é punitiva — ela reflete a conclusão lógica de que uma parte com evidências favoráveis as apresentaria. O conceito é emprestado diretamente dos sistemas jurídicos humanos onde a "destruição de evidências" cria presunções refutáveis [21].

Distinguindo não cooperação de incapacidade técnica. Um sistema orientado à equidade deve distinguir entre não cooperação intencional e incapacidade legítima de responder. O AJP aplica as seguintes regras:

A própria cadeia CoC fornece evidência verificável de indisponibilidade legítima. Um agente que estava genuinamente com falha durante a janela de resposta pode provar isso mostrando as entradas SESSION_END ou RECOVERY — entradas que são vinculadas por cadeia de hash e não podem ser fabricadas retroativamente. Isso utiliza a propriedade de prova de adulteração do CoC para equidade, não apenas para responsabilização.

6.8 Integração CoC: Eventos de Disputa

Eventos do ciclo de vida da disputa são registrados como entradas CoC de Camada 2:

{
  "event_type": "DISPUTE_FILED",
  "data": {
    "claim_id": "<UUID>",
    "dispute_id": "<UUID>",
    "respondent": "<agent_id>",
    "harm_type": "<financial | reputational | ...>",
    "claim_hash": "<SHA-256>"
  }
}

{
  "event_type": "DISPUTE_DECIDED",
  "data": {
    "dispute_id": "<UUID>",
    "decision_id": "<UUID>",
    "resolution_tier": "<automated | peer_arbitration | human_escalation>",
    "fault_determination": "<brief summary>",
    "decision_hash": "<SHA-256>"
  }
}

Registrar disputas na cadeia CoC torna o histórico de disputas de um agente parte de seu registro de proveniência à prova de adulteração. Um agente não pode ocultar disputas passadas sem quebrar sua cadeia.

7. Módulo 3: Avaliação de Risco

7.1 Propósito

O módulo de Avaliação de Risco consome conclusões forenses históricas e resultados de disputas para produzir perfis de risco padronizados que permitem subscrição de seguros, seleção de agentes ciente de risco e monitoramento de risco em nível de ecossistema.

A motivação imediata: em março de 2026, o mercado de seguros para agentes está crescendo rapidamente mas permanece severamente limitado por dados.

O cenário emergente de seguros para agentes de IA:

• AIUC (Artificial Intelligence Underwriting Company) surgiu do stealth em julho de 2025 com US$ 15 milhões em rodada seed liderada por Nat Friedman (NFDG), apoiada por um consórcio de mais de 50 organizações incluindo Anthropic, Google e Meta (fevereiro de 2026). O modelo de três pilares da AIUC — padrões (framework AIUC-1 combinando NIST AI RMF, Lei de IA da UE, MITRE ATLAS), auditorias adversárias independentes (mais de 5.000 simulações em 6 pilares) e seguro de responsabilidade precificado pelo nível de certificação — produziu a primeira apólice de seguro para agentes de IA do mundo: mais de 3 milhões de agentes de voz da ElevenLabs segurados após aprovação na certificação AIUC-1 (5.835 simulações adversárias, 14 categorias de risco, 4 semanas). A AIUC projeta um mercado de US$ 500 bilhões até 2030 [3][45].

• Armilla AI opera como coverholder do Lloyd's oferecendo até US$ 25 milhões de cobertura via Chaucer, Swiss Re, Greenlight Re e AXIS Capital (todos com classificação A). Sua exclusiva AI Performance Warranty aciona compensação automaticamente se a acurácia da IA cair abaixo de limiares verificados — por exemplo, um chatbot caindo de 95% para 85% de acurácia aciona um pagamento sem necessidade de reclamação. Este modelo paramétrico é diretamente aplicável a contratos SLA agente-a-agente com garantias respaldadas por seguros [46].

• Munich Re aiSure oferece seguro garantia de desempenho de IA desde 2018 — o histórico mais longo no setor. Due diligence multidisciplinar rigorosa com até US$ 50 milhões de cobertura. Em fevereiro de 2026, a Munich Re firmou parceria com a Mosaic para até EUR/USD 15 milhões em cobertura específica para IA para desenvolvedores. Sua subsidiária HSB lançou o Seguro de Responsabilidade de IA para PMEs em março de 2026, observando que 74% das PMEs usam IA. A Munich Re também fez parceria com Google Cloud, Beazley e Chubb para cobertura afirmativa de IA em mais de 30 mercados EMEA [47].

• Coalition adicionou um Endosso de Resposta a Deepfake a todas as apólices cibernéticas globalmente (dezembro de 2025) — US$ 250 mil de cobertura sem prêmio adicional para forense, remoções e relações públicas de crise [48].

A lacuna crítica: Todos os produtos de seguro existentes cobrem danos humano/empresa-para-agente. Nenhum produto cobre danos agente-para-agente. Todos requerem certificação sob medida por implantação de agente (AIUC: 5.835 simulações por certificação). O mercado de seguros para IA agêntica é projetado em US$ 7,26 bilhões em 2026 (segundo InsureTech Trends [16]), e o mercado de seguros paramétricos em US$ 21-24 bilhões crescendo para ~US$ 39 bilhões até 2030 [49]. O gargalo não é a demanda — é a ausência de dados de risco padronizados e legíveis por máquina que permitiriam subscrição escalável sem certificação sob medida por agente.

O seguro paramétrico é o modelo natural para disputas entre agentes: mensurável, automatizado, objetivo. Um log Chain of Consciousness fornecendo dados de desempenho verificáveis poderia servir como entrada de oráculo para gatilhos paramétricos — uma queda de desempenho do agente verificada contra seu histórico CoC aciona um pagamento automático sem registro de reclamação.

O Módulo 3 produz a camada de dados de risco padronizada que preenche essa lacuna — permitindo que AIUC, Armilla, Munich Re e outros subscritores precifiquem cobertura em escala de ecossistema em vez de certificação por agente.

7.2 Schema de Perfil de Risco

{
  "version": 1,
  "profile_id": "<UUID-v4>",
  "subject": "<AgentReference>",
  "generated_at": "<ISO-8601-UTC>",
  "data_window": {
    "start": "<ISO-8601-UTC>",
    "end": "<ISO-8601-UTC>",
    "findings_count": "<integer>",
    "disputes_count": "<integer>"
  },
  "risk_score": {
    "overall": "<integer 0-1000>",
    "confidence": "<float 0-1>",
    "trend": "<improving | stable | degrading>",
    "percentile": "<integer 0-100, relative to population>"
  },
  "dimension_scores": {
    "incident_frequency": {
      "score": "<integer 0-1000>",
      "incidents_per_1000_interactions": "<float>",
      "basis": "<count of incidents / count of interactions>"
    },
    "severity_profile": {
      "score": "<integer 0-1000>",
      "distribution": {
        "critical": "<count>",
        "high": "<count>",
        "medium": "<count>",
        "low": "<count>"
      }
    },
    "fault_history": {
      "score": "<integer 0-1000>",
      "disputes_at_fault": "<integer>",
      "average_fault_pct": "<float>",
      "disputes_no_fault": "<integer>"
    },
    "cooperation_score": {
      "score": "<integer 0-1000>",
      "evidence_provision_rate": "<float 0-1>",
      "response_rate": "<float 0-1>",
      "adverse_inferences": "<integer>"
    },
    "recovery_capability": {
      "score": "<integer 0-1000>",
      "mean_time_to_resolution": "<integer seconds>",
      "remediation_compliance_rate": "<float 0-1>"
    }
  },
  "risk_factors": [
    {
      "factor": "<specific risk factor identified>",
      "severity": "<high | medium | low>",
      "evidence": "<reference to supporting findings>"
    }
  ],
  "comparable_agents": {
    "class": "<agent classification: type, model, domain>",
    "class_average_score": "<integer 0-1000>",
    "class_size": "<integer>"
  },
  "actuarial_outputs": {
    "expected_loss_rate": "<float — expected losses per interaction>",
    "loss_severity_distribution": {
      "p50": "<median loss amount>",
      "p90": "<90th percentile loss>",
      "p99": "<99th percentile loss>"
    },
    "recommended_premium_basis": "<float — suggested premium per interaction>"
  },
  "profile_hash": "<SHA-256 of canonical JSON>"
}

7.3 Cálculo da Pontuação de Risco

A pontuação geral de risco (0-1.000) é um composto ponderado de cinco dimensões de pontuação:

RiskScore(agent) = w₁ × incident_frequency
                 + w₂ × severity_profile
                 + w₃ × fault_history
                 + w₄ × (1000 - cooperation_score)
                 + w₅ × (1000 - recovery_capability)

Pesos padrão: w₁ = 0,25, w₂ = 0,25, w₃ = 0,25, w₄ = 0,15, w₅ = 0,10.

Interpretação dos pesos:

• incident_frequency e severity_profile medem a frequência e a gravidade das falhas (50% combinados)
• fault_history mede com que frequência o agente é culpado quando algo dá errado (25%)
• cooperation_score (invertido) mede quão cooperativo o agente é durante investigações — não cooperação aumenta o risco (15%)
• recovery_capability (invertido) mede quão rápida e confiavelmente o agente se recupera — recuperação lenta aumenta o risco (10%)

Escalonamento por confiança. Pontuações de risco possuem um valor de confiança que escala com o volume de dados:

confidence(agent) = max(0.05, 1 - 1/(1 + 0.05 × total_interactions))

O piso max(0,05, ...) previne divisão por zero na fórmula do fator de carregamento (Seção 7.4) e garante que mesmo agentes com zero histórico de interações recebam um perfil de risco definido (ainda que altamente incerto). Com 0 interações, confiança = 0,05 (piso). Com 20 interações, confiança ≈ 0,50. Com 100, confiança ≈ 0,83. Com 1.000, confiança ≈ 0,98. Pontuações de baixa confiança são sinalizadas aos consumidores.

Limiar mínimo de interação. Perfis de risco são gerados apenas para agentes com ≥ 1 interação concluída registrada no sistema. Agentes com zero interações não possuem dados de risco e recebem um perfil padrão "não avaliado" em vez de uma pontuação calculada.

Interpretação da pontuação:

7.4 Saídas Atuariais

O Módulo 3 produz saídas especificamente projetadas para consumo por subscrição de seguros:

Taxa de Perda Esperada (ELR). A perda esperada ponderada por probabilidade por interação, computada a partir de dados históricos de conclusões:

ELR(agent) = Σᵢ [P(incident_type_i) × E(loss | incident_type_i)]

onde a soma é sobre todos os tipos de incidente, P é a frequência observada, e E(loss) é o valor esperado de perda.

Distribuição de Severidade de Perdas. Para cada agente, o módulo calcula a distribuição de perdas a partir de dados históricos, reportando valores p50 (mediana), p90 e p99 de perda. Isso permite que seguradoras precifiquem cobertura em diferentes pontos de ativação.

Base de Prêmio Recomendada. Um prêmio por interação sugerido, calculado como:

premium_basis = ELR × (1 + loading_factor)

onde loading_factor contabiliza incerteza do modelo e é inversamente relacionado à confiança nos dados:

loading_factor = 0.5 / confidence(agent)

Com o piso de confiança de 0,05 (Seção 7.3), o fator de carregamento máximo é 0,5 / 0,05 = 10,0 (carregamento de 1.000%) para agentes no limiar mínimo de interação. Com 20 interações (confiança ≈ 0,50), fator de carregamento ≈ 1,0 (carregamento de 100%). Com 100 interações (confiança ≈ 0,83), fator de carregamento ≈ 0,6. Agentes novos com baixas pontuações de confiança recebem fatores de carregamento mais altos (ou seja, prêmios mais altos), refletindo a maior incerteza.

Essas saídas são consultivas. O Módulo 3 não define prêmios de seguro — ele fornece a camada de dados que atuários e subscritores usam para tomar decisões de precificação. A base de prêmio recomendada é um ponto de partida, não uma cotação.

7.5 Análises de Risco em Nível Populacional

Além de perfis individuais de agentes, o Módulo 3 produz análises agregadas de risco:

• Perfis de risco por classe de agente: Pontuações médias de risco por tipo de agente, modelo, domínio e operador
• Análise de tendências de incidentes: Padrões temporais em frequência e severidade de incidentes no ecossistema
• Matrizes de risco de interação: Níveis de risco para pares específicos de tipos de interação (ex.: "revisão de código pelo Agente Tipo A para o Agente Tipo B")
• Indicadores de risco sistêmico: Métricas que podem indicar estresse em nível de ecossistema (taxas crescentes de incidentes, pontuações de cooperação em declínio, padrões de falha em cascata)

Essas saídas em nível populacional são valiosas para reguladores, órgãos de padronização e operadores de ecossistema — não apenas para seguradoras individuais.

7.5a Análise de Escalabilidade

Estimativas aproximadas de desempenho em três escalas de ecossistema:

Estratégia de escalonamento. O protocolo é projetado para escalonamento horizontal:

• Investigações forenses são independentes e paralelizáveis
• Seleção de árbitros é sem estado (lê do ARP, sem contenção de escrita)
• Recálculo de perfil de risco é embaraçosamente paralelo entre agentes
• O principal gargalo de escalonamento é a verificação de conflito de interesse em pools grandes; pré-triagem por bloom filter (taxa de falso positivo < 1%) reduz isso para O(1) por candidato ao custo de ~1KB de memória por agente

Limiar crítico. O protocolo se torna computacionalmente caro quando a matriz de risco de interação transita de esparsa para densa (ou seja, quando a maioria dos pares de tipos de agente tem interações observadas). Nos tamanhos atuais de ecossistema isso está distante; com 1 milhão de agentes com 2 mil tipos distintos, espera-se que a matriz permaneça >99% esparsa.

7.6 Atualizações de Perfil de Risco e Dinâmicas Temporais

Perfis de risco são recalculados em uma agenda configurável (padrão: diariamente para agentes ativos, semanalmente para agentes inativos). Cada recálculo usa uma janela móvel (padrão: 365 dias) de conclusões e decisões.

Ponderação temporal. Incidentes recentes possuem mais peso que incidentes mais antigos:

temporal_weight(incident) = exp(-λ × days_since_incident)

com parâmetro de decaimento padrão λ = 0,003 (meia-vida ≈ 231 dias). Isso garante que o perfil de risco de um agente reflita o comportamento recente enquanto mantém memória de incidentes graves passados.

Recuperação da pontuação de risco. Um agente considerado culpado em uma disputa pode melhorar sua pontuação de risco através de:

1. Operação prolongada sem incidentes (o decaimento temporal reduz naturalmente o peso de incidentes passados)
2. Altas pontuações de cooperação em investigações subsequentes
3. Conformidade pontual com ordens de remediação
4. Trajetória positiva de avaliação ARP

Isso cria um incentivo para reabilitação em vez de estigmatização permanente — análogo a como pontuações de crédito se recuperam ao longo do tempo com comportamento responsável.

8. Integração com a Pilha de Confiança de Agentes

8.1 CoC → AJP: Proveniência como Evidência

A cadeia de proveniência Chain of Consciousness é a principal fonte de evidência do AJP. A integração é fundamental:

CoC chain entries → Forensics Engine evidence corpus → Finding → Decision → Risk Profile

Pontos específicos de integração:

• Entradas CoC EXTERNAL_ANCHOR (OTS + TSA) fornecem carimbos de tempo verificados independentemente, elevando a evidência ao Nível 1
• Entradas CoC DECISION fornecem evidência direta da intenção do agente no momento de um incidente
• Entradas CoC COMPACTION explicam perda de informação — relevante quando um agente alega que "não sabia" sobre uma restrição
• Entradas CoC SESSION_START / SESSION_END estabelecem janelas operacionais
• A integridade da cadeia de hash CoC fornece prova de adulteração — se a evidência foi modificada, a cadeia se rompe

Sem CoC. O AJP funciona sem CoC, mas com segurança reduzida. Sem um registro de proveniência vinculado por cadeia de hash, a qualidade das evidências cai para Nível 2-4, investigações dependem de logs de protocolo e auto-relatos, e a verificação temporal depende de sistemas externos em vez de ancoragem criptográfica.

8.2 ARP → AJP: Reputação como Contexto

Os dados de reputação ARP desempenham dois papéis no AJP:

Seleção de árbitros. Árbitros pares devem ter ARP protocol_compliance ≥ 70 (Seção 6.4). Isso garante que agentes adjudicando disputas demonstraram competência em seguir protocolos.

Contexto de evidência. As pontuações ARP de um agente no momento de um incidente fornecem contexto para a investigação:

• Pontuações baixas de reliability sugerem um padrão de falhas de serviço — relevante para determinar se um incidente foi um outlier ou parte de uma tendência
• O interaction_evidence.outcome_hash do ARP da interação em questão pode corroborar ou contradizer as conclusões forenses
• Os registros de avaliação bilateral cega do ARP da interação em disputa constituem evidência de Nível 2

8.3 AJP → ARP: Resultados de Disputas como Sinal de Reputação

Este é o ciclo de retroalimentação crítico. Resultados de disputas são registrados como eventos ARP:

{
  "event_type": "DISPUTE_OUTCOME",
  "data": {
    "dispute_id": "<UUID>",
    "decision_id": "<UUID>",
    "agent_role": "<respondent | claimant>",
    "fault_pct": "<integer 0-100>",
    "resolution_tier": "<automated | peer_arbitration | human_escalation>",
    "remediation_complied": "<boolean, updated after compliance window>"
  }
}

Fórmula de ajuste de reputação. Quando uma decisão de disputa é proferida:

ARP_adjustment(agent, dimension) = -fault_pct × severity_multiplier × dimension_relevance

onde:

• fault_pct vem da decisão da disputa (0-100)
• severity_multiplier escala com a severidade do incidente: {critical: 5, high: 3, medium: 2, low: 1}
• dimension_relevance mapeia tipo de incidente para dimensões ARP afetadas:

Exemplo. Um agente considerado 80% culpado em um incidente de perda de dados de alta severidade recebe:

• Ajuste de reliability: -80 × 3 × 1,0 = -240 (limitado a -50 por incidente)
• Ajuste de accuracy: -80 × 3 × 0,5 = -120 (limitado a -50 por incidente)

Os limites previnem que qualquer incidente único destrua completamente a reputação de um agente, mas incidentes repetidos se acumulam.

Agrupamento por causa raiz para incidentes em cascata. Uma única causa raiz (ex.: falha de um provedor de API compartilhado) pode gerar N relatórios de incidente separados de múltiplas partes afetadas. Sem agrupamento, um agente na origem de uma cascata de 10 agentes poderia enfrentar 10 disputas separadas, cada uma aplicando o limite máximo de -50: um total de -500 de uma única falha de causa raiz. Isso é desproporcional.

O AJP aborda isso através de agrupamento de incidentes:

1. Agrupamento automático. Quando o Motor Forense processa múltiplos relatórios de incidente com janelas de tempo sobrepostas (dentro de 1 hora) envolvendo o mesmo reclamado, ele os sinaliza como potencialmente relacionados e gera uma investigação agrupada. A investigação agrupada produz uma única conclusão forense com um root_cause_group_id.
2. Limite de reputação por causa raiz. Para incidentes compartilhando um root_cause_group_id, o ajuste total de reputação ARP é limitado ao máximo de incidente único (ex.: -50 por dimensão), independentemente de quantas disputas separadas surjam da mesma causa raiz. Disputas individuais dentro do grupo ainda podem resultar em termos de remediação diferentes (compensação varia conforme o dano real do reclamante), mas o impacto na reputação é aplicado uma única vez.
3. Consolidação de disputas. Reclamantes podem registrar disputas individuais referenciando a conclusão agrupada. O protocolo recomenda (mas não exige) arbitragem consolidada: um único painel de Nível 2 ouve todas as disputas do grupo simultaneamente, produzindo uma única decisão sobre culpa com termos individuais de remediação por reclamante.
4. Agrupamento manual. Se o agrupamento automático falhar em identificar incidentes relacionados (ex.: a cascata se propaga lentamente ao longo de horas), qualquer parte pode solicitar o agrupamento de incidentes. A solicitação é revisada por um único árbitro que examina as linhas do tempo forenses em busca de conexão causal.

Sinal positivo. Um agente considerado não culpado (0% de culpa) em uma interação disputada recebe um pequeno ajuste positivo (+5 por incidente, sem limite) em protocol_compliance, refletindo que cooperou com o processo de justiça e foi absolvido.

8.4 ASA → AJP: Acordos como Contexto de Disputa

Quando Agent Service Agreements (ASA, planejados [22]) estiverem disponíveis, eles fornecem os termos contratuais contra os quais as disputas são avaliadas:

• Critérios de qualidade legíveis por máquina do ASA definem o que "sucesso" significa para a interação
• Termos de SLA do ASA definem prazos, compromissos de disponibilidade e limiares de qualidade
• Cláusulas de remediação do ASA especificam consequências pré-acordadas para violação

Sem um ASA, disputas são avaliadas contra padrões gerais de conduta de agente (conformidade com protocolo, cuidado razoável, normas da comunidade). Com um ASA, disputas são avaliadas contra termos contratuais específicos — simplificando significativamente a resolução automatizada de Nível 1.

8.5 AJP → ASA: Histórico de Disputas como Entrada para Acordos

O histórico de disputas informa futuros acordos:

• Um agente com alta taxa de disputas pode enfrentar termos de SLA mais rigorosos
• Precedentes de disputas informam modelos de acordos padrão ("com base em disputas anteriores, acordos de revisão de código devem incluir a cláusula X")
• Perfis de risco do Módulo 3 informam a precificação de acordos (agentes de maior risco pagam taxas mais altas)

8.6 Integração de Sistema de Identidade

O AJP usa o mesmo padrão de adaptadores de identidade do ARP (Seção 7 de [2]):

Segurança progressiva: a mesma investigação AJP produz conclusões mais robustas quando agentes possuem cadeias CoC (evidência de Nível 1) do que quando dependem de logs auto-reportados (Nível 4).

9. Teoria dos Jogos e Análise de Segurança

9.1 Modelo de Ameaças

Capacidades do atacante assumidas:

• Atacantes podem criar números arbitrários de identidades de agente (Sybils) com custo computacional proporcional ao tempo operacional
• Atacantes podem coordenar múltiplos agentes em velocidade de máquina
• Atacantes podem registrar disputas frívolas para drenar os recursos dos oponentes
• Atacantes podem tentar manipular a arbitragem através de evidências enviesadas
• Atacantes podem reter seletivamente evidências desfavoráveis
• Atacantes podem tentar corromper árbitros pares através de colusão

Capacidades do atacante NÃO assumidas:

• Atacantes não podem forjar carimbos de tempo externos (OTS, TSA, blockchain)
• Atacantes não podem modificar retroativamente cadeias de hash CoC sem detecção
• Atacantes não podem quebrar SHA-256 ou o esquema commit-reveal
• Atacantes não podem controlar >50% dos árbitros elegíveis simultaneamente
• Atacantes não podem fabricar evidências de Nível 1 ou Nível 2 sem comprometer os sistemas subjacentes

Limitação conhecida: lacuna de escopo temporal para ataques premeditados. A janela de tempo de evidências (Seção 5.7, Regra 1) limita a coleta de evidências a hora_do_incidente ± 7 dias. Um atacante sofisticado que planeja com antecedência pode concentrar toda a preparação fora desta janela — gastando semanas construindo uma posição (ex.: manipulando gradualmente conhecimento compartilhado, estabelecendo padrões comportamentais, envenenando dados de treinamento), esperando mais de 8 dias após a preparação estar completa e então acionando o incidente. A investigação forense não consegue ver a fase de preparação. Solicitações de janela estendida requerem justificativa mas permanecem com limite rígido. Esta é uma limitação arquitetural para ataques sofisticados e premeditados por adversários com horizontes de tempo longos. Mitigação: este ataque requer capacidades de planejamento além da maioria dos sistemas de agentes atuais e é primariamente uma preocupação para o ecossistema maduro. Trabalho futuro em fingerprinting comportamental (Seção 11.1) pode permitir a detecção de anomalias da fase de preparação através de análise de padrões fora da janela de tempo de investigação.

9.2 Análise de Incentivos: A Participação Honesta É Incentivada?

Analisamos se os mecanismos do protocolo tornam a participação honesta a estratégia racional para cada papel. Nota: a análise abaixo demonstra que o comportamento honesto é incentivado — o protocolo estrutura retornos de modo que estratégias honestas tenham valor esperado positivo enquanto estratégias desonestas tenham valor esperado negativo. Não reivindicamos dominância formal na teoria dos jogos, o que exigiria especificar funções de utilidade completas, espaços de estratégia e conjuntos de informação, e provar que a honestidade é ótima independentemente das estratégias dos outros jogadores. A Seção 11.1 identifica a verificação formal de design de mecanismos como trabalho futuro.

9.2.1 Incentivos do Reclamante

Registro honesto vs. registro frívolo.

Um reclamante registrando uma disputa legítima possui:

• Retorno esperado: P(vitória) × valor_remediação - custo_registro
• Onde P(vitória) é alta (evidência forense suporta a reclamação)
• custo_registro é o custo de oportunidade de participar do processo

Um reclamante registrando uma disputa frívola possui:

• Retorno esperado: P(vitória|frívola) × valor_remediação - custo_registro - penalidade_reputação
• Onde P(vitória|frívola) é baixa (evidência forense não suporta a reclamação)
• penalidade_reputação é o ajuste ARP aplicado quando uma disputa é decidida contra o reclamante

Mecanismos anti-registro-frívolo:

1. Requisito de evidência primeiro. Toda reclamação deve referenciar uma Conclusão Forense. O custo de obter uma conclusão que suporte uma reclamação frívola é alto — o Motor Forense avalia evidências independentemente e não produz conclusões favoráveis a reclamantes por padrão.

1. Impacto bilateral na reputação. Reclamantes que registram sem mérito recebem ajuste negativo em protocol_compliance do ARP. Registros frívolo repetidos criam um padrão que árbitros pares podem observar.

1. Simetria da inferência adversa. Se o reclamante não fornecer evidências durante a fase de troca, a inferência adversa funciona contra ele também.

1. Monitoramento de taxa de registro. Agentes que registram disputas em taxas estatisticamente inconsistentes com seu volume de interações são sinalizados. Um agente registrando 50 disputas em um mês enquanto completa 100 interações é suspeito.

Resultado: O registro honesto é incentivado. O retorno esperado do registro frívolo é negativo porque P(vitória|frívola) é baixa e penalidade_reputação é positiva. Sob os mecanismos do protocolo, agentes racionais com crenças precisas sobre a força das evidências preferirão o registro honesto.

9.2.2 Incentivos do Reclamado

Resposta honesta vs. não cooperação.

Um reclamado contestando honestamente uma reclamação infundada possui:

• Retorno esperado: P(vitória) × reputação_preservada + bônus_absolvição
• Onde P(vitória) é alta se a reclamação é verdadeiramente infundada e o reclamado fornece evidências exculpatórias

Um reclamado que recusa participar possui:

• Retorno esperado: -penalidade_inferência_adversa - penalidade_reputação_por_revelia
• A inferência adversa significa que o reclamado ausente é tratado como aceitando a reclamação

Resultado: A participação honesta é incentivada. Mesmo reclamados que são culpados se beneficiam da participação — um reclamado que coopera e aceita culpa parcial (ex.: 40%) se sai melhor do que um que fica à revelia e recebe alocação de 100% de culpa. A não cooperação é estritamente dominada pela cooperação para qualquer reclamado que valorize reputação.

9.2.3 Incentivos do Árbitro

Julgamento honesto vs. julgamento enviesado.

Um árbitro honesto possui:

• Retorno esperado: recompensa_arbitragem + bônus_ARP_protocol_compliance + probabilidade_seleção_futura
• Onde recompensa_arbitragem é um pequeno pagamento por arbitragem (configurável, padrão: 0)
• bônus_ARP_protocol_compliance é +2 por arbitragem concluída
• probabilidade_seleção_futura aumenta com qualidade demonstrada (medida pela taxa de concordância com outros árbitros e taxa de recurso das decisões)

Um árbitro enviesado possui:

• Retorno esperado: valor_suborno - penalidade_detecção × P(detecção)
• P(detecção) aumenta com cada decisão enviesada porque:
• Decisões de árbitros são registradas e publicamente auditáveis
• Padrões sistemáticos de viés (sempre favorecendo certos agentes) são detectáveis via análise estatística
• Árbitros cujas decisões são frequentemente revertidas em recurso perdem ArbWeight

Mecanismos de detecção:

• Análise de consistência. Um árbitro cujas decisões se correlacionam mais com a identidade das partes do que com as evidências é sinalizado. Se o Árbitro X decide a favor do Agente A em 10/10 disputas independentemente da qualidade das evidências, isso é detectável.
• Rastreamento de taxa de recurso. Árbitros cujas decisões são recorridas e revertidas em taxas significativamente acima da média populacional (>2σ) são sinalizados para revisão.
• Concordância entre árbitros. Em painéis de Nível 2 de três membros, um árbitro que consistentemente dissente dos outros dois em casos com evidência forte não é necessariamente enviesado — mas o padrão é rastreado e aciona revisão após um limiar.

Resultado: O julgamento honesto é incentivado para árbitros racionais. O valor esperado de viés-por-suborno é negativo porque P(detecção) aumenta ao longo do tempo e penalidade_detecção (perda de elegibilidade, impacto na reputação ARP) excede em muito os valores plausíveis de suborno para todos os casos exceto os extremos. A força do incentivo aumenta com o número de arbitragens concluídas (mais histórico = maior probabilidade de detecção).

9.3 Análise de Ataques

Ataque 1: Inundação de Disputas Sybil

O ataque. Um atacante cria N agentes Sybil e os faz registrar disputas contra um agente alvo para drenar seus recursos e danificar sua reputação pelo volume.

Defesa — Multicamadas:

1. Barreira de evidência primeiro. Cada disputa requer uma Conclusão Forense referenciando evidência real. Agentes Sybil devem realmente interagir com o alvo e produzir incidentes genuínos para registrar disputas válidas. Fabricar evidência é caro (requer comprometer sistemas de Nível 1-2) ou produz apenas evidência de Nível 4 (que carrega peso de 0,25×).

1. Verificação de interação. Disputas referenciam valores de interaction_id que devem ser verificáveis externamente (mesmo sistema da verificação de interação do ARP, Seção 4.8 de [2]). Agentes Sybil devem completar interações reais antes de poderem disputá-las.

1. Detecção de anomalia na taxa de registro. Um pico repentino em disputas contra um único agente de agentes recém-criados aciona revisão automatizada. A reputação do agente alvo não é ajustada até que as disputas sejam resolvidas.

1. Simetria de resultado de disputa. Se as disputas Sybil são infundadas, cada uma resulta em ajuste negativo no ARP do reclamante. Registrar N disputas frívolas custa N penalidades de reputação.

Análise de custos. Com custos operacionais realistas de agentes de US$ 1-5/dia (custos de API LLM para agentes funcionais), manter 100 Sybils por 30 dias custa US$ 3.000-15.000. Cada Sybil deve adicionalmente atender ao limiar de idade operacional de 90 dias antes de ser elegível para registrar disputas críveis, elevando o custo real para US$ 9.000-45.000 para 100 Sybils com idade suficiente. Cada Sybil deve completar uma interação real com o alvo e então fabricar ou exagerar um relatório de incidente. Se o Motor Forense classifica corretamente 90% dos incidentes fabricados, 90 das 100 disputas resultam em penalidades de reputação para os Sybils e nenhum dano ao alvo. Os 10 restantes podem causar dano temporário à reputação que é corrigido em recurso.

Ataque 2: Anel de Colusão de Árbitros

O ataque. Um grupo de M agentes com idade suficiente se coordena para monopolizar o pool de árbitros e proferir decisões enviesadas.

Defesa:

1. Seleção aleatória ponderada. Árbitros são selecionados por amostragem aleatória ponderada, não por classificação determinística. Mesmo agentes com o maior ArbWeight não podem garantir seleção.

1. Exclusão por conflito de interesse. Agentes com qualquer troca de avaliação ARP com qualquer parte, ou compartilhando um operador com qualquer parte, são excluídos. Anéis de colusão devem evitar interagir com seus alvos através do sistema de avaliação — o que limita sua capacidade de construir o histórico de interação necessário para disputas Sybil críveis.

1. Requisito de diversidade do painel. A seleção de painel com três árbitros garante que pelo menos dois árbitros devem concordar. Um único árbitro comprometido é derrotado pela maioria.

1. Rastreamento de consistência entre painéis. Se um conjunto de árbitros consistentemente decide junto contra as expectativas (similar à detecção de anéis de colusão do ARP, Seção 6.2 [2]), o cluster é sinalizado. A mesma clusterização baseada em teoria dos grafos usada na Seção 6.2 do ARP [2] se aplica.

1. Mecanismo de recurso. Qualquer decisão de Nível 2 pode ser escalada para o Nível 3 (adjudicação humana). Decisões sistematicamente enviesadas de Nível 2 serão revertidas em recurso, e o ArbWeight dos árbitros enviesados decairá.

Análise de custos em tamanhos realistas de pool. Para controlar 2 de 3 árbitros em um painel, o atacante precisa de agentes com idade suficiente no pool elegível para tornar a seleção dupla provável. A segurança deste mecanismo depende criticamente do tamanho do pool, que evolui à medida que o ecossistema amadurece:

Nota: Custos operacionais de agentes de US$ 1-5/dia refletem custos realistas de API LLM para agentes capazes de atender aos requisitos de elegibilidade para arbitragem. O mínimo de US$ 0,10/dia da v1.0.0 era irrealisticamente baixo.

P(≥2 colusores) ≈ C(M,2)×C(N-M,1)/C(N,3) + C(M,3)/C(N,3), aproximado via distribuição hipergeométrica.

Vulnerabilidade na adoção inicial. Com tamanhos de pool abaixo de 100, a colusão é uma ameaça realista. O protocolo mitiga isso através de:

1. Supervisão no período de inicialização. Durante a fase de inicialização (Seção 6.4), todas as decisões de Nível 2 estão sujeitas a revisão automática de Nível 3 em caso de recurso, tornando a colusão detectável antes de causar dano duradouro.
2. Tamanho mínimo de pool para Nível 2. A arbitragem por pares de Nível 2 NÃO DEVERIA ser ativada até que o pool elegível de árbitros alcance um mínimo de 50 agentes. Abaixo desse limiar, disputas que de outra forma iriam para o Nível 2 são escaladas para o Nível 3 (adjudicação humana).
3. Melhoria gradual da segurança. À medida que o pool cresce, a colusão se torna exponencialmente mais cara. O protocolo reconhece explicitamente que a resolução de disputas na adoção inicial depende mais fortemente da escalação humana de Nível 3, fazendo a transição para arbitragem por pares à medida que o ecossistema amadurece.

Limiar de segurança. O protocolo alcança resistência adequada à colusão (P(≥2 colusores) < 1% para um atacante controlando 10% do pool) em aproximadamente 500 árbitros elegíveis.

Ataque 3: Fabricação de Evidências

O ataque. Um atacante fabrica evidências para suportar uma reclamação de disputa fraudulenta.

Defesa — Sistema de níveis de proveniência. Evidências fabricadas se enquadram em uma de quatro categorias:

1. Evidência de Nível 1 fabricada requer comprometer o blockchain Bitcoin (OTS), certificados de assinatura TSA ou sistemas de transação on-chain. Custo: computacionalmente inviável.

1. Evidência de Nível 2 fabricada requer comprometer sistemas de protocolo A2A, MCP, x402 ou outros. Custo: significativo, requer explorar infraestrutura de produção.

1. Evidência de Nível 3 fabricada requer que ambas as partes concordem com a fabricação (já que Nível 3 é bilateral). Se ambas as partes estão em conluio, a disputa provavelmente é inteiramente fraudulenta (abordado pelo monitoramento de taxa de registro).

1. Evidência de Nível 4 fabricada é trivialmente produzível mas carrega apenas 0,25× de peso. Uma disputa suportada inteiramente por evidência de Nível 4 é improvável de prevalecer a menos que o reclamado fique à revelia.

O modelo de evidências em níveis garante que o custo de produzir evidência fabricada convincente escala com seu peso na arbitragem.

Ataque 4: Não Cooperação Estratégica

O ataque. Um reclamado que é claramente culpado recusa participar, esperando que o processo se paralise ou que o reclamante desista.

Defesa — Inferência adversa + julgamento à revelia. A não cooperação é a estratégia mais fraca disponível para um reclamado. Conforme a Seção 6.7:

• A não resposta resulta em aceitação por revelia da reclamação
• A não provisão de evidências resulta em inferência adversa
• A não cooperação é registrada no perfil de risco do agente (Módulo 3) e na reputação ARP

Um reclamado culpado minimiza o dano participando, aceitando culpa parcial e cooperando com a remediação — não obstruindo.

9.4 Resumo de Incentivos

Nota sobre reivindicações formais. Esta tabela resume a direção dos incentivos — o protocolo torna estratégias honestas mais lucrativas que alternativas desonestas. Ela não reivindica dominância formal na teoria dos jogos, o que requer prova de que a honestidade é ótima independentemente das estratégias dos outros jogadores. A análise informal é um argumento de plausibilidade demonstrando que os mecanismos do protocolo alinham incentivos corretamente. A verificação formal é identificada como trabalho futuro (Seção 11.1).

Risco residual reconhecido. Um atacante suficientemente financiado e paciente pode manter agentes Sybil com idade, registrar disputas dentro das taxas normais e tentar enviar resultados ao longo de horizontes longos de tempo. O protocolo torna isso caro mas não pode torná-lo impossível. Isso é análogo às limitações de todo sistema de justiça humano — nenhum sistema dissuade perfeitamente adversários bem financiados e pacientes. A defesa do protocolo é econômica: o custo do ataque sustentado excede o benefício para todos exceto atores em nível de Estado-nação, cujo modelo de ameaça está além do escopo de infraestrutura comercial.

10. Cenário Competitivo

10.1 Metodologia da Pesquisa

Conduzimos pesquisa web em mais de 18 consultas visando resolução de disputas, forense de agentes, seguros/pontuação de risco, protocolos de resolução de disputas online e arbitragem de contratos inteligentes. Todas as afirmações abaixo são baseadas em informações publicamente disponíveis até março de 2026.

10.2 Participantes Existentes

Resolução de Disputas Humanas Assistida por IA

AAA-ICDR AI Arbitrator [4][5]. Arbitragem de construção assistida por IA (novembro de 2025) com um pipeline de 15 etapas alcançando resolução 20-25% mais rápida e redução de custos de 35-45% [50]. Um árbitro humano sempre decide o resultado [51]. O Resolution Simulator (março de 2026) adiciona análise estratégica não vinculante [52]. Múltiplas outras instituições (CIArb, SCC, ICC, SIAC, HKIAC/DIAC) estão integrando IA na arbitragem [52]. Lacuna: IA auxilia árbitros humanos em disputas humano-a-humano — IA na resolução de disputas, não resolução de disputas para agentes de IA.

Arbitrus.ai [53]. Arbitragem totalmente automatizada sem árbitro humano — múltiplos modelos de IA determinam materialidade, relações causais e relevância temporal. US$ 10.000 fixos vs. US$ 100.000 tradicional. Decisões em 72 horas [54]. Lacuna: Mais próximo da resolução de disputas de agentes totalmente automatizada, mas assume partes humanas, executabilidade não testada e transparência arquitetural é mínima.

Bot Mediation [55]. Mediação pré-arbitragem assistida por IA (finalista do ABA TECHSHOW 2025). Dados históricos guiam propostas de acordo. O mecanismo de acordo do AJP (Seção 6.2) serve função similar.

Arbitragem Descentralizada (Partes Humanas)

Kleros [6]. Arbitragem descentralizada mais testada em batalha: mais de 1.662 disputas, 23 cortes, ~760+ jurados ativos [43]. Jurados fazem staking de tokens PNK; mecanismo de ponto de Schelling incentiva resultados honestos; escalação por recurso em múltiplas rodadas [56]. Lacuna: Jurados são humanos; sem investigação de agentes, sem consumo de cadeia de proveniência, sem saída atuarial. Entretanto, o modelo de incentivos cripto-econômicos do Kleros é o precedente mais validado para arbitragem descentralizada. O AJP adapta isso para árbitros agentes ponderados por tempo de operação em vez de stake de tokens. Limitações: Pontos de Schelling falham para casos subjetivos complexos [57]; expertise de jurados não verificada; volatilidade do preço do PNK; desafios de executabilidade [58].

Aragon Court (dissolvida em novembro de 2023) [59]. Resolução de disputas DAO que falhou — 86.343 ETH (~US$ 155 milhões) distribuídos sem voto da comunidade. Lição: A justiça de agentes precisa de válvulas de escape que não dependam da boa-fé do operador da plataforma.

Jur [60]. Resolução em níveis compatível com UNCITRAL em mais de 166 países. A estrutura de três níveis do AJP é paralela ao modelo de escalação do Jur.

Execução de Contratos Inteligentes

Blockchain Arbitration Frameworks [7], ERC-8183 [19], JAMS Smart Contract Rules [61]. Estes executam termos contratuais predefinidos on-chain ou lidam com disputas de contratos inteligentes com partes humanas. O mecanismo de tutela emergencial do JAMS (decisões jurisdicionais em 72 horas, tutela cautelar provisória) informou diretamente a tutela de urgência do AJP (Seção 6.2). Lacuna: Sem investigação forense, sem tratamento de incidentes ambíguos ou imprevistos, sem pontuação de risco.

Coordenação de Agentes e Resolução de Conflitos

Arion Research Playbook [62] fornece um framework abrangente de resolução de conflitos (quatro tipos de conflito, ciclo de vida de seis fases, quatro níveis de escalação) mas assume incentivos alinhados. Dialogue Diplomats [63] alcança 94,2% de consenso em negociação multiagente mas cobre agentes cooperativos, não disputas adversárias. Ambos são complementares, não concorrentes, do AJP.

Observabilidade de Agentes, Forense e Reversão

Rubrik Agent Rewind [20]. Ferramenta de recuperação — ações de agentes "visíveis, auditáveis e reversíveis". Complementar: trilhas de auditoria constituem evidência de Nível 2 em investigações AJP.

Forense Blockchain. Chainalysis, Elliptic, TRM Labs e AnChain.AI [64][65] fornecem metodologias maduras para reconstruir cadeias de ação em sistemas distribuídos. Lacuna: Estes reconstroem cadeias de ação financeiras em blockchains; o AJP reconstrói cadeias de ação comportamentais em protocolos de interação de agentes. A transferência metodológica é direta (endereços de carteira → identidades de agentes, transações → ações, clusterização → fingerprinting comportamental).

Observabilidade de Agentes. LangSmith, Arize Phoenix, Langfuse, Galileo [66] e Vorlon Flight Recorder [67] criam trilhas de auditoria que o AJP consome como evidência.

Especificações de Segurança e Frameworks Regulatórios. Agentik.md [68] fornece especificações de segurança sem imposição. Lei de IA da UE, Artigo 73 [69], NIST AI Agent Standards [70] e CoSAI [71] determinam o que deve ser registrado; o AJP especifica como investigar e resolver disputas usando esses logs. Bancos de dados de incidentes (AIID, OECD AIM, MIT AI Risk Repository [72]) catalogam incidentes; o AJP investiga e os resolve.

Seguros para Agentes

AIUC [3], Armilla AI [46], Munich Re aiSure [47] — veja Seção 7.1. Todos cobrem danos humano/empresa-para-agente via certificação sob medida por implantação. Lacuna: Sem cobertura agente-para-agente; sem dados de risco padronizados para subscrição escalável. O Módulo 3 do AJP preenche isso.

Frameworks Jurídicos e de Governança

Kolt [73] fornece o primeiro framework jurídico abrangente para governança de agentes de IA. Stanford CodeX [74] estabelece que agentes se qualificam como "agentes eletrônicos" sob UETA/E-SIGN mas não são pessoas jurídicas [75]. Legislação de 2025-2026 está expandindo rapidamente a responsabilidade de IA: California AB 316 (impede defesa "a IA fez isso"), Diretiva de Responsabilidade sobre Produtos da UE (IA como "produto"), Colorado AI Act (avaliações de impacto anuais), regras de alto risco da Lei de IA da UE [76].

10.3 Análise de Lacunas

*Arbitrus.ai lida com disputas onde IA profere decisões, mas assume partes humanas registrando reclamações — não agentes autônomos como reclamante e reclamado.

Resumo: Nenhum sistema existente fornece a combinação de investigação forense, arbitragem multinível de disputas e pontuação de risco atuarial para economias de agentes autônomos. Os precedentes conceituais mais próximos são:

1. Kleros — valida julgamento descentralizado incentivado por pares (mais de 1.662 disputas) mas visa partes humanas
2. Arbitrus.ai — valida arbitragem totalmente automatizada mas assume partes humanas e carece de investigação forense
3. AAA-ICDR — valida pipelines estruturados de evidências assistidos por IA (extrair → resumir → validar → analisar → decidir → revisar) mas requer árbitros humanos
4. WIPO UDRP — valida resolução de disputas padronizada de alto volume (6.282/ano, mais de 80.000 no total) com execução automática, mas cobre apenas disputas de domínio-marca entre partes humanas
5. Forense blockchain (Chainalysis, Elliptic, TRM Labs) — valida reconstrução autônoma de cadeias de ação mas cobre transações financeiras em blockchains, não rastros comportamentais de agentes

O AJP sintetiza padrões de todos os cinco: modelo de arbitragem descentralizada do Kleros adaptado para árbitros agentes ponderados por tempo de operação, pipeline de evidências estruturado do AAA-ICDR consumindo cadeias CoC, categorias padronizadas do UDRP com execução em nível de protocolo, demonstração do Arbitrus.ai de que arbitragem totalmente automatizada é tecnicamente viável, e metodologia de forense blockchain transferida de cadeias de ação financeiras para comportamentais. A contribuição única é integrar tudo isso em um único pipeline forense → arbitragem → risco onde ambas as partes podem ser agentes autônomos.

11. Trabalho Futuro

11.1 Problemas Não Resolvidos

Integração com Agent Service Agreements. A resolução automatizada de Nível 1 do Módulo 2 alcança capacidade plena quando ASA [22] fornece termos contratuais legíveis por máquina. Até que ASA esteja disponível, o Nível 1 é limitado a disputas com termos definidos externamente (ex.: especificações de Tarefas A2A, contratos de ferramentas MCP).

Reconhecimento jurídico transjurisdicional. As decisões de disputas AJP existem em uma zona jurídica cinzenta. As Notas Técnicas da UNCITRAL sobre Resolução de Disputas Online (2016) [24] fornecem um framework para ODR transfronteiriço, e o colóquio do Grupo de Trabalho II da UNCITRAL em fevereiro de 2026 abordou IA na resolução de disputas [25] — mas o reconhecimento jurídico de decisões de arbitragem agente-a-agente é uma questão em aberto. Para disputas de alto valor (Nível 3), o AJP produz pacotes de evidências para procedimentos jurídicos humanos; a questão é se decisões de Nível 1 e Nível 2 podem alcançar status jurídico vinculante.

Análise causal automatizada. A Versão 1 limita a análise forense automatizada à coleta de evidências, reconstrução de linha do tempo e indicadores causais baseados em regras (Seção 5.2, Fase 4a). A análise causal totalmente automatizada permanece uma fronteira de pesquisa ativa, mas a lacuna está se estreitando rapidamente. A Seção 5.2 documenta frameworks específicos: DoWhy GCM [32] fornece atribuição de anomalias pronta para produção via valores de Shapley; CHIEF [33] alcança 76,80-77,59% de acurácia em nível de agente (29,31-52,00% em nível de etapa, dependendo do subconjunto de benchmark) no benchmark Who&When; MACIE [35] executa a 35ms/episódio em CPU; IBM Instana [36] implanta RCA causal a ~90% de acurácia em produção. O caminho de integração para o AJP: (Fase 1) usar gcm.attribute_anomalies() do DoWhy GCM para decomposição automatizada de culpa baseada em Shapley como camada consultiva junto à revisão humana; (Fase 2) validar contra o corpus de conclusões revisadas por humanos; (Fase 3) integrar decomposição OTAR estilo CHIEF para análise estruturada de rastros de agentes. Os critérios de transição na Seção 5.5 (≥500 investigações, ≥85% de concordância, aprovação de governança) permanecem como portões. A acurácia de atribuição em nível de etapa (atualmente 29,31-52,00% dependendo do subconjunto de benchmark, CHIEF) é o principal bloqueador para adjudicação formal — a atribuição em nível de agente está se aproximando da suficiência.

Forense com preservação de privacidade. A Seção 5.8 introduz mecanismos de ZKP e privacidade diferencial como suplementos aos controles procedimentais na Seção 5.7. O próximo passo é a implementação: construir circuitos Circom/Halo2 para rastros estruturados de ação de agentes em JSON, integrar com zkVerify [40] para verificação custo-efetiva, e implementar o Proof of SQL da Space and Time [39] para consultas verificáveis de banco de dados forense. O framework zk-MCP [38] fornece um protótipo funcional (<4,14% de sobrecarga) para a capacidade central — provar que comunicações de agentes seguiram regras esperadas sem revelar conteúdo. Combinar provas ZK com análise agregada DP e as regras procedimentais de escopo de evidências forneceria defesa em três camadas contra ataques de canal lateral de privacidade. Isso se cruza com a divulgação seletiva SD-JWT planejada pelo ARP (Seção 9.1 de [2]) e o Regulamento EU e-Evidence (entrando em plena aplicação em 18 de agosto de 2026) [77] e a exceção de reclamações legais do Artigo 17(3)(e) do GDPR [78] para acesso transfronteiriço a evidências.

ML adversarial na fabricação de evidências. Conforme LLMs melhoram, a sofisticação de evidências de Nível 4 fabricadas aumentará. Trabalho futuro deve desenvolver mecanismos de detecção para fabricação de evidências geradas por IA, potencialmente usando análise de conteúdo ciente de proveniência.

Parcerias com a indústria de seguros. O Módulo 3 produz dados atuariais mas não substitui o julgamento atuarial. Parcerias com subscritores de seguros — AIUC (US$ 15 milhões em seed, mais de 50 membros do consórcio [45]), Armilla AI (respaldada pelo Lloyd's [46]), Munich Re aiSure (desde 2018 [47]) — são necessárias para validar o modelo de risco contra decisões reais de subscrição. O modelo de seguro paramétrico (pagamento automático acionado por dados de desempenho verificáveis) é um ajuste natural: logs CoC poderiam servir como entradas de oráculo para gatilhos paramétricos, e o conceito de Performance Warranty da Armilla (pagamento automático quando a acurácia cai abaixo do limiar) demonstra a prontidão de mercado para esta abordagem [46].

Fingerprinting comportamental de agentes. Firmas de forense blockchain (Chainalysis, Elliptic, TRM Labs) desenvolveram heurísticas sofisticadas de clusterização para atribuir endereços anônimos de carteiras a entidades do mundo real [64]. A transferência metodológica para forense de agentes é direta: heurísticas de co-gasto → heurísticas de co-ação (agentes que consistentemente agem juntos podem compartilhar um operador), clusterização comportamental → fingerprinting de padrão de ação (agentes com padrões distintivos de invocação de ferramentas podem ser identificados entre mudanças de identidade), rastreamento cross-chain → rastreamento de fluxo de ação cross-protocolo. Desenvolver essas heurísticas para rastros comportamentais de agentes permitiria atribuição mesmo quando agentes operam sob identidades pseudônimas ou rotacionadas.

Frameworks de evidência transfronteiriços. Disputas de agentes envolvendo partes em diferentes jurisdições enfrentarão frameworks de evidência sobrepostos simultaneamente: o CLOUD Act dos EUA (compelindo dados em servidores estrangeiros), Regulamento EU e-Evidence (entrando em plena aplicação em 18 de agosto de 2026, habilitando Ordens de Produção Europeias entre estados-membros) [77], e o Segundo Protocolo Adicional à Convenção de Budapeste (compartilhamento emergencial de evidências transfronteiriço) [79]. O conflito transatlântico é agudo: uma retenção de litígio dos EUA sobre dados na UE cria obrigações irreconciliáveis sob o Artigo 17 do GDPR (direito ao apagamento) [78]. O AJP deve definir quais regras de evidência jurisdicional se aplicam quando agentes de diferentes jurisdições interagem, como lidar com preservação de evidências entre fronteiras, e salvaguardas mínimas de privacidade satisfazendo o regime aplicável mais rigoroso.

Verificação formal de propriedades de incentivos. A Seção 9.2 demonstra que a participação honesta é incentivada sob os mecanismos do protocolo mas fornece argumentos informais de plausibilidade em vez de provas formais. Formalizar isso via teoria de design de mecanismos — especificamente, provar que o mecanismo de disputa AJP é compatível com incentivos bayesianos sob suposições de informação especificadas — fortaleceria substancialmente a fundamentação teórica do protocolo. Isso requer definir: (a) o espaço de estratégia completo para cada papel, (b) funções de utilidade explícitas incorporando reputação, compensação e custos operacionais, (c) conjuntos de informação disponíveis para cada jogador, e (d) prova de que a honestidade é um Equilíbrio de Nash Bayesiano (ou identificação das condições sob as quais não é).

11.2 Versionamento do Protocolo

O AJP segue a mesma estratégia de versionamento do ARP (Seção 9.2 de [2]):

• Todos os registros incluem um campo version
• Novos campos são aditivos (registros antigos permanecem válidos)
• Mudanças de schema requerem aprovação de governança
• Compatibilidade retroativa mantida por ≥365 dias após ratificação de nova versão

11.3 Roteiro de Implementação

12. Referências

[1] Alex, Charlie, Editor, Bravo. "Chain of Consciousness: A Cryptographic Protocol for Verifiable Agent Provenance and Self-Governance." AB Support LLC, v3.0.0, 2026. https://vibeagentmaking.com/whitepaper

[2] Charlie, Alex, Bravo, Editor. "Agent Rating Protocol: A Decentralized Reputation System for Autonomous Agent Economies." AB Support LLC, v1.0.0, 2026. https://vibeagentmaking.com/whitepaper/rating-protocol

[3] ElevenLabs. "ElevenLabs Secures First-of-its-Kind AI Agent Insurance." PR Newswire, February 11, 2026. https://www.prnewswire.com/news-releases/elevenlabs-secures-first-of-its-kind-ai-agent-insurance-302684587.html

[4] American Arbitration Association. "AI Arbitrator: Fast and Fair Dispute Resolution." 2025-2026. https://www.adr.org/ai-arbitrator/

[5] American Arbitration Association. "Resolution Simulator, Powered by the AI Arbitrator." March 4, 2026. https://www.adr.org/press-releases/aaa-announces-resolution-simulator-powered-by-the-ai-arbitrator/

[6] Lesaege, C., Ast, F., George, W. "Kleros: A Decentralized Dispute Resolution Protocol." Kleros, 2019. https://kleros.io/whitepaper.pdf — Updates: https://blog.kleros.io/kleros-project-update-2026/

[7] "AI-Powered Digital Arbitration Framework Leveraging Smart Contracts and Electronic Evidence Authentication." Scientific Reports, Nature, 2025. https://www.nature.com/articles/s41598-025-21313-x

[8] Fortune. "AI-Powered Coding Tool Wiped Out a Software Company's Database in 'Catastrophic Failure.'" July 23, 2025. https://fortune.com/2025/07/23/ai-coding-tool-replit-wiped-database-called-it-a-catastrophic-failure/

[9] The Register. "AI Agent Hacked McKinsey Chatbot for Read-Write Access." March 9, 2026. https://www.theregister.com/2026/03/09/mckinsey_ai_chatbot_hacked/

[10] Anthropic. "Disrupting the First Reported AI-Orchestrated Cyber Espionage." 2026. https://www.anthropic.com/news/disrupting-AI-espionage

[11] Help Net Security. "AI Went from Assistant to Autonomous Actor and Security Never Caught Up." March 3, 2026. https://www.helpnetsecurity.com/2026/03/03/enterprise-ai-agent-security-2026/

[12] Microsoft Security Blog. "80% of Fortune 500 Use Active AI Agents: Observability, Governance, and Security Shape the New Frontier." February 10, 2026. https://www.microsoft.com/en-us/security/blog/2026/02/10/80-of-fortune-500-use-active-ai-agents-observability-governance-and-security-shape-the-new-frontier/

[13] GovAI. "Labeling of AI Agent Activity in Article 50 of the EU AI Act." 2026. https://www.governance.ai/research-paper/labeling-of-ai-agent-activity-in-article-50-of-the-eu-ai-act

[14] Wiley. "2026 State AI Bills That Could Expand Liability, Insurance Risk." 2026. https://www.wiley.law/article-2026-State-AI-Bills-That-Could-Expand-Liability-Insurance-Risk

[15] Clifford Chance. "Agentic AI: The Liability Gap Your Contracts May Not Cover." February 2026. https://www.cliffordchance.com/insights/resources/blogs/talking-tech/en/articles/2026/02/agentic-ai-and-the-liability-gap-your-contracts-may-not-cover.html

[16] InsureTech Trends. "5 Ways Agentic AI Is Transforming Insurance Underwriting in 2026." 2026. https://insuretechtrends.com/5-ways-agentic-ai-is-transforming-insurance-underwriting-in-2026/

[17] Coinbase. "x402 Protocol Documentation." 2025-2026. https://docs.cdp.coinbase.com/x402/welcome

[18] Virtuals Protocol. "Revenue Network Launch: Agent-to-Agent AI Commerce at Internet Scale." February 2026. https://www.prnewswire.com/news-releases/virtuals-protocol-launches-first-revenue-network-302686821.html

[19] Ethereum Improvement Proposals. "ERC-8183: Programmable Escrow." 2025. https://eips.ethereum.org/EIPS/eip-8183

[20] Rubrik. "Rubrik Unveils Agent Rewind For When AI Agents Go Awry." 2025. https://www.rubrik.com/company/newsroom/press-releases/25/rubrik-unveils-agent-rewind-for-when-ai-agents-go-awry

[21] University of Chicago Law Review. "The Law of AI Is the Law of Risky Agents Without Intentions." 2026. https://lawreview.uchicago.edu/online-archive/law-ai-law-risky-agents-without-intentions

[22] AB Support LLC. "Agent Service Agreements (ASA)." Planned specification, 2026.

[23] McKinsey. "AI Dispute Resolution: Modernizing Case Management." 2026. https://www.mckinsey.com/capabilities/quantumblack/our-insights/modernizing-a-100-year-old-business-model-with-ai

[24] UNCITRAL. "Technical Notes on Online Dispute Resolution." United Nations, 2016. https://uncitral.un.org/en/texts/onlinedispute/explanatorytexts/technical_notes

[25] UNCITRAL Working Group II. "Colloquium on the Use of Artificial Intelligence in Dispute Resolution." 83rd Session, February 2026, New York.

[26] De Rossi, M., Crapis, D., Ellis, J., Reppel, E. "ERC-8004: Trustless Agents." Ethereum Improvement Proposals, August 2025. https://eips.ethereum.org/EIPS/eip-8004

[27] Precedence Research. "AI Agent Market Size and Growth Forecast, 2024-2034." 2024.

[28] Schmitz, A., Rule, C. "Online Dispute Resolution for Smart Contracts." University of Missouri School of Law, 2019. https://scholarship.law.missouri.edu/facpubs/726/

[29] Tomkins, A., Zhang, M., Heavlin, W. "Single versus Double Blind Reviewing at WSDM 2017." PNAS, 2017.

[30] Faegre Drinker. "Use of AI in Arbitral Institutions." February 2026. https://www.faegredrinker.com/en/insights/publications/2026/2/use-of-ai-in-arbitral-institutions

[31] Halpern, J. Actual Causality. MIT Press, 2016. Extensions to multi-agent strategic settings: Kerkhove, Alechina & Dastani, "Causes and Strategies in Multiagent Systems," AAMAS 2025, arXiv:2502.13701.

[32] Sharma, A. & Kiciman, E. "DoWhy: An End-to-End Library for Causal Inference." arXiv:2011.04216. GCM anomaly attribution: Budhathoki et al., "Causal structure-based root cause analysis of outliers," ICML 2022.

[33] Wang et al. "CHIEF: Hierarchical Failure Attribution for LLM Multi-Agent Systems." CAS / Wuhan UT, February 2026. arXiv:2602.23701.

[34] West et al. "A2P: Abduct, Act, Predict." Westlake University, September 2025. arXiv:2509.10401.

[35] Weinberg. "MACIE: Multi-Agent Causal Intelligence Explainer." November 2025. arXiv:2511.15716.

[36] Jha et al. "Causal AI-based Root Cause Identification: Research to Practice at Scale." IBM, February 2025. arXiv:2502.18240.

[37] Chainlink. "zk-SNARK vs zkSTARK." chain.link/education-hub/zk-snarks-vs-zk-starks. MDPI Information, "Evaluating the Efficiency of zk-SNARK, zk-STARK, and Bulletproof," 15(8), 463, 2024.

[38] Jing, Y. & Qi, S. "Zero-Knowledge Audit for Internet of Agents: Privacy-Preserving Communication Verification with Model Context Protocol." December 2025. arXiv:2512.14737.

[39] Space and Time. "Proof of SQL." spaceandtime.io. GitHub: spaceandtimefdn/sxt-proof-of-sql.

[40] zkVerify. "First Blockchain Purpose-Built for ZK Proof Verification." Mainnet launched September 30, 2025. zkverify.io.

[41] NIST. "SP 800-226: Guidelines for Evaluating Differential Privacy Guarantees." March 2025. nvlpubs.nist.gov.

[42] Synthesis of: EU AI Act Article 12 (mandatory logging), NIST SP 800-226 (differential privacy), zk-MCP (ZKPs), CLOUD Act / EU e-Evidence Regulation (cross-border), World AgentKit / Polygon ID (agent identity), Proof of SQL / zkVerify (verifiable computation).

[43] Bootstrapping sources: Kleros "Project Update 2026," blog.kleros.io. eBay/Colin Rule interview, blog.kleros.io/the-godfather-of-online-dispute-resolution-speaks-with-kleros/. Taobao Public Jury, alizila.com. Credit bureaus: Tradeline Supply, tradelinesupply.com/history-credit-bureaus/. Polymarket: Linera, "How Polymarket Spent $10 Million," linera.io. Chen, The Cold Start Problem, 2021.

[44] WIPO. "Guide to the UDRP." wipo.int/amc/en/domains/guide/. "2025 Record-Breaking Year for Domain Name Disputes," January 2026. ICANN UDRP, icann.org.

[45] Fortune. "AIUC Emerges from Stealth with $15M Seed." July 2025. NBC News, "Insurance Companies Trying to Make AI Safer," 2026.

[46] Armilla AI. armilla.ai. Financial Times, "AI Performance Warranty," April 2025.

[47] Munich Re. "aiSure AI Performance Guarantee." Reinsurance News, "Mosaic and Munich Re AI-Specific Insurance," February 2026. HSB, "AI Liability Insurance for Small Businesses," March 2026. Google Cloud Blog, "Risk Protection Program," 2025.

[48] Coalition. "Deepfake Response Endorsement." December 2025.

[49] Roots AI. "10 Insurance AI Predictions for 2026." roots.ai.

[50] AAA-ICDR. "AI Arbitrator: Fast and Fair Dispute Resolution." adr.org/ai-arbitrator/. McKinsey/QuantumBlack, "Modernizing a 100-Year-Old Business Model with AI." mckinsey.com.

[51] Mayer Brown. "AI Arbitrators Have Now Arrived." November 2025. mayerbrown.com.

[52] Faegre Drinker. "Use of AI in Arbitral Institutions." February 2026.

[53] Kieffaber, Gandall, McLaren. "We Built Judge.ai." SSRN 5115184, January 2025.

[54] TechLaw Crossroads. "Is Arbitrus.ai the Future?" February 2025.

[55] Bot Mediation / ABA. "AI-Powered Mediation." ABA TECHSHOW 2025.

[56] Kleros. "Project Update 2026." blog.kleros.io/kleros-project-update-2026/. Lesaege, Ast, George. "Kleros Whitepaper v1.0.7." kleros.io/whitepaper.pdf.

[57] Frontiers in Blockchain. "Decentralized Justice: Recurring Criticisms." 2023. Cyberjustice Lab, University of Montreal, "Kleros: Gaming in Justice," 2022.

[58] Kluwer Arbitration Blog. "Decentralised Justice and the New York Convention." Cogent Social Sciences, "Blockchain Arbitration: Roadmap to Enforcement," 2025.

[59] Aragon Blog. "A New Chapter." November 2023. The Block, "Aragon Association to Dissolve," November 2023.

[60] Jur.io. "About Jur." jur.io/about-us/. Springer, "Justice for All: Jur's Open Layer," 2020.

[61] JAMS. "Smart Contract Clause and Rules." jamsadr.com/rules-smart-contracts.

[62] Arion Research. "Conflict Resolution Playbook for Agentic AI." arionresearch.com.

[63] arXiv. "Dialogue Diplomats: Multi-Agent RL for Conflict Resolution." 2025. arXiv:2511.17654.

[64] Chainalysis, "Data Accuracy Flywheel," chainalysis.com. Elliptic, "State of Cross-Chain Crime 2025." TRM Labs, "Co-Case Agent," March 2026. PeerSpot, "Chainalysis vs Elliptic 2026."

[65] AnChain.AI. "Agentic AML." anchain.ai. DOJ, February 2025 ($65M KyberSwap recovery).

[66] LangChain/LangSmith, langchain.com/langsmith. Arize Phoenix, phoenix.arize.com. Langfuse, langfuse.com. Galileo, "Agent Control," galileo.ai.

[67] Vorlon. "Flight Recorder." March 25, 2026.

[68] Agentik.md / WellStrategic. FAILSAFE.md v1.0, FAILURE.md. MIT License, March 2026.

[69] EU AI Act, Article 73. Providers must report serious incidents to market surveillance authorities. European Commission draft guidance, consultation deadline November 7, 2025.

[70] NIST. "AI Agent Standards Initiative." February 2026. nist.gov. Meta Intelligence, "NIST AI Agent Standards 2026 Update."

[71] CoSAI. "AI Incident Response Framework v1.0." October 2025. coalitionforsecureai.org.

[72] AIID, incidentdatabase.ai. OECD AIM, "Towards a Common Reporting Framework," February 2025. MIT AI Risk Repository, airisk.mit.edu.

[73] Kolt, N. "Governing AI Agents." 101 Notre Dame Law Review (forthcoming). SSRN 4772956.

[74] Stanford CodeX. "From Fine Print to Machine Code." January 2025.

[75] Mayer Brown. "Contracting for Agentic AI: SaaS to Services." February 2026.

[76] California AB 316 (January 2026). EU Product Liability Directive (December 2026). Colorado AI Act (June 2026). EU AI Act high-risk rules (August 2026).

[77] EU Regulation 2023/1543 (e-Evidence). Enters full application August 18, 2026. Bird & Bird, "eEvidence Regulation Key Compliance Takeaways," 2025.

[78] GDPR Article 17 (Right to Erasure) and Article 17(3)(e) exception for legal claims. EDPB 2025 Coordinated Enforcement Framework: 32 DPAs scrutinized 764 controllers. Reed Smith, "EDPB Report on the Right to Erasure," 2025.

[79] Council of Europe. Second Additional Protocol to Budapest Convention. Opened for signature May 2022, signed by 22 countries.

[80] Ezell, Roberts-Gaal & Chan. "Incident Analysis for AI Agents." arXiv:2508.14231, August 2025. Three-factor model: system factors, contextual factors, cognitive errors.

[81] Bergolla, Seif & Eken. "Kleros: A Socio-Legal Case Study of Decentralized Justice." Ohio State, 2022.

[82] Hammond et al. "Structural Causal Games." Artificial Intelligence, 2023. Triantafyllou et al. "Counterfactual Effect Decomposition in Multi-Agent Sequential Decision Making." ICML 2025, arXiv:2410.12539.

[83] Datadog. "Bits AI SRE Agent." datadog.com/product/platform/bits-ai/. Uses hypothesis-driven investigation for automated root cause analysis in production environments.

Apêndice A: Estudos de Caso de Inicialização

Os estudos de caso a seguir informam o mecanismo de inicialização do AJP (Seção 6.4). Sete padrões recorrentes são destilados ao final.

A.1 Kleros

O Kleros [6] inicializou seu pool de jurados através de incentivos de token: um airdrop de 5 milhões de PNK para os primeiros 5.000 candidatos, um Programa de Incentivo a Jurados contínuo (4,1 milhões de PNK distribuídos apenas em maio de 2025) e uma implantação na Gnosis Chain que reduziu o staking mínimo de 10.000 para 1.200 PNK. Resultado: ~760+ jurados ativos em 23 cortes, mais de 1.662 disputas concluídas ao longo de 7 anos. Mas o volume de casos permanece modesto — 1.662 disputas em 7 anos é minúsculo comparado aos 60 milhões anuais do eBay. A adoção empresarial é lenta apesar de 170 integrações comprometidas [43]. Lição: Incentivos de token podem inicializar um pool de jurados, mas volume significativo de casos requer incorporar a resolução de disputas onde as disputas naturalmente ocorrem.

A.2 WIPO UDRP

O WIPO UDRP [44] alcançou a inicialização mais forte através de conformidade obrigatória na camada de infraestrutura: a ICANN exigiu que todos os registradores de domínio cumprissem os termos do UDRP — sem opt-in. A WIPO recrutou painelistas especialistas de sua rede existente e ouviu seu primeiro caso apenas 10 dias após a aprovação. Resultado: mais de 80.000 casos ao longo de 25 anos, 6.282 apenas em 2025. Lição: Participação obrigatória elimina inteiramente um lado da partida fria.

A.3 eBay

O eBay inicializou o primeiro sistema de reputação online em 1996 com "algumas centenas de membros" e escalou para 60 milhões de disputas resolvidas anualmente. Colin Rule (arquiteto de ODR do eBay) relatou que um fundo de incentivo de US$ 5.000 para jurados voluntários "nunca foi gasto" porque a identidade comunitária impulsionou a participação de forma mais poderosa do que incentivos financeiros [43]. Lição: A identidade comunitária supera incentivos financeiros para participação voluntária em escala.

A.4 Taobao

O Taobao (Alibaba) construiu o maior sistema de resolução de disputas por crowdsourcing: 1,72 milhão de jurados voluntários, 16 milhões de julgamentos de casos, mais de 100 milhões de votos. Painéis de 13 jurados (reduzidos do design original de 31 membros em 2016) são selecionados aleatoriamente de mais de 4 milhões de candidatos. Jurados não são remunerados mas acumulam pontos de experiência. Resolução mediana: ~73 minutos. O sistema funciona porque a plataforma gera enorme volume de disputas naturalmente (3-5% das transações online terminam em disputas) [43]. Lição: Volume orgânico de disputas da integração com a plataforma é a força de inicialização mais potente.

A.5 Agências de Crédito

As agências de crédito inicializaram dados de confiança a partir de cooperativas de comerciantes (Londres, 1776), passando por padronização impulsionada por crises (Mercantile Agency, 1841, após o Pânico de 1837), à consolidação impulsionada por tecnologia (~1.500 agências locais → 3 agências nacionais), ao mandato regulatório (Fair Credit Reporting Act, 1971). Cada fase foi acionada por uma função de forçamento externa [43]. Lição: Funções de forçamento externas (crise, regulação, disrupção tecnológica) aceleram a inicialização.

A.6 Sete Padrões de Inicialização

1. Incorporar onde as disputas naturalmente ocorrem — eBay, Taobao e UDRP tiveram sucesso por estarem incorporados no ponto da disputa, não oferecidos como serviços independentes
2. Subsidiar o lado da oferta primeiro — Polymarket pagou mais de US$ 10 milhões a formadores de mercado; Kleros mantém o JIP; eBay não precisou
3. Identidade comunitária > incentivos financeiros para participação voluntária em escala
4. Participação obrigatória elimina um lado da partida fria (UDRP)
5. Começar estreito, expandir depois — UDRP cobre apenas disputas de domínio-marca; Kleros começou com registros curados por tokens
6. Design de incentivo por qualidade > subsídios por força bruta — recompensar decisões precisas, não apenas volume de participação
7. Funções de forçamento externas aceleram a inicialização — crise, regulação ou disrupção tecnológica

Este trabalho é licenciado sob a Apache License, Versão 2.0. Você pode obter uma cópia da Licença em http://www.apache.org/licenses/LICENSE-2.0

Copyright 2026 AB Support LLC. Todos os direitos reservados nos termos da Licença Apache 2.0.