EMILIA Protocol

EMILIA Protocol

---

Deja que tu agente prepare el pago. Controla lo que puede liberar.

Un agente prepara un pago a proveedor de $82,000. Alguien lo aprueba. Luego el monto o el destino bancario cambia. La aprobación anterior no debe liberar el pago modificado.

EMILIA Gate verifica la autoridad antes de que una herramienta protegida se ejecute. El protocolo abierto hace que la evidencia resultante sea verificable de forma independiente bajo las propias claves de confianza y reglas del verificador. Mantén tu proveedor de identidad, marco de agentes y sistemas de negocio existentes.

Ejecuta el ejemplo de pago

Con Node.js 20.19 o más reciente y npm instalado:

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

El ejemplo rechaza una llamada sin aprobación, vincula la aprobación al monto, la moneda, el proveedor y el destino, admite la llamada coincidente una sola vez, y rechaza detalles de pago modificados, reproducción y evidencia falsificada. Consulta el ejemplo y sus límites.

Esta es una demostración local: claves de firma generadas, consumo en memoria y una herramienta de pago simulada. No realiza una ceremonia humana real ni mueve dinero. En producción se necesitan credenciales inscritas, estado compartido duradero y Gate en cada ruta hacia la credencial protegida del proveedor. Una aprobación válida no establece que los datos bancarios sean legítimos.

¿Prefieres un navegador? Prueba una passkey en un pago de muestra. Esa demostración separada muestra la integridad del recibo con tu autenticador de plataforma; no se envía ningún pago.

Protege una herramienta que ya usas

Comienza en el servicio que posee la credencial real del proveedor, no solo dentro del proceso del agente. El propietario define el trabajo permitido y cuándo se requiere una aprobación nueva. Un agente puede trabajar dentro de esos límites sin que una persona apruebe cada llamada.

• MCP o HTTP: Gate Starter te guía a través de una acción cubierta.
• Hugging Face smolagents: envuelve una herramienta existente.
• GitHub: Merge Gate vincula una verificación a la fusión propuesta. La verificación debe ser obligatoria y las rutas de fusión alternativas deben estar cerradas.

El protocolo prueba. Gate previene en las rutas que el despliegue media por completo. Gate no puede restringir una ruta de evasión. Si el resultado de un proveedor es desconocido, el ciclo de vida de producción preserva esa incertidumbre para conciliación en lugar de reintentar a ciegas.

Sistemas de IA y revisores de repositorios: comienza con AI_CONTEXT.md. La evidencia legible por máquina actual, procedencia, suposiciones y exclusiones se publican en EMILIA-REPO-CONTEXT-v1. Los documentos archivados o en borrador no establecen el estado actual de implementación o IETF. Evidencia pública de diligencia debida y límites de afirmaciones: DUE_DILIGENCE.md.

Evidencia de ingeniería, no afirmaciones de arquitectura

EMILIA incluye un caso de seguridad que los revisores pueden ejecutar. El repositorio actual resuelve 35 afirmaciones de seguridad sobre 264 archivos de evidencia con hash, verifica 20 lemas de Tamarin en dos modelos compuestos de Dolev-Yao — 17 obligaciones de todas las trazas y 3 testigos de alcanzabilidad de trazas existentes — y preserva 8 variantes deliberadamente debilitadas que producen trazas de ataque concretas cuando se eliminan las verificaciones de carga. El corpus de conformidad del mismo equipo en vivo contiene 21 suites y 340 vectores actuales. Por separado, un verificador Rust de autoría externa está fijado al paquete congelado de 16 suites/164 vectores y una campaña de hostilidad de 359 casos. La suite más amplia contiene más de 10,700 pruebas automatizadas en más de 650 archivos.

Las superficies de producción en JavaScript y JSDoc se verifican con el compilador TypeScript checkJs; la aplicación segura tiene su propio proyecto de compilador de compatibilidad, mientras que las declaraciones y el SDK público de TypeScript se verifican en modo estricto. Esto es cobertura completa de verificación de tipos de producción configurada, no una afirmación de que el repositorio se convirtió por completo de JavaScript a TypeScript o que cada proyecto JavaScript tiene la opción strict de TypeScript habilitada.

Cada afirmación de seguridad nombra la ruta de aplicación, vectores positivos y negativos, cobertura de lenguaje, alcance formal o brecha explícita, suposiciones, exclusiones y hash de evidencia. Comienza con el mapa de evidencia legible por humanos, luego inspecciona el caso de seguridad resuelto o ejecuta npm run check:security-case.

AEB-1: prueba el límite de evidencia a efecto

El paquete abierto de Conformidad de Admisión de Consecuencia AEB-1 prueba la ruta compuesta CAID/AEC en el último punto de control antes de una acción consecuente: verificación nativa, aceptación de la parte confiada, vinculación de acción exacta, coincidencia de CAID requerida, satisfacción de evidencia AEC requerida, autorización local, reserva atómica, custodia INVOKING, verdad separada de resultado del proveedor y efecto observado, comportamiento sin reintento ciego, y conciliación autenticada.

Lee el límite de admisión de consecuencia para la división exacta de responsabilidades en la ruta compuesta CAID/AEC, la ruta nativa directa, la custodia AEB y la evidencia de resultado del proveedor.

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

Es neutral al formato y se ejecuta por sí mismo. Un informe aprobado es evidencia de conformidad autoatestiguada, no una auditoría, certificación, afirmación de despliegue en producción o permiso para ejecutar una acción.

Bajo AEB-07, publicado el 2026-09-25 como un Internet-Draft individual y no adoptado por ningún grupo de trabajo, CAID se usa solo cuando acciones codificadas de forma independiente deben unirse, y AEC se usa solo cuando la política local requiere varias patas de evidencia. Un corpus sintético separado de 26 casos modela ese ciclo de vida nativo directo sobre adaptadores de resultados de AuthZEN/COAZ-MCP, AP2, OAuth Transaction Token y mandato firmado local:

npm run conformance:composition:consequence-admission

El ejecutor del corpus es un modelo de ciclo de vida independiente con su propio almacenamiento en memoria y lógica de admisión. No ejecuta el código @emilia-protocol/verify o @emilia-protocol/gate incluido, por lo que no es evidencia para esos paquetes, que tienen sus propias suites de pruebas. Tampoco es evidencia de que los protocolos nativos nombrados cumplan con AEB-07.

Para una prueba ejecutable enfocada de la ruta Gate del repositorio, ejecuta:

npm run proof:gate:reference

Este comando ejercita ejemplos locales y límites de servicio enfocados con claves generadas, estado en memoria y comportamiento simulado del proveedor. Es una prueba local útil, no evidencia de un humano real, banco externo, despliegue de producción o una integración de producción de extremo a extremo.

La identidad no es una descripción de trabajo

La identidad dice quién o qué está llamando. La política dice qué está permitido en general. Ninguna define el trabajo finito que un trabajador autónomo puede realizar ahora: su misión, límites de acciones materiales, presupuesto, evidencia requerida, vencimiento, reglas de delegación y ruta de excepción.

EMILIA mantiene esas preguntas separadas:

Capa	Pregunta
Identidad	¿Quién o qué está presente?
Política	¿Qué está permitido en general?
Autoridad	¿Qué trabajo exacto puede realizar este agente bajo este mandato?

Las credenciales otorgan alcance. La autoridad define el trabajo. No toda acción necesita un humano; toda acción consecuente necesita autoridad válida.

En la base, EP Core aún expone tres objetos interoperables: un Recibo de Confianza lleva evidencia atribuible, un Perfil de Confianza representa estado de confianza estructurado, y una Decisión de Confianza registra el resultado evaluado por la política de la parte confiada. Las capas del plano de control de autoridad agregan vinculación de acción exacta, mandatos finitos, admisión, consumo y evidencia de resultado sin colapsar esos objetos en una sola afirmación.

---

Establece el mandato una vez. Deja que el agente trabaje.

El cliente define la misión, los límites, los requisitos de evidencia, el vencimiento y las reglas de excepción. El código local puede reducir esa autoridad; no puede inventarla ni ampliarla. Gate vincula cada solicitud ejecutable al mandato, reserva la autoridad cubierta antes de la entrada al proveedor, permite un intento de proveedor admitido para esa instancia de autorización dentro del dominio de autoridad duradero compartido, y escala solo cuando la autoridad falta, está obsoleta, agotada o es demasiado estrecha.

Los ejemplos MCP incluidos ejercitan un perfil de política que requiere aprobación en el límite. Generan claves de firma de demostración e invocan herramientas simuladas. El ejemplo de pago vincula los cuatro campos materiales declarados; los otros ejemplos demuestran vinculaciones de recursos más estrechas. No capturan una decisión humana real ni contactan a un proveedor:

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

La demostración de composición más profunda ejecuta un pago delegado vinculado a CAID a través de la ruta real de capacidad limitada de Gate, luego verifica el certificado de ejecución firmado sin conexión:

npm run demo:receipt-program

Deliberadamente no incluye blockchain ni afirmaciones simuladas de conocimiento cero. Consulta la arquitectura del programa de recibos para conocer los requisitos de estado de producción y confianza.

Comienza con una acción MCP consecuente declarada. Instala el entorno de ejecución local exacto, luego crea su Gate Starter y ejecuta la verificación limitada de cuatro casos:

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

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

La verificación local generada usa estado de demostración explícitamente efímero y prueba solo los casos sintéticos declarados de ausencia, coincidencia exacta, mutación, reproducción y herramienta no escaneada. El comando revisado crea una transferencia con límite de privacidad; no activa Gate. La producción requiere un libro de procedencia duradero, un almacén de consumo atómico compartido, claves fijadas y el envoltorio en cada ruta hacia la credencial real del proveedor. Consulta examples/mcp/ y /mcp.

Detén nuevas acciones sin pretender deshacer las anteriores

La congelación de autoridad de emergencia de Gate bloquea nuevas reservas y evita que reservas anteriores entren después de que cambie la época del dominio de control cubierto. Si la entrada al proveedor ocurrió primero, el intento permanece consumido y necesita conciliación. Restaurar la autoridad no revive una reserva anterior.

Esto requiere mediación completa y estado compartido autoritativo. No detiene el cómputo, revierte un efecto ni alcanza instantáneamente dominios desconectados. Consulta la implementación del dominio de control y sus límites.

Pruébalo 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

Prueba una passkey de plataforma en un pago de muestra → Firma un pago ilustrativo de $82,000, cambia su monto y observa cómo falla la verificación de integridad. Tu autenticador puede usar biometría o un PIN del dispositivo. La página también ofrece una simulación de software separada. Ningún modo envía un pago ni establece autorización de producción.

Verifica cualquier recibo en tu navegador — pégalo, no se sube nada.

---

Cómo funciona — un ciclo de vida de autoridad

Ejecútalo tú mismo: node examples/crash-test.mjs — completamente sin conexión, sin clave 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. La fuente de autoridad define el trabajo finito. Puede ser un programa operativo firmado por el cliente, una capacidad limitada, una decisión humana requerida, un quórum o una composición de la parte confiada de evidencia nativa.

Trabajo exacto. Gate vincula método, origen, destinatario, objetivo, ocurrencia y cada campo material en el objeto ejecutable canónico. La intención, un prompt o el texto de un ticket no son ese objeto.

Verifica, reserva y entra. Los artefactos nativos permanecen nativos. La parte confiada fija los perfiles de confianza y mapeo, evalúa el requisito de evidencia completo, toma la decisión de autorización local separada y reserva la autoridad cubierta antes de que el adaptador que posee la credencial entre al proveedor.

Autoridad humana fresca cuando se requiere. Una política puede requerir una decisión WebAuthn/passkey vinculada a la acción exacta y al hash de visualización determinista. Esto reduce la brecha de "lo que viste es lo que firmaste"; no prueba comprensión, sabiduría, legalidad ni resultado. Para implementaciones empresariales, Gate puede adicionalmente requerir una confirmación de un Servidor de Autorización verificado de forma independiente, vinculada a esa evidencia humana exacta, la misma acción exacta, la instantánea de identidad que el AS realmente observó, y la clave del Servidor de Recursos prevista. El tiempo de la instantánea y la antigüedad máxima de la parte confiable son explícitos: un token nuevo no puede hacer que los datos de directorio obsoletos sean actuales. La parte del AS es evidencia bajo confianza fijada por el cliente; nunca autoriza por sí misma, prueba el estado de empleo instantáneo, ni convierte al orquestador de agentes en una autoridad.

Resultado veraz. La admisión no es ejecución, y la ejecución no es efecto. Un registro firmado puede verificarse sin conexión; la evidencia del proveedor y la del observador permanecen separadas. Una respuesta perdida se convierte en INDETERMINATE, que es un estado a reconciliar—no permiso para reintentar. Un remedio es una nueva acción autorizada y nunca reescribe el resultado anterior.

---

Por qué los desarrolladores lo usan

Comience mapeando el trabajo localmente, luego proteja una superficie de acción declarada con el servidor MCP o un envoltorio SDK delgado. El escáner propone un mapa revisable; el propietario define el mandato; Gate posee la credencial del proveedor y aplica la acción exacta en la ruta cubierta. Ningún escaneo prueba la mediación completa, y el descubrimiento por sí solo no otorga autoridad.

# 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

El agente recibe la capacidad de realizar trabajo limitado, no una credencial permanente que pueda reinterpretar.

---

Por qué las empresas lo necesitan

Los procesos de agentes se reinician y los modelos cambian. El mandato del cliente, el estado de consumo, la revocación, la incertidumbre y el historial de trabajo deben sobrevivir fuera de ellos. EMILIA mantiene ese estado de autoridad duradero en el límite del cliente mientras acepta pruebas externas a través de adaptadores fijados.

El Gate gestionado y el Plano de Garantía añaden operaciones de mandato, integraciones, operaciones de evidencia, re-ejecución, soporte y niveles de servicio alrededor del protocolo abierto. El cliente conserva el control de la autoridad, las raíces de confianza, las credenciales, la política y la evidencia portátil.

---

El estándar

EMILIA Protocol es abierto y con licencia Apache-2.0. Su trabajo de estándares se publica como un portafolio de Borradores de Internet individuales. Un Borrador de Internet publicado no es un RFC, un elemento adoptado por un grupo de trabajo, ni un respaldo de la IETF; Datatracker es autoritativo para la revisión y el estado.

Una superficie de límite de consecuencias

El actual AEB-07, publicado el 2026-09-25 como un Borrador de Internet individual y no adoptado, convierte a AEB en el punto de composición después de una decisión nativa. OAuth, AuthZEN, COAZ, AP2 y los sistemas locales mantienen la propiedad de sus credenciales, mapeos de operaciones y decisiones de autorización. AIMS (draft-ietf-wimse-aims) es un documento informativo del grupo de trabajo WIMSE que perfila estándares existentes como WIMSE y OAuth; no emite credenciales ni decisiones por sí mismo. AEB aplica la decisión nativa en el límite del proveedor protegido: vincula la acción final cuando es necesario, deriva una identidad de reproducción nativa por concesión, reserva antes de la entrada al proveedor, rechaza un segundo intento de la misma acción mientras una anterior esté en vuelo o incierta, y mantiene un resultado incierto bloqueado hasta la reconciliación autenticada.

CAID-04 se usa cuando deben compararse representaciones codificadas de forma independiente. No es un segundo mapeo obligatorio cuando el PEP que posee la consecuencia ya deriva y aplica una decisión actual sobre la operación final. AEC-06 se usa cuando la parte confiable requiere varias patas de evidencia. Los Recibos de Autorización, el Vinculación de Autorización Humana y la Introducción de Autoridad siguen siendo perfiles disponibles para implementaciones que los necesiten; no son requisitos previos para cada integración de AEB. Architecture-03 sigue siendo el documento de navegación.

La guía de admisión de consecuencias establece el límite de implementación y los casos donde AEB es innecesario. El perfil de traspaso nativo directo es un perfil de implementación de repositorio que muestra cómo un permiso existente llega a Gate sin una segunda capa de CAID o AEC. AEB-07 especifica qué atestigua dicho traspaso de puerta y cómo el límite lo verifica, pero deja la codificación a los fijados de implementación; cita una instantánea fijada de este perfil como una codificación de referencia informativa. Los bytes exactos del -07 enviado y su registro de publicación se conservan en standards/staged/NEXT-AEB-07.

El portafolio activo completo es de 26 registros de Datatracker: 21 registros de autoría única y cinco de coautoría, cada uno con su propio alcance, historial de revisiones y estado de mantenimiento registrado. Consulte la guía de estándares, el portafolio y el inventario de estado legible por máquina.

Borradores de Internet de la IETF	Rutas de instantánea local actuales: inventario de estado · inventario publicado de autoría única · estado en vivo autoritativo: IETF Datatracker
Verificadores entre lenguajes	JavaScript · Python · Go — los tres demuestran acuerdo en vectores de conformidad adversariales, en cada push (npm run conformance). Una verificación de consistencia entre los puertos de un equipo, no implementaciones independientes de sala limpia. Por separado, una implementación Rust de autoría externa desde la especificación (fuente pública) pasa el paquete fijado de 16 suites/164 vectores y la campaña de hostilidad fijada de 359 casos bajo una reconstrucción controlada por el evaluador desde un árbol fuente inmutable. Su evidencia de construcción verificada permanece firmada por el implementador, no atestiguada por terceros (declaración firmada); la aceptación estricta de sala limpia espera el manifiesto corregido atestiguado por terceros y la clave de atestiguador fijada de forma independiente.
Evidencia de modelo formal	26 propiedades de seguridad TLA+ acotadas mantenidas en sus espacios de estado configurados; esto no es refinamiento de implementación ni una prueba no acotada · 35 hechos de Alloy, 32 aserciones en cuatro modelos · dos modelos simbólicos compuestos de Dolev-Yao que cubren desafío, CAID, dos aprobaciones, fijados de emisor y autoridad, vista de registro, revocación, consumo, ejecución y seis límites de reclamación dedicados. Veinte lemas de Tamarin verifican — 17 obligaciones de todos los rastros y 3 testigos de rastro existente; ocho variantes deliberadamente debilitadas producen rastros de ataque concretos cuando se eliminan las comprobaciones de carga (formal/tamarin/).
Distribución MCP	Paquete npm @emilia-protocol/mcp-server · la publicación oficial en el Registro se rastrea por separado en MCP-REGISTRY.md; los listados de agregadores no se infieren de ninguno de los dos estados
Licencia	Apache-2.0

Tres puertos de referencia del mismo equipo (JS / Python / Go) coinciden en las 21 suites y 340 vectores. Por separado, una implementación Rust de autoría externa reconstruida desde un árbol fuente público fijado pasa el paquete fijado de sala limpia de 16 suites/164 vectores y una campaña de hostilidad de 359 casos, re-ejecutada en su propio carril de CI en cada cambio. Las suites más nuevas de aceptación AEC y resolución de cuatro resultados no se atribuyen a Rust. Eso es evidencia de interoperabilidad externa, no aceptación estricta de construcción de sala limpia; el registro de CI agregado cuenta la aceptación estricta como cero pendiente de atestación independiente. Consulte CONFORMANCE.md, o verifique un recibo usted mismo en emiliaprotocol.ai/verify.

---

La pila de autoridad

Capa	Qué hace
Mandato	Define misión, límites, evidencia, expiración, delegación y reglas de excepción.
CAID / acción exacta	Compara el significado material cuando la autorización y la ejecución usan representaciones codificadas de forma independiente; no autoriza.
AEC	Cuando se requiere, evalúa si la evidencia verificada y coincidente de forma independiente satisface el requisito de múltiples patas de la parte confiable; no autoriza.
AEB / Gate	Aplica la decisión de autorización nativa o local en el límite de consecuencias, reserva la autoridad cubierta y controla la entrada al proveedor.
Evidencia de resultado	Mantiene la invocación, la respuesta del proveedor, el efecto observado y la incertidumbre distintos.

---

Puntos de prueba

Métrica	Valor
Casos de prueba automatizados	10,700+ en 650+ archivos; todos los casos aplicables a la plataforma deben pasar
Propiedades de seguridad TLA+	26 invariantes acotadas mantenidas en el espacio de estado configurado; no es una prueba de refinamiento de implementación o no acotada — consulte PROOF_STATUS.md
Aserciones relacionales de Alloy	35 hechos + 32 aserciones en cuatro modelos — verificadas en CI
Casos de equipo rojo catalogados	86 — RED_TEAM_CASES.md
Estado de seguridad de lanzamiento	Las comprobaciones de seguridad del repositorio pasan; cada hallazgo de Strix en los cambios auditados se remedia con cobertura de regresión y su hilo de revisión resuelto
Conformidad (7/7)	node conformance/ep-conformance-test.js https://www.emiliaprotocol.ai
Conformidad entre lenguajes	340 vectores · 21 suites: recibos · firmas de dispositivos · resolución de cuatro resultados · quórum multipartito · revocación · Vinculación de Resultado (semántica + criptografía real) · unión de emisor de Documento/Prueba de Autoridad · atestación de tiempo · recibo de confianza (x2 perfiles) · procedencia · registro de evidencia · canonicalización · límite · aceptación AEC · moneda · atestación de iniciador · prueba de consumo · testigo · prueba de marca de tiempo (RFC 3161). Los verificadores JS / Python / Go coinciden (node conformance/run.mjs). La línea base externa de Rust permanece en 164 vectores / 16 suites. Consulte CONFORMANCE.md.
p95 de creación de protocolo de enlace	575ms a 50 VUs — PERFORMANCE_PROOF.md

Longevidad criptográfica (con límites de implementación explícitos)

La evidencia destinada a verificarse años después debe sobrevivir a los algoritmos bajo los cuales se firmó. EP envía cuatro capacidades acotadas para eso, cada una con un límite exacto que es parte de la reclamación:

• Firmas híbridas (EP-RECEIPT-HYBRID-v1). Ed25519 y ML-DSA-65 sobre los mismos bytes canónicos, con el conjunto de algoritmos requerido comprometido en los bytes firmados para que quitar una pata rompa la firma sobreviviente. La capacidad es opt-in en la implementación; una vez que un firmante dual aprobado está registrado y la política permite su pata PQ, una postura de Gate no fijada resuelve a emisión dual por defecto. De lo contrario, permanece solo clásico con una razón nombrada. Los verificadores v1 rechazan recibos híbridos limpiamente en lugar de aceptar una pata. El contrato de firmante externo y el adaptador de AWS KMS están implementados, pero no se reivindica ninguna llamada de firma de AWS en vivo, clave de producción, verificación de parte confiable o validación FIPS de ML-DSA. Consulte conformance/hybrid-receipts/ y lib/pq-custody-aws-kms.ts.
• Perfil de Declaración Firmada SCITT (EP-SCITT-STATEMENT-v1). Una forma completa de Declaración Firmada RFC 9943 para recibos EP, incluido el encabezado protegido de Reclamaciones CWT. Límite: ningún Servicio de Transparencia ha aceptado una declaración EP; el registro externo es un paso separado y controlado y ninguno se ha realizado. Consulte EP-RECEIPT-SCITT-PROFILE.md.
• Re-atestación (EP-EVIDENCE-REATTESTATION-v1). La evidencia firmada bajo un algoritmo envejecido puede re-anclarse bajo uno actual antes de que el antiguo se debilite. Límite: la re-atestación debe preceder al compromiso; no puede reparar evidencia después del hecho.
• Modo de implementación FIPS (EP-FIPS-MODE-v1). Ejecuta operaciones clásicas a través de un proveedor validado FIPS 140-3 suministrado por el operador, con la ruta ML-DSA controlada detrás de un reconocimiento explícito de implementación no validada. Límite: esto gana "algoritmos basados en FIPS, con un modo de implementación de proveedor validado" y depende del proveedor del operador y el límite de certificado declarado; no es una reclamación de cumplimiento general, y nada aquí está validado por FIPS. Consulte FIPS-MODE.md.

El programa híbrido de toda la pila (cada superficie de firma interna) está mapeado en pq-hybrid-program.md y no está completo; hasta que lo esté, no se hace ninguna reclamación general sobre toda la pila.

---

Objetos centrales del protocolo

Objeto	Qué es
Programa de autoridad / capacidad acotada	Un mandato finito con alcance explícito, presupuesto o unidades, caducidad, delegación y reglas de consumo.
CAID	Un identificador canónico para una acción material bajo un perfil de mapeo nombrado; la coincidencia no es autorización.
Requisito de evidencia y resultado de AEC	La regla fijada por la parte que confía y su evaluación SATISFIED, UNSATISFIED o INDETERMINATE.
Registro de admisión y custodia de AEB	El registro del lado del ejecutor de autorización, reserva, entrada de proveedor y estado de conciliación.
Evidencia de autorización y resultado	Artefactos portátiles nativos o EP que conservan su emisor, alcance y límite de reclamación exactos.

---

Inicio rápido

1. Instale el runtime de guardia local exacto y luego ejecute npx @emilia-protocol/scan@0.5.0 protect ./tools.json --action sendWire --apply --verify, reemplazando sendWire con una herramienta consecuente declarada exacta.
2. Revise el Mapa de Autoridad generado, el manifiesto de acciones, los campos materiales, el límite seleccionado y los puntos ciegos nombrados.
3. Ejecute el comando separado --reviewed --crossing-profile <launch-profile> para crear la transferencia solo para el propietario y el espacio de trabajo de Labor sin sellar a partir de esos bytes sin cambios.
4. Instale Gate en la ruta que posee la credencial del proveedor y el estado de consumo duradero.
5. Defina el mandato operativo y cualquier regla de excepción de humano fresco o quórum.
6. Ejecute los casos de rechazo, acción exacta, repetición, tiempo de espera y conciliación antes de habilitar la aplicación.

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

---

Qué es EP — y qué no es

EMILIA es infraestructura de autoridad para trabajo autónomo, no un sistema de identidad, billetera, puntaje de reputación, riel de liquidación o motor de políticas universal.

• Es: un plano de control para mandatos operativos finitos, verificación de acción exacta, estado de admisión duradero, incertidumbre veraz y evidencia portátil en rutas de ejecutor cubiertas.
• No es: un reemplazo para OAuth/OIDC, identidad de carga de trabajo o motores de políticas. Esos permanecen como entradas nativas bajo los pines de la parte que confía.
• No es: un requisito de que un humano apruebe cada acción. Un mandato puede permitir trabajo automático dentro de límites finitos y exigir autoridad fresca solo en el borde.
• No es: prueba de que una acción admitida se ejecutó con éxito o causó el efecto previsto.
• No es: control de protocolo propietario. El núcleo es Apache-2.0 y los Internet-Drafts son envíos individuales, no RFC ni respaldo de IETF.

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