EMILIA Protocol

Протокол EMILIA

---

ИИ-агенты становятся работниками. Работникам нужны полномочия.

EMILIA — это плоскость управления полномочиями для автономной работы. Gate — это граница последствий, где подтверждённое учётными данными намерение агента превращается в изменение денег, кода, разрешений, записей или инфраструктуры. Человек или организация определяет конечный операционный мандат; Gate проверяет точную единицу работы на соответствие мандату до того, как защищённый путь провайдера сможет начаться.

Gate — это коммерческий брандмауэр последствий на этой границе. Он проверяет полномочия, которые владелец требует для точного действия, резервирует эти полномочия до входа провайдера, разрешает одну допущенную попытку провайдера для покрываемого экземпляра авторизации в пределах своего долговечного домена полномочий и оставляет переносимое доказательство того, что защищённый путь допустил и впоследствии наблюдал. Когда результат неизвестен, он требует сверки вместо слепого повтора. Протокол доказывает. Gate предотвращает.

• Authority Brain сопоставляет поддерживаемые декларируемые поверхности действий локально. Никакая учётная запись, загрузка или обратный вызов не требуются. Обнаружение не создаёт полномочий; владелец просматривает карту.
• EMILIA Gate превращает утверждённую карту и операционный мандат в превентивный контроль на полностью опосредованном пути исполнения, владеющем учётными данными.
• Протокол EMILIA — это открытая базовая основа Apache-2.0 для идентичности точного действия, нативной проверки доказательств, композиции доказательств, долговечного состояния допуска и переносимых записей о работе.
• EMILIA Approver фиксирует привязанное к устройству человеческое решение о точном действии, когда мандат или локальная политика требуют свежих человеческих полномочий. Человеческий клик — это один источник полномочий, а не модель исполнения по умолчанию.
• EMILIA Assurance Plane предоставляет ограниченную проверку, повторное исполнение, отчёты о соответствии и доказательства развёртывания. Он поддерживает аудиторов, страховщиков, регуляторов и клиентов; EMILIA не является аудитором или аккредитованным сертификатором, и никакая публичная программа сертификации EMILIA не действует.

Запустите локальную карту (npx @emilia-protocol/scan), выберите один критически важный рабочий процесс и разместите Gate там, где учётные данные провайдера превращают намерение в работу.

Первый профиль распространения с низким порогом входа — GitHub: открытый Merge Gate связывает мандат, принадлежащий репозиторию, и откреплённую квитанцию с точными базовым и головным коммитами до того, как защищённая проверка слияния пройдёт. Это превентивно только тогда, когда репозиторий делает проверку обязательной и закрывает альтернативные пути слияния. Это эксперимент с продуктом и распространением, а не свидетельство внешнего внедрения.

Агент может продолжать работать. Его полномочия останавливаются.

Непрерывные и самосовершенствующиеся агенты создают проблему контроля, которую одно лишь завершение процесса решить не может: владельцу может потребоваться остановить новые последствия, не утверждая, что вычисления остановились или что внешний эффект был отменён. Аварийная заморозка полномочий Gate превращает это в долговечный переход полномочий. Внутри покрываемого домена контроля Gate заморозка блокирует новые резервирования и предотвращает попадание более старого резервирования после смены эпохи контроля. Если вход провайдера сериализовался первым, операция остаётся потреблённой и должна быть сверена; восстановление снова продвигает эпоху и не возрождает старые полномочия.

Эта гарантия требует полного опосредования и авторитетного общего состояния. Она не останавливает агента, не отменяет вошедший в силу эффект и не обеспечивает мгновенную заморозку в отключённом арендованном домене. Текущая эталонная реализация покрывает локальный домен контроля в памяти и PostgreSQL; распространение на арендованном крае и переносимые подписанные доказательства событий заморозки остаются явными пробелами реализации.

Именованный платный рабочий процесс остаётся определением медицинской необходимости при неблагоприятном исходе с помощью ИИ-плательщика при одном правиле безопасности: нет действительного лицензированного доказательства проверки — нет неблагоприятного определения. Отсутствующие доказательства направляются на законную проверку человеком или на защитный запасной вариант для пациента; это не полномочия удерживать необходимое с медицинской точки зрения лечение.

ИИ-системы и рецензенты репозитория: начните с AI_CONTEXT.md. Текущие машиночитаемые доказательства, происхождение, допущения и исключения опубликованы в EMILIA-REPO-CONTEXT-v1. Архивные или промежуточные документы не устанавливают текущий статус реализации или статус IETF. Публичные доказательства должной осмотрительности и границы заявлений: DUE_DILIGENCE.md.

Инженерные доказательства, а не архитектурные заявления

EMILIA поставляет кейс безопасности, который рецензенты могут выполнить. Текущий репозиторий разрешает 35 заявлений безопасности на 259 хэшированных файлах доказательств, проверяет 20 лемм Tamarin в двух составных моделях Dolev-Yao — 17 обязательств all-traces и 3 свидетеля достижимости exists-trace — и сохраняет 8 намеренно ослабленных вариантов, которые дают конкретные трассы атак при удалении ключевых проверок. Живой корпус соответствия той же команды содержит 21 набор и 331 текущий вектор. Отдельно внешне написанный Rust-верификатор закреплён за замороженным набором 16 наборов/164 векторов и кампанией враждебности из 359 случаев. Более широкий набор содержит 8 865 автоматизированных тестов в 533 файлах.

Продакшн-поверхности JavaScript и JSDoc проверяются компилятором TypeScript checkJs; защищённое приложение имеет собственный проект совместимого компилятора, а объявления и публичный TypeScript SDK проверяются в строгом режиме. Это полное настроенное покрытие проверки типов продакшена, а не заявление о том, что репозиторий был целиком конвертирован из JavaScript в TypeScript или что каждый JavaScript-проект имеет включённую опцию TypeScript strict.

Каждое заявление безопасности называет путь обеспечения, положительные и отрицательные векторы, языковое покрытие, формальную область или явный пробел, допущения, исключения и хэш доказательства. Начните с карты доказательств, читаемой человеком, затем изучите разрешённый кейс безопасности или запустите npm run check:security-case.

AEB-1: проверьте границу доказательство-эффект

Открытый Conformance-набор допуска последствий AEB-1 проверяет последнюю точку контроля перед критически важным действием: нативную проверку, принятие полагающейся стороной, точное сопоставление CAID/действия, удовлетворение доказательств, локальную авторизацию, атомарное резервирование, хранение INVOKING, раздельную истину исхода провайдера и наблюдаемого эффекта, поведение без слепого повтора и аутентифицированную сверку.

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

Он нейтрален к формату и запускается самостоятельно. Проходящий отчёт — это самостоятельно подтверждённое доказательство соответствия, а не аудит, сертификация, заявление о продакшен-развёртывании или разрешение на выполнение действия.

Для сфокусированного исполняемого доказательства пути Gate репозитория запустите:

npm run proof:gate:reference

Эта команда выполняет локальные примеры и сфокусированные границы сервисов с сгенерированными ключами, состоянием в памяти и фиктивным поведением провайдера. Это полезное локальное доказательство, а не свидетельство реального человека, внешнего банка, продакшен-развёртывания или одной сквозной продакшен-интеграции.

Идентичность — это не должностная инструкция

Идентичность говорит, кто или что вызывает. Политика говорит, что вообще разрешено. Ни то, ни другое не определяет конечную работу, которую автономный работник может выполнять сейчас: его миссию, пределы материальных действий, бюджет, требуемые доказательства, срок действия, правила делегирования и путь исключений.

EMILIA разделяет эти вопросы:

Уровень	Вопрос
Идентичность	Кто или что присутствует?
Политика	Что вообще разрешено?
Полномочия	Какую точную работу может выполнять этот агент в рамках этого мандата?

Учётные данные предоставляют доступ. Полномочия определяют работу. Не каждое действие требует человека; каждое критически важное действие требует действительных полномочий.

В основе EP Core по-прежнему предоставляет три совместимых объекта: Trust Receipt несёт атрибутируемое доказательство, Trust Profile представляет структурированное состояние доверия, а Trust Decision фиксирует результат, оценённый политикой полагающейся стороны. Слои плоскости управления полномочиями добавляют привязку точного действия, конечные мандаты, допуск, потребление и доказательства исхода, не сводя эти объекты к одному заявлению.

---

Установите мандат один раз. Позвольте агенту работать.

Клиент определяет миссию, пределы, требования к доказательствам, срок действия и правила исключений. Локальный код может сузить эти полномочия; он не может их выдумать или расширить. Gate привязывает каждый исполняемый запрос к мандату, резервирует покрываемые полномочия до входа провайдера, разрешает одну допущенную попытку провайдера для этого экземпляра авторизации внутри общего долговечного домена полномочий и повышает уровень только когда полномочия отсутствуют, устарели, исчерпаны или слишком узки.

Встроенные примеры MCP демонстрируют один профиль политики, в котором свежее человеческое решение требуется на границе. Они выполняют полный локальный цикл — отсутствующее доказательство отклонено, точное действие подписано, одна попытка провайдера допущена, поддельное доказательство отклонено — без заявления о том, что каждое автономное действие требует человеческого клика:

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

Более глубокая демонстрация композиции выполняет делегированный платёж, привязанный к CAID, через реальный путь ограниченных возможностей Gate, а затем проверяет подписанный сертификат исполнения офлайн:

npm run demo:receipt-program

Она намеренно не включает блокчейн или имитацию доказательства с нулевым разглашением. См. архитектуру программы квитанций для продакшен-состояния и требований доверия.

Начните с пробного запуска по вашей объявленной поверхности инструментов, затем создайте проверяемые файлы интеграции:

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

Сгенерированная локальная проверка использует явно эфемерное демонстрационное состояние и доказывает только то, что её синтетический обработчик не был вызван. Продакшен требует долговечного реестра происхождения, общего атомарного хранилища потребления, закреплённых ключей и обёртки на каждом пути к реальным учётным данным провайдера. См. examples/mcp/ и /mcp.

Попробуйте за 30 секунд

# 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

Попробуйте реальное подтверждение Face ID → Подтвердите перевод на 82 000 долларов своим собственным passkey. Посмотрите, как выглядит VERIFIED. Подделайте квитанцию. Посмотрите, как она отклоняется.

Проверьте любую квитанцию в своём браузере — вставьте её, ничего не загружается.

---

Как это работает — один жизненный цикл полномочий

Запустите сами: node examples/crash-test.mjs — полностью офлайн, без 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

Мандат. Источник полномочий определяет конечную работу. Это может быть операционная программа, подписанная клиентом, ограниченная возможность, требуемое человеческое решение, кворум или композиция полагающейся стороной нативных доказательств.

Точная работа. Gate связывает метод, происхождение, вызываемый объект, цель, вхождение и каждое материальное поле в канонический исполняемый объект. Намерение, подсказка или текст заявки не являются этим объектом.

Проверьте, зарезервируйте и войдите. Нативные артефакты остаются нативными. Полагающаяся сторона закрепляет профили доверия и сопоставления, оценивает полное требование доказательств, принимает отдельное решение локальной авторизации и резервирует покрываемые полномочия до того, как адаптер, владеющий учётными данными, войдёт к провайдеру.

Свежие человеческие полномочия, когда требуется. Политика может требовать решение WebAuthn/passkey, привязанное к точному действию и детерминированному хэшу отображения. Это сужает разрыв «что вы видели, то вы и подписали»; это не доказывает понимание, мудрость, законность или исход.

Для корпоративных развёртываний Gate может дополнительно требовать независимо проверенное подтверждение Authorization Server, привязанное к этому точному человеческому доказательству, тому же точному действию, снимку идентичности, который AS фактически наблюдал, и предполагаемому ключу Resource Server. Время снимка и максимальный возраст полагающейся стороны явны: свежий токен не может сделать устаревшие данные каталога актуальными. Сегмент AS является доказательством в рамках доверия, закреплённого клиентом; он никогда не авторизует сам по себе, не доказывает мгновенный статус трудоустройства и не превращает оркестратор агента в источник полномочий. Правдивый результат. Допуск не является исполнением, а исполнение — эффектом. Подписанная запись может быть
проверена офлайн; доказательства поставщика и наблюдателя остаются раздельными. Потерянный ответ становится
INDETERMINATE, что является состоянием для согласования, а не разрешением на повтор. Исправление — это новое авторизованное
действие и никогда не переписывает старый результат.

---

Зачем это используют разработчики

Начните с локального сопоставления работы, затем защитите одну заявленную поверхность действий с помощью MCP-сервера или
тонкой обёртки SDK. Сканер предлагает проверяемую карту; владелец определяет мандат; Gate владеет
учётными данными поставщика и обеспечивает точное действие на покрытом пути. Ни одно сканирование не доказывает полное
посредничество, а одно только обнаружение не даёт полномочий.

# 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

Агент получает возможность выполнять ограниченную работу, а не постоянные учётные данные, которые он может переосмыслить.

---

Зачем это нужно предприятиям

Процессы агентов перезапускаются, а модели меняются. Мандат клиента, состояние потребления, отзыв,
неопределённость и история работы должны сохраняться вне их. EMILIA сохраняет это долговечное состояние полномочий на
границе клиента, принимая внешние доказательства через закреплённые адаптеры.

Управляемые Gate и Assurance Plane добавляют операции с мандатами, интеграции, операции с доказательствами,
повторное исполнение, поддержку и уровни обслуживания вокруг открытого протокола. Клиент сохраняет контроль
над полномочиями, корнями доверия, учётными данными, политикой и переносимыми доказательствами.

---

Стандарт

Протокол EMILIA открыт и доступен по лицензии Apache-2.0. Его работа по стандартизации публикуется как
портфолио отдельных Internet-Draft. Опубликованный Internet-Draft не является
RFC, принятым элементом рабочей группы или одобрением IETF; Datatracker является
авторитетным источником для ревизий и статуса.

Каноническая поверхность представления из четырёх документов

Для навигации читателя канонический путь доказательства выглядит так:

1. Authorization Receipts-11
   определяет профиль доказательств одобрения, привязанных к действию. Текущая опубликованная
   ревизия — -11, поданная как индивидуальная подача кандидата на трек Standards Track.
2. Human Authorization Binding-00
   привязывает артефакт авторизации именованного человека к соседней записи хоста.
3. Authority Introduction-03
   устанавливает корни доверия, закреплённые за полагающейся стороной, и ограниченные полномочия.
4. Authorization Evidence Chain-05
   оценивает, удовлетворяют ли нативно проверенные доказательства, соответствующие действию, требованию
   полагающейся стороны; он возвращает SATISFIED или UNSATISFIED, никогда
   AUTHORIZED.

Эта поверхность из четырёх документов предназначена только для представления. Она не объединяет, не выводит,
не заменяет, не обновляет, не устаревает, не подчиняет и не понижает ни один черновик в активном
портфолио.

Отдельный исполнительный хребет времени выполнения

Путь времени выполнения: Architecture-02
→ CAID-02
→ AEC-05
→ AEB-03:
границы системы, точное сопоставление материальных действий, удовлетворение доказательств, затем
допуск на стороне исполнителя и долговременное хранение последствий. AEC появляется в обоих
представлениях, потому что удовлетворение доказательств питает допуск времени выполнения, а не потому, что
представления эквивалентны.

Полное активное портфолио остаётся 23 записями Datatracker: 20 активных
draft-schrock-* записей и три соавторские записи, каждая со своей областью
и историей ревизий. См. руководство по стандартам,
портфолио и машиночитаемую
инвентаризацию статусов.

IETF Internet-Drafts	Текущие локальные снимки: опубликованная инвентаризация · авторитетный живой статус: IETF Datatracker
Кросс-языковые верификаторы	JavaScript · Python · Go — все три доказанно согласуются на состязательных векторах конформности при каждом пушe (npm run conformance). Проверка согласованности между портами одной команды, а не независимые реализации в чистой комнате. Отдельно реализация Rust на основе спецификации, созданная внешним автором, (исходный код публичен) проходит закреплённый набор из 16 пакетов/164 векторов и закреплённую кампанию враждебности из 359 случаев при пересборке, контролируемой оценщиком, из неизменяемого исходного дерева. Его зафиксированные доказательства соответствия остаются подписанными реализатором, а не третьей стороной (подписанное заявление); строгое принятие в чистой комнате ожидает исправленного манифеста, заверенного третьей стороной, и независимо закреплённого ключа аттестатора.
Формально-модельные доказательства	26 ограниченных свойств безопасности TLA+ сохраняются в заданных пространствах состояний; это не уточнение реализации и не неограниченное доказательство · 35 фактов Alloy, 32 утверждения в четырёх моделях · две составные символические модели Dolev-Yao, покрывающие запрос, CAID, два одобрения, эмитента и закрепления полномочий, вид реестра, отзыв, потребление, исполнение и шесть специальных границ утверждений. Двадцать лемм Tamarin верифицируют — 17 обязательств для всех трасс и 3 свидетеля exists-trace; восемь намеренно ослабленных вариантов дают конкретные трассы атак при удалении критических проверок (formal/tamarin/).
Реестры MCP	Официальный реестр MCP · Glama (Grade A, официальный значок) · Smithery
Лицензия	Apache-2.0

Три эталонных порта одной команды (JS / Python / Go) согласуются во всех 21 наборах и 331 векторе. Отдельно реализация Rust от внешнего автора, пересобранная из закреплённого публичного исходного дерева, проходит закреплённый набор чистой комнаты из 16 наборов/164 векторов и кампанию враждебности из 359 случаев, перезапускаемую в собственной CI-полосе при каждом изменении. Более новые наборы приёма AEC и разрешения четырёх исходов не приписываются Rust. Это внешние доказательства интероперабельности, а не строгое принятие конструкции в чистой комнате; агрегированный случай CI фиксирует строгое принятие как ноль до независимой аттестации. См. CONFORMANCE.md или проверьте квитанцию самостоятельно на emiliaprotocol.ai/verify.

---

Стек полномочий

Слой	Что он делает
Мандат	Определяет миссию, ограничения, доказательства, срок действия, делегирование и правила исключений.
CAID / точное действие	Фиксирует материальный исполняемый объект, чтобы доказательства не могли перейти к другой работе.
AEC	Оценивает, удовлетворяют ли независимо проверенные и сопоставленные доказательства требованию полагающейся стороны; он не авторизует.
AEB / Gate	Принимает локальное решение об авторизации, резервирует покрытые полномочия и контролирует вход поставщика.
Доказательства результата	Сохраняет вызов, ответ поставщика, наблюдаемый эффект и неопределённость раздельными.

---

Подтверждающие факты

Метрика	Значение
Автоматизированные тестовые случаи	8 865 в 533 файлах; все применимые к платформе случаи должны проходить
Свойства безопасности TLA+	26 ограниченных инвариантов сохраняются в заданном пространстве состояний; это не уточнение реализации или неограниченное доказательство — см. PROOF_STATUS.md
Реляционные утверждения Alloy	35 фактов + 32 утверждения в четырёх моделях — проверено в CI
Каталогизированные случаи красной команды	85 — RED_TEAM_CASES.md
Статус безопасности релиза	Проверки безопасности репозитория проходят; каждое обнаружение Strix по проверенным изменениям устранено с покрытием регрессии и его обсуждение разрешено
Соответствие (7/7)	node conformance/ep-conformance-test.js https://www.emiliaprotocol.ai
Кросс-языковое соответствие	331 вектор · 21 набор: квитанции · подтверждения устройств · разрешение четырёх исходов · многосторонний кворум · отзыв · привязка результата (семантическая + реальная криптография) · объединение эмитента документа/доказательства полномочий · аттестация времени · доверительная квитанция (2 профиля) · происхождение · запись доказательства · канонизация · граница · приём AEC · валюта · аттестация инициатора · доказательство потребления · свидетель · доказательство временной метки (RFC 3161). Верификаторы JS / Python / Go согласуются (node conformance/run.mjs). Внешний базовый уровень Rust остаётся 164 векторами / 16 наборами. См. CONFORMANCE.md.
Создание рукопожатия p95	575мс при 50 VUs — PERFORMANCE_PROOF.md

---

Основные объекты протокола

Объект	Что это такое
Программа полномочий / ограниченная возможность	Конечный мандат с явными областью, бюджетом или единицами, сроком действия, делегированием и правилами потребления.
CAID	Канонический идентификатор одного материального действия в рамках именованного профиля сопоставления; сопоставление не является авторизацией.
Требование к доказательствам и результат AEC	Закреплённое правило полагающейся стороны и его оценка SATISFIED, UNSATISFIED или INDETERMINATE.
Запись допуска и хранения AEB	Запись на стороне исполнителя об авторизации, резервировании, входе поставщика и состоянии согласования.
Авторизация и доказательства результата	Переносимые нативные артефакты или артефакты EP, сохраняющие точного эмитента, область и границу утверждения.

---

Быстрый старт

1. Запустите npx @emilia-protocol/scan protect ./tools.json, чтобы сопоставить поддерживаемые заявленные поверхности.
2. Проверьте сгенерированный манифест действий, материальные поля, учётные данные и названные слепые зоны.
3. Установите Gate на путь, который владеет учётными данными поставщика и долговременным состоянием потребления.
4. Определите операционный мандат и любые правила исключений для нового человека или кворума.
5. Запустите случаи отказа, точного действия, повтора, тайм-аута и согласования перед включением принудительного исполнения.

90-секундная демонстрация · Быстрый старт · Прохождение агента · Черновик IETF · Discord

---

Что такое EP — и чем он не является

EMILIA — это инфраструктура полномочий для автономной работы, а не система идентификации, кошелёк, репутационный
балл, расчётная шина или универсальный движок политик.

• Является: контрольной плоскостью для конечных операционных мандатов, проверки точных действий, долговременного
  состояния допуска, правдивой неопределённости и переносимых доказательств на покрытых путях исполнителя.
• Не является: заменой OAuth/OIDC, идентификации рабочих нагрузок или движков политик. Они остаются нативными
  входами под закреплениями полагающейся стороны.
• Не является: требованием, чтобы человек одобрял каждое действие. Мандат может разрешать автоматическую работу
  в конечных границах и требовать свежих полномочий только на краю.
• Не является: доказательством того, что допущенное действие успешно выполнено или вызвало ожидаемый эффект.
• Не является: контролем проприетарного протокола. Ядро лицензировано Apache-2.0, а Internet-Drafts являются
  индивидуальными подачами, а не RFC или одобрением IETF.

См. CONFORMANCE.md · SECURITY.md · THREAT_MODEL.md · GOVERNANCE.md · Neutrality Covenant