EMILIA Protocol

EMILIA Protocol

---

Позвольте агенту подготовить платёж. Контролируйте, что он может отправить.

Агент подготавливает платёж поставщику на сумму $82,000. Кто-то его одобряет. Затем меняется сумма или банковские реквизиты получателя. Предыдущее одобрение не должно разрешать отправку изменённого платежа.

EMILIA Gate проверяет полномочия до запуска защищённого инструмента. Открытый протокол позволяет независимо проверять полученные свидетельства с помощью собственных доверенных ключей и правил проверяющей стороны. Сохраните существующие поставщика удостоверений, платформу агента и бизнес-системы.

Запустите пример с платежом

При установленном Node.js версии 20.19 или новее и npm:

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

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

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

Предпочитаете браузер? Попробуйте passkey для тестового платежа. Эта отдельная демонстрация показывает целостность квитанции с помощью платформенного аутентификатора; платёж не отправляется.

Защитите один уже используемый инструмент

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

• MCP или HTTP: Gate Starter показывает, как защитить одно действие.
• Hugging Face smolagents: оберните существующий инструмент.
• GitHub: Merge Gate связывает проверку с предлагаемым слиянием. Проверка должна быть обязательной, а альтернативные пути слияния — закрыты.

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

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

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

EMILIA поставляется с обоснованием безопасности, которое проверяющие могут выполнить. В текущем репозитории разрешены 35 утверждений о безопасности на основе 264 файлов свидетельств с хешами, проверяются 20 лемм Tamarin в двух объединённых моделях Dolev-Yao — 17 обязательств для всех трасс и 3 свидетеля достижимости для существующих трасс и сохранены 8 намеренно ослабленных вариантов, которые дают конкретные трассы атак при удалении критически важных проверок. Актуальный корпус соответствия для той же команды содержит 21 набор тестов и 340 текущих векторов. Отдельно созданный внешними авторами верификатор на Rust закреплён за замороженным набором из 16 наборов тестов и 164 векторов, а также за кампанией проверки устойчивости из 359 случаев. Более широкий набор включает более 10 700 автоматизированных тестов в более чем 650 файлах.

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

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

AEB-1: проверка границы между свидетельством и действием

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

В разделе Граница допуска к последствиям описано точное распределение ответственности между объединённым путём CAID/AEC, прямым нативным путём, хранением AEB и свидетельствами о результате поставщика.

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

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

Согласно AEB-07, опубликованному 2026-09-25 как индивидуальный Internet-Draft и не принятому ни одной рабочей группой, CAID используется только тогда, когда необходимо объединить независимо закодированные действия, а AEC — только когда локальная политика требует несколько составляющих свидетельств. Отдельный синтетический корпус из 26 случаев моделирует этот нативный жизненный цикл для AuthZEN/COAZ-MCP, AP2, OAuth Transaction Token и результатов адаптера локального подписанного мандата:

npm run conformance:composition:consequence-admission

Средство запуска корпуса — это автономная модель жизненного цикла с собственным хранилищем в памяти и логикой допуска. Оно не выполняет код @emilia-protocol/verify или @emilia-protocol/gate, поставляемый в составе продукта, поэтому не является свидетельством для этих пакетов, у которых есть собственные наборы тестов. Оно также не подтверждает соответствие названных нативных протоколов AEB-07.

Чтобы выполнить целевую проверку пути 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

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

Начните с одного объявленного значимого действия MCP. Установите точную локальную среду выполнения, затем создайте для неё Gate Starter и запустите ограниченную проверку из четырёх случаев:

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

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

Остановите новые действия, не делая вид, что отменили старые

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

Для этого необходимы полный контроль всех путей и авторитетное общее состояние. Механизм не останавливает вычисления, не отменяет эффект и не достигает мгновенно отключённых доменов. См. Реализация домена управления и её ограничения.

Попробуйте за 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

Попробуйте платформенный passkey для тестового платежа → Подпишите демонстрационный платёж на сумму $82,000, измените его сумму и убедитесь, что проверка целостности не пройдена. Аутентификатор может использовать биометрию или PIN-код устройства. На странице также доступна отдельная программная симуляция. Ни один из режимов не отправляет платёж и не устанавливает полномочия для промышленной эксплуатации.

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

---

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

Запустите самостоятельно: 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 Protocol открыт и распространяется по лицензии Apache-2.0. Работа над стандартами публикуется в виде портфеля отдельных Internet-Drafts. Опубликованный Internet-Draft не является RFC, принятым документом рабочей группы или одобрением IETF; Datatracker является авторитетным источником сведений о редакциях и статусе.

Регистрации IANA

Два зарегистрированных имени дают разработчикам общую точку отсчёта для форматов EMILIA:

• application/vnd.emilia.authorization-evidence-challenge+json зарегистрирован 6 октября 2026 года. Он обозначает простой JSON-объект AE-CHALLENGE-v1, определённый в опубликованной спецификации сериализации. В ответах HTTP с отказом по-прежнему используется application/problem+json.
• canactid: предварительно зарегистрирован 5 октября 2026 года. Он обозначает точные типизированные действия в рамках CAID-05. Исправленный номер схемы CRI — 1033.

Эти регистрации публикуют имена и соответствующие спецификации. Они не подтверждают принятие IETF, одобрение, сертификацию или внедрение заказчиками.

Единая поверхность границы последствий

Текущая опубликованная версия AEB-07, размещённая 2026-09-25 как отдельный Internet-Draft и не принятая, определяет AEB как точку композиции после принятия нативного решения. OAuth, AuthZEN, COAZ, AP2 и локальные системы сохраняют контроль над своими учётными данными, сопоставлениями операций и решениями об авторизации. AIMS (draft-ietf-wimse-aims) — информационный документ рабочей группы WIMSE, профилирующий существующие стандарты, такие как WIMSE и OAuth; сам по себе он не выдаёт учётные данные и не принимает решений. AEB применяет нативное решение на защищённой границе провайдера: при необходимости он привязывает итоговое действие, выводит один нативный идентификатор повтора для каждого разрешения, резервирует полномочия до входа в провайдера, отказывает во второй попытке выполнить то же действие, пока предыдущая попытка выполняется или её результат не определён, и сохраняет блокировку неопределённого результата до аутентифицированного согласования.

CAID-05 используется, когда необходимо сравнить независимо закодированные представления. Для новых идентификаторов используется предварительно зарегистрированная IANA схема URI canactid:. Эта регистрация не означает принятия IETF, одобрения, сертификации или постоянного статуса. CAID не является обязательным дополнительным сопоставлением, если PEP, отвечающий за последствия, уже выводит и обеспечивает выполнение актуального решения по итоговой операции. Попробуйте площадку для точных действий или прочитайте руководство по переходу с CAID-04 на CAID-05. AEC-06 используется, когда проверяющей стороне требуется несколько участков свидетельств. Профили Authorization Receipts, Human Authorization Binding и Authority Introduction по-прежнему доступны для развертываний, которым они нужны; они не являются обязательными условиями для каждой интеграции AEB. Architecture-03 остаётся навигационным документом.

Руководство по допуску к последствиям описывает границы реализации и случаи, когда AEB не нужен. Профиль прямой передачи нативного решения — это профиль реализации в репозитории, показывающий, как существующее разрешение передаётся в Gate без дополнительного уровня CAID или AEC. AEB-07 определяет, что именно подтверждает такая передача шлюзу и как граница это проверяет, но оставляет кодирование на усмотрение закреплённых в развертывании параметров; в качестве одного из справочных вариантов кодирования в нём приводится закреплённый снимок этого профиля. Точные байты отправленной версии -07 и запись о её публикации сохранены в standards/staged/NEXT-AEB-07.

Полный активный портфель включает 26 записей Datatracker: 21 запись с одним автором и пять совместно написанных записей, каждая со своей областью действия, историей редакций и зафиксированным статусом сопровождения. См. руководство по стандартам, портфель и машиночитаемый реестр статусов.

Internet-Drafts IETF	Пути к текущим локальным снимкам: реестр статусов · реестр опубликованных документов с одним автором · авторитетный актуальный статус: IETF Datatracker
Межъязыковые верификаторы	JavaScript · Python · Go — все три доказали согласованность на векторах соответствия с враждебными входными данными при каждом push (npm run conformance). Это проверка согласованности портов одной команды, а не независимые реализации, созданные с нуля. Отдельно созданная внешним автором реализация на Rust (исходный код открыт) проходит закреплённый набор из 16 наборов тестов и 164 векторов, а также закреплённую кампанию из 359 проверок на устойчивость к атакам при контролируемой оценщиком повторной сборке из неизменяемого дерева исходного кода. Сохранённые в репозитории свидетельства сборки подписаны разработчиком, а не заверены третьей стороной (подписанное заявление); для строгого приёма независимой реализации ожидаются исправленный манифест с заверением третьей стороны и независимо закреплённый ключ аттестатора.
Свидетельства формальной модели	26 ограниченных свойств безопасности TLA+ выполняются в настроенных пространствах состояний; это не уточнение реализации и не доказательство без ограничений · 35 фактов Alloy, 32 утверждения в четырёх моделях · две составные символические модели Dolev–Yao, охватывающие challenge, CAID, два подтверждения, закрепления издателя и полномочий, представление реестра, отзыв, потребление, выполнение и шесть отдельных границ утверждений. Двадцать лемм Tamarin подтверждены — 17 обязательств для всех трасс и 3 свидетеля существования трасс; восемь намеренно ослабленных вариантов дают конкретные трассы атак при удалении критически важных проверок (formal/tamarin/).
Распространение MCP	Пакет npm @emilia-protocol/mcp-server · публикация в официальном Registry отслеживается отдельно в MCP-REGISTRY.md; наличие в каталогах-агрегаторах не выводится ни из одного из этих состояний
Лицензия	Apache-2.0

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

---

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

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

---

Подтверждения

Показатель	Значение
Автоматизированные тестовые случаи	Более 10 700 в более чем 650 файлах; все применимые к платформе случаи должны проходить
Свойства безопасности TLA+	26 ограниченных инвариантов выполняются в настроенном пространстве состояний; это не уточнение реализации и не доказательство без ограничений — см. PROOF_STATUS.md
Реляционные утверждения Alloy	35 фактов + 32 утверждения в четырёх моделях — проверяются в CI
Задокументированные случаи red team	86 — RED_TEAM_CASES.md
Статус безопасности выпуска	Проверки безопасности репозитория пройдены; все обнаружения Strix в проверенных изменениях устранены с регрессионным покрытием, а обсуждения проверки закрыты
Соответствие (7/7)	node conformance/ep-conformance-test.js https://www.emiliaprotocol.ai
Межъязыковое соответствие	340 векторов · 21 набор тестов: квитанции · подтверждения устройств · разрешение четырёх исходов · кворум нескольких сторон · отзыв · Outcome Binding (семантический + реальная криптография) · объединение издателя Authority Document/Proof · аттестация времени · trust-receipt (2 профиля) · происхождение · запись свидетельства · канонизация · граница · приём AEC · валюта · аттестация инициатора · доказательство потребления · свидетель · доказательство временной метки (RFC 3161). Верификаторы JS / Python / Go согласуются (node conformance/run.mjs). Базовая внешняя реализация на Rust по-прежнему охватывает 164 вектора / 16 наборов тестов. См. CONFORMANCE.md.
p95 создания рукопожатия	575 мс при 50 VU — PERFORMANCE_PROOF.md

Криптографическая долговечность (с явно заданными границами развертывания)

Свидетельства, которые должны оставаться проверяемыми спустя годы, должны пережить алгоритмы, которыми они были подписаны. EP предоставляет для этого четыре ограниченные возможности, каждая с точной границей, являющейся частью утверждения:

• Гибридные подписи (EP-RECEIPT-HYBRID-v1). Ed25519 и ML-DSA-65 для одних и тех же канонических байтов; обязательный набор алгоритмов фиксируется в подписанных байтах, поэтому удаление одной из подписей нарушает проверку оставшейся. Возможность включается отдельно при развертывании; после регистрации утвержденного двойного подписанта и разрешения его PQ-подписи политикой неприкрепленная к конкретному варианту конфигурация Gate по умолчанию приводит к выпуску обеих подписей. В противном случае используется только классическая подпись с указанием причины. Проверяющие версии v1 корректно отклоняют гибридные квитанции, а не принимают одну из подписей. Контракт внешнего подписанта и адаптер AWS KMS реализованы, однако не заявляется о выполнении реального вызова подписи AWS, наличии производственного ключа, проверке со стороны полагающейся стороны или валидации ML-DSA по FIPS. См. conformance/hybrid-receipts/ и lib/pq-custody-aws-kms.ts.
• Профиль SCITT Signed Statement (EP-SCITT-STATEMENT-v1). Полная структура Signed Statement по RFC 9943 для квитанций EP, включая защищенный заголовок CWT Claims. Ограничение: ни одна Transparency Service не приняла заявление EP; внешняя регистрация — отдельный этап с дополнительным разрешением, который не выполнялся. См. EP-RECEIPT-SCITT-PROFILE.md.
• Повторная аттестация (EP-EVIDENCE-REATTESTATION-v1). Доказательство, подписанное устаревающим алгоритмом, можно повторно привязать к актуальному алгоритму до ослабления старого. Ограничение: повторная аттестация должна предшествовать компрометации; она не может исправить доказательство задним числом.
• Режим развертывания FIPS (EP-FIPS-MODE-v1). Выполняет классические операции через предоставленный оператором провайдер, валидированный по FIPS 140-3, а путь ML-DSA доступен только после явного подтверждения использования нереализованной валидации. Ограничение: это позволяет заявить «алгоритмы на основе FIPS с режимом развертывания через валидированный провайдер» и зависит от провайдера оператора и заявленных границ сертификата; это не безусловное заявление о соответствии, и ничто здесь не валидировано по FIPS. См. FIPS-MODE.md.

Гибридная программа для всего стека (каждая внутренняя поверхность подписи) описана в pq-hybrid-program.md и еще не завершена; до ее завершения никаких общих заявлений обо всем стеке не делается.

---

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

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

---

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

1. Установите точную локальную среду выполнения guard, затем запустите npx @emilia-protocol/scan@0.6.0 protect ./tools.json --action sendWire --apply --verify, заменив sendWire одним точно указанным значимым инструментом.
2. Проверьте созданные карту полномочий, манифест действий, материальные поля, выбранную границу и явно названные слепые зоны.
3. Выполните отдельную команду --reviewed --crossing-profile <launch-profile>, чтобы создать передачу с доступом только владельцу и незапечатанную рабочую область Lab на основе тех же неизмененных байтов.
4. Установите Gate на пути, который управляет учетными данными провайдера и постоянным состоянием расходования.
5. Определите рабочий мандат и правила исключений, требующих свежего подтверждения человека или кворума.
6. Перед включением принудительного применения выполните сценарии отказа, точного действия, повтора, тайм-аута и сверки.

Демонстрация за 90 секунд · Быстрый старт · Обзор работы агента · Черновик IETF · Discord

---

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

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

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

См. CONFORMANCE.md · SECURITY.md · THREAT_MODEL.md · GOVERNANCE.md · Пакт нейтралитета