EMILIA Protocol

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

841

¿Qué puedes hacer con EMILIA Protocol MCP?

Escanea las superficies de herramientas declaradas — Ejecuta npx @emilia-protocol/scan protect ./tools.json para mapear las acciones admitidas y revisa el manifiesto generado antes de proteger un flujo de trabajo.
Emite recibos sin conexión — Usa npx @emilia-protocol/issue demo para generar un Recibo de Confianza localmente sin necesidad de clave API ni backend.
Verifica recibos en el navegador — Pega cualquier recibo en emiliaprotocol.ai/verify para comprobar su autenticidad sin conexión; no se sube nada.
Ejecuta pruebas de conformidad AEB-1 — Ejecuta npx @emilia-protocol/verify aeb-conformance --reference para probar el límite de evidencia-a-efecto con verificación nativa y comportamiento sin reintentos ciegos.
Protege herramientas MCP con Gate — Envuelve herramientas como release_payment o delete_repo para que rechacen la ejecución sin un recibo válido, como se muestra en los ejemplos MCP incluidos.
Añade EMILIA a Claude/Cursor/Cline — Ejecuta npx -y @emilia-protocol/mcp-server para integrar el plano de control de autoridad en tu asistente de IA.

Documentación

EMILIA Protocol

Los agentes de IA se están convirtiendo en trabajadores. Los trabajadores necesitan autoridad.

EMILIA es el plano de control de autoridad para el trabajo autónomo. Gate es el límite de consecuencias donde la intención acreditada de un agente se convierte en un cambio sobre dinero, código, permisos, registros o infraestructura. Un humano o una institución define un mandato operativo finito; Gate verifica la unidad exacta de trabajo contra ese mandato antes de que comience la ruta del proveedor protegido.

Gate es el Cortafuegos de Consecuencias comercial en ese límite. Verifica la autoridad que el propietario exige para la acción exacta, reserva esa autoridad antes de la entrada al proveedor, permite un único intento de proveedor admitido para la instancia de autorización cubierta dentro de su dominio de autoridad duradero, y deja evidencia portable de lo que la ruta protegida admitió y posteriormente observó. Cuando el resultado es desconocido, exige conciliación en lugar de una reintroducción ciega. El Protocolo demuestra. Gate previene.

Authority Brain mapea localmente las superficies de acción declaradas soportadas. No se requiere cuenta, carga ni callback. El descubrimiento no crea autoridad; el propietario revisa el mapa.
EMILIA Gate convierte el mapa aprobado y el mandato operativo en control preventivo sobre una ruta de ejecutor totalmente mediada y propietaria de credenciales.
EMILIA Protocol es el sustrato abierto Apache-2.0 para identidad de acción exacta, verificación nativa de evidencia, composición de evidencia, estado de admisión duradero y registros de trabajo portables.
EMILIA Approver captura una decisión humana de acción exacta vinculada al dispositivo cuando el mandato o la política local exige autoridad humana fresca. Un clic humano es una fuente de autoridad, no el modelo de ejecución por defecto.
EMILIA Assurance Plane proporciona verificación acotada, re-ejecución, informes de conformidad y evidencia de despliegue. Apoya a auditores, aseguradoras, reguladores y clientes; EMILIA no es un auditor ni un certificador acreditado, y no opera ningún programa público de certificación EMILIA.

Ejecuta el mapa local (npx @emilia-protocol/scan), elige un flujo de trabajo con consecuencias y coloca Gate donde la credencial del proveedor convierte la intención en trabajo.

El primer perfil de distribución de baja fricción es GitHub: el Merge Gate abierto vincula un mandato propiedad del repositorio y un recibo desacoplado a los commits base y head exactos antes de que pase una verificación de merge protegida. Es preventivo solo cuando el repositorio hace que la verificación sea obligatoria y cierra rutas de merge alternativas. Esto es un experimento de producto y distribución, no evidencia de adopción externa.

El agente puede seguir ejecutándose. Su autoridad se detiene.

Los agentes continuos y auto-mejorantes crean un problema de control que la terminación del proceso por sí sola no puede resolver: el propietario puede necesitar detener nuevas consecuencias sin afirmar que el cómputo se detuvo o que un efecto externo fue revertido. El Congelamiento de Autoridad de Emergencia de Gate convierte esto en una transición de autoridad duradera. Dentro de un dominio de control de Gate cubierto, el congelamiento bloquea nuevas reservas y evita que una reserva anterior entre después de que cambie la época de control. Si la entrada al proveedor se serializó primero, la operación permanece consumida y debe conciliarse; la restauración avanza la época nuevamente y no revive autoridad antigua.

Esta garantía requiere mediación completa y estado compartido autoritativo. No detiene al agente, no deshace un efecto ya ingresado, ni proporciona congelamiento instantáneo a través de un dominio arrendado desconectado. La implementación de referencia actual cubre el dominio de control local en memoria y PostgreSQL; la propagación de borde arrendado y la evidencia portable de eventos de congelamiento firmados siguen siendo brechas de implementación explícitas.

El flujo de trabajo pagado nominado sigue siendo la determinación adversa de necesidad médica asistida por IA del pagador, bajo una regla de seguridad: sin evidencia válida de revisión licenciada, no hay determinación adversa. La evidencia faltante se deriva a revisión humana legal o a una alternativa protectora del paciente; no es autoridad para retener atención médicamente necesaria.

Los sistemas de IA y revisores de repositorios: comiencen 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 etapa de preparación no establecen el estado actual de implementación o el estado IETF. Evidencia pública de diligencia debida y límites de reclamos: 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 reclamos de seguridad sobre 259 archivos de evidencia con hash, verifica 20 lemas de Tamarin en dos modelos compuestos 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 vivo del mismo equipo contiene 21 suites y 331 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 8,865 pruebas automatizadas en 533 archivos.

Las superficies de JavaScript y JSDoc de producción se verifican con el compilador de 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 fue convertido por completo de JavaScript a TypeScript o de que cada proyecto JavaScript tenga la opción strict de TypeScript habilitada.

Cada reclamo 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 AEB-1 Conformance de Admisión de Consecuencias prueba el último punto de control antes de una acción con consecuencias: verificación nativa, aceptación por parte del parte confiada, coincidencia exacta de CAID/acción, satisfacción de evidencia, autorización local, reserva atómica, custodia INVOKING, verdad separada de resultado del proveedor y efecto observado, comportamiento de no-reintentar-a-ciegas y conciliación autenticada.

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

Es neutral en cuanto al formato y se ejecuta de forma autónoma. Un informe aprobado es evidencia de conformidad auto-atestiguada—no una auditoría, certificación, reclamo de despliegue en producción o permiso para ejecutar una acción.

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, un banco externo, un despliegue en producción o una integración de extremo a extremo en producción.

La identidad no es una descripción de trabajo

La identidad dice quién o qué está llamando. La política dice qué está generalmente permitido. Ninguna define el trabajo finito que un trabajador autónomo puede realizar ahora: su misión, límites de acción material, presupuesto, evidencia requerida, expiración, 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á generalmente permitido?
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 con consecuencias necesita autoridad válida.

En la base, EP Core aún expone tres objetos interoperables: un Trust Receipt lleva evidencia atribuible, un Trust Profile representa estado de confianza estructurado y un Trust Decision registra el resultado evaluado por política del parte confiada. Las capas del plano de control de autoridad añaden vinculación de acción exacta, mandatos finitos, admisión, consumo y evidencia de resultado sin colapsar esos objetos en un único reclamo.

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

El cliente define la misión, los límites, los requisitos de evidencia, la expiración y las reglas de excepción. El código local puede estrechar 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 único intento de proveedor admitido para esa instancia de autorización dentro del dominio de autoridad duradero compartido, y escala únicamente cuando la autoridad falta, está obsoleta, agotada o es demasiado estrecha.

Los ejemplos MCP incluidos demuestran un perfil de política en el que se requiere una decisión humana fresca en el borde. Ejecutan el bucle local completo—evidencia faltante rechazada, acción exacta firmada, un intento de proveedor admitido, evidencia falsificada rechazada—sin afirmar que toda acción autónoma necesita un clic humano:

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 demo de composición más profunda ejecuta un pago delegado vinculado a CAID a través de la ruta real de capacidad acotada de Gate, y luego verifica el certificado de ejecución firmado fuera de línea:

npm run demo:receipt-program

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

Comienza con una ejecución en seco contra tu superficie de herramientas declarada y luego genera los archivos de integración revisables:

npx @emilia-protocol/scan protect ./tools.json
npx @emilia-protocol/scan protect ./tools.json --apply
node emilia/verify-setup.mjs

La verificación local generada utiliza estado de demo explícitamente efímero y prueba solo que su manejador sintético no fue llamado. La producción requiere un libro de procedencia duradero, un almacén de consumo atómico compartido, claves fijadas y el wrapper en cada ruta hacia la credencial real del proveedor. Consulta examples/mcp/ y /mcp.

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 aprobación real con Face ID → Aprueba una transferencia de $82,000 con tu propia passkey. Observa cómo se ve VERIFIED. Falsifica el recibo. Obsérvalo fallar.

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

Cómo funciona: un ciclo de vida de autoridad

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.

Ejecútalo tú mismo: node examples/crash-test.mjs — completamente fuera de línea, 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, capacidad acotada, decisión humana requerida, quórum o una composición del 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 es ese objeto.

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

Autoridad humana fresca 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 de "lo que viste es lo que firmaste"; no prueba comprensión, sabiduría, legalidad o resultado.

Para despliegues empresariales, Gate puede adicionalmente requerir una confirmación del Servidor de Autorización verificada 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 Resource Server prevista. El tiempo de la instantánea y la antigüedad máxima del parte confiada son explícitos: un token fresco no puede hacer que los datos de directorio obsoletos sean actuales. La etapa del AS es evidencia bajo confianza fijada por el cliente; nunca autoriza por sí misma, no prueba posición laboral instantánea 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 del observador permanecen separadas. Una respuesta perdida se convierte en INDETERMINATE, que es un estado a conciliar, no un permiso para reintentar. Un remedio es una nueva acción autorizada y nunca reescribe el resultado anterior.

Por qué lo usan los desarrolladores

Comience mapeando el trabajo localmente y luego proteja una superficie de acción declarada con el servidor MCP o el envoltorio SDK ligero. 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 demuestra 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 sobrevivir fuera de ellos. EMILIA mantiene ese estado de autoridad duradero en el límite del cliente mientras acepta pruebas externas mediante adaptadores fijados.

El Gate gestionado y el Assurance Plane 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, las políticas y la evidencia portable.

El estándar

EMILIA Protocol es abierto y Apache-2.0. Su trabajo de estándares se publica como un portafolio de Internet-Drafts individuales. Un Internet-Draft publicado no es un RFC, un elemento adoptado por un grupo de trabajo ni un respaldo de la IETF; Datatracker es la autoridad en cuanto a revisión y estado.

Superficie de presentación canónica de cuatro documentos

Para la navegación del lector, la ruta canónica de evidencia es:

Authorization Receipts-11 define el perfil de evidencia de aprobación vinculada a la acción. La revisión publicada actual es la -11, presentada como envío individual candidato a Standards Track.
Human Authorization Binding-00 vincula un artefacto de autorización de humano nombrado en un registro de host adyacente.
Authority Introduction-03 establece raíces de confianza fijadas por la parte que confía y autoridad con alcance.
Authorization Evidence Chain-05 evalúa si la evidencia verificada de forma nativa y coincidente con la acción satisface el requisito de la parte que confía; devuelve SATISFIED o UNSATISFIED, nunca AUTHORIZED.

Esta superficie de cuatro documentos es solo de presentación. No fusiona, retira, reemplaza, actualiza, obsoleta, subordina ni degrada ningún borrador del portafolio activo.

Espina de ejecución en tiempo de ejecución separada

La ruta en tiempo de ejecución es Architecture-02 → CAID-02 → AEC-05 → AEB-03: límites del sistema, coincidencia exacta de la acción material, satisfacción de la evidencia, y luego admisión del lado del ejecutor y custodia duradera de las consecuencias. AEC aparece en ambas vistas porque la satisfacción de la evidencia alimenta la admisión en tiempo de ejecución, no porque las vistas sean equivalentes.

El portafolio activo completo sigue siendo 23 registros de Datatracker: 20 registros activos draft-schrock-* y tres registros coautorados, cada uno con su propio alcance e historial de revisiones. Consulte la guía de estándares, el portafolio y el inventario de estado legible por máquina.


IETF Internet-Drafts	Instantáneas locales actuales: inventario publicado · estado en vivo autoritativo: IETF Datatracker
Verificadores entre lenguajes	JavaScript · Python · Go — los tres demostrados para coincidir en vectores de conformidad adversariales, en cada push (`npm run conformance`). Una verificación de consistencia entre los ports de un mismo equipo, no implementaciones independientes de sala limpia. Por separado, una implementación Rust de especificación escrita externamente (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 registrada sigue 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 Alloy, 32 aserciones en cuatro modelos · dos modelos simbólicos compuestos Dolev-Yao que cubren desafío, CAID, dos aprobaciones, fijaciones de emisor y autoridad, vista de registro, revocación, consumo, ejecución y seis límites de reclamación dedicados. Veinte lemas Tamarin se 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 verificaciones estructurales (formal/tamarin/).
Registros MCP	Registro MCP oficial · Glama (Grado A, insignia oficial) · Smithery
Licencia	Apache-2.0

Tres ports de referencia del mismo equipo (JS / Python / Go) coinciden en las 21 suites y 331 vectores. Por separado, una implementación Rust escrita externamente reconstruida desde un árbol fuente público fijado pasa el paquete de sala limpia fijado 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 externa de interoperabilidad, no aceptación estricta de construcción en sala limpia; el caso agregado de CI registra el recuento de aceptación estricta como cero a la espera de atestación independiente. Consulte CONFORMANCE.md, o verifique un recibo usted mismo en emiliaprotocol.ai/verify.

La pila de autoridad

Capa	Qué hace
Mandate	Define misión, límites, evidencia, caducidad, delegación y reglas de excepción.
CAID / acción exacta	Congela el objeto ejecutable material para que la evidencia no pueda moverse a un trabajo diferente.
AEC	Evalúa si la evidencia verificada de forma independiente y coincidente satisface el requisito de la parte que confía; no autoriza.
AEB / Gate	Toma la decisión de autorización local, reserva la autoridad cubierta y controla la entrada del proveedor.
Evidencia de resultado	Mantiene la invocación, la respuesta del proveedor, el efecto observado y la incertidumbre como elementos distintos.

Puntos de prueba

Métrica	Valor
Casos de prueba automatizados	8,865 en 533 archivos; todos los casos aplicables a la plataforma deben pasar
Propiedades de seguridad TLA+	26 invariantes acotados mantenidos en el espacio de estado configurado; no es una prueba de refinamiento de implementación ni no acotada — consulte PROOF_STATUS.md
Aserciones relacionales Alloy	35 hechos + 32 aserciones en cuatro modelos — verificadas en CI
Casos de red team catalogados	85 — RED_TEAM_CASES.md
Estado de seguridad de la versión	Las verificaciones 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 se resuelve
Conformidad (7/7)	`node conformance/ep-conformance-test.js https://www.emiliaprotocol.ai`
Conformidad entre lenguajes	331 vectores · 21 suites: recibos · firmas de dispositivo · resolución de cuatro resultados · quórum multiparte · revocación · Outcome Binding (semántico + criptografía real) · unión de emisor de Authority Document/Proof · atestación de tiempo · trust-receipt (x2 perfiles) · procedencia · registro de evidencia · canonicalización · límite · aceptación AEC · moneda · atestación del 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 sigue siendo 164 vectores / 16 suites. Consulte CONFORMANCE.md.
Creación de handshake p95	575ms a 50 VUs — PERFORMANCE_PROOF.md

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 AEC	La regla fijada de la parte que confía y su evaluación `SATISFIED`, `UNSATISFIED` o `INDETERMINATE`.
Registro de admisión y custodia AEB	El registro del lado del ejecutor de autorización, reserva, entrada del proveedor y estado de conciliación.
Evidencia de autorización y resultado	Artefactos portables nativos o EP que conservan su emisor exacto, alcance y límite de reclamación.

Inicio rápido

Ejecute npx @emilia-protocol/scan protect ./tools.json para mapear las superficies declaradas compatibles.
Revise el manifiesto de acciones generado, los campos materiales, las credenciales y los puntos ciegos nombrados.
Instale Gate en la ruta que posee la credencial del proveedor y el estado de consumo duradero.
Defina el mandato operativo y cualquier regla de excepción de humano fresco o quórum.
Ejecute los casos de rechazo, acción exacta, reproducción, tiempo de espera y conciliación antes de habilitar la aplicación.

Demo de 90 segundos · Inicio rápido · Recorrido del agente · IETF Draft · Discord

Qué es EP — y qué no es

EMILIA es infraestructura de autoridad para trabajo autónomo, no un sistema de identidad, billetera, puntuación de reputación, vía de liquidación ni 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 portable en rutas de ejecutor cubiertas.
No es: un reemplazo para OAuth/OIDC, identidad de carga de trabajo o motores de políticas. Esos siguen siendo entradas nativas bajo las fijaciones 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 la IETF.

Consulte CONFORMANCE.md · SECURITY.md · THREAT_MODEL.md · GOVERNANCE.md · Neutrality Covenant