Emilia Protocol

EMILIA Protocol

---

エージェントに支払いの準備を任せましょう。実行できる範囲は制御できます。

エージェントが82,000ドルの仕入先への支払いを準備します。担当者が承認します。その後、金額または銀行の送金先が変更されます。先の承認で、変更後の支払いが実行されてはなりません。

EMILIA Gate は、保護されたツールの実行前に権限を確認します。 オープンなプロトコルにより、生成された証拠を、検証者が独自に信頼する鍵とルールに基づいて個別に検証できます。既存の ID プロバイダー、エージェントフレームワーク、業務システムをそのまま利用できます。

支払いの例を実行する

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

この例では、承認のない呼び出しを拒否し、承認を金額、通貨、仕入先、送金先に紐付け、条件が一致する呼び出しを1回だけ許可します。また、支払いの詳細が変更された場合、リプレイされた場合、証拠が偽造された場合は拒否します。例とその制限を参照してください。

これはローカルでのデモです。 生成した署名鍵、メモリ内の消費状態、モックの支払いツールを使用します。実際の人による承認手続きや送金は行いません。本番環境では、登録済みの認証情報、永続的な共有状態、保護対象のプロバイダー認証情報に至るすべての経路での Gate が必要です。有効な承認があっても、銀行口座の詳細が正当であることは証明されません。

ブラウザーで試したい場合は、サンプルの支払いでパスキーを試すをご覧ください。この別のデモでは、プラットフォーム認証器を使ってレシートの完全性を確認できます。支払いは送信されません。

既存のツールを1つ保護する

エージェントのプロセス内だけでなく、実際のプロバイダー認証情報を保持するサービスから始めてください。所有者が許可する作業と、新たな承認が必要になる条件を定義します。エージェントは、すべての呼び出しについて担当者の承認を得なくても、その制限の範囲内で作業できます。

• MCP または HTTP： Gate Starterでは、対象となる操作を1つ使って手順を説明します。
• Hugging Face smolagents： 既存のツールをラップする。
• GitHub： Merge Gateは、チェックを提案されたマージに紐付けます。このチェックを必須にし、別のマージ経路を閉じる必要があります。

プロトコルは証明し、Gate は防止します。 ただし、デプロイメントが完全に仲介する経路に限ります。Gate は迂回経路を制約できません。プロバイダーの処理結果が不明な場合、本番環境のライフサイクルでは、その不確実性を調整のために保持し、無条件に再試行することはありません。

AI システムおよびリポジトリのレビュアーへ： AI_CONTEXT.mdから始めてください。 現在の機械可読な証拠、来歴、前提条件、除外事項は EMILIA-REPO-CONTEXT-v1で公開しています。 アーカイブ済みまたは準備段階の文書は、現在の実装や IETF の状況を示すものではありません。 公開されているデューデリジェンス資料と主張の範囲については、DUE_DILIGENCE.mdを参照してください。

アーキテクチャ上の主張ではなく、エンジニアリングの証拠

EMILIA には、レビュー担当者が実行できるセキュリティケースが含まれています。現在のリポジトリは、264 個のハッシュ付き証拠ファイルにわたる 35 件のセキュリティ主張を解決し、**2 つの合成 Dolev-Yao モデルにまたがる 20 個の Tamarin 補題（全トレース義務 17 件、存在トレース到達可能性の証人 3 件）**を検証し、不可欠なチェックを取り除くと具体的な攻撃トレースを生成する、意図的に弱体化させた 8 つのバリアントを保持しています。現在の同一チーム適合性コーパスには、21 のスイートと 340 個の現行ベクトルが含まれています。これとは別に、外部で作成された Rust 検証ツールは、凍結された 16 スイート／164 ベクトルのバンドルと、359 ケースの敵対性キャンペーンに固定されています。より広範なスイートには、650 以上のファイルにわたる 10,700 件以上の自動テストが含まれています。

本番用の JavaScript と JSDoc のサーフェスは TypeScript checkJs でコンパイラーチェックされます。セキュアアプリには独自の互換性コンパイラープロジェクトがあり、宣言ファイルとパブリック TypeScript SDK は厳格モードでチェックされます。これは、設定された本番コードの型チェックを完全に網羅しているという意味であり、リポジトリ全体を JavaScript から TypeScript に一括変換した、あるいはすべての JavaScript プロジェクトで TypeScript の strict オプションが有効になっている、という主張ではありません。

各セキュリティ主張には、適用経路、肯定的および否定的なベクトル、言語の対象範囲、形式的な適用範囲または明示的なギャップ、前提条件、除外事項、証拠ハッシュが記載されています。まず人が読める証拠マップを確認し、次に解決済みセキュリティケースを調べるか、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

これは形式に依存せず、自分で実行できます。合格レポートは自己申告による適合性の証拠であり、監査、認証、本番環境へのデプロイに関する主張、またはアクションを実行する許可ではありません。

2026-09-25 に個人による Internet-Draft として公開され、いずれのワーキンググループにも採択されていない AEB-07 では、独立してエンコードされたアクションを結合する必要がある場合に限り 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 が引き続き公開するのは、相互運用可能な 3 つのオブジェクトです。Trust Receipt は帰属可能な証拠を保持し、Trust Profile は構造化された信頼状態を表し、Trust Decision は依拠当事者のポリシー評価結果を記録します。権限制御プレーンのレイヤーでは、これらのオブジェクトを 1 つのクレームに統合することなく、正確なアクションの紐付け、有限の委任、受付、消費、結果の証拠を追加します。

---

委任は一度設定する。あとはエージェントに任せる。

顧客がミッション、制限、証拠要件、有効期限、例外ルールを定義します。ローカルコードはその権限を狭めることはできますが、独自に作り出したり、拡大したりすることはできません。Gate は実行可能な各リクエストを委任に紐付け、プロバイダーに入る前に対象となる権限を予約し、共通の永続的な権限ドメイン内で、その認可インスタンスに対する受付済みのプロバイダー試行を 1 回だけ許可します。また、権限が不足している、古い、使い切られている、または対象範囲が狭すぎる場合に限り、エスカレーションします。

同梱の MCP の例では、境界で承認を必要とするポリシープロファイルを使用しています。 デモ用の署名キーを生成し、モックツールを呼び出します。決済の例では、宣言された 4 つの重大フィールドすべてを紐付けます。他の例では、より限定的なリソースの紐付けを示します。 これらの例は、実際の人間による判断を取得したり、プロバイダーに接続したりするものではありません。

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

より詳細な構成のデモでは、Gate の実際の権限制限付き機能の経路を通じて、CAID に紐付けられた委任済みの決済を実行し、その後、署名付き実行証明書をオフラインで検証します。

npm run demo:receipt-program

意図的に、ブロックチェーンも、シミュレートされたゼロ知識の主張も含めていません。本番環境における状態と信頼要件については、 レシートプログラムのアーキテクチャを参照してください。

宣言済みの重大な MCP アクションを 1 つ用意して始めましょう。正確なローカルランタイムをインストールし、Gate Starter を作成して、4 ケースの権限制限チェックを実行します。

npm install --save-exact @emilia-protocol/[email protected]
npx @emilia-protocol/[email protected] protect ./tools.json --action sendWire --apply --verify

# after reading emilia/authority-map.html and action-control.manifest.json
npx @emilia-protocol/[email protected] 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

サンプル決済でプラットフォームのパスキーを試す → 82,000ドルの例示的な決済に署名し、その金額を変更して整合性チェックが失敗する様子を確認してください。 認証器では、生体認証またはデバイスのPINが使用される場合があります。このページでは、別途ソフトウェアによるシミュレーションも利用できます。どちらのモードでも決済は送信されず、本番環境での認可も確立されません。

ブラウザーで任意のレシートを検証 — 貼り付けるだけで、何もアップロードされません。

---

仕組み — 1つの権限ライフサイクル

ご自身で実行できます：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／パスキーによる判断を必須にできます。これにより「見た内容に署名した」という認識のずれを狭められますが、理解、賢明さ、合法性、結果を証明するものではありません。

エンタープライズ環境へのデプロイでは、Gate はさらに、同一の正確な人間による証拠、同じ正確なアクション、AS が実際に観測した ID スナップショット、および意図された Resource Server の鍵に結び付けられた、独立検証済みの Authorization 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-Draft のポートフォリオとして公開されています。公開された Internet-Draft は RFC でも、採択されたワーキンググループ文書でも、IETF による承認でもありません。改訂版とステータスについては Datatracker が正式な情報源です。

影響境界を一元化するサーフェス

現在公開されている AEB-07 は、2026-09-25 に個別の Internet-Draft として投稿され、採択されていません。この文書では、ネイティブな判断の後に AEB を構成ポイントとして位置付けています。OAuth、AuthZEN、COAZ、AP2、およびローカルシステムは、それぞれの認証情報、オペレーションのマッピング、認可判断の管理を引き続き担います。AIMS（draft-ietf-wimse-aims）は、WIMSE ワーキンググループの情報提供文書であり、WIMSE や OAuth などの既存標準をプロファイル化しています。AIMS 自体が認証情報や判断を発行するわけではありません。AEB は、保護対象プロバイダーの境界でネイティブな判断を適用します。必要に応じて最終アクションをバインドし、許可ごとにネイティブなリプレイ識別子を1つ導出し、プロバイダーへの処理開始前に予約します。また、以前の試行が進行中または不確かな状態にある間は、同じアクションに対する2回目の試行を拒否し、不確かな結果は認証済みの照合が行われるまでロック状態に保ちます。

独立してエンコードされた表現を比較する必要がある場合は、 CAID-05 を使用します。新しい識別子には、IANA に暫定登録された canactid: URI スキームを使用します。この登録は、IETF による採択、承認、認証、または恒久的なステータスを意味しません。影響を担う PEP が最終オペレーションに対する現行の判断をすでに導出して適用している場合、CAID は必須の追加マッピングではありません。 完全一致アクションのプレイグラウンドを試すか、 CAID-04 から CAID-05 への移行ガイドをお読みください。 複数の証拠レッグを求める依拠当事者 には、AEC-06 を使用します。Authorization Receipts、Human Authorization Binding、Authority Introduction は、必要とするデプロイメント向けのプロファイルとして引き続き利用できます。すべての AEB 統合に必須のものではありません。Architecture-03 は引き続きナビゲーション文書です。

影響の受け入れに関するガイドでは、実装の境界と AEB が不要なケースについて説明しています。 直接的なネイティブ引き継ぎプロファイル は、既存の許可が2つ目の CAID 層や AEC 層を介さずに Gate に到達する方法を示す、リポジトリの実装プロファイルです。AEB-07 は、このようなゲートウェイ引き継ぎが証明する内容と、その境界での検証方法を規定していますが、エンコーディングはデプロイメントのピン留めに委ねています。また、情報提供用の参照エンコーディングの一例として、このプロファイルのピン留めされたスナップショットを参照しています。提出された正確な -07 のバイト列と公開記録は、 standards/staged/NEXT-AEB-07に保存されています。

現在有効なポートフォリオは、Datatracker の記録26件で構成されています。単独執筆の記録が21件、共著の記録が5件あり、それぞれに固有の適用範囲、改訂履歴、記録済みのメンテナンス状況があります。標準ガイド、 ポートフォリオ、および機械可読な ステータス一覧を参照してください。

IETF インターネットドラフト	現在のローカルスナップショットのパス：ステータス一覧 · 単独著者による公開済み一覧 · 権威ある最新ステータス：IETF Datatracker
言語横断ベリファイアー	JavaScript · Python · Go — 敵対的な適合性ベクトルで3つすべてが一致することを検証済みで、プッシュごとに実行しています（npm run conformance）。これは1つのチームによる移植版同士の整合性チェックであり、独立したクリーンルーム実装ではありません。これとは別に、外部の作者による仕様ベースのRust実装（ソース公開済み）は、評価者が管理する不変のソースツリーからの再ビルドにより、固定された16スイート／164ベクトルのバンドルと、固定された359ケースの敵対性キャンペーンに合格しています。チェックイン済みの構築証拠は引き続き実装者による署名であり、第三者による証明ではありません（署名済みステートメント）。厳格なクリーンルーム受け入れには、修正済みの第三者証明付きマニフェストと、独立して固定された証明者キーが必要です。
形式モデルの証拠	構成された状態空間において、26の有界TLA+安全性プロパティが成立しました。これは実装の精密化でも無界証明でもありません · 4つのモデルにわたる35のAlloy事実、32のアサーション · チャレンジ、CAID、2つの承認、発行者と権限者のピン、レジストリビュー、失効、消費、実行、および6つの専用クレーム境界を網羅する、合成された2つの記号的Dolev-Yaoモデル。20のTamarin補題で検証済みです — 全トレースに関する義務が17件、存在トレースの証人が3件です。意図的に弱めた8つの変形では、重要なチェックを取り除くと具体的な攻撃トレースが生成されます（formal/tamarin/）。
MCPの配布	npmパッケージ @emilia-protocol/mcp-server · 公式Registryへの公開はMCP-REGISTRY.mdで別途追跡しています。アグリゲーターの掲載状況は、どちらの状態からも推定しません
ライセンス	Apache-2.0

同じチームによる3つの参照移植版（JS／Python／Go）は、21のすべてのスイートと340のベクトルで一致します。これとは別に、外部の作者によるRust実装は、固定された公開ソースツリーからの再ビルドにより、固定された16スイート／164ベクトルのクリーンルームバンドルと359ケースの敵対性キャンペーンに合格しており、変更のたびに独自のCIレーンで再実行されます。新しいAEC受け入れスイートと4つの結果解決スイートについて、Rustは合格したとはされていません。これは外部相互運用性の証拠であり、厳格なクリーンルーム構築の受け入れを示すものではありません。集計CIのケース記録では、独立した証明が保留されているため、厳格な受け入れ件数はゼロと記録されています。CONFORMANCE.mdを参照するか、emiliaprotocol.ai/verifyでレシートをご自身で検証してください。

---

権限スタック

レイヤー	役割
委任	ミッション、制限、証拠、有効期限、委任、および例外のルールを定義します。
CAID／正確なアクション	認可と実行で独立してエンコードされた表現が使われる場合に、実質的な意味を比較します。認可は行いません。
AEC	必要な場合、独立して検証され照合された証拠が、依拠する当事者の複数要件を満たすかどうかを評価します。認可は行いません。
AEB／ゲート	結果が生じる境界でネイティブまたはローカルの認可判断を適用し、対象となる権限を確保して、プロバイダーへの処理開始を制御します。
結果の証拠	呼び出し、プロバイダーの応答、観測された効果、および不確実性を区別して保持します。

実証データ

指標	値
自動テストケース	650 以上のファイルにまたがる 10,700 件以上。各プラットフォームで適用可能なケースはすべて合格する必要があります
TLA+ 安全性プロパティ	設定された状態空間で、26 個の有界不変条件が成立しました。実装の精緻化証明でも無界証明でもありません。詳しくは PROOF_STATUS.md を参照してください
Alloy 関係アサーション	4 つのモデルにわたる 35 個の事実と 32 個のアサーション。CI で検証済みです
カタログ化されたレッドチームケース	86 件。RED_TEAM_CASES.md
リリースのセキュリティ状況	リポジトリのセキュリティチェックは合格しています。監査対象の変更に関する Strix のすべての検出事項は回帰テストで対処され、レビューのスレッドも解決済みです
適合性（7/7）	node conformance/ep-conformance-test.js https://www.emiliaprotocol.ai
クロスランゲージ適合性	340 個のベクトル・21 個のスイート：レシート・デバイス署名・4 つの結果による解決・複数当事者クォーラム・失効・Outcome Binding（セマンティック＋実際の暗号処理）・Authority Document/Proof 発行者の結合・時刻証明・信頼レシート（2 つのプロファイル）・来歴・エビデンスレコード・正規化・境界・AEC 受け入れ・通貨・開始者の証明・消費証明・証人・タイムスタンプ証明（RFC 3161）。JS / Python / Go の検証器は一致します（node conformance/run.mjs）。外部の Rust ベースラインは引き続き 164 個のベクトル・16 個のスイートです。CONFORMANCE.md を参照してください。
ハンドシェイク作成の p95	50 VU で 575ms。PERFORMANCE_PROOF.md

暗号技術の長期的な有効性（明示的なデプロイ境界付き）

数年後に検証することを想定したエビデンスは、署名に使われたアルゴリズムよりも長く有効である必要があります。EP はそのための有界な機能を 4 つ提供しており、それぞれの主張には正確な境界が含まれます。

• ハイブリッド署名（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）。 CWT Claims 保護ヘッダーを含む、EP レシート向けの完全な RFC 9943 Signed Statement 形式です。境界：EP ステートメントを受け入れた Transparency Service はありません。外部登録は別途、ゲート付きで行う手順であり、まだ実施されていません。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	名前付きマッピングプロファイルに基づく、1つの重要なアクションの正規識別子です。一致していることは認可を意味しません。
証拠要件とAECの結果	依拠当事者が固定したルールと、そのSATISFIED、UNSATISFIED、またはINDETERMINATEの評価結果です。
AEBの受付と保管記録	認可、予約、プロバイダーへの処理開始、照合状態を記録する、実行側の記録です。
認可と結果の証拠	発行者、適用範囲、主張の境界を正確に保持する、ポータブルなネイティブまたはEPのアーティファクトです。

---

クイックスタート

1. 正確なローカルガードランタイムをインストールし、npx @emilia-protocol/[email protected] protect ./tools.json --action sendWire --apply --verifyを実行します。sendWireは、宣言済みの重要なツールのうち、正確な1つに置き換えてください。
2. 生成されたAuthority Map、アクションマニフェスト、重要なフィールド、選択された境界、明示された盲点を確認します。
3. 別途、--reviewed --crossing-profile <launch-profile>コマンドを実行し、変更されていないこれらのバイト列から、オーナー専用の引き継ぎと、封印されていないLabワークスペースを作成します。
4. プロバイダーの認証情報と永続的な消費状態を管理する経路上にGateをインストールします。
5. 運用上の権限と、新たな人間の承認または定足数に関する例外ルールを定義します。
6. 強制を有効にする前に、拒否、正確なアクション、リプレイ、タイムアウト、照合のケースを実行します。

90秒のデモ · クイックスタート · エージェントのチュートリアル · IETFドラフト · Discord

---

EPとは何か、何ではないか

EMILIAは自律的な作業のための権限インフラストラクチャであり、IDシステム、ウォレット、評判スコア、決済レール、汎用ポリシーエンジンではありません。

• 該当するもの：対象となる実行経路における、有限の運用権限、正確なアクションの検証、永続的な受付状態、誠実な不確実性の扱い、ポータブルな証拠のためのコントロールプレーンです。
• 該当しないもの：OAuth/OIDC、ワークロードID、ポリシーエンジンの代替ではありません。これらは引き続き、依拠当事者が固定するネイティブな入力として扱われます。
• 該当しないもの：すべてのアクションについて人間の承認を必須とするものではありません。権限によって、有限の範囲内では作業を自動化し、その範囲の境界でのみ新たな承認を求めることができます。
• 該当しないもの：受け付けられたアクションが正常に実行されたことや、意図した効果をもたらしたことの証明ではありません。
• 該当しないもの：プロトコルを独占的に管理するものではありません。コアはApache-2.0ライセンスで提供され、Internet-Draftは個人の提出物であり、RFCでもIETFによる承認でもありません。

CONFORMANCE.md · SECURITY.md · THREAT_MODEL.md · GOVERNANCE.md · 中立性規約を参照してください。