Right to History: A Sovereignty Kernel for Verifiable AI Agent Execution

Título: Direito à História: Um Kernel de Soberania para Execução Verificável de Agentes de IA

1. O Problema: A Lacuna de Responsabilidade e Verificabilidade

Com o aumento da adoção de agentes de IA que atuam em nome de humanos (enviando e-mails, modificando arquivos, executando código), surge um problema fundamental de responsabilidade: não existe atualmente nenhum sistema capaz de produzir uma prova criptográfica do que foi feito, quem autorizou e se o agente permaneceu dentro dos limites declarados.

• Limitações Atuais: Mecanismos de auditoria de nível de SO (como auditd ou eBPF) operam na granularidade de chamadas de sistema (syscalls) e não conseguem atribuir ações a semânticas de nível de agente ou suportar governança com intervenção humana. Sistemas de logs transparentes (como Certificate Transparency) fornecem ferramentas criptográficas, mas nunca foram aplicados ao registro de ações de agentes de IA.
• O Cenário de Hardware Pessoal: A lacuna é crítica quando agentes rodam em hardware pessoal. Diferente de provedores centralizados na nuvem, não há um servidor de logs controlado por terceiros. O usuário é simultaneamente provedor, implantador e supervisor. Sem um registro verificável, o usuário não pode garantir a integridade ou a completude do histórico de ações.
• Urgência Regulatória: Regulamentações como o Ato de IA da UE (Artigo 12) e o NIST AI Risk Management Framework começam a exigir registro automático e transparência para sistemas de alto risco. A ausência de um histórico verificável torna-se uma responsabilidade regulatória, especialmente para sistemas locais.

2. Metodologia e Conceito Central: O "Direito à História"

O artigo propõe o Direito à História (Right to History): o princípio de que indivíduos têm direito, em seu próprio hardware, a um registro completo, verificável e à prova de violação (tamper-evident) de cada ação realizada por um agente de IA em seu nome.

Para implementar isso, os autores desenvolveram o PunkGo, um kernel de soberania escrito em Rust. O sistema baseia-se em três pilares:

1. Kernel como Base de Computação Confiável (TCB): O kernel é o único componente confiável; os agentes (LLMs) e ferramentas externas são tratados como não confiáveis.
2. Logs de Auditoria Merkle (RFC 6962): Utilização de árvores de Merkle para criar logs imutáveis e append-only (apenas adição), permitindo provas de inclusão e consistência em tempo logarítmico.
3. Governança por Orçamento de Energia e Capacidades: Um modelo que combina isolamento baseado em capacidades (least privilege) com um sistema econômico de "energia" para limitar a taxa de ações e desencorajar ataques de negação de serviço ou tentativas de burlar limites.

3. Contribuições Principais

• C1. Framework Formal:
  • Definição de um modelo com três primitivas (Ator, Energia, Estado) e quatro ações atômicas (observar, criar, mutar, executar).
  • Estabelecimento de cinco invariantes do sistema com esboços de prova estruturados:
    1. Append-Only (Apenas Adição): O log nunca pode ser modificado ou deletado.
    2. Completude: Toda ação que passa na verificação de limites e tem energia suficiente é registrada.
    3. Integridade: A raiz da árvore Merkle reflete exatamente o conteúdo do log.
    4. Aplicação de Limites (Boundary Enforcement): Agentes não podem executar ações fora de seus limites declarados.
    5. Conservação de Energia: Agentes não podem consumir mais energia do que a alocada.
• C2. Implementação do Kernel PunkGo:
  • Um kernel em Rust que unifica logs de auditoria Merkle, limites de capacidade baseados em "envelopes" (envelopes de permissão) e governança de orçamento de energia.
  • Mecanismo de Hold (Suspensão): Um mecanismo de aprovação humana onde ações de alto risco pausam a execução até que um humano aprove ou rejeite, com um custo econômico (20% da energia reservada) para rejeições, desencorajando tentativas de sondagem de limites.
• C3. Inversão de Soberania:
  • O trabalho inverte a pergunta comum na literatura: em vez de "como os agentes mantêm soberania sobre humanos", o foco é "como os humanos mantêm soberania sobre os agentes".
• C4. Validação:
  • Verificação das invariantes através de testes adversariais e medição de desempenho.

4. Arquitetura do Sistema

O PunkGo opera em três camadas:

1. Camada de Agente (Não Confiável): LLMs e ferramentas que submetem ações ao kernel.
2. Kernel (TCB - Confiável): O único ponto de commit. Valida, registra e prova as ações. Não executa código externo, apenas registra o que o agente afirma ter feito (semelhante ao Certificate Transparency).
3. Camada de Cliente: Interface para aprovação humana e visualização de histórico.

Fluxo de Ação:

1. Validação: Verifica se a ação está dentro dos limites de capacidade do agente.
2. Cotação e Reserva: Calcula o custo em energia e reserva os recursos.
3. Hold (Opcional): Se a ação aciona uma regra de aprovação, o kernel registra um pedido de hold, reserva energia e espera a resposta humana.
4. Aprovação/Rejeição: Se aprovado, a ação é reenviada com guardas de replay; se rejeitado, paga-se um custo de compromisso (20%).
5. Append: A ação é escrita no log imutável e a árvore Merkle é atualizada.

5. Resultados e Avaliação

• Verificação de Invariantes: Todos os cinco invariantes foram testados sob cenários adversariais (tentativas de escalada de privilégio, esgotamento de orçamento, adulteração de histórico) e todos passaram. O sistema detectou adulterações em ~55ms.
• Desempenho:
  • Latência: Mediana de < 1,3 ms por ação (dominada por I/O de armazenamento e atualização da árvore Merkle).
  • Throughput: Aproximadamente 400 ações/segundo em execução sequencial.
  • Provas de Inclusão: Tamanho de 448 bytes para 10.000 entradas (14 hashes SHA-256), seguindo a complexidade $O(\log n)$.
• Comparação: Diferente do AIOS (que coloca o LLM como TCB e não possui logs auditáveis), o PunkGo coloca o kernel como TCB e fornece provas criptográficas de integridade.

6. Significado e Conclusão

O artigo estabelece que o registro verificável de ações não deve ser um recurso opcional, mas um compromisso arquitetural fundamental para a infraestrutura de agentes de IA.

• Soberania Computacional: O "Direito à História" estende o conceito de soberania de dados para a soberania do histórico computacional, permitindo que usuários em hardware pessoal cumpram regulamentações como o Ato de IA da UE sem depender de provedores de nuvem.
• Segurança e Auditoria: Ao fornecer um registro imutável e verificável independentemente, o PunkGo permite auditorias post-factum, resolução de disputas e detecção de desvios de comportamento do agente.
• Futuro: O trabalho abre caminho para a integração com ambientes de execução confiáveis (TEEs como SGX/TDX) para elevar a confiança contra adversários privilegiados e para a verificação formal automatizada (usando ferramentas como Verus).

Em suma, o PunkGo preenche a lacuna entre a capacidade de execução de agentes de IA e a necessidade crítica de responsabilidade e transparência, transformando o registro de ações em um direito fundamental do usuário.