EMILIA Protocol

EMILIA Protocol

---

Agentes de IA estão se tornando trabalhadores. Trabalhadores precisam de autoridade.

EMILIA é o plano de controle de autoridade para trabalho autônomo. Gate é o limite de consequência onde a intenção credenciada de um agente se torna uma mudança em dinheiro, código, permissões, registros ou infraestrutura. Um humano ou instituição define um mandato operacional finito; Gate verifica a unidade exata de trabalho contra esse mandato antes que o caminho protegido do provedor possa começar.

Gate é o Firewall de Consequências comercial nesse limite. Ele verifica a autoridade que o proprietário exige para a ação exata, reserva essa autoridade antes da entrada no provedor, permite uma tentativa admitida de provedor para a instância de autorização coberta dentro de seu domínio de autoridade durável, e deixa evidência portátil do que o caminho protegido admitiu e posteriormente observou. Quando o resultado é desconhecido, ele exige reconciliação em vez de uma nova tentativa cega. Protocolo prova. Gate previne.

• Authority Brain mapeia superfícies de ação declaradas suportadas localmente. Nenhuma conta, upload ou callback é necessário. A descoberta não cria autoridade; o proprietário revisa o mapa.
• EMILIA Gate transforma o mapa aprovado e o mandato operacional em controle preventivo em um caminho de executor totalmente mediado e que possui credenciais.
• EMILIA Protocol é o substrato aberto Apache-2.0 para identidade de ação exata, verificação nativa de evidências, composição de evidências, estado de admissão durável e registros de trabalho portáteis.
• EMILIA Approver captura uma decisão humana de ação exata vinculada ao dispositivo quando o mandato ou a política local exige autoridade humana fresca. Um clique humano é uma fonte de autoridade, não o modelo de execução padrão.
• EMILIA Assurance Plane fornece verificação escopada, re-execução, relatórios de conformidade e evidência de implantação. Ele apoia auditores, seguradoras, reguladores e clientes; EMILIA não é um auditor ou certificador acreditado, e nenhum programa público de certificação EMILIA está em operação.

Execute o mapa local (npx @emilia-protocol/scan), escolha um fluxo de trabalho consequente e coloque Gate onde a credencial do provedor transforma intenção em trabalho.

O primeiro perfil de distribuição de baixa fricção é o GitHub: o Merge Gate aberto vincula um mandato pertencente ao repositório e um recibo destacado aos commits exatos de base e cabeça antes que uma verificação de merge protegida passe. Ele é preventivo apenas quando o repositório torna a verificação obrigatória e fecha caminhos alternativos de merge. Isso é um experimento de produto e distribuição, não evidência de adoção externa.

O agente pode continuar rodando. Sua autoridade para.

Agentes contínuos e auto-melhoradores criam um problema de controle que a terminação de processo sozinha não pode resolver: o proprietário pode precisar parar novas consequências sem afirmar que a computação parou ou que um efeito externo foi revertido. O Emergency Authority Freeze do Gate torna isso uma transição de autoridade durável. Dentro de um domínio de controle Gate coberto, o congelamento bloqueia novas reservas e impede que uma reserva mais antiga entre após a mudança de época de controle. Se a entrada no provedor foi serializada primeiro, a operação permanece consumida e deve ser reconciliada; restaurar avança a época novamente e não revive autoridade antiga.

Essa garantia exige mediação completa e estado compartilhado autoritativo. Ela não para o agente, desfaz um efeito entrado ou fornece congelamento instantâneo em um domínio arrendado desconectado. A implementação de referência atual cobre o domínio de controle local em memória e PostgreSQL; propagação de borda arrendada e evidência de evento de congelamento assinada portátil permanecem lacunas explícitas de implementação.

O fluxo de trabalho pago nomeado permanece a determinação adversa de necessidade médica assistida por IA do pagador, sob uma regra de segurança: sem evidência válida de revisão licenciada, sem determinação adversa. Evidência ausente encaminha para revisão humana legal ou um fallback protetor do paciente; não é autoridade para reter cuidados medicamente necessários.

Sistemas de IA e revisores de repositório: comece com AI_CONTEXT.md. Evidências atuais legíveis por máquina, proveniência, suposições e exclusões são publicadas em EMILIA-REPO-CONTEXT-v1. Documentos arquivados ou em estágio não estabelecem status atual de implementação ou IETF. Evidências públicas de due diligence e limites de reivindicação: DUE_DILIGENCE.md.

Evidência de engenharia, não alegações de arquitetura

EMILIA entrega um caso de segurança que revisores podem executar. O repositório atual resolve 35 reivindicações de segurança sobre 259 arquivos de evidência com hash, verifica 20 lemas Tamarin em dois modelos Dolev-Yao compostos — 17 obrigações de todos os traços e 3 testemunhas de alcançabilidade de traço existente — e preserva 8 variantes deliberadamente enfraquecidas que produzem traços de ataque concretos quando verificações de sustentação são removidas. O corpus de conformidade ao vivo da mesma equipe contém 21 suítes e 331 vetores atuais. Separadamente, um verificador Rust escrito externamente é fixado ao pacote congelado 16-suítes/164-vetores e uma campanha de hostilidade de 359 casos. A suíte mais ampla contém 8.865 testes automatizados em 533 arquivos.

Superfícies de produção JavaScript e JSDoc são verificadas por compilador com TypeScript checkJs; o aplicativo seguro tem seu próprio projeto de compilador de compatibilidade, enquanto declarações e o SDK público TypeScript são verificados em modo estrito. Isso é cobertura completa de verificação de tipo de produção configurada, não uma alegação de que o repositório foi convertido em massa de JavaScript para TypeScript ou que todo projeto JavaScript tem a opção strict do TypeScript habilitada.

Cada reivindicação de segurança nomeia o caminho de aplicação, vetores positivos e negativos, cobertura de linguagem, escopo formal ou lacuna explícita, suposições, exclusões e hash de evidência. Comece com o mapa de evidências legível por humanos, depois inspecione o caso de segurança resolvido ou execute npm run check:security-case.

AEB-1: teste o limite evidência-para-efeito

O pacote aberto AEB-1 Consequence Admission Conformance testa o último ponto de controle antes de uma ação consequente: verificação nativa, aceitação da parte confiante, correspondência exata de CAID/ação, satisfação de evidência, autorização local, reserva atômica, custódia INVOKING, separação de resultado do provedor e efeito observado, comportamento sem nova tentativa cega, e reconciliação autenticada.

npx @emilia-protocol/verify aeb-conformance --reference

Ele é neutro em formato e autoexecutável. Um relatório aprovado é evidência de conformidade autodeclarada—não uma auditoria, certificação, alegação de implantação em produção, ou permissão para executar uma ação.

Para uma prova executável focada do caminho Gate do repositório, execute:

npm run proof:gate:reference

Este comando exercita exemplos locais e limites de serviço focados com chaves geradas, estado em memória e comportamento de provedor simulado. É prova local útil, não evidência de um humano real, banco externo, implantação em produção, ou uma integração de ponta a ponta em produção.

Identidade não é uma descrição de trabalho

Identidade diz quem ou o que está chamando. Política diz o que é geralmente permitido. Nenhuma define o trabalho finito que um trabalhador autônomo pode executar agora: sua missão, limites de ação material, orçamento, evidência exigida, expiração, regras de delegação e caminho de exceção.

EMILIA mantém essas questões separadas:

Camada	Pergunta
Identidade	Quem ou o que está presente?
Política	O que é geralmente permitido?
Autoridade	Que trabalho exato este agente pode executar sob este mandato?

Credenciais concedem alcance. Autoridade define o trabalho. Nem toda ação precisa de um humano; toda ação consequente precisa de autoridade válida.

Na fundação, o EP Core ainda expõe três objetos interoperáveis: um Trust Receipt carrega evidência atribuível, um Trust Profile representa estado de confiança estruturado, e um Trust Decision registra o resultado avaliado por política da parte confiante. As camadas do plano de controle de autoridade adicionam vinculação de ação exata, mandatos finitos, admissão, consumo e evidência de resultado sem colapsar esses objetos em uma única reivindicação.

---

Defina o mandato uma vez. Deixe o agente trabalhar.

O cliente define a missão, limites, requisitos de evidência, expiração e regras de exceção. Código local pode restringir essa autoridade; não pode inventá-la ou ampliá-la. Gate vincula cada solicitação executável ao mandato, reserva a autoridade coberta antes da entrada no provedor, permite uma tentativa admitida de provedor para essa instância de autorização dentro do domínio de autoridade durável compartilhado, e escala apenas quando a autoridade está ausente, desatualizada, esgotada ou estreita demais.

Os exemplos MCP incluídos demonstram um perfil de política em que uma decisão humana fresca é exigida na borda. Eles executam o loop local completo—evidência ausente recusada, ação exata assinada, uma tentativa de provedor admitida, evidência forjada rejeitada—sem afirmar que toda ação autônoma precisa de um clique humano:

node examples/mcp/payment-server.mjs    # release_payment  — refuses without a receipt
node examples/mcp/github-admin.mjs      # delete_repo      — refuses without a receipt
node examples/mcp/prod-deploy.mjs       # deploy_production — refuses without a receipt

A demonstração de composição mais profunda executa um pagamento delegado vinculado a CAID através do caminho real de capacidade limitada do Gate, depois verifica o certificado de execução assinado offline:

npm run demo:receipt-program

Ela deliberadamente não inclui blockchain ou reivindicação simulada de conhecimento zero. Veja a arquitetura do programa de recibo para os requisitos de estado e confiança de produção.

Comece com uma execução seca contra sua superfície de ferramentas declarada, depois gere os arquivos de integração revisáveis:

npx @emilia-protocol/scan protect ./tools.json
npx @emilia-protocol/scan protect ./tools.json --apply
node emilia/verify-setup.mjs

A verificação local gerada usa estado de demonstração explicitamente efêmero e prova apenas que seu manipulador sintético não foi chamado. Produção exige um ledger de proveniência durável, um armazenamento de consumo atômico compartilhado, chaves fixadas e o wrapper em todos os caminhos para a credencial real do provedor. Veja examples/mcp/ e /mcp.

Experimente em 30 segundos

# Issue a receipt offline — no API key, no backend needed
npx @emilia-protocol/issue demo

# Add EMILIA to Claude / Cursor / Cline
npx -y @emilia-protocol/mcp-server

Experimente uma aprovação real com Face ID → Aprove uma transferência de $82.000 com sua própria passkey. Veja como VERIFIED se parece. Forje o recibo. Veja falhar.

Verifique qualquer recibo no seu navegador — cole-o, nada é enviado.

---

Como funciona — um ciclo de vida de autoridade

Execute você mesmo: node examples/crash-test.mjs — totalmente offline, sem chave de API.

  [ MANDATE ]       [ EXACT WORK ]       [ VERIFY ]       [ RESERVE + ENTER ]  [ RECONCILE ]
  mission, limits   canonical action     pinned native    one admitted        preserve provider
  evidence, expiry  + occurrence         evidence         provider entry      and effect truth

Mandato. A fonte de autoridade define trabalho finito. Pode ser um programa operacional assinado pelo cliente, capacidade limitada, decisão humana exigida, quórum ou uma composição da parte confiante de evidência nativa.

Trabalho exato. Gate vincula método, origem, destinatário, alvo, ocorrência e todo campo material ao objeto executável canônico. Intenção, um prompt ou texto de ticket não é esse objeto.

Verifique, reserve e entre. Artefatos nativos permanecem nativos. A parte confiante fixa perfis de confiança e mapeamento, avalia o requisito completo de evidência, toma a decisão de autorização local separada, e reserva a autoridade coberta antes que o adaptador que possui credenciais entre no provedor.

Autoridade humana fresca quando exigida. Uma política pode exigir uma decisão WebAuthn/passkey vinculada à ação exata e ao hash de exibição determinístico. Isso reduz a lacuna "o que você viu é o que você assinou"; não prova compreensão, sabedoria, legalidade ou resultado.

Para implantações empresariais, Gate pode adicionalmente exigir uma confirmação de Authorization Server verificada independentemente, vinculada àquela evidência humana exata, à mesma ação exata, ao snapshot de identidade que o AS realmente observou, e à chave pretendida do Resource Server. O tempo do snapshot e a idade máxima da parte confiante são explícitos: um token fresco não pode tornar dados de diretório desatualizados atuais. A perna do AS é evidência sob confiança fixada pelo cliente; ela nunca autoriza por si só, prova posição de emprego instantânea, ou transforma o orquestrador de agente em uma autoridade. Resultado fiel. Admissão não é execução, e execução não é efeito. Um registro assinado pode ser verificado offline; evidências de provedor e observador permanecem separadas. Uma resposta perdida torna-se INDETERMINATE, que é um estado a reconciliar—não permissão para repetir. Uma correção é uma nova ação autorizada e nunca reescreve o resultado antigo.

---

Por que desenvolvedores usam

Comece mapeando o trabalho localmente e, em seguida, proteja uma superfície de ação declarada com o servidor MCP ou wrapper fino de SDK. O scanner propõe um mapa revisável; o proprietário define o mandato; o Gate detém a credencial do provedor e aplica a ação exata no caminho coberto. Nenhuma varredura prova mediação completa, e a descoberta por si só não concede autoridade.

# langchain-emilia — wrap any LangChain tool with an EP gate
from langchain_emilia import EmiliaGateClient

gate = EmiliaGateClient(base_url="https://www.emiliaprotocol.ai", api_key="...")
safe_tool = gate.wrap(your_destructive_tool)

pip install langchain-emilia   # PyPI
npm install @emilia-protocol/verify  # npm

O agente recebe a capacidade de executar trabalho limitado, não uma credencial permanente que possa reinterpretar.

---

Por que empresas precisam

Processos de agente reiniciam e modelos mudam. O mandato do cliente, o estado de consumo, a revogação, a incerteza e o histórico de trabalho devem sobreviver fora deles. A EMILIA mantém esse estado de autoridade durável na fronteira do cliente, aceitando prova externa por meio de adaptadores fixados.

O Gate gerenciado e o Plano de Garantia adicionam operações de mandato, integrações, operações de evidência, reexecução, suporte e níveis de serviço em torno do protocolo aberto. O cliente mantém o controle da autoridade, raízes de confiança, credenciais, políticas e evidências portáveis.

---

O padrão

O EMILIA Protocol é aberto e licenciado sob Apache-2.0. Seu trabalho de padronização é publicado como um portfólio de Internet-Drafts individuais. Um Internet-Draft publicado não é um RFC, um item adotado por grupo de trabalho ou endosso da IETF; o Datatracker é autoritativo para revisão e status.

Superfície de apresentação canônica em quatro documentos

Para navegação do leitor, o caminho canônico de evidência é:

1. Authorization Receipts-11 define o perfil de evidência de aprovação vinculada à ação. A revisão publicada atual é a -11, registrada como submissão individual candidata a Standards Track.
2. Human Authorization Binding-00 vincula um artefato de autorização humana nomeada a um registro hospedeiro adjacente.
3. Authority Introduction-03 estabelece raízes de confiança fixadas pela parte confiante e autoridade com escopo.
4. Authorization Evidence Chain-05 avalia se evidências verificadas nativamente e correspondentes à ação satisfazem o requisito da parte confiante; retorna SATISFIED ou UNSATISFIED, nunca AUTHORIZED.

Esta superfície de quatro documentos é apenas apresentação. Ela não mescla, aposenta, substitui, atualiza, torna obsoleto, subordina ou rebaixa qualquer draft no portfólio ativo.

Espinha de execução em tempo de execução separada

O caminho em tempo de execução é Architecture-02 → CAID-02 → AEC-05 → AEB-03: fronteiras do sistema, correspondência exata de ação material, satisfação de evidência e, em seguida, admissão no executor e custódia durável de consequência. AEC aparece em ambas as visões porque a satisfação de evidência alimenta a admissão em tempo de execução, não porque as visões são equivalentes.

O portfólio ativo completo permanece com 23 registros no Datatracker: 20 registros draft-schrock-* ativos e três registros em coautoria, cada um com seu próprio escopo e histórico de revisão. Consulte o guia de padrões, o portfólio e o inventário de status legível por máquina.

IETF Internet-Drafts	Snapshots locais atuais: inventário publicado · status ao vivo autoritativo: IETF Datatracker
Verificadores multilíngues	JavaScript · Python · Go — todos os três comprovadamente concordam em vetores de conformidade adversariais, a cada push (npm run conformance). Uma verificação de consistência entre os ports de uma mesma equipe, não implementações independentes em sala limpa. Separadamente, uma implementação Rust externa, escrita a partir da especificação (fonte pública), passa o pacote fixado de 16 suítes/164 vetores e a campanha de hostilidade fixada de 359 casos sob reconstrução controlada pelo avaliador a partir de uma árvore de fonte imutável. Sua evidência de construção registrada permanece assinada pelo implementador, não atestada por terceiros (declaração assinada); a aceitação estrita em sala limpa aguarda o manifesto atestado por terceiros corrigido e a chave do atestador fixada de forma independente.
Evidência de modelo formal	26 propriedades de segurança TLA+ limitadas mantidas em seus espaços de estado configurados; isso não é refinamento de implementação nem prova ilimitada · 35 fatos Alloy, 32 asserções em quatro modelos · dois modelos simbólicos compostos Dolev-Yao cobrindo desafio, CAID, duas aprovações, fixações de emissor e autoridade, visão de registro, revogação, consumo, execução e seis fronteiras de reivindicação dedicadas. Vinte lemas Tamarin verificam — 17 obrigações de todos os traços e 3 testemunhas de existência de traço; oito variantes deliberadamente enfraquecidas produzem traços de ataque concretos quando verificações estruturais são removidas (formal/tamarin/).
Registros MCP	Registro MCP oficial · Glama (Grau A, selo Oficial) · Smithery
Licença	Apache-2.0

Três ports de referência da mesma equipe (JS / Python / Go) concordam em todas as 21 suítes e 331 vetores. Separadamente, uma implementação Rust escrita externamente, reconstruída a partir de uma árvore de fonte pública fixada, passa o pacote de sala limpa fixado de 16 suítes/164 vetores e uma campanha de hostilidade de 359 casos, reexecutada em seu próprio pipeline de CI a cada alteração. As suítes mais recentes de aceitação AEC e resolução de quatro resultados não são atribuídas ao Rust. Isso é evidência de interoperabilidade externa, não aceitação estrita de construção em sala limpa; o registro agregado de CI registra a contagem de aceitação estrita como zero, pendente de atestação independente. Consulte CONFORMANCE.md ou verifique um recibo você mesmo em emiliaprotocol.ai/verify.

---

A pilha de autoridade

Camada	O que faz
Mandato	Define missão, limites, evidência, expiração, delegação e regras de exceção.
CAID / ação exata	Congela o objeto executável material para que a evidência não possa migrar para trabalho diferente.
AEC	Avalia se evidências verificadas independentemente e correspondentes satisfazem o requisito da parte confiante; não autoriza.
AEB / Gate	Toma a decisão de autorização local, reserva a autoridade coberta e controla a entrada do provedor.
Evidência de resultado	Mantém invocação, resposta do provedor, efeito observado e incerteza distintos.

---

Pontos de comprovação

Métrica	Valor
Casos de teste automatizados	8.865 em 533 arquivos; todos os casos aplicáveis à plataforma devem passar
Propriedades de segurança TLA+	26 invariantes limitados mantidos no espaço de estado configurado; não é refinamento de implementação nem prova ilimitada — consulte PROOF_STATUS.md
Asserções relacionais Alloy	35 fatos + 32 asserções em quatro modelos — verificados no CI
Casos de equipe vermelha catalogados	85 — RED_TEAM_CASES.md
Status de segurança do release	Verificações de segurança do repositório passam; cada achado do Strix nas alterações auditadas é corrigido com cobertura de regressão e seu thread de revisão resolvido
Conformidade (7/7)	node conformance/ep-conformance-test.js https://www.emiliaprotocol.ai
Conformidade entre linguagens	331 vetores · 21 suítes: recibos · assinaturas de dispositivo · resolução de quatro resultados · quórum multipartidário · revogação · Outcome Binding (semântico + criptografia real) · junção de emissor Authority Document/Proof · atestação de tempo · trust-receipt (2 perfis) · proveniência · registro de evidência · canonicalização · fronteira · aceitação AEC · moeda · atestação de iniciador · prova de consumo · testemunha · prova de timestamp (RFC 3161). Verificadores JS / Python / Go concordam (node conformance/run.mjs). A linha de base externa Rust permanece em 164 vetores / 16 suítes. Consulte CONFORMANCE.md.
p95 de criação de handshake	575ms a 50 VUs — PERFORMANCE_PROOF.md

---

Objetos centrais do protocolo

Objeto	O que é
Programa de autoridade / capacidade limitada	Um mandato finito com escopo explícito, orçamento ou unidades, expiração, delegação e regras de consumo.
CAID	Um identificador canônico para uma ação material sob um perfil de mapeamento nomeado; correspondência não é autorização.
Requisito de evidência e resultado AEC	A regra fixada da parte confiante e sua avaliação SATISFIED, UNSATISFIED ou INDETERMINATE.
Registro de admissão e custódia AEB	O registro no executor de autorização, reserva, entrada do provedor e estado de reconciliação.
Evidência de autorização e resultado	Artefatos EP ou nativos portáveis que retêm seu emissor, escopo e fronteira de reivindicação exatos.

---

Início rápido

1. Execute npx @emilia-protocol/scan protect ./tools.json para mapear superfícies declaradas suportadas.
2. Revise o manifesto de ações gerado, campos materiais, credenciais e pontos cegos nomeados.
3. Instale o Gate no caminho que detém a credencial do provedor e o estado de consumo durável.
4. Defina o mandato operacional e quaisquer regras de exceção de humano fresco ou quórum.
5. Execute os casos de recusa, ação exata, repetição, tempo limite e reconciliação antes de habilitar a aplicação.

Demonstração de 90 segundos · Início rápido · Passo a passo do agente · IETF Draft · Discord

---

O que EP é — e não é

A EMILIA é infraestrutura de autoridade para trabalho autônomo, não um sistema de identidade, carteira, pontuação de reputação, trilho de liquidação ou mecanismo universal de políticas.

• É: um plano de controle para mandatos operacionais finitos, verificação de ação exata, estado de admissão durável, incerteza fiel e evidência portável em caminhos de executor cobertos.
• Não é: um substituto para OAuth/OIDC, identidade de carga de trabalho ou mecanismos de políticas. Esses permanecem entradas nativas sob as fixações da parte confiante.
• Não é: um requisito de que um humano aprove cada ação. Um mandato pode permitir trabalho automático dentro de limites finitos e exigir autoridade fresca apenas na borda.
• Não é: prova de que uma ação admitida foi executada com sucesso ou causou o efeito pretendido.
• Não é: controle de protocolo proprietário. O núcleo é Apache-2.0 e os Internet-Drafts são submissões individuais, não RFCs ou endosso da IETF.

Consulte CONFORMANCE.md · SECURITY.md · THREAT_MODEL.md · GOVERNANCE.md · Neutrality Covenant