EMILIA Protocol

EMILIA Protocol

---

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

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

EMILIA Gate comprueba la autoridad antes de que se ejecute una herramienta protegida. El protocolo abierto permite verificar de forma independiente las pruebas resultantes con las claves y reglas de confianza propias del verificador. Conserva tu proveedor de identidad, marco de agentes y sistemas empresariales actuales.

Ejecuta el ejemplo de pago

Con Node.js 20.19 o posterior y npm instalados:

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 importe, la moneda, el proveedor y el destino, admite una vez la llamada coincidente y rechaza los detalles de pago modificados, la repetición y las pruebas falsificadas. Consulta el ejemplo y sus limitaciones.

Esta es una demostración local: utiliza 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 todas las rutas hacia la credencial protegida del proveedor. Una aprobación válida no demuestra que los datos bancarios sean legítimos.

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

Protege una herramienta que ya utilizas

Empieza por el servicio que contiene la credencial real del proveedor, no solo por el 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 explica paso a paso una acción protegida.
• Hugging Face smolagents: envuelve una herramienta existente.
• GitHub: Merge Gate vincula una comprobación a la fusión propuesta. La comprobación debe ser obligatoria y deben cerrarse las rutas de fusión alternativas.

El protocolo demuestra. Gate impide las acciones en las rutas que la implementación media por completo. Gate no puede restringir una ruta de elusión. Si se desconoce el resultado de un proveedor, el ciclo de vida de producción conserva esa incertidumbre para conciliarla, en lugar de reintentar a ciegas.

Sistemas de IA y revisores de repositorios: empieza por AI_CONTEXT.md. Las pruebas actuales legibles por máquina, su procedencia, supuestos y exclusiones se publican en EMILIA-REPO-CONTEXT-v1. Los documentos archivados o en preparación no demuestran la implementación actual ni el estado ante el IETF. Pruebas públicas para la diligencia debida y límites de las afirmaciones: DUE_DILIGENCE.md.

Pruebas 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 con 264 archivos de pruebas con hash, verifica 20 lemas de Tamarin en dos modelos Dolev-Yao compuestos —17 obligaciones para todas las trazas y 3 testigos de alcanzabilidad para trazas existentes— y conserva 8 variantes debilitadas deliberadamente que producen trazas de ataque concretas al eliminar comprobaciones esenciales. El corpus de conformidad activo del mismo equipo contiene 21 suites y 340 vectores actuales. Por separado, un verificador de Rust escrito externamente está fijado al paquete congelado de 16 suites/164 vectores y a 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 JavaScript de producción y JSDoc se comprueban con el compilador de TypeScript checkJs; la aplicación segura tiene su propio proyecto de compilación de compatibilidad, mientras que las declaraciones y el SDK público de TypeScript se comprueban en modo estricto. Esto representa una cobertura completa de comprobación de tipos para la producción configurada; no significa que todo el repositorio se haya convertido de JavaScript a TypeScript ni que todos los proyectos de JavaScript tengan habilitada la opción strict de TypeScript.

Cada afirmación de seguridad especifica la ruta de aplicación, los vectores positivos y negativos, la cobertura de lenguajes, el alcance formal o la brecha explícita, los supuestos, las exclusiones y el hash de las pruebas. Empieza por el mapa de pruebas para personas, luego consulta el caso de seguridad resuelto o ejecuta npm run check:security-case.

AEB-1: prueba el límite entre las pruebas y el efecto

El paquete abierto AEB-1 Consequence Admission Conformance prueba la ruta compuesta CAID/AEC en el último punto de control antes de una acción con consecuencias: verificación nativa, aceptación por la parte dependiente, vinculación a la acción exacta, coincidencia de CAID obligatoria, satisfacción de las pruebas AEC requeridas, autorización local, reserva atómica, custodia de INVOKING, veracidad independiente del resultado del proveedor y del efecto observado, comportamiento sin reintentos a ciegas y conciliación autenticada.

Lee sobre el límite de admisión de consecuencias para conocer la división exacta de responsabilidades entre la ruta compuesta CAID/AEC, la ruta nativa directa, la custodia AEB y las pruebas del resultado del proveedor.

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

Es independiente del formato y se ejecuta por cuenta propia. Un informe aprobado es una prueba de conformidad autodeclarada, no una auditoría, certificación, afirmación de implementación en producción ni permiso para ejecutar una acción.

Según AEB-07, publicado el 2026-09-25 como Internet-Draft individual y no adoptado por ningún grupo de trabajo, CAID se utiliza solo cuando es necesario combinar acciones codificadas de forma independiente, y AEC solo cuando la política local exige varias fuentes de pruebas. Un corpus sintético independiente de 26 casos modela ese ciclo de vida nativo directo sobre AuthZEN/COAZ-MCP, AP2, OAuth Transaction Token y resultados de adaptadores de mandatos firmados locales:

npm run conformance:composition:consequence-admission

El ejecutor del corpus es un modelo de ciclo de vida independiente, con su propio almacén en memoria y lógica de admisión. No ejecuta el código distribuido de @emilia-protocol/verify ni @emilia-protocol/gate, por lo que no constituye una prueba de esos paquetes, que cuentan con sus propias suites de pruebas. Tampoco demuestra que los protocolos nativos mencionados cumplan con AEB-07.

Para obtener una prueba ejecutable y específica de la ruta Gate del repositorio, ejecuta:

npm run proof:gate:reference

Este comando ejecuta ejemplos locales y límites de servicio específicos con claves generadas, estado en memoria y comportamiento simulado del proveedor. Es una prueba local útil, pero no demuestra la participación de una persona real, de un banco externo, una implementación en producción ni una integración de producción integral.

La identidad no es una descripción del trabajo

La identidad indica quién o qué realiza la llamada. La política indica qué está permitido en general. Ninguna de las dos define el trabajo finito que un agente autónomo puede realizar ahora: su misión, los límites de las acciones importantes, el presupuesto, las pruebas requeridas, el vencimiento, las reglas de delegación y la vía de excepción.

EMILIA mantiene esas cuestiones 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 todas las acciones requieren una persona; toda acción con consecuencias requiere autoridad válida.

En la base, EP Core sigue exponiendo tres objetos interoperables: un Trust Receipt contiene pruebas atribuibles, un Trust Profile representa un estado de confianza estructurado y un Trust Decision registra el resultado evaluado según la política de la parte dependiente. Las capas del plano de control de autoridad añaden la vinculación a la acción exacta, mandatos finitos, admisión, consumo y pruebas del resultado, sin reducir esos objetos a una sola afirmación.

---

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

El cliente define la misión, los límites, los requisitos de pruebas, el vencimiento y las reglas de excepción. El código local puede restringir esa autoridad, pero no inventarla ni ampliarla. Gate vincula cada solicitud ejecutable al mandato, reserva la autoridad cubierta antes de acceder al proveedor, permite un intento de proveedor admitido por instancia de autorización dentro del dominio de autoridad compartido y duradero, y escala solo cuando la autoridad falta, está obsoleta, se ha agotado o es demasiado limitada.

Los ejemplos MCP incluidos prueban un perfil de política que exige 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 importantes declarados; los demás ejemplos muestran vinculaciones a recursos más limitadas. No capturan una decisión humana real ni se comunican con 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 avanzada ejecuta un pago delegado vinculado a CAID mediante la ruta real de capacidad acotada de Gate y luego verifica sin conexión el certificado de ejecución firmado:

npm run demo:receipt-program

Deliberadamente, no incluye ninguna afirmación sobre blockchain ni sobre pruebas de conocimiento cero simuladas. Consulta la arquitectura del programa de recibos para conocer los requisitos de estado y confianza en producción.

Empieza con una acción MCP con consecuencias declarada. Instala el entorno de ejecución local exacto, crea su Gate Starter y ejecuta la comprobación acotada de cuatro 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

La comprobación local generada utiliza un estado de demostración explícitamente efímero y solo demuestra los casos sintéticos indicados: ausencia, coincidencia exacta, modificación, repetición y herramienta no analizada. El comando revisado crea una transferencia acotada por privacidad; no activa Gate. En producción se necesita un registro de procedencia duradero, un almacén de consumo atómico compartido, claves fijadas y el contenedor en todas las rutas hacia la credencial real del proveedor. Consulta examples/mcp/ y /mcp.

Detén las acciones nuevas sin fingir que deshaces las anteriores

El bloqueo de emergencia de autoridad de Gate impide nuevas reservas y evita que reservas anteriores se ejecuten después de que cambie la época del dominio de control cubierto. Si el acceso al proveedor ocurrió primero, el intento sigue consumido y requiere conciliación. Restaurar la autoridad no reactiva una reserva antigua.

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

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 con un pago de muestra → Firma un pago ilustrativo de $82,000, cambia su importe y observa cómo falla la comprobación de integridad. Tu autenticador puede usar datos biométricos o el PIN de un dispositivo. La página también ofrece una simulación de software independiente. Ninguno de los dos modos envía un pago ni establece una autorización de producción.

Verifica cualquier recibo en tu navegador — pégalo; no se carga nada.

---

Cómo funciona: un ciclo de vida de autoridad

Pruébalo tú mismo: node examples/crash-test.mjs — completamente sin conexión, sin clave 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. La fuente de autoridad define el trabajo finito. Puede ser un programa operativo firmado por el cliente, una capacidad acotada, una decisión humana obligatoria, un quórum o una composición de pruebas nativas por parte de la parte dependiente.

Trabajo exacto. Gate vincula el método, el origen, el destinatario, el objetivo, la ocurrencia y todos los campos importantes al objeto ejecutable canónico. La intención, un prompt o el texto de un ticket no constituyen ese objeto.

Verificar, reservar y acceder. Los artefactos nativos siguen siendo nativos. La parte dependiente fija los perfiles de confianza y de mapeo, evalúa todos los requisitos de pruebas, toma la decisión independiente de autorización local y reserva la autoridad cubierta antes de que el adaptador que posee la credencial acceda al proveedor.

Autoridad humana reciente cuando se requiere. Una política puede exigir una decisión WebAuthn/passkey vinculada a la acción exacta y al hash de visualización determinista. Esto reduce la brecha entre «lo que viste es lo que firmaste»; no demuestra comprensión, sensatez, legalidad ni resultado. Para despliegues empresariales, Gate también puede exigir una confirmación del Authorization Server verificada de forma independiente y vinculada a esa evidencia humana exacta, a la misma acción exacta, a la instantánea de identidad que el AS observó realmente y a la clave del Resource Server previsto. La hora de la instantánea y la antigüedad máxima del relying party son explícitas: un token reciente no puede actualizar datos de directorio obsoletos. El tramo del AS es evidencia bajo la confianza fijada por el cliente; nunca autoriza por sí solo, demuestra que la relación laboral sigue vigente en ese instante ni convierte al orquestador del agente 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 siguen siendo independientes. Una respuesta perdida se convierte en INDETERMINATE, que es un estado que debe conciliarse, no un permiso para reintentar. Una reparación es una nueva acción autorizada y nunca reescribe el resultado anterior.

---

Por qué lo usan los desarrolladores

Empieza por mapear el trabajo localmente y luego protege una superficie de acción declarada con el servidor MCP o un contenedor SDK ligero. El escáner propone un mapa que se puede revisar; el propietario define el mandato; Gate controla la credencial del proveedor y aplica la acción exacta en la ruta cubierta. Ningún escaneo demuestra una 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 acotado, no una credencial permanente que pueda reinterpretar.

---

Por qué lo necesitan las empresas

Los procesos de los 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 persistir fuera de ellos. EMILIA mantiene ese estado de autoridad duradero en el límite del cliente y, a la vez, acepta pruebas externas mediante adaptadores fijados.

Gate y Assurance Plane gestionados añaden operaciones de mandato, integraciones, operaciones de evidencia, nueva ejecución, soporte y niveles de servicio en torno al protocolo abierto. El cliente conserva el control de la autoridad, las raíces de confianza, las credenciales, la política y la evidencia portable.

---

El estándar

EMILIA Protocol es abierto y está bajo Apache-2.0. Su trabajo de estandarización se publica como un conjunto de Internet-Drafts individuales. Un Internet-Draft publicado no es un RFC, un elemento adoptado por un grupo de trabajo ni un respaldo del IETF; Datatracker es la fuente autorizada para las revisiones y el estado.

Registros de IANA

Dos nombres registrados ofrecen a los implementadores una referencia común para los formatos de EMILIA:

• application/vnd.emilia.authorization-evidence-challenge+json se registró el 6 de octubre de 2026. Identifica el objeto JSON AE-CHALLENGE-v1 sin envoltorio, definido en la especificación de serialización publicada. Las respuestas HTTP de rechazo siguen usando application/problem+json.
• canactid: se registró provisionalmente el 5 de octubre de 2026. Designa acciones tipadas exactas según CAID-05. Su número de esquema CRI corregido es 1033.

Estos registros publican los nombres y sus especificaciones. No establecen adopción, respaldo, certificación ni despliegue por parte del IETF.

Una superficie en el límite de las consecuencias

La versión publicada actual de AEB-07, publicada el 2026-09-25 como Internet-Draft individual y no adoptada, establece AEB como punto de composición posterior a una decisión nativa. OAuth, AuthZEN, COAZ, AP2 y los sistemas locales conservan la titularidad de sus credenciales, asignaciones 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 repetición nativa por concesión, reserva antes de entrar al proveedor, rechaza un segundo intento de la misma acción mientras el anterior esté en curso o en estado incierto, y mantiene bloqueado un resultado incierto hasta que se concilie de forma autenticada.

CAID-05 se usa cuando es necesario comparar representaciones codificadas de forma independiente. Los identificadores nuevos usan el esquema URI canactid: registrado provisionalmente por IANA. El registro no implica adopción, respaldo, certificación ni estado permanente por parte del IETF. CAID no es una segunda asignación obligatoria cuando el PEP que controla las consecuencias ya deriva y aplica una decisión vigente sobre la operación final. Prueba el entorno interactivo de acciones exactas o consulta la guía de migración de CAID-04 a CAID-05. AEC-06 se usa cuando el relying party exige varios tramos de evidencia. Los perfiles de Authorization Receipts, Human Authorization Binding y Authority Introduction siguen disponibles para los despliegues que los necesiten; no son requisitos previos para todas las integraciones de AEB. Architecture-03 sigue siendo el documento de referencia para la navegación.

La guía de admisión de consecuencias establece el límite de implementación y los casos en los que AEB no es necesario. El perfil de transferencia nativa directa es un perfil de implementación del repositorio que muestra cómo un permiso existente llega a Gate sin una segunda capa CAID o AEC. AEB-07 especifica qué atestigua esa transferencia a la pasarela y cómo lo verifica el límite, pero deja la codificación a las fijaciones del despliegue; cita una instantánea fijada de este perfil como una codificación de referencia informativa. Los bytes exactos enviados para -07 y su registro de publicación se conservan en standards/staged/NEXT-AEB-07.

La cartera activa completa consta de 26 registros de Datatracker: 21 registros de autoría individual y cinco coescritos, cada uno con su propio alcance, historial de revisiones y estado de mantenimiento registrado. Consulta la guía de estándares, la cartera y el inventario de estado legible por máquina.

Internet-Drafts del IETF	Rutas de la instantánea local actual: inventario de estado · inventario de publicaciones de autoría individual · estado oficial en tiempo real: IETF Datatracker
Verificadores multilingües	JavaScript · Python · Go: los tres han demostrado concordar con vectores de conformidad adversariales en cada push (npm run conformance). Es una comprobación de coherencia entre las implementaciones de un mismo equipo, no implementaciones independientes desarrolladas desde cero. Por separado, una implementación de Rust escrita externamente a partir de la especificación (código fuente público) supera el conjunto fijado de 16 suites/164 vectores y la campaña de hostilidad fijada de 359 casos, en una reconstrucción controlada por el evaluador a partir de un árbol de fuentes inmutable. La evidencia de construcción incluida en el repositorio sigue estando firmada por el implementador, no atestiguada por terceros (declaración firmada); la aceptación estricta de una implementación independiente desde cero espera el manifiesto corregido y atestiguado por terceros, así como una clave de atestador fijada de forma independiente.
Evidencia de modelos formales	Se mantuvieron 26 propiedades de seguridad acotadas de TLA+ en sus espacios de estados configurados; esto no es un refinamiento de la implementación ni una prueba sin límites · 35 hechos de Alloy y 32 aserciones en cuatro modelos · dos modelos simbólicos compuestos de Dolev-Yao que cubren desafío, CAID, dos aprobaciones, fijaciones de emisor y autoridad, vista del registro, revocación, consumo, ejecución y seis límites de afirmaciones específicos. Se verifican veinte lemas de Tamarin: 17 obligaciones para todas las trazas y 3 testigos de trazas existentes; ocho variantes debilitadas deliberadamente producen trazas de ataque concretas al eliminar comprobaciones esenciales (formal/tamarin/).
Distribución de MCP	Paquete npm @emilia-protocol/mcp-server · la publicación oficial en Registry se registra por separado en MCP-REGISTRY.md; no se infieren listados en agregadores a partir de ninguno de esos estados
Licencia	Apache-2.0

Tres implementaciones de referencia del mismo equipo (JS / Python / Go) concuerdan en las 21 suites y los 340 vectores. Por separado, una implementación de Rust escrita externamente y reconstruida a partir de un árbol de fuentes público fijado supera el conjunto limpio fijado de 16 suites/164 vectores y una campaña de hostilidad de 359 casos, que se vuelve a ejecutar en su propio carril de CI con cada cambio. Las nuevas suites de aceptación de AEC y de resolución de cuatro resultados no se atribuyen a Rust. Esto constituye evidencia de interoperabilidad externa, no aceptación estricta de una construcción independiente desde cero; el registro agregado de CI indica cero casos de aceptación estricta a la espera de una atestación independiente. Consulta CONFORMANCE.md o verifica un recibo en emiliaprotocol.ai/verify.

---

La pila de autoridad

Capa	Función
Mandato	Define la misión, los límites, la evidencia, el vencimiento, la delegación y las 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 cotejada de forma independiente satisface el requisito de varios tramos del relying party; no autoriza.
AEB / Gate	Aplica la decisión de autorización nativa o local en el límite de las consecuencias, reserva la autoridad cubierta y controla la entrada al proveedor.
Evidencia del resultado	Mantiene diferenciados la invocación, la respuesta del proveedor, el efecto observado y la incertidumbre.

---

Puntos de prueba

Métrica	Valor
Casos de prueba automatizados	Más de 10.700 en más de 650 archivos; deben aprobarse todos los casos aplicables a la plataforma
Propiedades de seguridad de TLA+	Se mantuvieron 26 invariantes acotadas en el espacio de estados configurado; no es un refinamiento de la implementación ni una prueba sin límites; consulta 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 la versión	Las comprobaciones de seguridad del repositorio se superan; todos los hallazgos de Strix en los cambios auditados se han corregido con cobertura de regresión y sus hilos de revisión se han resuelto
Conformidad (7/7)	node conformance/ep-conformance-test.js https://www.emiliaprotocol.ai
Conformidad multilingüe	340 vectores · 21 suites: recibos · aprobaciones de dispositivos · resolución de cuatro resultados · cuórum multipartito · revocación · vinculación de resultados (semántica + criptografía real) · unión de emisor de Authority Document/Proof · atestación temporal · recibo de confianza (2 perfiles) · procedencia · registro de evidencia · canonicalización · límite · aceptación de AEC · moneda · atestación del iniciador · prueba de consumo · testigo · prueba de marca de tiempo (RFC 3161). Los verificadores JS / Python / Go concuerdan (node conformance/run.mjs). La referencia externa de Rust sigue en 164 vectores / 16 suites. Consulta CONFORMANCE.md.
p95 de creación del handshake	575 ms con 50 VUs — PERFORMANCE_PROOF.md

Longevidad criptográfica (con límites de despliegue explícitos)

La evidencia que debe poder verificarse años después tiene que perdurar más que los algoritmos con los que se firmó. EP ofrece cuatro capacidades acotadas para ello, cada una con un límite exacto que forma parte de la afirmació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, de modo que eliminar una parte invalida la firma restante. La capacidad es opcional en el despliegue; una vez registrado un firmante dual aprobado y si la política permite su parte PQ, una postura de Gate sin fijar resuelve por defecto a emisión dual. De lo contrario, se mantiene solo en modo clásico, con un motivo explícito. Los verificadores v1 rechazan correctamente los recibos híbridos en lugar de aceptar una sola parte. El contrato del firmante externo y el adaptador de AWS KMS están implementados, pero no se afirma que haya llamadas de firma reales a AWS, claves de producción, verificación por partes dependientes ni validación FIPS de ML-DSA. Consulta conformance/hybrid-receipts/ y lib/pq-custody-aws-kms.ts.
• Perfil de declaración firmada SCITT (EP-SCITT-STATEMENT-v1). Una estructura completa de declaración firmada RFC 9943 para recibos EP, incluido el encabezado protegido de CWT Claims. Límite: ningún servicio de transparencia ha aceptado una declaración EP; el registro externo es un paso independiente y sujeto a autorización, y no se ha realizado. Consulta EP-RECEIPT-SCITT-PROFILE.md.
• Reatestación (EP-EVIDENCE-REATTESTATION-v1). Las pruebas firmadas con un algoritmo que está quedando obsoleto pueden volver a anclarse con uno vigente antes de que el anterior se debilite. Límite: la reatestación debe preceder al compromiso; no puede reparar pruebas a posteriori.
• Modo de despliegue FIPS (EP-FIPS-MODE-v1). Ejecuta las operaciones clásicas mediante un proveedor validado según FIPS 140-3 suministrado por el operador, y condiciona la ruta ML-DSA a un reconocimiento explícito de que la implementación no está validada. Límite: esto permite afirmar «algoritmos basados en FIPS, con un modo de despliegue de proveedor validado» y depende del proveedor del operador y de los límites del certificado declarados; no es una afirmación general de cumplimiento, y nada de lo aquí descrito está validado por FIPS. Consulta FIPS-MODE.md.

El programa híbrido de toda la pila (todas las superficies de firma internas) está descrito en pq-hybrid-program.md y no está completo; hasta que lo esté, no se hace ninguna afirmación general sobre toda la pila.

---

Objetos centrales del protocolo

Objeto	Qué es
Programa de autoridad / capacidad acotada	Un mandato finito con alcance, presupuesto o unidades, vencimiento, delegación y reglas de consumo explícitos.
CAID	Un identificador canónico para una acción material según un perfil de mapeo determinado; la coincidencia no es autorización.
Requisito de pruebas y resultado AEC	La regla fijada por la parte dependiente y su evaluación SATISFIED, UNSATISFIED o INDETERMINATE.
Admisión AEB y registro de custodia	El registro del lado del ejecutor de la autorización, la reserva, la entrada del proveedor y el estado de conciliación.
Pruebas de autorización y resultado	Artefactos nativos o EP portátiles que conservan exactamente su emisor, alcance y límites de las afirmaciones.

---

Inicio rápido

1. Instala el entorno de ejecución de protección local exacto y luego ejecuta npx @emilia-protocol/scan@0.6.0 protect ./tools.json --action sendWire --apply --verify, sustituyendo sendWire por una herramienta consecuente declarada exacta.
2. Revisa el mapa de autoridad generado, el manifiesto de acciones, los campos materiales, el límite seleccionado y los puntos ciegos identificados.
3. Ejecuta el comando independiente --reviewed --crossing-profile <launch-profile> para crear, a partir de esos mismos bytes sin modificar, la transferencia de acceso exclusivo del propietario y el espacio de trabajo Lab sin sellar.
4. Instala Gate en la ruta que controla la credencial del proveedor y el estado de consumo duradero.
5. Define el mandato operativo y las reglas de excepción que requieran una persona presente o un quórum.
6. Ejecuta los casos de rechazo, acción exacta, repetición, tiempo de espera y conciliación antes de habilitar la aplicación de controles.

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

---

Qué es EMILIA y qué no es

EMILIA es infraestructura de autoridad para el trabajo autónomo, no un sistema de identidad, una cartera, una puntuación de reputación, una vía de liquidación ni un motor de políticas universal.

• Es: un plano de control para mandatos operativos finitos, verificación de acciones exactas, estado de admisión duradero, incertidumbre expresada con veracidad y pruebas portátiles en las rutas de ejecución cubiertas.
• No es: un sustituto de OAuth/OIDC, la identidad de cargas de trabajo ni los motores de políticas. Estos siguen siendo entradas nativas según las fijaciones de la parte dependiente.
• No es: un requisito de que una persona apruebe cada acción. Un mandato puede permitir trabajo automático dentro de límites finitos y exigir autoridad renovada solo al llegar al límite.
• No es: una prueba de que una acción admitida se ejecutó correctamente o produjo el efecto previsto.
• No es: control propietario del protocolo. El núcleo está bajo Apache-2.0 y los Internet-Drafts son propuestas individuales, no RFC ni avales del IETF.

Consulta CONFORMANCE.md · SECURITY.md · THREAT_MODEL.md · GOVERNANCE.md · Pacto de neutralidad