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

この例では、承認なしの呼び出しを拒否し、承認を金額、通貨、ベンダー、送金先に紐付けます。一致する呼び出しは一度だけ許可し、変更された支払い情報、リプレイ、偽造された証拠は拒否します。例とその制限を参照してください。

これはローカルでのデモです: 生成した署名鍵、メモリ内での消費管理、モックの支払いツールを使用します。実際の人間による承認手続きは行わず、資金も移動しません。本番環境では、登録済みの認証情報、永続的な共有状態、そして保護対象のプロバイダー認証情報に至るすべての経路での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はstrictモードでチェックされます。これは、設定済みの本番コード全体を対象とする型チェックが完了しているという意味であり、リポジトリ全体を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/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

サンプル支払いでプラットフォームパスキーを試す → 例示用の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 serverまたは薄いSDKラッパーで、宣言したアクションサーフェスを1つ保護します。スキャナーはレビュー可能なマップを提案し、オーナーが権限を定義し、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が正式な情報源です。

IANA登録

2つの登録名により、EMILIA形式の共通参照先が実装者に提供されます。

• application/vnd.emilia.authorization-evidence-challenge+json は2026年10月6日に登録されました。これは、公開済みのシリアライズ仕様で定義された、ラップされていないAE-CHALLENGE-v1 JSONオブジェクトを識別します。 HTTPの拒否応答では引き続きapplication/problem+jsonを使用します。
• canactid: は2026年10月5日に暫定登録されました。CAID-05に基づく、型付きの正確なアクションを表します。訂正後のCRIスキーム番号は1033です。

これらの登録は、名称とその仕様を公開するものです。IETFによる採択、承認、認証、または顧客環境への導入を確立するものではありません。

1つの結果境界サーフェス

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

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

結果の許可に関するガイドでは、 実装境界とAEBが不要なケースを説明しています。 ネイティブな直接引き渡しプロファイル は、既存の許可を第2のCAIDレイヤーやAECレイヤーなしでGateに渡す方法を示す、リポジトリ内の実装プロファイルです。AEB-07は、そのようなゲートウェイの引き渡しが何を証明し、境界がそれをどのように検証するかを規定しますが、エンコーディングは導入環境のピン留めに委ねています。また、このプロファイルのピン留めされたスナップショットを、参考となるエンコーディングの1つとして引用しています。提出された正確な-07のバイト列とその公開記録は、 standards/staged/NEXT-AEB-07に保存されています。

有効なポートフォリオ全体はDatatrackerの26件の記録で構成されます。単独執筆の記録が21件、共著の記録が5件あり、それぞれに独自の範囲、改訂履歴、記録された保守ステータスがあります。標準ガイド、 ポートフォリオ、および機械可読な ステータス一覧を参照してください。

IETF Internet-Drafts	現在のローカルスナップショットのパス：ステータス一覧 · 単独執筆の公開済み一覧 · 正式な最新ステータス：IETF Datatracker
クロス言語検証器	JavaScript · Python · Go — 3つすべてが、敵対的な適合性ベクトルに対して一致することを、すべてのpushで実証済み (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 / Gate	結果境界でネイティブまたはローカルの認可判断を適用し、対象となる権限を予約して、プロバイダーへの進入を制御します。
結果の証拠	呼び出し、プロバイダーの応答、観測された効果、不確実性を区別して保持します。

---

実績

指標	値
自動テストケース	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発行者の結合 · 時刻証明 · trust-receipt（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 形式です。境界条件: 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 にまとめられており、まだ完了していません。完了するまでは、スタック全体について包括的な主張は行いません。

---

コアプロトコルオブジェクト

オブジェクト	内容
Authority program / bounded capability	明示的なスコープ、予算または単位、有効期限、委任、消費ルールを備えた有限の権限付与。
CAID	名前付きマッピングプロファイルに基づく、1つの重要なアクションを表す正規識別子。一致していることは認可を意味しません。
Evidence requirement and AEC result	依拠当事者がピン留めしたルールと、その SATISFIED、UNSATISFIED、または INDETERMINATE による評価。
AEB admission and custody record	認可、予約、プロバイダーへの引き渡し、照合状態を記録する、実行側の記録。
Authorization and outcome evidence	発行者、スコープ、クレームの境界を正確に保持する、移植可能なネイティブまたは EP の成果物。

---

クイックスタート

1. 正確なローカルガードランタイムをインストールし、npx @emilia-protocol/scan@0.6.0 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 Draft · Discord

---

EP とは何か — そして何ではないか

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

• 該当するもの: 有限の運用権限付与、アクションの厳密な検証、永続的な受付状態、正確な不確実性の表現、対象となる実行経路における移植可能な証拠を扱うコントロールプレーンです。
• 該当しないもの: OAuth/OIDC、ワークロード ID、ポリシーエンジンの代替ではありません。これらは依拠当事者がピン留めしたネイティブ入力として引き続き使用されます。
• 該当しないもの: すべてのアクションで人間の承認を必須とする仕組みではありません。権限付与によって、有限の範囲内での自動作業を許可し、境界に達した場合にのみ新たな権限を要求できます。
• 該当しないもの: 受け付けられたアクションが正常に実行されたことや、意図した効果をもたらしたことの証明ではありません。
• 該当しないもの: 独自プロトコルによる支配ではありません。コアは Apache-2.0 で提供され、Internet-Drafts は個人による提出物であり、RFC でも IETF の推奨でもありません。

CONFORMANCE.md · SECURITY.md · THREAT_MODEL.md · GOVERNANCE.md · 中立性の誓約