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は厳格モードでチェックされています。これは、リポジトリが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

これはフォーマット中立で自己実行型です。合格レポートは自己証明された 適合性証跡であり、監査、認証、本番デプロイメントの 主張、またはアクションの実行許可ではありません。

AEB-07に基づき、2026-09-25に個々のインターネットドラフトとして投稿され、いかなるワーキンググループにも採用されていない場合、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

このコマンドは、生成された鍵、インメモリ状態、およびモックプロバイダー動作を使用して、ローカル例と焦点を絞ったサービス境界を実行します。これは有用なローカル証明ですが、実際の人間、外部銀行、本番デプロイメント、または1つのエンドツーエンドの本番統合の証跡ではありません。

アイデンティティは職務記述書ではない

アイデンティティは、誰がまたは何が呼び出しているかを示します。ポリシーは、一般的に何が許可されているかを示します。どちらも、自律ワーカーが今実行できる有限のジョブを定義しません: そのミッション、重要なアクションの制限、予算、必要な証跡、有効期限、委任ルール、および例外パス。

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

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

宣言された1つの結果的なMCPアクションから始めます。正確なローカルランタイムをインストールし、Gate Starterを作成して、有界の4ケースチェックを実行します:

npm install --save-exact @emilia-protocol/mcp-guard@0.6.0
npx @emilia-protocol/scan@0.5.0 protect ./tools.json --action sendWire --apply --verify

# after reading emilia/authority-map.html and action-control.manifest.json
npx @emilia-protocol/scan@0.5.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/パスキー決定を要求できます。これにより、「見たものが署名したもの」というギャップが狭まります。理解、賢明さ、合法性、または結果を証明するものではありません。 For enterprise deployments, Gate can additionally require an independently verified Authorization Server confirmation bound to that exact human evidence, the same exact action, the identity snapshot the AS actually observed, and the intended Resource Server key. The snapshot time and relying-party maximum age are explicit: a fresh token cannot make stale directory data current. The AS leg is evidence under customer-pinned trust; it never authorizes by itself, proves instantaneous employment standing, or turns the agent orchestrator into an authority.

Truthful result. Admission is not execution, and execution is not effect. A signed record can be verified offline; provider and observer evidence remain separate. A lost response becomes INDETERMINATE, which is a state to reconcile—not permission to retry. A remedy is a new authorized action and never rewrites the old result.

---

Why developers use it

Start by mapping the work locally, then protect one declared action surface with the MCP server or thin SDK wrapper. The scanner proposes a reviewable map; the owner defines the mandate; Gate owns the provider credential and enforces the exact action on the covered path. No scan proves complete mediation, and discovery alone grants no authority.

# 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

The agent receives the ability to perform bounded work, not a standing credential it can reinterpret.

---

Why enterprises need it

Agent processes restart and models change. The customer's mandate, consumption state, revocation, uncertainty, and work history must survive outside them. EMILIA keeps that durable authority state at the customer's boundary while accepting foreign proof through pinned adapters.

The managed Gate and Assurance Plane add mandate operations, integrations, evidence operations, re-performance, support, and service levels around the open protocol. The customer retains control of authority, trust roots, credentials, policy, and portable evidence.

---

The standard

EMILIA Protocol is open and Apache-2.0. Its standards work is published as a portfolio of individual Internet-Drafts. A published Internet-Draft is not an RFC, an adopted working-group item, or IETF endorsement; Datatracker is authoritative for revision and status.

One consequence-boundary surface

The current published AEB-07, posted on 2026-09-25 as an individual Internet-Draft and not adopted, makes AEB the composition point after a native decision. OAuth, AuthZEN, COAZ, AP2, and local systems keep ownership of their credentials, operation mappings, and authorization decisions. AIMS (draft-ietf-wimse-aims) is an Informational WIMSE working-group document that profiles existing standards such as WIMSE and OAuth; it does not itself issue credentials or decisions. AEB applies the native decision at the protected provider boundary: it binds the final action when needed, derives one native replay identity per grant, reserves before provider entry, refuses a second attempt at the same action while an earlier one is in flight or uncertain, and keeps an uncertain result locked until authenticated reconciliation.

CAID-04 is used when independently encoded representations must be compared. It is not a mandatory second mapping when the consequence-owning PEP already derives and enforces a current decision over the final operation. AEC-06 is used when the relying party requires several evidence legs. Authorization Receipts, Human Authorization Binding, and Authority Introduction remain available profiles for deployments that need them; they are not prerequisites for every AEB integration. Architecture-03 remains the navigation document.

The consequence-admission guide states the implementation boundary and the cases where AEB is unnecessary. The direct native handoff profile is a repository implementation profile that shows how an existing permit reaches Gate without a second CAID or AEC layer. AEB-07 specifies what such a gateway handoff attests and how the boundary verifies it, but leaves the encoding to deployment pins; it cites a pinned snapshot of this profile as one informative reference encoding. The exact submitted -07 bytes and their publication record are retained in standards/staged/NEXT-AEB-07.

The complete active portfolio is 26 Datatracker records: 21 sole-authored records and five coauthored records, each with its own scope, revision history, and recorded maintenance status. See the standards guide, portfolio, and machine-readable status inventory.

IETF Internet-Drafts	Current local snapshot paths: status inventory · sole-authored posted inventory · authoritative live status: IETF Datatracker
Cross-language verifiers	JavaScript · Python · Go — all three proven to agree on adversarial conformance vectors, every push (npm run conformance). A consistency check across one team's ports, not clean-room independent implementations. Separately, an externally authored from-spec Rust implementation (source public) passes the pinned 16-suite/164-vector bundle and the pinned 359-case hostility campaign under an evaluator-controlled rebuild from an immutable source tree. Its checked-in construction evidence remains implementer-signed, not third-party-attested (signed statement); strict clean-room acceptance waits for the corrected third-party-attested manifest and independently pinned attestor key.
Formal-model evidence	26 bounded TLA+ safety properties held in their configured state spaces; this is not implementation refinement or an unbounded proof · 35 Alloy facts, 32 assertions across four models · two composed symbolic Dolev-Yao models covering challenge, CAID, two approvals, issuer and authority pins, registry view, revocation, consumption, execution, and six dedicated claim boundaries. Twenty Tamarin lemmas verify — 17 all-traces obligations and 3 exists-trace witnesses; eight deliberately weakened variants produce concrete attack traces when load-bearing checks are removed (formal/tamarin/).
MCP distribution	npm package @emilia-protocol/mcp-server · official Registry publication is tracked separately in MCP-REGISTRY.md; aggregator listings are not inferred from either state
License	Apache-2.0

Three same-team reference ports (JS / Python / Go) agree across all 21 suites and 340 vectors. Separately, an externally authored Rust implementation rebuilt from a pinned public source tree passes the pinned 16-suite/164-vector clean-room bundle and a 359-case hostility campaign, re-run in its own CI lane on every change. The newer AEC acceptance and four-outcome resolution suites are not attributed to Rust. That is external interoperability evidence, not strict clean-room construction acceptance; the aggregate CI case records the strict acceptance count as zero pending independent attestation. See CONFORMANCE.md, or verify a receipt yourself at emiliaprotocol.ai/verify.

---

The authority stack

Layer	What it does
Mandate	Defines mission, limits, evidence, expiry, delegation, and exception rules.
CAID / exact action	Compares material meaning when authorization and execution use independently encoded representations; it does not authorize.
AEC	When required, evaluates whether independently verified and matched evidence satisfies the relying party's multi-leg requirement; it does not authorize.
AEB / Gate	Applies the native or local authorization decision at the consequence boundary, reserves the covered authority, and controls provider entry.
Outcome evidence	Keeps invocation, provider response, observed effect, and uncertainty distinct.

---

Proof points

Metric	Value
Automated test cases	10,700+ across 650+ files; all platform-applicable cases must pass
TLA+ safety properties	26 bounded invariants held in the configured state space; not an implementation-refinement or unbounded proof — see PROOF_STATUS.md
Alloy relational assertions	35 facts + 32 assertions across four models — verified in CI
Red-team cases cataloged	86 — RED_TEAM_CASES.md
Release security status	Repository security checks pass; every Strix finding on the audited changes is remediated with regression coverage and its review thread resolved
Conformance (7/7)	node conformance/ep-conformance-test.js https://www.emiliaprotocol.ai
Cross-language conformance	340 vectors · 21 suites: receipts · device signoffs · four-outcome resolution · multi-party quorum · revocation · Outcome Binding (semantic + real-crypto) · Authority Document/Proof issuer join · time-attestation · trust-receipt (x2 profiles) · provenance · evidence-record · canonicalization · boundary · AEC acceptance · currency · initiator-attestation · consumption-proof · witness · timestamp-proof (RFC 3161). JS / Python / Go verifiers agree (node conformance/run.mjs). The external Rust baseline remains 164 vectors / 16 suites. See CONFORMANCE.md.
Handshake create p95	575ms at 50 VUs — PERFORMANCE_PROOF.md

Cryptographic longevity (with explicit deployment boundaries)

Evidence meant to be verified years later must outlive the algorithms it was signed under. EP ships four bounded capabilities for that, each with an exact boundary that is part of the claim:

• Hybrid signatures (EP-RECEIPT-HYBRID-v1). Ed25519 and ML-DSA-65 over the same canonical bytes, with the required algorithm set committed into the signed bytes so stripping a leg breaks the surviving signature. The capability is opt-in at deployment; once an approved dual signer is registered and policy permits its PQ leg, an unpinned Gate posture resolves to dual issuance by default. Otherwise it stays classical-only with a named reason. v1 verifiers refuse hybrid receipts cleanly rather than accepting one leg. The external signer contract and AWS KMS adapter are implemented, but no live AWS signing call, production key, relying-party verification, or ML-DSA FIPS validation is claimed. See conformance/hybrid-receipts/ and lib/pq-custody-aws-kms.ts.
• SCITT Signed Statement profile (EP-SCITT-STATEMENT-v1). A complete RFC 9943 Signed Statement shape for EP receipts, including the CWT Claims protected header. Boundary: no Transparency Service has accepted an EP statement; external registration is a separate, gated step and none has been performed. See EP-RECEIPT-SCITT-PROFILE.md.
• Re-attestation (EP-EVIDENCE-REATTESTATION-v1). Evidence signed under an aging algorithm can be re-anchored under a current one before the old one weakens. Boundary: re-attestation must precede compromise; it cannot repair evidence after the fact.
• FIPS deployment mode (EP-FIPS-MODE-v1). Runs classical operations through an operator-supplied FIPS 140-3 validated provider, with the ML-DSA path gated behind an explicit unvalidated-implementation acknowledgment. Boundary: this earns "FIPS-based algorithms, with a validated-provider deployment mode" and depends on the operator's provider and declared certificate boundary; it is not a blanket compliance claim, and nothing here is FIPS validated. See FIPS-MODE.md.

The stack-wide hybrid program (every internal signature surface) is mapped in pq-hybrid-program.md and is not complete; until it is, no blanket claim about the whole stack is made.

---

Core protocol objects

オブジェクト	その内容
権限プログラム／有界ケーパビリティ	明示的なスコープ、予算または単位、有効期限、委任、消費ルールを持つ有限の権限委任。
CAID	名前付きマッピングプロファイルに基づく1つの具体的なアクションの正規識別子。マッチングは認可ではない。
証拠要件とAEC結果	依存当事者が固定したルールと、そのSATISFIED、UNSATISFIED、またはINDETERMINATE評価。
AEB受理記録と保管記録	実行側における認可、予約、プロバイダー登録、照合状態の記録。
認可と結果の証拠	発行者、スコープ、クレーム境界を正確に保持する、ポータブルなネイティブまたはEPアーティファクト。

---

クイックスタート

1. 正確なローカルガードランタイムをインストールし、npx @emilia-protocol/scan@0.5.0 protect ./tools.json --action sendWire --apply --verifyを実行します。sendWireは、宣言された具体的な結果的ツールの1つに置き換えます。
2. 生成された権限マップ、アクションマニフェスト、重要フィールド、選択された境界、名前付きブラインドスポットを確認します。
3. 別の--reviewed --crossing-profile <launch-profile>コマンドを実行して、その変更されていないバイトからオーナーのみのハンドオフとシール解除されたLabワークスペースを作成します。
4. プロバイダー資格情報と永続的な消費状態を保持するパスにGateをインストールします。
5. 運用マンデートと、フレッシュヒューマンまたはクォーラム例外ルールを定義します。
6. 強制を有効にする前に、拒否、正確なアクション、リプレイ、タイムアウト、照合の各ケースを実行します。

90秒デモ · クイックスタート · エージェントウォークスルー · IETFドラフト · Discord

---

EPとは何か、何でないか

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

• である: 有限の運用マンデート、正確なアクション検証、永続的な受理状態、誠実な不確実性、および対象となる実行パス上のポータブルな証拠のためのコントロールプレーン。
• でない: OAuth/OIDC、ワークロードアイデンティティ、またはポリシーエンジンの置き換え。これらは依存当事者のピンの下でネイティブ入力として残ります。
• でない: すべてのアクションに人間の承認を要求するもの。マンデートは、有限の境界内での自動作業を許可し、境界でのみ新しい権限を要求することができます。
• でない: 受理されたアクションが正常に実行された、または意図した効果を引き起こしたことの証明。
• でない: 独自プロトコル制御。コアはApache-2.0であり、インターネットドラフトは個人提出物であり、RFCやIETFの承認ではありません。

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