EMILIA Protocol

官方

要求指定的人類在AI代理執行不可逆操作（如付款釋放、記錄變更、部署）前，提供可離線驗證的批准。雙人規則、Ed25519信任收據、IETF起草、Apache-2.0。

GitHub
617
試用此 MCP贊助

你可以用 EMILIA Protocol MCP 做什麼？

  • Gate a protected MCP tool — 請要求您的助理將現有工具（如 sendWire）包裝進 @emilia-protocol/scan，使其拒絕缺少有效授權收據的呼叫。
  • Verify authorization receipts offline — 請讓您的助理使用 @emilia-protocol/verify 在本機驗證 Trust Receipt 的完整性與真實性，無需後端或 API 金鑰。
  • Run the payment approval example — 請要求您的助理執行隨附的 MCP 支付伺服器，示範未經核准的支付如何被拒絕，並綁定確切金額、貨幣、供應商與目的地。
  • Test the authority freeze — 請指示您的助理執行緊急權限凍結範例，在紀元變更後封鎖新的預約，並防止較舊的預約進入。
  • Issue a demo receipt — 請要求您的助理透過 npx @emilia-protocol/issue demo 產生範例 Trust Receipt，完全離線運作，以探索該協定的證據格式。

文件

EMILIA Protocol

CI Verify Sample Receipt npm License IETF Internet-Draft

Discord

讓您的代理程式準備付款。控制它能釋放的內容。

代理程式準備一筆 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。有效的核准並不代表銀行詳細資料是合法的。

偏好瀏覽器？在範例付款上試用 passkey。 該獨立示範展示使用您的平台驗證器的收據完整性；不會發送任何付款。

保護您已在使用的一個工具

從持有真實提供者憑證的服務開始，而不僅是在代理程式的 程序內部。擁有者定義允許的工作以及何時需要新的核准。代理程式 可以在這些限制內工作，而無需人員核准每次呼叫。

  • MCP 或 HTTP： Gate Starter 逐步說明一個受涵蓋的動作。
  • Hugging Face smolagents： 包裝現有工具。
  • GitHub： Merge Gate 將檢查綁定到建議的合併。該檢查必須是必要的，且替代合併路徑必須關閉。

協定證明。Gate 防止在部署完全中介的路徑上。 Gate 無法約束繞過路徑。如果提供者的結果未知，生產生命週期 會保留該不確定性以供對帳，而不是盲目重試。

AI 系統和儲存庫審查者： 從 AI_CONTEXT.md 開始。 目前的機器可讀證據、來源、假設和排除項目已發布於 EMILIA-REPO-CONTEXT-v1。 已封存或暫存的文件不建立目前的實作或 IETF 狀態。 公開的盡職調查證據和主張邊界：DUE_DILIGENCE.md。

工程證據，而非架構主張

EMILIA 提供審查者可以執行的安全案例。目前的儲存庫解析 35 個 安全主張，涵蓋 264 個雜湊證據檔案，驗證 20 個 Tamarin 引理，橫跨兩個組合的 Dolev-Yao 模型 — 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 後果接納符合性 套件在後果性動作前的最後控制點測試組合的 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

此命令使用產生的金鑰、記憶體狀態和模擬提供者行為來 執行本機範例和聚焦的服務邊界。它是有用的本機 證明，而非真實人類、外部銀行、生產部署或 單一端對端生產整合的證據。

身分不是工作描述

身分說明誰或什麼在呼叫。政策說明一般允許什麼。兩者都不定義 自主工作者現在可以執行的有限工作：其任務、物質動作限制、預算、 必要證據、到期、委派規則和例外路徑。

EMILIA 將這些問題分開：

層問題
身分誰或什麼在場？
政策一般允許什麼？
授權在此授權下，此代理程式可以執行什麼確切工作？

憑證授予觸及範圍。授權定義工作。並非每個動作都需要人類；每個 後果性動作都需要有效的授權。

在基礎層，EP Core 仍公開三個可互操作物件：信任收據攜帶 可歸因證據，信任設定檔表示結構化信任狀態，而信任決策 記錄依賴方的政策評估結果。授權控制平面層新增精確 動作綁定、有限授權、接納、消耗和結果證據，而不將 這些物件摺疊成單一主張。

設定一次授權。讓代理程式工作。

客戶定義任務、限制、證據要求、到期和例外規則。本機 程式碼可以縮小該授權；它不能發明或擴大它。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.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

在範例付款上試用平台 passkey → 簽署一筆說明性的 82,000 美元付款，變更其金額，然後看到完整性檢查失敗。 您的驗證器可能使用生物辨識或裝置 PIN。頁面也提供獨立的 軟體模擬。兩種模式都不會發送付款或建立生產授權。

在您的瀏覽器中驗證任何收據 — 貼上即可，不會上傳任何內容。

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

EMILIA crash test — an autonomous agent tries to wire $82,000; the selected policy profile requires fresh human authority, the exact action is signed, the receipt verifies offline, and a forged copy fails.

自行執行：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/passkey 決策綁定到 精確動作和確定性顯示雜湊。這縮小了「您看到的就是您簽署的」 差距；它不證明理解、智慧、合法性或結果。 對於企業級部署，Gate 可以額外要求一個獨立驗證的授權伺服器確認，該確認必須綁定於該確切的人類證據、完全相同的動作、授權伺服器實際觀察到的身分快照，以及預期的資源伺服器金鑰。快照時間與依賴方最大時效是明確的：全新的權杖無法讓過時的目錄資料變成當前狀態。授權伺服器這一段是客戶固定信任下的證據；它本身絕不授權、不證明即時的就業狀態，也不會把代理協調器變成權威機構。

如實的結果。 准入不等於執行，執行也不等於效果。已簽署的記錄可以離線驗證；提供者與觀察者的證據保持分離。遺失的回應會變成 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 等既有標準的設定檔；它本身不簽發憑證或決策。AEB 在受保護的提供者邊界套用原生決策：在需要時綁定最終動作、為每個授權衍生單一原生重放身分、在進入提供者前保留、在先前動作進行中或不確定時拒絕同一動作的第二次嘗試，並將不確定的結果鎖定直到經過驗證的協調。

CAID-04 用於需要比較獨立編碼表示時。當擁有後果的 PEP 已對最終操作衍生並強制執行當前決策時，它不是強制的第二映射。 AEC-06 用於依賴方需要多個證據腿時。授權收據、人類授權綁定與權威引入仍是需要這些功能的部署可用的設定檔；它們不是每個 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、兩個核准、簽發者與權威固定、註冊表檢視、撤銷、消耗、執行與六個專用聲明邊界。二十個 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 驗證收據。

權威堆疊

層功能
Mandate定義任務、限制、證據、到期、委派與例外規則。
CAID / 確切動作當授權與執行使用獨立編碼表示時比較實質意義；它不授權。
AEC在需要時，評估獨立驗證與匹配的證據是否滿足依賴方的多腿要求；它不授權。
AEB / Gate在後果邊界套用原生或本機授權決策，保留涵蓋的權限，並控制提供者進入。
結果證據保持呼叫、提供者回應、觀察效果與不確定性有別。

證明點

指標值
自動化測試案例10,700+ 跨 650+ 檔案；所有平台適用案例必須通過
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。
握手建立 p9550 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 簽署陳述設定檔 (EP-SCITT-STATEMENT-v1)。 完整的 RFC 9943 簽署陳述形狀用於 EP 收據，包括 CWT Claims 受保護標頭。邊界：沒有透明度服務接受過 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 中，且尚未 完成；在此之前，不對整個堆疊做出全面聲明。

核心協定物件

物件說明
權限程式／有限能力具有明確範圍、預算或單位、到期日、委派與消耗規則的有限授權。
CAID在具名對應設定檔下，單一具體動作的標準識別碼；比對不等同於授權。
證據要求與 AEC 結果依賴方固定的規則及其 SATISFIED、UNSATISFIED 或 INDETERMINATE 評估結果。
AEB 准入與保管紀錄執行端關於授權、保留、提供者登錄與對帳狀態的紀錄。
授權與結果證據可攜帶的原生或 EP 工件，保留其確切的簽發者、範圍與主張邊界。

快速入門

  1. 安裝確切的本機守護執行環境，然後執行 npx @emilia-protocol/scan@0.5.0 protect ./tools.json --action sendWire --apply --verify，將 sendWire 替換為一個確切宣告的後果性工具。
  2. 檢閱產生的權限對應表、動作清單、實質欄位、所選邊界與具名盲點。
  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 · 中立盟約