EMILIA Protocol

EMILIA Protocol

---

Để agent chuẩn bị khoản thanh toán. Kiểm soát những gì agent có thể giải ngân.

Một agent chuẩn bị khoản thanh toán 82.000 USD cho nhà cung cấp. Có người phê duyệt khoản thanh toán. Sau đó, số tiền hoặc đích đến ngân hàng thay đổi. Phê duyệt trước đó không được phép giải ngân khoản thanh toán đã thay đổi.

EMILIA Gate kiểm tra thẩm quyền trước khi một công cụ được bảo vệ chạy. Giao thức mở giúp bằng chứng thu được có thể được kiểm tra độc lập theo các khóa và quy tắc đáng tin cậy của bên xác minh. Tiếp tục sử dụng nhà cung cấp danh tính, khung agent và hệ thống nghiệp vụ hiện có của bạn.

Chạy ví dụ thanh toán

Với Node.js 20.19 trở lên và npm đã cài đặt:

git clone https://github.com/emiliaprotocol/emilia-protocol.git
cd emilia-protocol
npm ci
FAST=1 node examples/mcp/payment-server.mjs

Ví dụ từ chối lời gọi nếu chưa được phê duyệt, ràng buộc phê duyệt với số tiền, đơn vị tiền tệ, nhà cung cấp và đích đến, chấp nhận lời gọi khớp đúng một lần, đồng thời từ chối thông tin thanh toán đã thay đổi, phát lại và bằng chứng giả mạo. Xem ví dụ và các giới hạn.

Đây là bản minh họa chạy cục bộ: khóa ký được tạo tự động, trạng thái tiêu thụ trong bộ nhớ và công cụ thanh toán giả lập. Bản này không thực hiện quy trình phê duyệt thực sự của con người hay chuyển tiền. Môi trường production cần thông tin xác thực đã đăng ký, trạng thái dùng chung bền vững và Gate trên mọi đường dẫn đến thông tin xác thực của nhà cung cấp được bảo vệ. Phê duyệt hợp lệ không chứng minh thông tin ngân hàng là chính đáng.

Thích dùng trình duyệt hơn? Thử passkey với khoản thanh toán mẫu. Bản demo riêng này cho thấy tính toàn vẹn của biên nhận bằng trình xác thực nền tảng của bạn; không có khoản thanh toán nào được gửi đi.

Bảo vệ một công cụ bạn đang dùng

Bắt đầu từ dịch vụ lưu thông tin xác thực thực của nhà cung cấp, không chỉ bên trong tiến trình của agent. Chủ sở hữu xác định công việc được phép và thời điểm cần phê duyệt mới. Agent có thể làm việc trong các giới hạn đó mà không cần người phê duyệt từng lời gọi.

• MCP hoặc HTTP: Gate Starter hướng dẫn cách triển khai một hành động được bảo vệ.
• Hugging Face smolagents: bọc một công cụ hiện có.
• GitHub: Merge Gate ràng buộc một lần kiểm tra với nội dung merge được đề xuất. Lần kiểm tra phải là bắt buộc và các đường dẫn merge thay thế phải bị đóng.

Giao thức chứng minh. Gate ngăn chặn trên các đường dẫn được triển khai kiểm soát hoàn toàn. Gate không thể hạn chế đường dẫn bỏ qua. Nếu chưa rõ kết quả từ nhà cung cấp, vòng đời production giữ nguyên trạng thái chưa chắc chắn đó để đối soát thay vì thử lại một cách mù quáng.

Hệ thống AI và người đánh giá kho lưu trữ: bắt đầu với AI_CONTEXT.md. Bằng chứng hiện tại ở định dạng máy đọc được, nguồn gốc, giả định và nội dung loại trừ được công bố tại EMILIA-REPO-CONTEXT-v1. Tài liệu đã lưu trữ hoặc đang ở giai đoạn chuẩn bị không chứng minh việc triển khai hiện tại hay trạng thái IETF. Bằng chứng thẩm định công khai và ranh giới của các tuyên bố: DUE_DILIGENCE.md.

Bằng chứng kỹ thuật, không phải tuyên bố về kiến trúc

EMILIA cung cấp một hồ sơ bảo mật mà người đánh giá có thể chạy. Kho lưu trữ hiện tại giải quyết 35 tuyên bố bảo mật trên 264 tệp bằng chứng có mã băm, xác minh 20 bổ đề Tamarin trên hai mô hình Dolev-Yao được kết hợp — 17 nghĩa vụ đúng với mọi vết và 3 nhân chứng về khả năng đạt được theo vết tồn tại — đồng thời lưu giữ 8 biến thể bị làm yếu có chủ đích, tạo ra các vết tấn công cụ thể khi loại bỏ những bước kiểm tra then chốt. Bộ kiểm thử tuân thủ hiện hành của cùng nhóm có 21 bộ kiểm thử và 340 vector hiện tại. Riêng biệt, một trình xác minh Rust do bên ngoài phát triển được ghim vào gói đã đóng băng gồm 16 bộ kiểm thử/164 vector và một chiến dịch kiểm thử đối kháng gồm 359 trường hợp. Bộ kiểm thử rộng hơn có hơn 10.700 kiểm thử tự động trên hơn 650 tệp.

Các bề mặt JavaScript production và JSDoc được kiểm tra kiểu bằng trình biên dịch TypeScript checkJs; ứng dụng bảo mật có dự án trình biên dịch tương thích riêng, trong khi các khai báo và SDK TypeScript công khai được kiểm tra ở chế độ nghiêm ngặt. Đây là phạm vi kiểm tra kiểu production đã cấu hình đầy đủ, không phải tuyên bố rằng toàn bộ kho lưu trữ đã được chuyển đổi từ JavaScript sang TypeScript hoặc mọi dự án JavaScript đều bật tùy chọn strict của TypeScript.

Mỗi tuyên bố bảo mật nêu rõ đường dẫn thực thi, vector tích cực và tiêu cực, phạm vi hình thức hoặc khoảng trống được nêu rõ, các giả định, nội dung loại trừ và mã băm bằng chứng. Bắt đầu với bản đồ bằng chứng dành cho người đọc, sau đó xem hồ sơ bảo mật đã được giải quyết hoặc chạy npm run check:security-case.

AEB-1: kiểm thử ranh giới từ bằng chứng đến tác động

Gói mở AEB-1 Consequence Admission Conformance kiểm thử đường dẫn CAID/AEC kết hợp tại điểm kiểm soát cuối cùng trước một hành động có hệ quả: xác minh gốc, chấp nhận của bên dựa vào, ràng buộc chính xác hành động, đối chiếu CAID bắt buộc, đáp ứng bằng chứng AEC bắt buộc, ủy quyền cục bộ, đặt chỗ nguyên tử, lưu giữ INVOKING, tách biệt sự thật về kết quả từ nhà cung cấp với sự thật về tác động đã quan sát, không thử lại mù quáng và đối soát có xác thực.

Đọc về ranh giới tiếp nhận hành động có hệ quả để biết phân chia trách nhiệm chính xác giữa đường dẫn CAID/AEC kết hợp, đường dẫn gốc trực tiếp, lưu giữ AEB và bằng chứng về kết quả từ nhà cung cấp.

npx @emilia-protocol/verify aeb-conformance --reference

Gói này không phụ thuộc định dạng và có thể tự chạy. Báo cáo đạt là bằng chứng tuân thủ do bên tự đánh giá xác nhận, không phải cuộc kiểm toán, chứng nhận, tuyên bố triển khai production hay quyền thực thi hành động.

Theo AEB-07, được đăng ngày 2026-09-25 dưới dạng Internet-Draft cá nhân và chưa được nhóm công tác nào thông qua, CAID chỉ được dùng khi cần kết hợp các hành động được mã hóa độc lập, còn AEC chỉ được dùng khi chính sách cục bộ yêu cầu nhiều nhánh bằng chứng. Một bộ kiểm thử tổng hợp riêng gồm 26 trường hợp mô hình hóa vòng đời gốc trực tiếp đó trên các kết quả bộ chuyển đổi AuthZEN/COAZ-MCP, AP2, OAuth Transaction Token và ủy nhiệm đã ký cục bộ:

npm run conformance:composition:consequence-admission

Trình chạy bộ kiểm thử là mô hình vòng đời độc lập với kho lưu trữ trong bộ nhớ và logic tiếp nhận riêng. Nó không thực thi mã @emilia-protocol/verify hoặc @emilia-protocol/gate được cung cấp, vì vậy không phải là bằng chứng cho các gói đó, vốn có bộ kiểm thử riêng. Đây cũng không phải bằng chứng cho thấy các giao thức gốc được nêu tên tuân thủ AEB-07.

Để có bằng chứng thực thi tập trung vào đường dẫn Gate của kho lưu trữ, hãy chạy:

npm run proof:gate:reference

Lệnh này chạy các ví dụ cục bộ và kiểm thử tập trung vào ranh giới dịch vụ bằng khóa được tạo tự động, trạng thái trong bộ nhớ và hành vi nhà cung cấp giả lập. Đây là bằng chứng cục bộ hữu ích, không phải bằng chứng về con người thực, ngân hàng bên ngoài, triển khai production hay một tích hợp production đầu cuối.

Danh tính không phải là mô tả công việc

Danh tính cho biết ai hoặc thứ gì đang gọi. Chính sách cho biết điều gì thường được phép. Không điều nào xác định công việc hữu hạn mà một tác nhân tự chủ có thể thực hiện ngay lúc này: nhiệm vụ, giới hạn đối với hành động trọng yếu, ngân sách, bằng chứng bắt buộc, thời hạn hết hiệu lực, quy tắc ủy quyền và quy trình xử lý ngoại lệ.

EMILIA tách biệt các câu hỏi đó:

Lớp	Câu hỏi
Danh tính	Ai hoặc thứ gì đang hiện diện?
Chính sách	Điều gì thường được phép?
Thẩm quyền	Agent này được phép thực hiện chính xác công việc nào theo ủy nhiệm này?

Thông tin xác thực cấp quyền truy cập. Thẩm quyền xác định công việc. Không phải hành động nào cũng cần con người; mọi hành động có hệ quả đều cần thẩm quyền hợp lệ.

Ở nền tảng cốt lõi, EP Core vẫn cung cấp ba đối tượng có khả năng tương tác: Trust Receipt mang bằng chứng có thể quy thuộc, Trust Profile biểu diễn trạng thái tin cậy có cấu trúc và Trust Decision ghi lại kết quả được đánh giá theo chính sách của bên dựa vào. Các lớp mặt phẳng điều khiển thẩm quyền bổ sung ràng buộc hành động chính xác, ủy nhiệm hữu hạn, tiếp nhận, tiêu thụ và bằng chứng kết quả mà không gộp các đối tượng đó thành một tuyên bố duy nhất.

---

Thiết lập ủy nhiệm một lần. Để agent làm việc.

Khách hàng xác định nhiệm vụ, giới hạn, yêu cầu bằng chứng, thời hạn hết hiệu lực và quy tắc ngoại lệ. Mã cục bộ có thể thu hẹp thẩm quyền đó; không thể tự tạo ra hoặc mở rộng thẩm quyền. Gate ràng buộc từng yêu cầu có thể thực thi với ủy nhiệm, đặt chỗ thẩm quyền được bao phủ trước khi gọi nhà cung cấp, cho phép một lần thử gọi nhà cung cấp được tiếp nhận cho mỗi phiên bản ủy quyền trong miền thẩm quyền bền vững dùng chung, và chỉ chuyển cấp khi thiếu thẩm quyền, thẩm quyền đã cũ, cạn kiệt hoặc quá hẹp.

Các ví dụ MCP đi kèm kiểm thử một hồ sơ chính sách yêu cầu phê duyệt tại ranh giới. Chúng tạo khóa ký minh họa và gọi các công cụ giả lập. Ví dụ thanh toán ràng buộc cả bốn trường trọng yếu đã khai báo; các ví dụ khác minh họa các ràng buộc tài nguyên hẹp hơn. Chúng không ghi nhận quyết định thực sự của con người hay liên hệ với nhà cung cấp:

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

Bản demo kết hợp chuyên sâu hơn thực thi khoản thanh toán được ủy quyền và ràng buộc CAID thông qua đường dẫn năng lực giới hạn thực sự của Gate, sau đó xác minh ngoại tuyến chứng chỉ thực thi đã ký:

npm run demo:receipt-program

Bản này cố ý không bao gồm blockchain hay tuyên bố không kiến thức mô phỏng nào. Xem kiến trúc chương trình biên nhận để biết các yêu cầu về trạng thái và độ tin cậy trong production.

Bắt đầu với một hành động MCP có hệ quả đã khai báo. Cài đặt môi trường chạy cục bộ chính xác, sau đó tạo Gate Starter cho hành động đó và chạy kiểm tra giới hạn gồm bốn trường hợp:

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

Kiểm tra cục bộ được tạo ra sử dụng trạng thái demo được chỉ định rõ là tạm thời và chỉ chứng minh các trường hợp tổng hợp đã nêu: thiếu, khớp chính xác, thay đổi, phát lại và công cụ chưa được quét. Lệnh đã được xem xét tạo một gói bàn giao giới hạn quyền riêng tư; lệnh này không kích hoạt Gate. Production cần sổ cái nguồn gốc bền vững, kho tiêu thụ nguyên tử dùng chung, khóa được ghim và trình bao bọc trên mọi đường dẫn đến thông tin xác thực thực của nhà cung cấp. Xem examples/mcp/ và /mcp.

Ngăn hành động mới mà không giả vờ hoàn tác hành động cũ

Cơ chế đóng băng thẩm quyền khẩn cấp của Gate chặn các lượt đặt chỗ mới và ngăn các lượt đặt chỗ cũ hơn được tiếp tục sau khi epoch của miền kiểm soát được bao phủ thay đổi. Nếu việc gọi nhà cung cấp đã diễn ra trước đó, lần thử vẫn được tính là đã tiêu thụ và cần được đối soát. Khôi phục thẩm quyền không làm sống lại lượt đặt chỗ cũ.

Điều này đòi hỏi kiểm soát toàn diện và trạng thái dùng chung có thẩm quyền. Cơ chế này không dừng tính toán, đảo ngược tác động hay tiếp cận tức thời các miền bị ngắt kết nối. Xem triển khai miền kiểm soát và các giới hạn.

Dùng thử trong 30 giây

# 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

Thử passkey nền tảng với khoản thanh toán mẫu → Ký một khoản thanh toán minh họa trị giá 82.000 USD, thay đổi số tiền và xem bước kiểm tra tính toàn vẹn thất bại. Trình xác thực của bạn có thể dùng sinh trắc học hoặc mã PIN thiết bị. Trang này cũng cung cấp một mô phỏng phần mềm riêng. Cả hai chế độ đều không gửi khoản thanh toán hay thiết lập quyền ủy quyền production.

Kiểm tra bất kỳ biên nhận nào trong trình duyệt — dán biên nhận vào, không có dữ liệu nào được tải lên.

---

Cách hoạt động — một vòng đời thẩm quyền

Tự chạy: node examples/crash-test.mjs — hoàn toàn ngoại tuyến, không cần khóa 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

Ủy nhiệm. Nguồn thẩm quyền xác định công việc hữu hạn. Nguồn này có thể là chương trình vận hành do khách hàng ký, năng lực giới hạn, quyết định bắt buộc của con người, cơ chế đồng thuận hoặc tổ hợp bằng chứng gốc của bên dựa vào.

Công việc chính xác. Gate ràng buộc phương thức, nguồn gốc, bên được gọi, mục tiêu, lần thực hiện và mọi trường trọng yếu vào đối tượng thực thi chuẩn tắc. Ý định, lời nhắc hoặc nội dung phiếu công việc không phải là đối tượng đó.

Xác minh, đặt chỗ và gọi. Các tạo tác gốc vẫn giữ nguyên dạng gốc. Bên dựa vào ghim hồ sơ tin cậy và ánh xạ, đánh giá toàn bộ yêu cầu bằng chứng, đưa ra quyết định ủy quyền cục bộ riêng biệt và đặt chỗ thẩm quyền được bao phủ trước khi bộ chuyển đổi sở hữu thông tin xác thực gọi nhà cung cấp.

Thẩm quyền mới từ con người khi được yêu cầu. Chính sách có thể yêu cầu quyết định WebAuthn/passkey được ràng buộc với hành động chính xác và mã băm hiển thị xác định. Điều này thu hẹp khoảng cách giữa “những gì bạn thấy là những gì bạn ký”; nhưng không chứng minh sự thấu hiểu, sáng suốt, tính hợp pháp hay kết quả. Đối với các triển khai doanh nghiệp, Gate cũng có thể yêu cầu xác nhận từ Authorization Server được xác minh độc lập, gắn với chính xác bằng chứng con người đó, cùng hành động chính xác đó, ảnh chụp danh tính mà AS thực sự đã quan sát và khóa Resource Server dự kiến. Thời điểm chụp ảnh và tuổi tối đa do bên dựa vào quy định được nêu rõ: token mới không thể khiến dữ liệu thư mục đã cũ trở nên hiện hành. Nhánh AS là bằng chứng dựa trên độ tin cậy do khách hàng ghim; bản thân nó không cấp quyền, không chứng minh tình trạng việc làm tức thời, cũng không biến bộ điều phối tác tử thành một cơ quan có thẩm quyền.

Kết quả trung thực. Việc tiếp nhận không phải là thực thi, và thực thi không phải là hiệu lực. Có thể xác minh bản ghi đã ký ngoại tuyến; bằng chứng từ nhà cung cấp và bên quan sát vẫn tách biệt. Phản hồi bị mất trở thành INDETERMINATE, tức một trạng thái cần đối soát—không phải sự cho phép thử lại. Biện pháp khắc phục là một hành động mới được cấp quyền và không bao giờ viết lại kết quả cũ.

---

Vì sao nhà phát triển sử dụng

Trước tiên, hãy lập bản đồ công việc cục bộ, sau đó bảo vệ một bề mặt hành động đã khai báo bằng máy chủ MCP hoặc lớp bọc SDK mỏng. Trình quét đề xuất một bản đồ có thể xem xét; chủ sở hữu xác định phạm vi ủy quyền; Gate nắm giữ thông tin xác thực của nhà cung cấp và thực thi chính xác hành động trên đường dẫn được bao phủ. Không bản quét nào chứng minh được việc trung gian hóa hoàn chỉnh, và riêng việc khám phá không cấp quyền hạn nào.

# 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

Tác tử nhận được khả năng thực hiện công việc có giới hạn, chứ không phải thông tin xác thực thường trực mà nó có thể diễn giải lại.

---

Vì sao doanh nghiệp cần

Các tiến trình tác tử khởi động lại và mô hình thay đổi. Phạm vi ủy quyền, trạng thái tiêu thụ, việc thu hồi, sự không chắc chắn và lịch sử công việc của khách hàng phải tồn tại bên ngoài chúng. EMILIA duy trì trạng thái quyền hạn bền vững đó tại ranh giới của khách hàng, đồng thời tiếp nhận bằng chứng bên ngoài thông qua các bộ điều hợp được ghim.

Gate được quản lý và Assurance Plane bổ sung các thao tác phạm vi ủy quyền, tích hợp, thao tác bằng chứng, thực hiện lại, hỗ trợ và mức dịch vụ xoay quanh giao thức mở. Khách hàng vẫn kiểm soát quyền hạn, gốc tin cậy, thông tin xác thực, chính sách và bằng chứng có thể chuyển đổi.

---

Tiêu chuẩn

EMILIA Protocol là giao thức mở theo giấy phép Apache-2.0. Công việc tiêu chuẩn hóa được công bố dưới dạng một danh mục các Internet-Draft riêng lẻ. Internet-Draft đã công bố không phải là RFC, hạng mục đã được nhóm công tác thông qua hay sự chứng thực của IETF; Datatracker là nguồn có thẩm quyền về phiên bản và trạng thái.

Đăng ký IANA

Hai tên đã đăng ký cung cấp cho người triển khai một tham chiếu chung về các định dạng EMILIA:

• application/vnd.emilia.authorization-evidence-challenge+json được đăng ký vào ngày 6 tháng 10 năm 2026. Tên này xác định đối tượng JSON AE-CHALLENGE-v1 thuần được định nghĩa trong đặc tả tuần tự hóa đã công bố. Các phản hồi từ chối HTTP tiếp tục sử dụng application/problem+json.
• canactid: được đăng ký tạm thời vào ngày 5 tháng 10 năm 2026. Tên này chỉ định các hành động có kiểu chính xác theo CAID-05. Số lược đồ CRI đã được sửa là 1033.

Các đăng ký này công bố tên và đặc tả tương ứng. Chúng không xác lập việc IETF thông qua, chứng thực, chứng nhận hay triển khai tại khách hàng.

Một bề mặt ranh giới hệ quả

Bản AEB-07 hiện được công bố, đăng ngày 2026-09-25 dưới dạng Internet-Draft riêng lẻ và chưa được thông qua, xác định AEB là điểm kết hợp sau một quyết định gốc. OAuth, AuthZEN, COAZ, AP2 và các hệ thống cục bộ vẫn sở hữu thông tin xác thực, ánh xạ thao tác và quyết định cấp quyền của mình. AIMS (draft-ietf-wimse-aims) là tài liệu Informational của nhóm công tác WIMSE, mô tả các tiêu chuẩn hiện có như WIMSE và OAuth; bản thân tài liệu này không cấp thông tin xác thực hay quyết định. AEB áp dụng quyết định gốc tại ranh giới nhà cung cấp được bảo vệ: khi cần, nó gắn hành động cuối cùng, tạo một danh tính phát lại gốc cho mỗi quyền cấp, đặt chỗ trước khi gọi nhà cung cấp, từ chối lần thử thứ hai đối với cùng hành động khi lần trước vẫn đang diễn ra hoặc chưa rõ kết quả, và giữ trạng thái chưa rõ bị khóa cho đến khi được đối soát đã xác thực.

CAID-05 được dùng khi cần so sánh các biểu diễn được mã hóa độc lập. Các mã định danh mới sử dụng lược đồ URI canactid: được IANA đăng ký tạm thời. Việc đăng ký không đồng nghĩa với IETF thông qua, chứng thực, chứng nhận hay trạng thái vĩnh viễn. CAID không phải là bước ánh xạ thứ hai bắt buộc khi PEP sở hữu hệ quả đã tự suy ra và thực thi quyết định hiện hành trên thao tác cuối cùng. Thử sân chơi hành động chính xác hoặc đọc hướng dẫn di chuyển từ CAID-04 sang CAID-05. AEC-06 được dùng khi bên dựa vào yêu cầu nhiều nhánh bằng chứng. Authorization Receipts, Human Authorization Binding và Authority Introduction vẫn là các hồ sơ khả dụng cho những triển khai cần đến chúng; chúng không phải điều kiện tiên quyết cho mọi tích hợp AEB. Architecture-03 vẫn là tài liệu định hướng.

Hướng dẫn tiếp nhận hệ quả nêu rõ ranh giới triển khai và các trường hợp không cần AEB. Hồ sơ bàn giao gốc trực tiếp là hồ sơ triển khai trong kho lưu trữ, minh họa cách một quyền cho phép hiện có đến Gate mà không cần thêm lớp CAID hoặc AEC thứ hai. AEB-07 quy định nội dung mà một lần bàn giao cổng như vậy xác nhận và cách ranh giới xác minh nội dung đó, nhưng để việc mã hóa cho các cấu hình ghim của từng triển khai; tài liệu này trích dẫn một ảnh chụp đã ghim của hồ sơ này làm một cách mã hóa tham khảo mang tính thông tin. Các byte -07 chính xác đã gửi và hồ sơ công bố của chúng được lưu giữ tại standards/staged/NEXT-AEB-07.

Danh mục đang hoạt động đầy đủ gồm 26 bản ghi Datatracker: 21 bản ghi do một tác giả duy nhất viết và năm bản ghi đồng tác giả, mỗi bản ghi có phạm vi, lịch sử phiên bản và trạng thái bảo trì được ghi nhận riêng. Xem hướng dẫn tiêu chuẩn, danh mục và bảng kiểm kê trạng thái ở định dạng máy đọc được.

IETF Internet-Draft	Đường dẫn ảnh chụp cục bộ hiện tại: bảng kiểm kê trạng thái · danh mục đã đăng của các bản ghi do một tác giả viết · trạng thái trực tiếp có thẩm quyền: IETF Datatracker
Bộ xác minh đa ngôn ngữ	JavaScript · Python · Go — cả ba đã chứng minh được sự nhất quán trên các vector tuân thủ đối kháng, trong mọi lần đẩy (npm run conformance). Đây là kiểm tra tính nhất quán giữa các bản chuyển thể của cùng một nhóm, không phải các triển khai độc lập được xây dựng từ đầu. Riêng biệt, một triển khai Rust do bên ngoài viết dựa trên đặc tả (mã nguồn công khai) vượt qua bộ 16 bộ kiểm thử/164 vector đã ghim và chiến dịch kiểm tra đối kháng 359 trường hợp đã ghim, trong một lần dựng lại do bên đánh giá kiểm soát từ cây mã nguồn bất biến. Bằng chứng xây dựng được lưu trong kho vẫn do người triển khai ký, không được bên thứ ba chứng thực (tuyên bố đã ký); việc chấp nhận nghiêm ngặt theo quy trình xây dựng độc lập chờ bản kê khai đã được bên thứ ba chứng thực đã sửa và khóa bên chứng thực được ghim độc lập.
Bằng chứng mô hình hình thức	26 thuộc tính an toàn TLA+ có giới hạn được giữ vững trong các không gian trạng thái đã cấu hình; đây không phải là tinh chỉnh triển khai hay chứng minh không giới hạn · 35 sự kiện Alloy, 32 khẳng định trên bốn mô hình · hai mô hình Dolev-Yao ký hiệu được kết hợp, bao quát thử thách, CAID, hai phê duyệt, các khóa ghim của bên phát hành và cơ quan có thẩm quyền, chế độ xem sổ đăng ký, thu hồi, tiêu thụ, thực thi và sáu ranh giới xác nhận chuyên biệt. Hai mươi bổ đề Tamarin được xác minh — 17 nghĩa vụ đúng với mọi vết và 3 nhân chứng tồn tại vết; tám biến thể bị làm yếu có chủ đích tạo ra các vết tấn công cụ thể khi bỏ các kiểm tra then chốt (formal/tamarin/).
Phân phối MCP	Gói npm @emilia-protocol/mcp-server · việc phát hành trên Registry chính thức được theo dõi riêng trong MCP-REGISTRY.md; không suy diễn danh sách trên các bộ tổng hợp từ một trong hai trạng thái
Giấy phép	Apache-2.0

Ba bản chuyển thể tham chiếu do cùng một nhóm thực hiện (JS / Python / Go) nhất quán trên cả 21 bộ kiểm thử và 340 vector. Riêng biệt, một triển khai Rust do bên ngoài viết, được dựng lại từ cây mã nguồn công khai đã ghim, vượt qua bộ kiểm thử độc lập 16 bộ/164 vector đã ghim và chiến dịch kiểm tra đối kháng 359 trường hợp, được chạy lại trong làn CI riêng mỗi khi có thay đổi. Các bộ kiểm thử chấp nhận AEC mới hơn và phân giải bốn kết quả không được tính cho Rust. Đây là bằng chứng về khả năng tương tác bên ngoài, không phải sự chấp nhận nghiêm ngặt đối với quy trình xây dựng độc lập; bản ghi trường hợp CI tổng hợp ghi nhận số lượng chấp nhận nghiêm ngặt là không cho đến khi có chứng thực độc lập. Xem CONFORMANCE.md, hoặc tự xác minh biên nhận tại emiliaprotocol.ai/verify.

---

Ngăn xếp quyền hạn

Lớp	Chức năng
Phạm vi ủy quyền	Xác định nhiệm vụ, giới hạn, bằng chứng, thời hạn hết hiệu lực, ủy quyền lại và quy tắc ngoại lệ.
CAID / hành động chính xác	So sánh ý nghĩa trọng yếu khi việc cấp quyền và thực thi sử dụng các biểu diễn được mã hóa độc lập; không cấp quyền.
AEC	Khi được yêu cầu, đánh giá xem bằng chứng được xác minh và đối chiếu độc lập có đáp ứng yêu cầu nhiều nhánh của bên dựa vào hay không; không cấp quyền.
AEB / Gate	Áp dụng quyết định cấp quyền gốc hoặc cục bộ tại ranh giới hệ quả, đặt chỗ quyền hạn được bao phủ và kiểm soát việc gọi nhà cung cấp.
Bằng chứng kết quả	Giữ riêng biệt việc gọi, phản hồi của nhà cung cấp, hiệu lực được quan sát và trạng thái không chắc chắn.

---

Các điểm chứng minh

Chỉ số	Giá trị
Trường hợp kiểm thử tự động	Hơn 10.700 trên hơn 650 tệp; mọi trường hợp áp dụng cho nền tảng đều phải vượt qua
Thuộc tính an toàn TLA+	26 bất biến có giới hạn được giữ vững trong không gian trạng thái đã cấu hình; không phải chứng minh tinh chỉnh triển khai hay chứng minh không giới hạn — xem PROOF_STATUS.md
Khẳng định quan hệ Alloy	35 sự kiện + 32 khẳng định trên bốn mô hình — đã được xác minh trong CI
Trường hợp đội đỏ được lập danh mục	86 — RED_TEAM_CASES.md
Trạng thái bảo mật bản phát hành	Các kiểm tra bảo mật của kho lưu trữ đều đạt; mọi phát hiện của Strix trên các thay đổi được kiểm toán đều đã được khắc phục kèm kiểm thử hồi quy và luồng thảo luận đánh giá đã được giải quyết
Tuân thủ (7/7)	node conformance/ep-conformance-test.js https://www.emiliaprotocol.ai
Tuân thủ đa ngôn ngữ	340 vector · 21 bộ kiểm thử: biên nhận · xác nhận thiết bị · phân giải bốn kết quả · túc số nhiều bên · thu hồi · Outcome Binding (ngữ nghĩa + mật mã thực) · phép nối bên phát hành Authority Document/Proof · xác nhận thời gian · trust-receipt (2 hồ sơ) · nguồn gốc · bản ghi bằng chứng · chuẩn hóa · ranh giới · chấp nhận AEC · tiền tệ · xác nhận bên khởi tạo · bằng chứng tiêu thụ · nhân chứng · bằng chứng dấu thời gian (RFC 3161). Các bộ xác minh JS / Python / Go nhất quán (node conformance/run.mjs). Đường cơ sở Rust bên ngoài vẫn ở mức 164 vector / 16 bộ kiểm thử. Xem CONFORMANCE.md.
p95 tạo bắt tay	575ms ở 50 VU — PERFORMANCE_PROOF.md

Tuổi thọ mật mã (với ranh giới triển khai được nêu rõ)

Bằng chứng cần được xác minh sau nhiều năm phải tồn tại lâu hơn các thuật toán đã dùng để ký chúng. EP cung cấp bốn khả năng có giới hạn cho mục đích đó, mỗi khả năng có một ranh giới chính xác là một phần của tuyên bố:

• Chữ ký lai (EP-RECEIPT-HYBRID-v1). Ed25519 và ML-DSA-65 trên cùng một chuỗi byte chuẩn hóa, với tập thuật toán bắt buộc được cam kết trong chuỗi byte đã ký, để việc loại bỏ một nhánh làm chữ ký còn lại không hợp lệ. Tính năng này được bật tùy chọn khi triển khai; khi một bên ký kép được phê duyệt đã đăng ký và chính sách cho phép nhánh PQ, trạng thái Gate không được ghim sẽ mặc định phát hành kép. Nếu không, hệ thống chỉ dùng thuật toán cổ điển và nêu rõ lý do. Trình xác minh v1 từ chối biên nhận lai một cách rõ ràng, thay vì chấp nhận một nhánh. Hợp đồng bên ký bên ngoài và bộ điều hợp AWS KMS đã được triển khai, nhưng không tuyên bố đã thực hiện lệnh gọi ký AWS trực tiếp, có khóa sản xuất, xác minh từ bên dựa vào, hoặc xác thực FIPS cho ML-DSA. Xem conformance/hybrid-receipts/ và lib/pq-custody-aws-kms.ts.
• Hồ sơ Signed Statement của SCITT (EP-SCITT-STATEMENT-v1). Cấu trúc Signed Statement RFC 9943 hoàn chỉnh cho biên nhận EP, bao gồm cả tiêu đề được bảo vệ CWT Claims. Giới hạn: chưa có Transparency Service nào chấp nhận một statement EP; đăng ký bên ngoài là bước riêng có kiểm soát và chưa được thực hiện. Xem EP-RECEIPT-SCITT-PROFILE.md.
• Chứng thực lại (EP-EVIDENCE-REATTESTATION-v1). Bằng chứng được ký bằng thuật toán đang dần lỗi thời có thể được neo lại bằng thuật toán hiện hành trước khi thuật toán cũ suy yếu. Giới hạn: phải chứng thực lại trước khi xảy ra xâm phạm; việc này không thể khắc phục bằng chứng sau sự việc.
• Chế độ triển khai FIPS (EP-FIPS-MODE-v1). Thực hiện các thao tác cổ điển thông qua nhà cung cấp đã được xác thực theo FIPS 140-3 do đơn vị vận hành cung cấp, đồng thời yêu cầu xác nhận rõ ràng về việc triển khai chưa được xác thực trước khi cho phép đường dẫn ML-DSA. Giới hạn: điều này chỉ cho phép tuyên bố “các thuật toán dựa trên FIPS, với chế độ triển khai dùng nhà cung cấp đã được xác thực” và phụ thuộc vào nhà cung cấp cùng ranh giới chứng chỉ do đơn vị vận hành khai báo; đây không phải là tuyên bố tuân thủ chung, và không có thành phần nào ở đây được xác thực FIPS. Xem FIPS-MODE.md.

Chương trình lai trên toàn bộ ngăn xếp (mọi bề mặt chữ ký nội bộ) được lập bản đồ trong pq-hybrid-program.md và chưa hoàn tất; cho đến khi hoàn tất, không đưa ra tuyên bố chung nào về toàn bộ ngăn xếp.

---

Các đối tượng giao thức cốt lõi

Đối tượng	Nội dung
Chương trình thẩm quyền / năng lực có giới hạn	Một ủy nhiệm hữu hạn với phạm vi, ngân sách hoặc đơn vị, thời hạn hết hiệu lực, quy tắc ủy quyền và quy tắc tiêu thụ được nêu rõ.
CAID	Định danh chuẩn tắc cho một hành động trọng yếu theo hồ sơ ánh xạ có tên; việc khớp không đồng nghĩa với được cấp quyền.
Yêu cầu bằng chứng và kết quả AEC	Quy tắc được ghim của bên dựa vào và kết quả đánh giá SATISFIED, UNSATISFIED hoặc INDETERMINATE.
Bản ghi tiếp nhận và lưu ký AEB	Bản ghi phía bộ thực thi về trạng thái cấp quyền, đặt trước, gọi nhà cung cấp và đối soát.
Bằng chứng cấp quyền và kết quả	Các tạo tác gốc hoặc EP có thể chuyển giao, giữ nguyên chính xác bên phát hành, phạm vi và ranh giới xác nhận của chúng.

---

Bắt đầu nhanh

1. Cài đặt chính xác môi trường chạy guard cục bộ, sau đó chạy npx @emilia-protocol/scan@0.6.0 protect ./tools.json --action sendWire --apply --verify, thay sendWire bằng một công cụ trọng yếu được khai báo chính xác.
2. Xem lại Authority Map được tạo, bản kê khai hành động, các trường trọng yếu, ranh giới đã chọn và các điểm mù được nêu rõ.
3. Chạy lệnh --reviewed --crossing-profile <launch-profile> riêng để tạo gói bàn giao chỉ dành cho chủ sở hữu và không gian làm việc Lab chưa niêm phong từ các byte không thay đổi đó.
4. Cài đặt Gate trên đường dẫn sở hữu thông tin xác thực của nhà cung cấp và trạng thái tiêu thụ bền vững.
5. Xác định ủy nhiệm vận hành cùng mọi quy tắc ngoại lệ yêu cầu con người mới xác nhận hoặc đồng thuận theo nhóm.
6. Chạy các trường hợp từ chối, hành động chính xác, phát lại, hết thời gian chờ và đối soát trước khi bật chế độ thực thi.

Bản demo 90 giây · Bắt đầu nhanh · Hướng dẫn từng bước cho agent · Bản nháp IETF · Discord

---

EP là gì — và không phải là gì

EMILIA là hạ tầng thẩm quyền cho công việc tự chủ, không phải hệ thống định danh, ví, điểm uy tín, đường ray thanh toán hay bộ máy chính sách phổ quát.

• Là: mặt phẳng điều khiển cho các ủy nhiệm vận hành hữu hạn, xác minh hành động chính xác, trạng thái tiếp nhận bền vững, thể hiện trung thực sự không chắc chắn và bằng chứng có thể chuyển giao trên các đường dẫn bộ thực thi được bao phủ.
• Không phải: giải pháp thay thế cho OAuth/OIDC, định danh khối lượng công việc hoặc bộ máy chính sách. Những thành phần đó vẫn là đầu vào gốc theo các giá trị ghim của bên dựa vào.
• Không phải: yêu cầu con người phê duyệt mọi hành động. Một ủy nhiệm có thể cho phép tự động thực hiện công việc trong các giới hạn hữu hạn và chỉ yêu cầu thẩm quyền mới khi vượt đến ranh giới.
• Không phải: bằng chứng rằng hành động đã được tiếp nhận thực thi thành công hoặc tạo ra hiệu ứng dự kiến.
• Không phải: quyền kiểm soát giao thức độc quyền. Phần cốt lõi dùng giấy phép Apache-2.0 và các Internet-Draft là bản đệ trình cá nhân, không phải RFC hay sự chứng thực của IETF.

Xem CONFORMANCE.md · SECURITY.md · THREAT_MODEL.md · GOVERNANCE.md · Cam kết trung lập