EMILIA Protocol MCP Server

oficial

Requiere la aprobación verificable fuera de línea de una persona nombrada antes de que un agente de IA realice una acción irreversible — liberación de pago, cambio de registro, despliegue. Regla de dos personas, Recibos de Confianza Ed25519, redactado por el IETF, Apache-2.0.

GitHub

Documentación

Protocolo EMILIA

El motor sin frenos

Durante cincuenta años, la seguridad del software respondió a una sola pregunta: ¿quién tiene permiso para entrar? Cortafuegos, OAuth y contraseñas — todo construido para verificar una identidad humana en la puerta.

Esa era está terminando. Los usuarios dominantes del software ya no son humanos; son agentes de IA autónomos. Los agentes no solo inician sesión — escriben código, llaman herramientas y cambian la realidad sobre la marcha. Cada CISO sabe que una sola instrucción maliciosa puede hacer que un agente borre una base de datos en producción o transfiera dinero a la cuenta equivocada. Por eso están bloqueando el despliegue — sentados sobre miles de millones en presupuesto de IA que no pueden gastar porque sus equipos de cumplimiento no pueden responder una pregunta:

¿Quién aprobó esa acción?

La crisis de nuestra generación no es la autenticación. Es la autorización en el momento de la acción: ¿cómo demuestras que lo que un agente está a punto de hacer es exactamente lo que un humano designado autorizó — antes de que se ejecute?

EMILIA es el cinturón de seguridad para la era agéntica.

Los registros de decisión son testimonio. EMILIA produce recibos.

Sin recibo, no hay acción irreversible

Si un agente intenta mover dinero, eliminar código, desplegar en producción, cambiar permisos o mutar un estado regulado sin un recibo EMILIA válido, la herramienta se niega a ejecutarse — y si se ejecuta, cualquiera puede verificar quién autorizó exactamente qué, sin conexión, sin confiar en nadie.

Ese es todo el protocolo. La cuña para el desarrollador es un envoltorio alrededor de una herramienta MCP irreversible. Véalo en frío, completamente sin conexión, sin clave, sin cuenta — cada demostración ejecuta el ciclo completo (rechazado → un humano designado firma la acción exacta → la herramienta se ejecuta → recibo falsificado rechazado):

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

Envuelva su propio despachador de herramientas en producción — vea examples/mcp/ y /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

Pruébelo en 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

Pruebe una firma real con Face ID → Apruebe una transferencia de $82,000 con su propia clave de acceso. Vea cómo se ve VERIFICADO. Falsifique el recibo. Vea cómo falla.

Verifique cualquier recibo en su navegador — péguelo, no se sube nada.

Cómo funciona — cuatro actos

EMILIA crash test — an autonomous agent tries to wire $82,000; the policy engine holds it, a named human signs off on their own device, the receipt verifies offline, and a forged copy fails.

Ejecútelo usted mismo: node examples/crash-test.mjs — completamente sin conexión, sin clave 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.

Acto I — Intercepción (nativa de MCP). Sin reescrituras. EMILIA engancha la llamada a la herramienta en el límite del Protocolo de Contexto del Modelo — en el momento en que un agente intenta eliminar un archivo o mover capital, la acción es atrapada en el aire.

Acto II — Decisión (vinculada a políticas, determinista). La acción se verifica contra una política anclada con hash: allow, allow-with-signoff o deny. Además de un modo de observación que no cambia nada en producción e informa lo que se habría retenido. Determinista, auditable — no es una puntuación de riesgo de caja negra.

Acto III — La ceremonia (firma humana vinculada al dispositivo). Cuando la política requiere un humano, EMILIA ejecuta una firma WebAuthn / clave de acceso vinculada a la acción exacta — Face ID / Touch ID en el propio dispositivo del operador. Lo que el humano vio es lo que firmó. Ningún script puede falsificarlo; ningún bucle autónomo puede omitirlo.

Acto IV — El recibo (la evidencia). El resultado es un recibo de autorización firmado que cualquiera puede verificar sin conexión, con código abierto, sin backend, sin confianza en el proveedor. Altérelo y la verificación falla por construcción. Opcionalmente, anclelo para un sellado de tiempo público — el núcleo no necesita cadena de bloques.

Por qué los desarrolladores lo usan

Quiere agentes que realmente hagan cosas — pero está paralizado por bucles descontrolados, gasto excesivo de API y destrucción accidental de datos. EMILIA le ofrece un servidor MCP plug-and-play + un delgado envoltorio SDK. Aplique un hash de política, y las llamadas a herramientas irreversibles obtienen una capa de aprobación y evidencia criptográficamente endurecida, mapeada a NIST-AI-RMF — sin construir flujos de aprobación o infraestructura de auditoría desde cero.

# 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

Su agente no puede superar su correa.

Por qué las empresas lo necesitan

Cada cambio de plataforma acuña una nueva primitiva de seguridad: la web obtuvo SSL, la nube obtuvo Okta / IAM, la economía de agentes necesita confianza a nivel de acción. Las empresas están sentadas sobre presupuestos de IA que el cumplimiento no les permite gastar — EMILIA es la llave que los desbloquea, al convertir agentes impredecibles en infraestructura lista para auditoría que mapea primitiva por primitiva a los controles NIST AI RMF, la Ley de IA de la UE y SOC 2 CC6/7.

La capa gestionada (GovGuard / FinGuard) extiende el estándar abierto con paquetes de políticas sectoriales, pilotos en modo observación y paquetes de evidencia listos para auditoría — sin necesidad de adquisiciones para comenzar.

El estándar

EMILIA es un estándar abierto, no un foso de producto. El núcleo es Apache-2.0 y se rastrea como un Borrador de Internet del IETF.


Borradores de Internet del IETF	Publicados: authorization-receipts · quorum. En preparación en `standards/`: authorization-evidence-chain (EP-AEC, composición) · evidence-record (EP-EVIDENCE-RECORD, retención a largo plazo). Mapa de campo: landscape survey.
Verificadores multi-lenguaje	JavaScript · Python · Go — los tres probados para concordar en vectores de conformidad adversarial, en cada envío (`npm run conformance`). Ese es el listón del IETF para un estándar real: múltiples implementaciones interoperables independientes.
Verificación formal	26 propiedades de seguridad TLA+ (0 errores) · 35 hechos Alloy, 22 aserciones — ambos se ejecutan en CI
Registros MCP	Registro MCP oficial · Glama (Grado A, insignia Oficial) · Smithery
Licencia	Apache-2.0

Tres implementaciones independientes probadas para concordar — vea CONFORMANCE.md, o verifique un recibo usted mismo en emiliaprotocol.ai/verify.

La pila EP

Eye observes. Handshake verifies. Signoff owns. Commit seals.

Capa	Lo que hace
EP Eye	Observa y clasifica el comportamiento del agente (OBSERVAR → SOMBREAR → HACER CUMPLIR)
EP Handshake	Ceremonia de consentimiento criptográfico con vinculación de 7 propiedades
EP Signoff	Propiedad humana designada — WebAuthn / clave de acceso Clase A, vinculada al dispositivo; quórum multipartito (M-de-N / ordenado — la regla de dos personas) para las acciones de mayor riesgo
EP Commit	Cierre de acción atómico e inmutable con recibos encadenados Merkle

Puntos de prueba

Métrica	Valor
Pruebas automatizadas	4,220 en 173 archivos
Propiedades de seguridad TLA+	26 verificadas (T1–T26), 0 errores — vea PROOF_STATUS.md
Aserciones relacionales Alloy	35 hechos + 22 aserciones en dos modelos — verificados en CI
Casos de equipo rojo catalogados	85 — RED_TEAM_CASES.md
Hallazgos de seguridad remediados	31
Conformidad (7/7)	`node conformance/ep-conformance-test.js https://www.emiliaprotocol.ai`
Conformidad multi-lenguaje	8 suites — recibos · firmas de dispositivo · quórum multipartito · revocación · atestación de tiempo · recibo de confianza · procedencia · registro de evidencia — verificadores JS / Python / Go concuerdan (`node conformance/run.mjs`)
Handshake crear p95	575ms a 50 VUs — PERFORMANCE_PROOF.md

Objetos centrales EP

EP estandariza tres objetos interoperables que cualquier implementación conforme puede producir y verificar:

Objeto	Lo que es
Recibo de Confianza	Un registro portátil y firmado de un evento de autorización — lo que sucedió
Perfil de Confianza	Un resumen estandarizado del estado de confianza observable — lo que se sabe
Decisión de Confianza	Un resultado evaluado por política con razones y ruta de apelación — qué hacer ahora

Las Extensiones EP (Handshake, Signoff, Commit, Delegation) añaden una aplicación más fuerte donde los sistemas deben restringir la ejecución. Las capas de producto (GovGuard / FinGuard) se construyen encima — no son el protocolo en sí.

Inicio rápido en cinco llamadas

Crear política
Iniciar handshake
Presentar evidencia
Verificar
Firmar y consumir

Demostración de 90 segundos · Inicio rápido · Recorrido del agente · Borrador IETF · Discord

Lo que EP es — y no es

EP es autorización en el momento de la acción, no un sistema de identidad, no una billetera, no una puntuación de reputación.

Es: un estándar de confianza para vincular la identidad del actor, autoridad, política y contexto exacto de la acción antes de la ejecución
No es: un reemplazo para OAuth / OIDC (esos responden quién eres — EP responde quién aprobó esta acción exacta)
No es: un producto propietario (el núcleo es Apache-2.0 y rastreado por el IETF)
No es: una cadena de bloques (el recibo es el héroe; el sellado de tiempo público opcional es una nota al pie)

Vea CONFORMANCE.md · SECURITY.md · THREAT_MODEL.md · GOVERNANCE.md