EMILIA Protocol MCP Server
oficialExija 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.
Documentação
Protocolo EMILIA
O motor sem freios
Por cinquenta anos, a segurança de software respondeu a uma pergunta: quem tem permissão para entrar? Firewalls, OAuth e senhas — todos construídos para verificar uma identidade humana na porta.
Essa era está acabando. Os usuários dominantes de software não são mais humanos; são agentes de IA autônomos. Agentes não apenas fazem login — eles escrevem código, chamam ferramentas e alteram a realidade em tempo real. Todo CISO sabe que um único prompt malicioso pode fazer um agente limpar um banco de dados de produção ou transferir dinheiro para a conta errada. Então eles estão bloqueando a implantação — retendo bilhões em orçamento de IA que não podem gastar porque suas equipes de conformidade não conseguem responder a uma pergunta:
Quem aprovou essa ação?
A crise da nossa geração não é autenticação. É autorização no momento da ação: como provar que o que um agente está prestes a fazer é exatamente o que um humano nomeado autorizou — antes da execução?
EMILIA é o cinto de segurança para a era agêntica.
Logs de decisão são testemunho. EMILIA produz recibos.
Sem recibo, sem ação irreversível
Se um agente tentar movimentar dinheiro, excluir código, implantar em produção, alterar permissões ou modificar estado regulado sem um recibo EMILIA válido, a ferramenta se recusa a executar — e se executar, qualquer um pode verificar quem autorizou exatamente o quê, offline, sem confiar em ninguém.
Esse é o protocolo completo. A cunha do desenvolvedor é um invólucro em torno de uma ferramenta MCP irreversível. Veja a frio, totalmente offline, sem chave, sem conta — cada demonstração executa o ciclo completo (recusado → humano nomeado assina a ação exata → ferramenta executa → recibo forjado rejeitado):
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
Encapsule seu próprio despachante de ferramentas em produção — veja examples/mcp/ e /mcp:
import { withMcpGuard } from '@emilia-protocol/mcp-guard';
const guarded = withMcpGuard(handleTool, {
annotations: { release_payment: { irreversible: true, action: 'payment.release' } },
}); // missing receipt → refused, never a silent pass
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 chave de acesso. Veja como é VERIFICADO. Forje o recibo. Veja falhar.
Verifique qualquer recibo no seu navegador — cole-o, nada é enviado.
Como funciona — quatro atos
Execute você mesmo:
node examples/crash-test.mjs— totalmente offline, sem chave de API.
[ INTENT ] [ DECISION ] [ CEREMONY ] [ RECEIPT ]
Agent calls a Policy-bound, hash- Named human signs Signed, offline-
tool via MCP → pinned: allow / → the EXACT action → verifiable proof.
allow-with-signoff / on their own Tamper it:
deny (+observe device (passkey). fails by design.
mode: zero change What they saw =
to production) what they signed.
Ato I — Interceptação (nativo MCP). Sem reescritas. EMILIA intercepta a chamada da ferramenta no limite do Model Context Protocol — no momento em que um agente tenta excluir um arquivo ou movimentar capital, a ação é capturada no ar.
Ato II — Decisão (vinculada à política, determinística). A ação é verificada contra uma política fixada por hash: allow, allow-with-signoff ou deny. Mais um modo de observação que não altera nada em produção e relata o que teria sido retido. Determinístico, auditável — não uma pontuação de risco de caixa-preta.
Ato III — A cerimônia (aprovação humana vinculada ao dispositivo). Quando a política exige um humano, EMILIA executa uma aprovação WebAuthn / chave de acesso vinculada à ação exata — Face ID / Touch ID no próprio dispositivo do operador. O que o humano viu é o que ele assinou. Nenhum script pode forjar; nenhum ciclo autônomo pode pular.
Ato IV — O recibo (a evidência). O resultado é um recibo de autorização assinado que qualquer um pode verificar offline, com código aberto, sem backend, sem confiança no fornecedor. Adultere-o e a verificação falha por construção. Opcionalmente, ancore-o para carimbo de tempo público — o núcleo não precisa de blockchain.
Por que os desenvolvedores usam
Você quer agentes que realmente façam coisas — mas está paralisado por loops descontrolados, gastos excessivos de API e destruição acidental de dados. EMILIA oferece um servidor MCP plug-and-play + um fino invólucro SDK. Aplique um hash de política e chamadas de ferramentas irreversíveis ganham uma camada de aprovação e evidência criptograficamente reforçada, mapeada para NIST-AI-RMF — sem construir fluxos de aprovação ou infraestrutura de auditoria do zero.
# 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
Seu agente não pode ultrapassar sua coleira.
Por que as empresas precisam
Cada mudança de plataforma cria uma nova primitiva de segurança: a web teve SSL, a nuvem teve Okta / IAM, a economia de agentes precisa de confiança no nível da ação. Empresas estão retendo orçamentos de IA que a conformidade não as deixa gastar — EMILIA é a chave que os desbloqueia, transformando agentes imprevisíveis em infraestrutura pronta para auditoria que mapeia primitiva por primitiva para controles NIST AI RMF, EU AI Act e SOC 2 CC6/7.
A camada gerenciada (GovGuard / FinGuard) estende o padrão aberto com pacotes de políticas setoriais, pilotos em modo de observação e pacotes de evidência prontos para auditoria — sem necessidade de aquisição para começar.
O padrão
EMILIA é um padrão aberto, não um fosso de produto. O núcleo é Apache-2.0 e rastreado como um Internet-Draft da IETF.
| Internet-Drafts da IETF | Publicados: authorization-receipts · quorum. Estagiados em standards/: authorization-evidence-chain (EP-AEC, composição) · evidence-record (EP-EVIDENCE-RECORD, retenção de longo prazo). Mapa de campo: pesquisa de panorama. |
| Verificadores multilinguagem | JavaScript · Python · Go — todos os três comprovadamente concordam em vetores de conformidade adversariais, a cada push (npm run conformance). Esse é o padrão IETF para um padrão real: múltiplas implementações interoperáveis independentes. |
| Verificação formal | 26 propriedades de segurança TLA+ (0 erros) · 35 fatos Alloy, 22 asserções — ambos executados em CI |
| Registros MCP | Registro MCP oficial · Glama (Grau A, selo Oficial) · Smithery |
| Licença | Apache-2.0 |
Três implementações independentes comprovadamente concordam — veja CONFORMANCE.md, ou verifique um recibo você mesmo em emiliaprotocol.ai/verify.
A pilha EP
Eye observes. Handshake verifies. Signoff owns. Commit seals.
| Camada | O que faz |
|---|---|
| EP Eye | Observa e classifica o comportamento do agente (OBSERVE → SHADOW → ENFORCE) |
| EP Handshake | Cerimônia de consentimento criptográfico com vinculação de 7 propriedades |
| EP Signoff | Propriedade humana nomeada — WebAuthn / chave de acesso Classe A, vinculada ao dispositivo; quórum multipartidário (M-de-N / ordenado — a regra das duas pessoas) para as ações de maior risco |
| EP Commit | Fechamento de ação atômico e imutável com recibos encadeados em Merkle |
Pontos de prova
| Métrica | Valor |
|---|---|
| Testes automatizados | 4.220 em 173 arquivos |
| Propriedades de segurança TLA+ | 26 verificadas (T1–T26), 0 erros — veja PROOF_STATUS.md |
| Asserções relacionais Alloy | 35 fatos + 22 asserções em dois modelos — verificados em CI |
| Casos de equipe vermelha catalogados | 85 — RED_TEAM_CASES.md |
| Achados de segurança remediados | 31 |
| Conformidade (7/7) | node conformance/ep-conformance-test.js https://www.emiliaprotocol.ai |
| Conformidade multilinguagem | 8 suítes — recibos · aprovações de dispositivo · quórum multipartidário · revogação · atestado de tempo · recibo de confiança · proveniência · registro de evidência — verificadores JS / Python / Go concordam (node conformance/run.mjs) |
| Handshake create p95 | 575ms a 50 VUs — PERFORMANCE_PROOF.md |
Objetos principais EP
EP padroniza três objetos interoperáveis que qualquer implementação conforme pode produzir e verificar:
| Objeto | O que é |
|---|---|
| Trust Receipt | Um registro portátil e assinado de um evento de autorização — o que aconteceu |
| Trust Profile | Um resumo padronizado do estado de confiança observável — o que é conhecido |
| Trust Decision | Um resultado avaliado por política com razões e caminho de apelação — o que fazer agora |
Extensões EP (Handshake, Signoff, Commit, Delegation) adicionam aplicação mais forte onde sistemas devem restringir a execução. As camadas de produto (GovGuard / FinGuard) são construídas em cima — não o protocolo em si.
Início rápido em cinco chamadas
- Criar política
- Iniciar handshake
- Apresentar evidência
- Verificar
- Aprovar e consumir
Demonstração de 90 segundos · Início rápido · Passo a passo do agente · IETF Draft · Discord
O que EP é — e não é
EP é autorização no momento da ação, não um sistema de identidade, não uma carteira, não uma pontuação de reputação.
- É: um padrão de confiança para vincular identidade do ator, autoridade, política e contexto exato da ação antes da execução
- Não é: um substituto para OAuth / OIDC (esses respondem quem é você — EP responde quem aprovou esta ação exata)
- Não é: um produto proprietário (o núcleo é Apache-2.0 e rastreado pela IETF)
- Não é: um blockchain (o recibo é o herói; o carimbo de tempo público opcional é uma nota de rodapé)
Veja CONFORMANCE.md · SECURITY.md · THREAT_MODEL.md · GOVERNANCE.md