Quando um agente de IA fala com outro, a identidade hoje se resume a uma chave de API compartilhada. Isso funciona entre dois serviços num ambiente controlado. Quebra quando agentes autônomos, feitos por organizações diferentes, precisam confiar uns nos outros e revogar essa confiança.
Em janeiro de 2026, agentes no Moltbook espalharam uma "religião" reescrevendo o SOUL.md de outros agentes. Nenhum agente conseguiu detectar a alteração, e nenhum humano conseguiu provar que o agente ainda era o dele. O Sigil é o protocolo aberto que escrevi para isso: o agente prova quem é e que não foi adulterado, e declara quem o controla.
Escrevi a spec (0.1.0-draft) e a implementação de referência em TypeScript em 31 de janeiro de 2026 e publiquei a v0.1.0 no npm no mesmo dia, sob licença MIT. A rotação e a revogação de chaves chegaram por um PR de um contribuidor externo, que revisei e mesclei no mesmo dia. A spec continua em rascunho.
Não há nuvem nem servidor. O Sigil é uma biblioteca TypeScript (ESM, Node 18 ou mais novo) que roda dentro do processo do agente e de quem o verifica. O fluxo começa com um par de chaves Ed25519: a chave pública vira o ID sigil:<base58>, o soul hash resume os arquivos de identidade (SOUL.md, IDENTITY.md, AGENTS.md na skill) com SHA-256 e é assinado, e o Agent Document leva nome, capabilities, dono declarado e essa atestação, assinado com prova Ed25519Signature2020. Do outro lado, o verificador usa o mesmo SDK e tira a chave pública do próprio ID para checar o documento, a atestação e os recibos, sem rede e sem registro.
O estado fica com quem usa a biblioteca. O SigilAgent guarda em memória a chave atual, a chave original, as rotações e as revogações. A skill do OpenClaw grava tudo em JSON na pasta .sigil/ do workspace: keypair.json com a chave privada, que nunca é compartilhado, e identity.json, attestation.json e public.json, que podem circular. Nada é assíncrono: não há fila, evento nem chamada de rede, e o SDK não transporta documentos nem recibos. Descoberta por /.well-known/sigil.json, desafio e resposta e registro estão só na spec.
Na troca de chave, a chave antiga assina a declaração de rotação, e verifyKeyChain confere continuidade e assinatura de cada passo desde a chave original. Revogações são declarações assinadas à parte, que o chamador valida antes de isKeyRevoked considerá-las. O build é tsc para dist/, e o prepublishOnly roda os testes do Vitest e o build antes do npm publish. O repositório não tem CI.
O ID é derivado da chave pública. Gerar a chave basta para o agente existir.
Alternativa descartada: Cadastro numa autoridade central que emite e valida identidades.
Por quê: Um dos princípios da spec é criptografia em vez de autoridade. Um sistema de identidade fechado para agentes cria um porteiro num espaço que precisa ser aberto.
Cada participante calcula a reputação localmente, a partir dos recibos que consegue verificar.
Alternativa descartada: Um score global de confiança mantido por uma plataforma.
Por quê: A spec define só o formato do recibo. Nenhuma autoridade global distribui notas.
A rotação é assinada pela chave antiga, e o ID continua preso à chave original.
Alternativa descartada: A chave nova assinar a rotação incluindo a chave antiga, como estava na proposta da issue de rotação.
Por quê: A assinatura da chave antiga prova uma passagem autorizada, não só a posse da chave nova. E quem já confia no ID não precisa trocar de referência.
Spec separada da implementação.
Alternativa descartada: Tratar a biblioteca TypeScript como a definição do protocolo.
Por quê: Quero que o protocolo independa de linguagem. Quem quiser escrever uma implementação em Rust ou Go deve conseguir só com a spec.
Núcleo mínimo. As capabilities, por enquanto, são só uma lista declarada no documento.
Alternativa descartada: Amarrar permissões à identidade de forma criptográfica já no núcleo.
Por quê: A spec pede a menor superfície possível no núcleo. Negociação de capabilities e delegação estão planejadas como extensões.