EMILIA Protocol
公式名前付きの人間によるオフライン検証可能な承認を、AIエージェントが不可逆的なアクション(支払いリリース、記録変更、デプロイ)を実行する前に要求します。二人体制、Ed25519トラストレシート、IETF草案、Apache-2.0。
EMILIA Protocol MCPで何ができますか?
-
Scan declared tool surfaces —
npx @emilia-protocol/scan protect ./tools.jsonを実行して、サポートされているアクションをマッピングし、ワークフローを保護する前に生成されたマニフェストを確認します。 -
Issue offline receipts —
npx @emilia-protocol/issue demoを使用して、APIキーやバックエンドを必要とせずに、Trust Receipt をローカルで生成します。 -
Verify receipts in-browser — 任意のレシートを emiliaprotocol.ai/verify に貼り付けて、オフラインでその信頼性を確認します。アップロードされるものはありません。
-
Run AEB-1 conformance tests —
npx @emilia-protocol/verify aeb-conformance --referenceを実行して、ネイティブ検証と no-blind-retry 動作で、エビデンスから効果への境界をテストします。 -
Protect MCP tools with Gate —
release_paymentやdelete_repoなどのツールをラップして、有効なレシートなしでは実行を拒否するようにします。これは、同梱の MCP の例に示されています。 -
Add EMILIA to Claude/Cursor/Cline —
npx -y @emilia-protocol/mcp-serverを実行して、権限制御プレーンを AI アシスタントに統合します。
ドキュメント
EMILIA Protocol
AIエージェントは労働者になりつつある。労働者には権限が必要だ。
EMILIAは自律的な作業のための権限コントロールプレーンです。 Gateは、エージェントの認証済みインテントがマネー、コード、権限、記録、またはインフラストラクチャへの変更となる境界、すなわち結果(コンシークエンス)の境界です。人間または組織が有限の運用マンデートを定義し、Gateは保護されたプロバイダーパスが開始される前に、その正確な作業単位をマンデートに対してチェックします。
Gateは、その境界における商業用のコンシークエンス・ファイアウォールです。所有者が正確なアクションに対して要求する権限を検証し、プロバイダー進入前にその権限を予約し、永続的な権限ドメイン内の対象となる認可インスタンスに対して許可された1回のプロバイダー試行を許可し、保護されたパスが許可して後に観測した内容のポータブルな証拠を残します。結果が不明な場合は、盲目的な再試行ではなく調整(リコンシリエーション)を要求します。プロトコルは証明する。Gateは防ぐ。
- Authority Brain は、サポートされている宣言済みアクションサーフェスをローカルにマッピングします。アカウント、アップロード、コールバックは不要です。ディスカバリーは権限を生み出しません。所有者がマップをレビューします。
- EMILIA Gate は、承認されたマップと運用マンデートを、完全に仲介された、資格情報を保持する実行パス上の予防的コントロールに変換します。
- EMILIA Protocol は、正確なアクションのアイデンティティ、ネイティブな証拠の検証、証拠の合成、永続的な入場状態、ポータブルな作業記録のためのオープンなApache-2.0基盤です。
- EMILIA Approver は、マンデートまたはローカルポリシーが新たな人間の権限を要求する場合に、デバイスにバインドされた正確なアクションに対する人間の意思決定をキャプチャします。人間のクリックは権限の1つのソースであり、デフォルトの実行モデルではありません。
- EMILIA Assurance Plane は、スコープ付き検証、再実行、適合性レポート、デプロイメント証拠を提供します。監査人、保険会社、規制当局、顧客をサポートします。EMILIAは監査人や認定認証機関ではなく、公開されたEMILIA認証プログラムは運用されていません。
ローカルマップ (npx @emilia-protocol/scan) を実行し、1つの結果を伴うワークフローを選択し、プロバイダーの資格情報がインテントを作業に変える場所にGateを配置してください。
最初の低摩擦な配布プロファイルはGitHubです。オープンなMerge Gateは、保護されたマージチェックが通過する前に、リポジトリ所有のマンデートと分離されたレシートを正確なベースコミットとヘッドコミットにバインドします。これは、リポジトリがチェックを必須にし、代替マージパスを閉じた場合にのみ予防的になります。これは製品および配布の実験であり、外部採用の証拠ではありません。
エージェントは稼働し続けてもよい。その権限は停止する。
継続的かつ自己改善型のエージェントは、プロセス終了だけでは解決できない制御問題を生み出します。所有者は、計算が停止したと主張したり、外部への影響が取り消されたと主張したりすることなく、新しい結果を停止する必要がある場合があります。Gateの緊急権限フリーズ(Emergency Authority Freeze)は、これを永続的な権限移行にします。カバーされたGate制御ドメイン内では、フリーズは新しい予約をブロックし、コントロールエポックが変更された後に古い予約が進入するのを防ぎます。プロバイダー進入が先にシリアライズされた場合、その操作は消費されたままであり、調整(リコンシリエーション)が必要です。リストアは再度エポックを進め、古い権限を復活させません。
この保証には、完全な仲介と権威ある共有状態が必要です。これはエージェントを停止させず、進入済みの影響を元に戻さず、切断されたリースドメイン全体に即時のフリーズを提供しません。現在の参照実装は、ローカルのインメモリおよびPostgreSQL制御ドメインをカバーしています。リースドエッジの伝播とポータブルな署名済みフリーズイベント証拠は、明示的な実装ギャップのままです。
指名された有償ワークフローは、支払者側のAI支援による医療上必要な判断の否定的決定のままであり、1つの安全ルールの下にあります: 有効なライセンス審査証拠がなければ、否定的決定はない。 証拠が欠落している場合は、合法的な人間によるレビューまたは患者保護のフォールバックにルーティングされます。それは医学的に必要なケアを差し控える権限ではありません。
AIシステムおよびリポジトリレビュアーの方へ: AI_CONTEXT.md から始めてください。 現在の機械可読な証拠、 provenance、前提、除外事項は EMILIA-REPO-CONTEXT-v1 に公開されています。 アーカイブまたはステージングされた文書は、現在の実装またはIETFステータスを確立しません。 公開デューデリジェンス証拠とクレーム境界: DUE_DILIGENCE.md。
アーキテクチャの主張ではなく、エンジニアリングの証拠
EMILIAは、レビュアーが実行できるセキュリティケースを提供します。現在のリポジトリは、259個のハッシュ化された証拠ファイルにわたる35件のセキュリティクレームを解決し、2つの構成されたDolev-Yaoモデルにわたって20件のTamarinレンマを検証(17件の全トレース義務と3件の存在トレース到達可能性証人)し、負荷のかかるチェックが削除されたときに具体的な攻撃トレースを生成する8件の意図的に弱体化されたバリアントを保持しています。ライブの同一チーム適合性コーパスには、21スイートと331の現在のベクトルが含まれています。別途、外部執筆のRust検証器が、凍結された16スイート/164ベクトルのバンドルと359ケースのホスティリティキャンペーンにピン留めされています。より広いスイートには、533ファイルにわたる8,865件の自動テストが含まれています。
本番の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/アクション一致、証拠充足、ローカル認可、アトミック予約、INVOKING カストディ、プロバイダー成果と観測効果の分離された真実、ブラインド再試行なしの動作、および認証付き調整です。
npx @emilia-protocol/verify aeb-conformance --reference
これは形式に依存せず、自己実行です。合格レポートは自己証明された適合性証拠であり、監査、認定、本番デプロイメントの主張、またはアクション実行の許可ではありません。
リポジトリのGateパスの焦点を絞った実行可能な証明については、以下を実行してください:
npm run proof:gate:reference
このコマンドは、生成されたキー、インメモリ状態、モックプロバイダー動作を使用して、ローカル例と焦点を絞ったサービス境界を実行します。これは有用なローカル証明ですが、実際の人間、外部銀行、本番デプロイメント、または1つのエンドツーエンドの本番統合の証拠ではありません。
アイデンティティは職務記述書ではない
アイデンティティは誰が、または何が呼び出しているかを示します。ポリシーは一般的に何が許可されているかを示します。どちらも自律的なワーカーが今実行できる有限のジョブを定義しません: そのミッション、重要なアクションの制限、予算、必要な証拠、有効期限、委任ルール、例外パス。
EMILIAはこれらの問いを分離します:
| レイヤー | 問い |
|---|---|
| アイデンティティ | 誰が、または何が存在するか? |
| ポリシー | 一般的に何が許可されているか? |
| 権限 | このマンデートの下で、このエージェントはどの正確な作業を実行できるか? |
資格情報は到達範囲を付与します。権限はジョブを定義します。すべてのアクションに人間が必要なわけではありません。すべての結果を伴うアクションには有効な権限が必要です。
基盤において、EP Coreは依然として3つの相互運用可能なオブジェクトを公開しています: Trust Receiptは帰属可能な証拠を運び、Trust Profileは構造化された信頼状態を表し、Trust Decisionは依拠当事者のポリシー評価済みの結果を記録します。権限コントロールプレーンのレイヤーは、それらのオブジェクトを1つのクレームに統合することなく、正確なアクションバインディング、有限マンデート、入場、消費、成果証拠を追加します。
マンデートを一度設定する。エージェントに作業させる。
顧客はミッション、制限、証拠要件、有効期限、例外ルールを定義します。ローカルコードはその権限を狭めることはできますが、発明したり拡大したりすることはできません。Gateは各実行可能リクエストをマンデートにバインドし、プロバイダー進入前にカバーされた権限を予約し、共有された永続的な権限ドメイン内のその認可インスタンスに対して1回の許可されたプロバイダー試行を許可し、権限が欠落、古い、枯渇、または狭すぎる場合にのみエスカレーションします。
同梱のMCP例は、エッジで新しい人間の意思決定が必要とされる1つのポリシープロファイルを示しています。これらは完全なローカルループを実行します(欠落した証拠の拒否、正確なアクションの署名、1回のプロバイダー試行の許可、偽造証拠の拒否)。すべての自律アクションに人間のクリックが必要だと主張するものではありません:
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
これは意図的にブロックチェーンやシミュレートされたゼロ知識の主張を含みません。本番状態と信頼要件については、レシートプログラムアーキテクチャ を参照してください。
宣言されたツールサーフェスに対するドライランから始め、次にレビュー可能な統合ファイルを生成します:
npx @emilia-protocol/scan protect ./tools.json
npx @emilia-protocol/scan protect ./tools.json --apply
node emilia/verify-setup.mjs
生成されたローカルチェックは、明示的に一時的なデモ状態を使用し、その合成ハンドラが呼び出されなかったことのみを証明します。本番には、永続的な provenance 台帳、共有アトミック消費ストア、ピン留めされたキー、および実際のプロバイダー資格情報へのすべてのパス上のラッパーが必要です。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ドルの送金を承認します。VERIFIEDがどのように見えるかを確認します。レシートを偽造します。失敗するのを見ます。
ブラウザで任意のレシートを検証する — 貼り付けるだけで、何もアップロードされません。
仕組み — 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が実際に観測したアイデンティティスナップショット、および意図されたリソースサーバーキーにバインドされます。スナップショット時間と依拠当事者の最大経過時間は明示的です: 新しいトークンは古いディレクトリデータを現在のものにすることはできません。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が権威ある情報源である。
標準的な4文書の提示サーフェス
読者のナビゲーションのために、標準的な証拠パスは次のとおりである:
- Authorization Receipts-11 は、アクションに紐づく承認証拠プロファイルを定義する。現在公開されている改訂版は-11であり、Standards Track候補の個人提出として提出されている。
- Human Authorization Binding-00 は、名前付き人間の承認アーティファクトを隣接するホストレコードにバインドする。
- Authority Introduction-03 は、依拠当事者がピン留めしたトラストルートとスコープ付き権限を確立する。
- Authorization Evidence Chain-05
は、ネイティブに検証され、アクションに一致する証拠が依拠当事者の要件を満たすかどうかを評価し、
SATISFIEDまたはUNSATISFIEDを返す。AUTHORIZEDを返すことは決してない。
この4文書のサーフェスは提示のみを目的とする。アクティブなポートフォリオ内のいかなるドラフトも統合、廃止、置換、更新、陳腐化、従属化、降格はしない。
分離されたランタイム実行スパイン
ランタイムパスは Architecture-02 → CAID-02 → AEC-05 → AEB-03 である:システム境界、正確な実質アクションのマッチング、証拠の充足、そしてエグゼキュータ側の承認と永続的な結果の管理である。AECは両方のビューに現れる。これは証拠の充足がランタイムの承認に供給されるためであり、ビューが同等であるからではない。
アクティブなポートフォリオ全体は依然として23件のDatatrackerレコードである:20件のアクティブな draft-schrock-* レコードと3件の共著レコードであり、それぞれ独自のスコープと改訂履歴を持つ。標準ガイド、ポートフォリオ、機械可読なステータスインベントリを参照のこと。
| IETF Internet-Drafts | 現在のローカルスナップショット:公開インベントリ・権威あるライブステータス:IETF Datatracker |
| クロス言語検証器 | JavaScript・Python・Go — 3つすべてが敵対的適合性ベクトルで一致することが、すべてのプッシュで証明されている(npm run conformance)。これは1つのチームの移植間での一貫性チェックであり、クリーンルームの独立実装ではない。別途、外部執筆の仕様準拠Rust実装(ソース公開)は、不変ソースツリーからの評価者管理下の再ビルドで、ピン留めされた16スイート/164ベクトルのバンドルとピン留めされた359ケースの敵対的キャンペーンに合格している。そのチェックイン済み構築証拠は、実装者署名のままであり、第三者認証ではない(署名済みステートメント)。厳格なクリーンルーム受理は、修正された第三者認証マニフェストと独立してピン留めされた証明者キーを待っている。 |
| 形式モデル証拠 | 設定された状態空間で保持される26件の有界TLA+安全性プロパティ。これは実装のリファインメントでも非有界の証明でもない・4つのモデルにわたる35件のAlloyファクト、32件のアサーション・チャレンジ、CAID、2つの承認、発行者と権限のピン、レジストリビュー、失効、消費、実行、および6つの専用クレーム境界をカバーする2つの合成Dovey-Yaoモデル。20件のTamarin補題が検証される — 17件の全トレース義務と3件の存在トレース証人。8件の意図的に弱化された変種は、耐荷重チェックが削除されると具体的な攻撃トレースを生成する(formal/tamarin/)。 |
| MCPレジストリ | 公式MCPレジストリ・Glama(Grade A、Officialバッジ)・Smithery |
| ライセンス | Apache-2.0 |
3つの同一チームのリファレンスポート(JS / Python / Go)は、全21スイートと331ベクトルで一致する。別途、ピン留めされた公開ソースツリーから再ビルドされた外部執筆のRust実装は、ピン留めされた16スイート/164ベクトルのクリーンルームバンドルと359ケースの敵対的キャンペーンに合格し、すべての変更で独自のCIレーンで再実行される。新しいAEC受理と4結果解決スイートはRustに帰属しない。これは外部の相互運用性証拠であり、厳格なクリーンルーム構築の受理ではない。集計CIケースは、独立した認証を待って厳格な受理数をゼロとして記録する。CONFORMANCE.mdを参照するか、emiliaprotocol.ai/verifyでレシートを自分で検証すること。
権限スタック
| レイヤー | 機能 |
|---|---|
| Mandate | ミッション、制限、証拠、有効期限、委任、例外ルールを定義する。 |
| CAID / 正確なアクション | 実質的な実行可能オブジェクトを固定し、証拠が異なる作業に移動できないようにする。 |
| AEC | 独立して検証され一致した証拠が依拠当事者の要件を満たすかどうかを評価する。承認はしない。 |
| AEB / Gate | ローカルの承認判断を行い、対象の権限を予約し、プロバイダーへの進入を制御する。 |
| 結果証拠 | 呼び出し、プロバイダー応答、観測された効果、不確実性を区別して保持する。 |
証明ポイント
| 指標 | 値 |
|---|---|
| 自動テストケース | 533ファイルにわたる8,865件。プラットフォームに適用可能なすべてのケースが合格しなければならない |
| TLA+安全性プロパティ | 設定された状態空間で保持される26件の有界不変条件。実装リファインメントや非有界の証明ではない — PROOF_STATUS.mdを参照 |
| Alloyリレーショナルアサーション | 4つのモデルにわたる35ファクト+32アサーション — CIで検証済み |
| レッドチームケースカタログ | 85件 — RED_TEAM_CASES.md |
| リリースセキュリティステータス | リポジトリのセキュリティチェックは合格。監査対象の変更に対するすべてのStrix指摘は、回帰カバレッジとレビュースレッドの解決をもって是正済み |
| 適合性(7/7) | node conformance/ep-conformance-test.js https://www.emiliaprotocol.ai |
| クロス言語適合性 | 331ベクトル・21スイート:レシート・デバイス署名・4結果解決・マルチパーティクォーラム・失効・Outcome Binding(セマンティック+実暗号)・Authority Document/Proof発行者結合・時刻認証・トラストレシート(x2プロファイル)・来歴・証拠レコード・正規化・境界・AEC受理・通貨・イニシエーター認証・消費証明・証人・タイムスタンプ証明(RFC 3161)。JS / Python / Go検証器が一致(node conformance/run.mjs)。外部Rustベースラインは164ベクトル/16スイートのまま。CONFORMANCE.mdを参照 |
| ハンドシェイク作成p95 | 50 VUで575ms — PERFORMANCE_PROOF.md |
コアプロトコルオブジェクト
| オブジェクト | 概要 |
|---|---|
| 権限プログラム / 有界能力 | 明示的なスコープ、予算またはユニット、有効期限、委任、消費ルールを持つ有限の権限範囲。 |
| CAID | 名前付きマッピングプロファイルの下での単一の実質アクションの標準識別子。マッチングは承認ではない。 |
| 証拠要件とAEC結果 | 依拠当事者のピン留めされたルールと、その SATISFIED、UNSATISFIED、または INDETERMINATE の評価。 |
| AEB受理と管理レコード | 承認、予約、プロバイダー進入、調整状態のエグゼキュータ側レコード。 |
| 承認と結果証拠 | 正確な発行者、スコープ、クレーム境界を保持するポータブルなネイティブまたはEPアーティファクト。 |
クイックスタート
npx @emilia-protocol/scan protect ./tools.jsonを実行して、サポートされている宣言済みサーフェスをマッピングする。- 生成されたアクションマニフェスト、実質フィールド、資格情報、名前付きブラインドスポットをレビューする。
- プロバイダー資格情報と永続的な消費状態を所有するパスにGateをインストールする。
- 運用権限範囲と、新規人間またはクォーラムの例外ルールを定義する。
- 強制を有効にする前に、拒否、正確なアクション、リプレイ、タイムアウト、調整の各ケースを実行する。
90秒デモ・クイックスタート・エージェントウォークスルー・IETF Draft・Discord
EPとは何か — そして何でないか
EMILIAは自律的な作業のための権限インフラであり、アイデンティティシステム、ウォレット、評判スコア、決済レール、または汎用ポリシーエンジンではない。
- である:有限の運用権限範囲、正確なアクション検証、永続的な承認状態、真実に基づく不確実性、カバーされたエグゼキュータパス上のポータブルな証拠のためのコントロールプレーン。
- ではない:OAuth/OIDC、ワークロードアイデンティティ、ポリシーエンジンの置き換え。これらは依拠当事者のピンの下でのネイティブ入力のままである。
- ではない:人間がすべてのアクションを承認するという要件。権限範囲は有限の境界内で自動作業を許可し、境界でのみ新しい権限を要求することができる。
- ではない:承認されたアクションが正常に実行された、または意図した効果を引き起こしたという証明。
- ではない:プロプライエタリなプロトコル制御。コアはApache-2.0であり、Internet-DraftsはRFCやIETFの承認ではなく個人提出である。
CONFORMANCE.md・SECURITY.md・THREAT_MODEL.md・GOVERNANCE.md・Neutrality Covenantを参照のこと