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。有效的核准並不能證明銀行資料真實無誤。

偏好使用瀏覽器？在範例付款上試用通行金鑰。 此獨立示範會使用你的平台驗證器展示收據完整性；不會送出付款。

保護你已在使用的工具

從持有真正提供者憑證的服務著手，而不只是代理程式的程序內部。負責人定義允許執行的工作，以及何時需要重新核准。代理程式可以在這些限制內工作，不必每次呼叫都由人員核准。

• MCP 或 HTTP：Gate Starter 會逐步說明如何涵蓋一項動作。
• Hugging Face smolagents：包裝現有工具。
• GitHub：Merge Gate 會將檢查綁定至提議的合併。該檢查必須設為必要條件，並封閉其他合併路徑。

Protocol 證明；Gate 在部署完全中介的路徑上阻止未授權操作。 Gate 無法限制繞過它的路徑。如果無法確定提供者的結果，正式環境生命週期會保留此不確定性以供調解，而不是盲目重試。

**AI 系統與儲存庫審查者：**請從 AI_CONTEXT.md 開始。 最新的機器可讀證據、來源資訊、假設與排除事項，發布於 EMILIA-REPO-CONTEXT-v1。 封存或暫存文件不能證明目前的實作或 IETF 狀態。 公開的盡職調查證據與聲明界線：DUE_DILIGENCE.md。

工程證據，而非架構宣稱

EMILIA 提供可供審查者執行的安全案例。目前的儲存庫解析 35 項安全聲明，涵蓋 264 個已雜湊的證據檔案，驗證 兩個組合式 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，CAID 僅在必須合併獨立編碼的動作時使用，AEC 僅在本機政策要求多項證據時使用。AEB-07 於 2026-09-25 以個人 Internet-Draft 形式發布，尚未獲任何工作組採納。另有一個獨立的 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

更深入的組合示範會透過 Gate 真正的有限能力路徑，執行由 CAID 綁定的委派付款，接著離線驗證已簽署的執行 憑證：

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 的緊急授權凍結會阻止新的保留，並在受涵蓋控制網域的 epoch 變更後，防止較早的保留進入。如果先前已進入提供者，該次嘗試仍視為已消耗，且需要調解。恢復授權不會讓舊保留重新生效。

這需要完整中介與權威共用狀態。它不會停止運算、逆轉效果，也無法即時觸及中斷連線的網域。請參閱控制網域的實作與限制。

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。頁面也提供獨立的軟體模擬。兩種模式都不會送出付款，也不會建立正式環境授權。

在瀏覽器中驗證任何收據 — 貼上收據即可，不會上傳任何資料。

---

運作方式 — 單一授權生命週期

自行執行：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 還可以要求由獨立驗證的 Authorization Server 確認，並將其綁定至該項確切的人類證據、同一項確切動作、AS 實際觀察到的身分快照，以及預定的 Resource Server 金鑰。快照時間與依賴方的最長有效時間都是明確指定的：新鮮的權杖無法讓過時的目錄資料變成最新資料。AS 這一環是在客戶釘選的信任之下提供的證據；它本身不會授權、不會證明即時的在職狀態，也不會讓代理程式協調器成為權威。

如實呈現結果。 准入不等於執行，執行也不等於產生效果。簽署的紀錄可離線驗證；提供者與觀察者的證據仍各自獨立。回應遺失時會變成 INDETERMINATE，這是一種需要調和的狀態，而不是重試的許可。補救措施是新的授權動作，絕不會改寫舊結果。

---

開發者為何使用它

先在本機盤點工作，再用 MCP server 或精簡的 SDK wrapper 保護一個已宣告的動作介面。掃描器會提出可供審查的盤點結果；負責人定義授權範圍；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 於 2026 年 10 月 6 日註冊。它識別由已發布的序列化規格定義的裸 AE-CHALLENGE-v1 JSON 物件。 HTTP 拒絕回應仍使用 application/problem+json。
• canactid: 於 2026 年 10 月 5 日暫時註冊。它命名 CAID-05 下的確切型別化動作。其更正後的 CRI scheme number is 1033。

這些註冊發布了名稱及其規格，但不代表 IETF 採納、背書、認證或客戶部署。

單一後果邊界介面

目前已發布的 AEB-07， 於 2026-09-25 以個別 Internet-Draft 發布，尚未獲採納；它將 AEB 定為原生決策之後的組合點。OAuth、AuthZEN、COAZ、AP2 與本機系統仍各自掌管其憑證、作業對應與授權決策。AIMS (draft-ietf-wimse-aims) 是 Informational WIMSE 工作組文件，為 WIMSE 與 OAuth 等既有標準制定設定檔；它本身不會簽發憑證或作出決策。AEB 會在受保護的提供者邊界套用原生決策：必要時綁定最終動作、為每項授權導出一個原生重播識別碼、在進入提供者之前預留權限、在先前嘗試仍在進行或結果不確定時拒絕對同一動作進行第二次嘗試，並將不確定結果維持鎖定，直到完成已驗證的調和。

需要比較獨立編碼的表示形式時，會使用 CAID-05。 新識別碼使用 IANA 暫時註冊的 canactid: URI scheme。此註冊不代表 IETF 採納、背書、認證或永久狀態。若負責後果的 PEP 已能針對最終作業導出並強制執行目前的決策，CAID 就不是必須額外進行的第二次對應。 試用確切動作互動展示，或閱讀 CAID-04 至 CAID-05 遷移指南。 依賴方要求多個證據環節時，會使用 AEC-06。 Authorization Receipts、Human Authorization Binding 與 Authority Introduction 仍可作為部署設定檔供有需要的部署使用；它們並非每項 AEB 整合的先決條件。Architecture-03 仍是導覽文件。

後果准入指南說明 實作邊界，以及不需要 AEB 的情況。 直接原生交接設定檔 是儲存庫中的實作設定檔，展示既有許可如何在不增加第二層 CAID 或 AEC 的情況下交給 Gate。AEB-07 規定此類閘道交接所證明的內容，以及邊界如何驗證該證明，但將編碼方式留給部署釘選；它引用此設定檔的釘選快照，作為一種資訊性參考編碼。確切提交的 -07 位元組與其發布紀錄保存在 standards/staged/NEXT-AEB-07。

完整的現行作品集包含 26 筆 Datatracker 紀錄：21 筆由單一作者撰寫，五筆由多位作者合著；每筆都有自己的範圍、修訂歷史與記錄在案的維護狀態。請參閱標準指南、 作品集，以及機器可讀的 狀態清單。

IETF Internet-Drafts	目前的本機快照路徑：狀態清單 · 單一作者的已發布清單 · 權威即時狀態：IETF Datatracker
跨語言驗證器	JavaScript · Python · Go — 三者皆已證明能在對抗性一致性測試向量上保持一致，每次推送皆如此 (npm run conformance)。這是同一團隊各語言移植版本之間的一致性檢查，並非由不同團隊獨立實作。此外，一個由外部作者依規格撰寫的 Rust 實作（原始碼公開），在評估者控制下，從不可變的原始碼樹重新建置後，通過釘選的 16 個測試套件／164 個測試向量組合，以及釘選的 359 個案例對抗性測試。其簽入的建置證據仍由實作者簽署，並非第三方證明（簽署聲明）；嚴格的獨立實作驗收仍待修正後、經第三方證明的資訊清單，以及獨立釘選的證明者金鑰。
形式模型證據	26 項有界 TLA+ 安全性屬性在其設定的狀態空間內成立；這不代表實作精化或無界證明 · 四個模型中有 35 項 Alloy 事實、32 項斷言 · 兩個組合式符號 Dolev-Yao 模型涵蓋挑戰、CAID、兩項核准、簽發者與權限釘選、登錄檢視、撤銷、使用、執行，以及六個專用宣稱邊界。20 項 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	在後果邊界套用原生或本機授權決策、預留受涵蓋的權限，並控制是否進入提供者。
結果證據	區分呼叫、提供者回應、觀察到的效果與不確定性。

---

證明指標

指標	數值
自動化測試案例	650 多個檔案中有 10,700 多個；所有適用於平台的案例都必須通過
TLA+ 安全性屬性	26 項有界不變條件在設定的狀態空間內成立；不代表實作精化或無界證明 — 請參閱 PROOF_STATUS.md
Alloy 關係式斷言	四個模型中有 35 項事實 + 32 項斷言 — 已在 CI 中驗證
已編目紅隊案例	86 項 — RED_TEAM_CASES.md
發布安全狀態	儲存庫安全檢查皆通過；稽核變更中的每項 Strix 發現均已修正並加入回歸測試，且其審查討論串已結案
一致性（7/7）	node conformance/ep-conformance-test.js https://www.emiliaprotocol.ai
跨語言一致性	340 個測試向量 · 21 個測試套件：收據 · 裝置簽署 · 四結果調和 · 多方法定人數 · 撤銷 · 結果綁定（語意 + 真實密碼學）· 權限文件／證明簽發者關聯 · 時間證明 · 信任收據（x2 個設定檔）· 來源資訊 · 證據紀錄 · 正規化 · 邊界 · AEC 驗收 · 貨幣 · 發起者證明 · 使用證明 · 見證 · 時間戳記證明（RFC 3161）。JS / Python / Go 驗證器結果一致 (node conformance/run.mjs)。外部 Rust 基準仍為 164 個測試向量／16 個測試套件。請參閱 CONFORMANCE.md。
Handshake 建立 p95	50 VUs 下為 575ms — 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)。 完整符合 RFC 9943 Signed Statement 格式的 EP 收據，包含 CWT Claims 受保護標頭。界線：尚無 Transparency Service 接受任何 EP statement；外部註冊是獨立且受控的步驟，目前尚未執行。請參閱 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	依具名對應設定檔，為單一實質動作建立的標準識別碼；相符不代表已獲授權。
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 替換為一個明確宣告的重大工具。
2. 檢視產生的 Authority Map、動作資訊清單、實質欄位、選定的界線及具名盲點。
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 · 中立性公約