EMILIA Protocol

oficial

Exija a aprovação verificável offline de um humano nomeado antes que um agente de IA tome uma ação irreversível — liberação de pagamento, alteração de registro, implantação. Regra de duas pessoas, Trust Receipts Ed25519, elaborado pelo IETF, Apache-2.0.

GitHub

550

O que você pode fazer com EMILIA Protocol MCP?

Proteja uma ferramenta de alto impacto — Peça ao seu assistente para configurar o EMILIA Gate para que uma ação declarada como sendWire recuse chamadas sem uma aprovação válida.
Vincule a aprovação aos detalhes exatos — Exija que uma aprovação abranja o valor, a moeda, o fornecedor e o destino, e recuse alterações nos dados do pagamento.
Bloqueie repetição e evidências falsificadas — Peça ao assistente para aceitar uma chamada correspondente uma única vez e rejeitar repetições ou comprovantes falsificados.
Verifique comprovantes offline — Peça ao assistente para verificar um comprovante assinado com base em chaves fixadas e regras, sem entrar em contato com um backend.
Congele novas ações — Solicite um congelamento emergencial de autoridade que bloqueie novas reservas e mantenha resultados incertos para reconciliação.

Documentação

EMILIA Protocol

Deixe seu agente preparar o pagamento. Controle o que ele pode liberar.

Um agente prepara um pagamento de US$ 82.000 a um fornecedor. Alguém o aprova. Então, o valor ou o destino bancário muda. A aprovação anterior não deve liberar o pagamento alterado.

O EMILIA Gate verifica a autoridade antes da execução de uma ferramenta protegida. O protocolo aberto permite que as evidências resultantes sejam verificadas de forma independente, segundo as próprias chaves confiáveis e regras do verificador. Mantenha seu provedor de identidade, framework de agentes e sistemas de negócios atuais.

Execute o exemplo de pagamento

Com Node.js 20.19 ou mais recente e npm instalados:

git clone https://github.com/emiliaprotocol/emilia-protocol.git
cd emilia-protocol
npm ci
FAST=1 node examples/mcp/payment-server.mjs

O exemplo recusa uma chamada sem aprovação, vincula a aprovação ao valor, à moeda, ao fornecedor e ao destino, admite a chamada correspondente uma vez e recusa detalhes de pagamento alterados, repetição e evidências forjadas. Consulte o exemplo e suas limitações.

Esta é uma demonstração local: chaves de assinatura geradas, consumo em memória e uma ferramenta de pagamento simulada. Ela não realiza uma cerimônia humana real nem movimenta dinheiro. A produção exige credenciais cadastradas, estado compartilhado durável e o Gate em todos os caminhos até a credencial do provedor protegido. Uma aprovação válida não comprova que os dados bancários são legítimos.

Prefere um navegador? Experimente uma passkey em um pagamento de exemplo. Essa demonstração separada mostra a integridade do recibo com o autenticador da sua plataforma; nenhum pagamento é enviado.

Proteja uma ferramenta que você já usa

Comece pelo serviço que detém a credencial real do provedor, não apenas pelo processo do agente. O responsável define o trabalho permitido e quando é necessária uma nova aprovação. Um agente pode trabalhar dentro desses limites sem que uma pessoa aprove cada chamada.

MCP ou HTTP: Gate Starter apresenta uma ação protegida.
Hugging Face smolagents: envolva uma ferramenta existente.
GitHub: Merge Gate vincula uma verificação à mesclagem proposta. A verificação deve ser obrigatória e os caminhos alternativos de mesclagem devem ser fechados.

O protocolo comprova. O Gate impede nos caminhos completamente mediados pela implantação. O Gate não pode restringir um caminho de desvio. Se o resultado do provedor for desconhecido, o ciclo de vida de produção preserva essa incerteza para reconciliação, em vez de tentar novamente às cegas.

Sistemas de IA e revisores de repositório: comecem por AI_CONTEXT.md. As evidências legíveis por máquina atuais, a proveniência, as premissas e as exclusões são publicadas em EMILIA-REPO-CONTEXT-v1. Documentos arquivados ou em preparação não comprovam a implementação atual nem o status perante a IETF. Evidências públicas de due diligence e limites das alegações: DUE_DILIGENCE.md.

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

O EMILIA fornece um caso de segurança que os revisores podem executar. O repositório atual resolve 35 alegações de segurança em 264 arquivos de evidência com hash, verifica 20 lemas Tamarin em dois modelos Dolev-Yao compostos — 17 obrigações para todos os rastros e 3 testemunhos de alcançabilidade por rastros existentes — e preserva 8 variantes deliberadamente enfraquecidas que produzem rastros de ataque concretos quando verificações essenciais são removidas. O corpus de conformidade ativo da mesma equipe contém 21 suítes e 340 vetores atuais. Separadamente, um verificador Rust desenvolvido externamente está fixado ao pacote congelado de 16 suítes/164 vetores e a uma campanha de hostilidade com 359 casos. A suíte mais ampla contém mais de 10.700 testes automatizados em mais de 650 arquivos.

As superfícies de JavaScript de produção e JSDoc são verificadas pelo compilador TypeScript checkJs; o aplicativo seguro tem seu próprio projeto de compilador de compatibilidade, enquanto as declarações e o SDK público de TypeScript são verificados em modo estrito. Isso representa uma cobertura completa de verificação de tipos da produção configurada, não uma alegação de que o repositório foi convertido integralmente de JavaScript para TypeScript ou de que todos os projetos JavaScript têm a opção strict do TypeScript habilitada.

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

AEB-1: teste o limite entre evidência e efeito

O pacote aberto AEB-1 Consequence Admission Conformance testa o caminho CAID/AEC composto no último ponto de controle antes de uma ação consequencial: verificação nativa, aceitação pela parte confiadora, vinculação à ação exata, correspondência CAID obrigatória, satisfação das evidências AEC obrigatórias, autorização local, reserva atômica, custódia INVOKING, veracidade separada do resultado do provedor e do efeito observado, comportamento sem novas tentativas às cegas e reconciliação autenticada.

Leia sobre o limite de admissão de consequências para conhecer a divisão exata de responsabilidades entre o caminho CAID/AEC composto, o caminho nativo direto, a custódia AEB e as evidências do resultado do provedor.

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

Ele é independente de formato e pode ser executado por conta própria. Um relatório aprovado é uma 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.

De acordo com o AEB-07, publicado em 2026-09-25 como um Internet-Draft individual e não adotado por nenhum grupo de trabalho, o CAID é usado somente quando ações codificadas de forma independente precisam ser associadas, e o AEC é usado somente quando a política local exige várias etapas de evidência. Um corpus sintético separado, com 26 casos, modela esse ciclo de vida nativo direto sobre resultados de adaptadores AuthZEN/COAZ-MCP, AP2, OAuth Transaction Token e mandato local assinado:

npm run conformance:composition:consequence-admission

O executor do corpus é um modelo de ciclo de vida independente, com seu próprio armazenamento em memória e lógica de admissão. Ele não executa o código @emilia-protocol/verify ou @emilia-protocol/gate fornecido, portanto não constitui evidência para esses pacotes, que têm suas próprias suítes de testes. Também não comprova que os protocolos nativos mencionados estão em conformidade com o AEB-07.

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

npm run proof:gate:reference

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

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

A identidade informa quem ou o que está chamando. A política informa o que geralmente é permitido. Nenhuma das duas define o trabalho finito que um agente autônomo pode realizar agora: sua missão, limites para ações relevantes, orçamento, evidências exigidas, validade, regras de delegação e caminho de exceção.

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 realizar sob este mandato?

As credenciais concedem alcance. A autoridade define o trabalho. Nem toda ação exige uma pessoa; toda ação consequencial exige autoridade válida.

Na base, o EP Core continua expondo três objetos interoperáveis: um Trust Receipt contém evidências atribuíveis, um Trust Profile representa um estado de confiança estruturado e uma Trust Decision registra o resultado avaliado segundo a política da parte confiadora. As camadas do plano de controle de autoridade acrescentam vinculação à ação exata, mandatos finitos, admissão, consumo e evidências de resultado, sem fundir esses objetos em uma única alegação.

Defina o mandato uma vez. Deixe o agente trabalhar.

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

Os exemplos MCP incluídos exercitam um perfil de política que exige aprovação no limite. Eles geram chaves de assinatura de demonstração e invocam ferramentas simuladas. O exemplo de pagamento vincula todos os quatro campos relevantes declarados; os outros exemplos demonstram vinculações de recursos mais restritas. Eles não registram uma decisão humana real nem contatam um provedor:

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 aprofundada executa um pagamento delegado vinculado a CAID pelo caminho real de capacidade limitada do Gate e, em seguida, verifica o certificado de execução assinado offline:

npm run demo:receipt-program

Ela deliberadamente não inclui blockchain nem alegações simuladas de conhecimento zero. Consulte a arquitetura do programa de recibos para conhecer os requisitos de estado e confiança em produção.

Comece com uma ação MCP consequencial declarada. Instale o ambiente de execução local exato e, em seguida, crie seu Gate Starter e execute a verificação limitada de quatro casos:

npm install --save-exact @emilia-protocol/mcp-guard@0.7.0
npx @emilia-protocol/scan@0.6.0 protect ./tools.json --action sendWire --apply --verify

# after reading emilia/authority-map.html and action-control.manifest.json
npx @emilia-protocol/scan@0.6.0 protect ./tools.json --action sendWire --reviewed \
  --crossing-profile ccs-wang-draft08-v13

A verificação local gerada usa estado de demonstração explicitamente efêmero e comprova apenas os casos sintéticos declarados: ausência, correspondência exata, alteração, repetição e ferramenta não verificada. O comando revisado cria uma transferência com privacidade limitada; ele não ativa o Gate. A produção exige um registro de proveniência durável, um armazenamento compartilhado de consumo atômico, chaves fixadas e o wrapper em todos os caminhos até a credencial real do provedor. Consulte examples/mcp/ e /mcp.

Interrompa novas ações sem fingir desfazer as antigas

O congelamento emergencial de autoridade do Gate bloqueia novas reservas e impede que reservas anteriores sejam executadas após a mudança da época do domínio de controle coberto. Se a entrada no provedor ocorreu primeiro, a tentativa permanece consumida e precisa de reconciliação. Restaurar a autoridade não reativa uma reserva antiga.

Isso exige mediação completa e estado compartilhado autoritativo. Não interrompe a computação, não reverte um efeito nem alcança instantaneamente domínios desconectados. Consulte a implementação e os limites do domínio de controle.

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 passkey da plataforma em um pagamento de exemplo → Assine um pagamento ilustrativo de US$ 82.000, altere o valor e veja a verificação de integridade falhar. Seu autenticador pode usar biometria ou o PIN do dispositivo. A página também oferece uma simulação de software separada. Nenhum dos modos envia um pagamento nem estabelece autorização de produção.

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

Como funciona — um ciclo de vida de autoridade

EMILIA crash test — an autonomous agent tries to wire $82,000; the selected policy profile requires fresh human authority, the exact action is signed, the receipt verifies offline, and a forged copy fails.

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 o trabalho finito. Pode ser um programa operacional assinado pelo cliente, uma capacidade limitada, uma decisão humana obrigatória, um quórum ou uma composição de evidências nativas pela parte confiadora.

Trabalho exato. O Gate vincula método, origem, destinatário, alvo, ocorrência e todos os campos relevantes ao objeto executável canônico. Intenção, um prompt ou o texto de um chamado não constituem esse objeto.

Verificar, reservar e executar. Os artefatos nativos permanecem nativos. A parte confiadora fixa os perfis de confiança e mapeamento, avalia o requisito completo de evidências, toma a decisão separada de autorização local e reserva a autoridade coberta antes que o adaptador que detém a credencial entre no provedor.

Autoridade humana atualizada 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 entre “o que você viu” e “o que você assinou”; não comprova compreensão, bom senso, legalidade ou resultado. Para implantações empresariais, o Gate também pode exigir uma confirmação do Authorization Server verificada de forma independente, 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 horário do snapshot e a idade máxima aceita pela parte confiadora são explícitos: um token recente não torna atuais dados de diretório desatualizados. A etapa do AS é evidência sob confiança fixada pelo cliente; ela nunca autoriza por si só, comprova a situação empregatícia instantânea nem transforma o orquestrador do agente em uma autoridade.

Resultado fidedigno. Admissão não é execução, e execução não é efeito. Um registro assinado pode ser verificado offline; as evidências do provedor e do observador permanecem separadas. Uma resposta perdida se torna INDETERMINATE, que é um estado a reconciliar — não uma permissão para tentar novamente. Uma medida corretiva é uma nova ação autorizada e nunca reescreve o resultado anterior.

Por que desenvolvedores usam isso

Comece mapeando o trabalho localmente e, em seguida, proteja uma superfície de ação declarada com o servidor MCP ou um wrapper fino de SDK. O scanner propõe um mapa que pode ser revisado; o responsável define o mandato; o Gate controla a credencial do provedor e impõe a ação exata no caminho coberto. Nenhuma varredura comprova 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 realizar trabalho delimitado, não uma credencial permanente que possa reinterpretar.

Por que empresas precisam disso

Os processos dos agentes reiniciam e os modelos mudam. O mandato do cliente, o estado de consumo, a revogação, a incerteza e o histórico de trabalho precisam persistir fora deles. O EMILIA mantém esse estado durável de autoridade no limite do cliente, aceitando provas externas por meio de adaptadores fixados.

O Gate gerenciado e o Assurance Plane acrescentam 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, das raízes de confiança, das credenciais, da política e das evidências portáteis.

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 um grupo de trabalho nem um endosso do IETF; o Datatracker é a fonte oficial para revisão e status.

Registros da IANA

Dois nomes registrados oferecem aos implementadores uma referência comum para os formatos EMILIA:

application/vnd.emilia.authorization-evidence-challenge+json foi registrado em 6 de outubro de 2026. Ele identifica o objeto JSON simples AE-CHALLENGE-v1 definido pela especificação de serialização publicada. As respostas HTTP de recusa continuam usando application/problem+json.
canactid: foi registrado provisoriamente em 5 de outubro de 2026. Ele nomeia ações tipadas exatas sob o CAID-05. Seu número de esquema CRI corrigido é 1033.

Esses registros publicam os nomes e suas especificações. Eles não estabelecem adoção pelo IETF, endosso, certificação ou implantação por clientes.

Uma superfície de limite de consequência

A versão atual publicada do AEB-07, publicada em 25/09/2026 como um Internet-Draft individual e não adotada, define o AEB como ponto de composição após uma decisão nativa. OAuth, AuthZEN, COAZ, AP2 e sistemas locais mantêm a propriedade de suas credenciais, mapeamentos de operações e decisões de autorização. O AIMS (draft-ietf-wimse-aims) é um documento Informational do grupo de trabalho WIMSE que descreve padrões existentes, como WIMSE e OAuth; ele próprio não emite credenciais nem decisões. O AEB aplica a decisão nativa no limite protegido do provedor: vincula a ação final quando necessário, deriva uma identidade nativa de repetição por concessão, reserva antes da entrada no provedor, recusa uma segunda tentativa da mesma ação enquanto uma tentativa anterior estiver em andamento ou incerta e mantém um resultado incerto bloqueado até a reconciliação autenticada.

O CAID-05 é usado quando representações codificadas de forma independente precisam ser comparadas. Novos identificadores usam o esquema URI canactid: registrado provisoriamente pela IANA. O registro não representa adoção pelo IETF, endosso, certificação ou status permanente. O CAID não é um segundo mapeamento obrigatório quando o PEP responsável pela consequência já deriva e impõe uma decisão atual sobre a operação final. Experimente o playground de ação exata ou leia o guia de migração do CAID-04 para o CAID-05. O AEC-06 é usado quando a parte confiadora exige várias etapas de evidência. Recibos de Autorização, Vinculação de Autorização Humana e Introdução de Autoridade continuam disponíveis como perfis para implantações que precisam deles; não são pré-requisitos para toda integração AEB. O Architecture-03 continua sendo o documento de navegação.

O guia de admissão de consequências descreve o limite de implementação e os casos em que o AEB é desnecessário. O perfil de transferência nativa direta é um perfil de implementação do repositório que mostra como uma permissão existente chega ao Gate sem uma segunda camada CAID ou AEC. O AEB-07 especifica o que essa transferência pelo gateway atesta e como o limite a verifica, mas deixa a codificação a cargo das configurações fixadas na implantação; ele cita um snapshot fixado deste perfil como uma codificação de referência informativa. Os bytes exatos enviados para o -07 e seu registro de publicação estão preservados em standards/staged/NEXT-AEB-07.

O portfólio ativo completo contém 26 registros no Datatracker: 21 registros de autoria individual e cinco coautoriais, cada um com seu próprio escopo, histórico de revisões e status de manutenção registrado. Consulte o guia de padrões, o portfólio e o inventário de status legível por máquina.


Internet-Drafts do IETF	Caminhos do snapshot local atual: inventário de status · inventário publicado de autoria individual · status oficial em tempo real: IETF Datatracker
Verificadores em várias linguagens	JavaScript · Python · Go — os três comprovadamente concordam nos vetores de conformidade adversariais, a cada push (`npm run conformance`). Uma verificação de consistência entre as portas de uma equipe, não implementações independentes desenvolvidas do zero. Separadamente, uma implementação Rust de autoria externa, criada a partir da especificação (código-fonte público), passa pelo pacote fixado de 16 suítes/164 vetores e pela campanha de hostilidade fixada de 359 casos, em uma reconstrução controlada pelo avaliador a partir de uma árvore de código-fonte imutável. As evidências de construção incluídas no repositório continuam assinadas pelo implementador, não atestadas por terceiros (declaração assinada); a aceitação estrita de desenvolvimento independente aguarda o manifesto corrigido, atestado por terceiros, e uma chave de atestador fixada de forma independente.
Evidências de modelos formais	26 propriedades de segurança limitadas do TLA+ foram mantidas nos espaços de estado configurados; isso não é refinamento da implementação nem prova ilimitada · 35 fatos Alloy, 32 asserções em quatro modelos · dois modelos simbólicos Dolev-Yao compostos que abrangem desafio, CAID, duas aprovações, pins de emissor e autoridade, visão do registro, revogação, consumo, execução e seis limites de alegações dedicados. Vinte lemas Tamarin são verificados — 17 obrigações para todos os rastros e 3 testemunhos de rastros existentes; oito variantes deliberadamente enfraquecidas produzem rastros de ataque concretos quando verificações essenciais são removidas (formal/tamarin/).
Distribuição MCP	Pacote npm `@emilia-protocol/mcp-server` · a publicação oficial no Registry é acompanhada separadamente em MCP-REGISTRY.md; não se infere a presença em agregadores a partir de nenhum desses estados
Licença	Apache-2.0

Três portas de referência da mesma equipe (JS / Python / Go) concordam em todas as 21 suítes e 340 vetores. Separadamente, uma implementação Rust de autoria externa, reconstruída a partir de uma árvore pública de código-fonte fixada, passa pelo pacote fixado de desenvolvimento independente de 16 suítes/164 vetores e por uma campanha de hostilidade de 359 casos, executada novamente em sua própria faixa de CI a cada alteração. As novas suítes de aceitação AEC e de 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 independente; o registro agregado de CI informa zero casos de aceitação estrita enquanto aguarda atestação independente. Consulte CONFORMANCE.md ou verifique você mesmo um recibo em emiliaprotocol.ai/verify.

A pilha de autoridade

Camada	O que faz
Mandato	Define missão, limites, evidências, expiração, delegação e regras de exceção.
CAID / ação exata	Compara o significado material quando a autorização e a execução usam representações codificadas de forma independente; não autoriza.
AEC	Quando exigido, avalia se evidências verificadas e correspondidas de forma independente satisfazem o requisito de várias etapas da parte confiadora; não autoriza.
AEB / Gate	Aplica a decisão de autorização nativa ou local no limite de consequência, reserva a autoridade coberta e controla a entrada no provedor.
Evidências de resultado	Mantém distintas a invocação, a resposta do provedor, o efeito observado e a incerteza.

Evidências concretas

Métrica	Valor
Casos de teste automatizados	Mais de 10.700 em mais de 650 arquivos; todos os casos aplicáveis à plataforma devem passar
Propriedades de segurança TLA+	26 invariantes limitadas mantidas no espaço de estados configurado; não constituem prova de refinamento da implementação nem prova ilimitada — consulte PROOF_STATUS.md
Asserções relacionais Alloy	35 fatos + 32 asserções em quatro modelos — verificadas em CI
Casos de red team catalogados	86 — RED_TEAM_CASES.md
Status de segurança da versão	As verificações de segurança do repositório passam; todas as descobertas do Strix nas alterações auditadas foram corrigidas com cobertura de regressão e seus tópicos de revisão foram resolvidos
Conformidade (7/7)	`node conformance/ep-conformance-test.js https://www.emiliaprotocol.ai`
Conformidade entre linguagens	340 vetores · 21 suítes: recibos · confirmações de dispositivo · resolução de quatro resultados · quórum multipartidário · revogação · Vinculação de Resultado (semântica + criptografia real) · junção de emissor de Documento/Prova de Autoridade · atestação de tempo · recibo de confiança (2 perfis) · proveniência · registro de evidências · canonicalização · limite · aceitação AEC · moeda · atestação do iniciador · prova de consumo · testemunha · prova de timestamp (RFC 3161). Os verificadores JS / Python / Go concordam (`node conformance/run.mjs`). A linha de base externa do Rust continua em 164 vetores / 16 suítes. Consulte CONFORMANCE.md.
p95 de criação de handshake	575 ms com 50 VUs — PERFORMANCE_PROOF.md

Longevidade criptográfica (com limites explícitos de implantação)

As evidências que precisam ser verificadas anos depois devem sobreviver aos algoritmos com os quais foram assinadas. O EP oferece quatro capacidades delimitadas para isso, cada uma com um limite exato que faz parte da alegação:

Assinaturas híbridas (EP-RECEIPT-HYBRID-v1). Ed25519 e ML-DSA-65 sobre os mesmos bytes canônicos, com o conjunto de algoritmos obrigatório comprometido nos bytes assinados, de modo que remover uma das partes invalida a assinatura restante. O recurso é opcional na implantação; depois que um assinante duplo aprovado é registrado e a política permite sua parte PQ, uma postura do Gate sem fixação resolve para emissão dupla por padrão. Caso contrário, permanece somente clássica, com um motivo identificado. Os verificadores v1 recusam recibos híbridos de forma clara, em vez de aceitar apenas uma parte. O contrato do assinante externo e o adaptador do AWS KMS estão implementados, mas não se afirma que tenha ocorrido uma chamada de assinatura real da AWS, nem que haja uma chave de produção, verificação por parte confiável ou validação FIPS de ML-DSA. Consulte conformance/hybrid-receipts/ e lib/pq-custody-aws-kms.ts.
Perfil de Signed Statement do SCITT (EP-SCITT-STATEMENT-v1). Uma estrutura completa de Signed Statement conforme a RFC 9943 para recibos EP, incluindo o cabeçalho protegido de CWT Claims. Limite: nenhum Transparency Service aceitou uma declaração EP; o registro externo é uma etapa separada e sujeita a controle, e não foi realizado. Consulte EP-RECEIPT-SCITT-PROFILE.md.
Reatestação (EP-EVIDENCE-REATTESTATION-v1). Evidências assinadas com um algoritmo em processo de envelhecimento podem ser reancoradas com um algoritmo atual antes que o antigo se enfraqueça. Limite: a reatestação deve ocorrer antes do comprometimento; ela não pode reparar evidências retroativamente.
Modo de implantação FIPS (EP-FIPS-MODE-v1). Executa operações clássicas por meio de um provedor validado segundo FIPS 140-3 fornecido pelo operador, com o caminho ML-DSA condicionado a uma confirmação explícita de implementação não validada. Limite: isso permite afirmar "algoritmos baseados em FIPS, com um modo de implantação de provedor validado" e depende do provedor do operador e dos limites de certificação declarados; não é uma declaração geral de conformidade, e nada aqui foi validado segundo FIPS. Consulte FIPS-MODE.md.

O programa híbrido para toda a pilha (todas as superfícies de assinatura internas) está mapeado em pq-hybrid-program.md e não está concluído; até que esteja, não se faz nenhuma declaração geral sobre a pilha inteira.

Objetos centrais do protocolo

Objeto	O que é
Programa de autoridade / capacidade delimitada	Um mandato finito com escopo, orçamento ou unidades, validade, delegação e regras de consumo explícitos.
CAID	Um identificador canônico para uma ação material segundo um perfil de mapeamento nomeado; correspondência não é autorização.
Requisito de evidência e resultado AEC	A regra fixada pela parte confiável e sua avaliação `SATISFIED`, `UNSATISFIED` ou `INDETERMINATE`.
Admissão AEB e registro de custódia	O registro do lado do executor sobre autorização, reserva, entrada no provedor e estado de reconciliação.
Evidências de autorização e resultado	Artefatos nativos ou EP portáteis que preservam exatamente seu emissor, escopo e limite das declarações.

Início rápido

Instale o runtime de proteção local exato e, em seguida, execute npx @emilia-protocol/scan@0.6.0 protect ./tools.json --action sendWire --apply --verify, substituindo sendWire por uma ferramenta consequencial declarada com exatidão.
Revise o Mapa de Autoridade gerado, o manifesto de ações, os campos materiais, o limite selecionado e os pontos cegos identificados.
Execute o comando separado --reviewed --crossing-profile <launch-profile> para criar, a partir desses mesmos bytes inalterados, a transferência de propriedade exclusiva e o espaço de trabalho Lab sem lacre.
Instale o Gate no caminho que controla a credencial do provedor e o estado durável de consumo.
Defina o mandato operacional e quaisquer regras de exceção para aprovação humana recente ou quórum.
Execute os casos de recusa, ação exata, repetição, tempo limite e reconciliação antes de habilitar a aplicação das regras.

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

O que é — e o que não é — o EP

EMILIA é uma 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ções exatas, estado durável de admissão, incerteza expressa com veracidade e evidências portáteis nos caminhos de execução cobertos.
Não é: um substituto para OAuth/OIDC, identidade de cargas de trabalho ou mecanismos de políticas. Esses continuam sendo entradas nativas conforme as fixações da parte confiável.
Não é: uma exigência de que uma pessoa aprove cada ação. Um mandato pode permitir trabalho automático dentro de limites finitos e exigir nova autorização somente no limite.
Não é: prova de que uma ação admitida foi executada com sucesso ou causou o efeito pretendido.
Não é: controle proprietário do protocolo. O núcleo é Apache-2.0 e os Internet-Drafts são submissões individuais, não RFCs nem endossos do IETF.

Consulte CONFORMANCE.md · SECURITY.md · THREAT_MODEL.md · GOVERNANCE.md · Pacto de Neutralidade