EMILIA Protocol

EMILIA Protocol

---

Hãy để agent của bạn chuẩn bị thanh toán. Kiểm soát những gì nó có thể giải phóng.

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

EMILIA Gate kiểm tra quyền hạ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 dưới các khóa và quy tắc đáng tin cậy của chính người xác minh. Giữ nguyên nhà cung cấp danh tính, khung agent và hệ thống kinh doanh 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 một lệnh gọi không có phê duyệt, ràng buộc phê duyệt với số tiền, loại tiền tệ, nhà cung cấp và điểm đến, chấp nhận lệnh gọi khớp đúng một lần, và từ chối các chi tiết thanh toán bị thay đổi, phát lại và bằng chứng giả mạo. Xem ví dụ và các giới hạn của nó.

Đây là một minh họa cục bộ: các khóa ký được tạo, tiêu thụ trong bộ nhớ và một công cụ thanh toán giả lập. Nó không thực hiện một nghi lễ con người thực sự hoặc chuyển tiền. Sản xuất cần thông tin xác thực đã đăng ký, trạng thái chia sẻ 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ệ. Một phê duyệt hợp lệ không thiết lập rằng các chi tiết ngân hàng là hợp pháp.

Thích trình duyệt hơn? Thử passkey trên một khoản thanh toán mẫu. Bản demo riêng đó cho thấy tính toàn vẹn của biên nhận với bộ 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 đã sử dụng

Bắt đầu tại dịch vụ giữ thông tin xác thực thực sự 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à khi nào cần phê duyệt mới. Một agent có thể làm việc trong các giới hạn đó mà không cần một người phê duyệt mọi lệnh gọi.

• MCP hoặc HTTP: Gate Starter hướng dẫn qua 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 kiểm tra với bản merge được đề xuất. Kiểm tra phải được yêu cầu 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 mà triển khai kiểm soát hoàn toàn. Gate không thể ràng buộc một đường dẫn vòng. Nếu kết quả của nhà cung cấp không xác định, vòng đời sản xuất bảo toàn sự không chắc chắn đó để đối chiếu thay vì mù quáng thử lại.

Hệ thống AI và người xem xét kho lưu trữ: bắt đầu với AI_CONTEXT.md. Bằng chứng hiện tại có thể đọc bằng máy, nguồn gốc, giả định và loại trừ được công bố tại EMILIA-REPO-CONTEXT-v1. Các tài liệu lưu trữ hoặc theo giai đoạn không thiết lập triển khai hiện tại hoặc trạng thái IETF. Bằng chứng thẩm định công khai và ranh giới tuyên bố: DUE_DILIGENCE.md.

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

EMILIA cung cấp một hồ sơ bảo mật mà người xem xét có thể thực thi. 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 đã băm, xác minh 20 bổ đề Tamarin trên hai mô hình Dolev-Yao kết hợp — 17 nghĩa vụ all-traces và 3 nhân chứng reachability exists-trace — và bảo toàn 8 biến thể bị làm yếu có chủ đích tạo ra các dấu vết tấn công cụ thể khi các kiểm tra chịu lực bị loại bỏ. Kho tương thích cùng nhóm trực tiếp chứa 21 bộ và 340 vector hiện tại. Riêng biệt, một bộ xác minh Rust do bên ngoài tác giả được ghim vào gói 16 bộ/164 vector đông lạnh và một chiến dịch thù địch 359 trường hợp. Bộ rộng hơn chứa hơn 10.700 bài kiểm tra tự động trên hơn 650 tệp.

Các bề mặt JavaScript và JSDoc sản xuất được kiểm tra bằng trình biên dịch với TypeScript checkJs; ứng dụng an toàn 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 loại sản xuất được cấu hình đầy đủ, không phải tuyên bố rằng kho lưu trữ đã được chuyển đổi toàn bộ từ JavaScript sang TypeScript hoặc rằng mọi dự án JavaScript có tùy chọn strict của TypeScript được bật.

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

AEB-1: kiểm tra ranh giới từ bằng chứng đến hiệu lực

Bộ kiểm tra mở AEB-1 Consequence Admission Conformance kiểm tra đườ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 hệ quả: xác minh gốc, chấp nhận của bên dựa vào, ràng buộc hành động chính xác, khớp CAID bắt buộc, thỏa mãn bằng chứng AEC bắt buộc, ủy quyền cục bộ, dự trữ nguyên tử, quyền giám sát INVOKING, sự thật riêng biệt về kết quả nhà cung cấp và hiệu ứng quan sát được, hành vi không thử lại mù, và đối chiếu xác thực.

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

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

Nó trung lập về định dạng và tự chạy. Một báo cáo đạt yêu cầu là bằng chứng tuân thủ tự chứng nhận, không phải kiểm toán, chứng nhận, tuyên bố triển khai sản xuất hoặc quyền thực hiện một hành động.

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

npm run conformance:composition:consequence-admission

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

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

npm run proof:gate:reference

Lệnh này thực thi các ví dụ cục bộ và các ranh giới dịch vụ tập trung với các khóa được tạo, 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ề một con người thực, ngân hàng bên ngoài, triển khai sản xuất hoặc một tích hợp sản xuất đầ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 cái gì đang gọi. Chính sách cho biết điều gì được phép chung. Không cái nào định nghĩa công việc hữu hạn mà một worker tự động có thể thực hiện ngay bây giờ: sứ mệnh của nó, giới hạn hành động vật chất, ngân sách, bằng chứng bắt buộc, thời hạn, quy tắc ủy quyền và đường dẫn ngoại lệ.

EMILIA giữ các câu hỏi đó riêng biệt:

Lớp	Câu hỏi
Danh tính	Ai hoặc cái gì đang hiện diện?
Chính sách	Điều gì được phép chung?
Quyền hạn	Công việc chính xác nào mà agent này có thể thực hiện theo nhiệm vụ này?

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

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

---

Đặt nhiệm vụ một lần. Để agent làm việc.

Khách hàng định nghĩa sứ mệnh, giới hạn, yêu cầu bằng chứng, thời hạn và quy tắc ngoại lệ. Mã cục bộ có thể thu hẹp quyền hạn đó; nó không thể phát minh hoặc mở rộng nó. Gate ràng buộc mỗi yêu cầu thực thi với nhiệm vụ, dự trữ quyền hạn được bao phủ trước khi vào nhà cung cấp, cho phép một lần thử nhà cung cấp được chấp nhận cho phiên bản ủy quyền đó trong miền quyền hạn bền vững chia sẻ và leo thang chỉ khi quyền hạn bị thiếu, lỗi thời, cạn kiệt hoặc quá hẹp.

Các ví dụ MCP đi kèm thực thi một hồ sơ chính sách yêu cầu phê duyệt tại ranh giới. Chúng tạo các 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 tất cả bốn trường vật chất được 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 lại quyết định con người thực hoặc 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 sâu hơn thực thi một khoản thanh toán được ủy quyền ràng buộc CAID qua đường dẫn khả năng giới hạn thực của Gate, sau đó xác minh chứng chỉ thực thi đã ký ngoại tuyến:

npm run demo:receipt-program

Nó cố ý không bao gồm blockchain hoặc tuyên bố zero-knowledge mô phỏng. Xem kiến trúc chương trình biên nhận cho các yêu cầu trạng thái sản xuất và tin cậy.

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

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

Kiểm tra cục bộ được tạo sử dụng trạng thái demo tạm thời rõ ràng và chỉ chứng minh các trường hợp thiếu tổng hợp, khớp chính xác, đột biến, phát lại và công cụ không quét được đã nêu. Lệnh được xem xét tạo một bàn giao giới hạn quyền riêng tư; nó không kích hoạt Gate. Sản xuất yêu cầu một sổ cái nguồn gốc bền vững, một kho lưu trữ tiêu thụ nguyên tử chia sẻ, các 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 nhà cung cấp thực. Xem examples/mcp/ và /mcp.

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

Việc đóng băng quyền hạn khẩn cấp của Gate chặn các dự trữ mới và ngăn các dự trữ cũ vào sau khi epoch của miền kiểm soát được bao phủ thay đổi. Nếu việc vào nhà cung cấp xảy ra trước, lần thử vẫn bị tiêu thụ và cần đối chiếu. Khôi phục quyền hạn không hồi sinh một dự trữ cũ.

Điều này yêu cầu trung gian hoàn toàn và trạng thái chia sẻ có thẩm quyền. Nó không dừng tính toán, đảo ngược hiệu ứng hoặc ngay lập tức tiếp cận các miền bị ngắt kết nối. Xem triển khai miền kiểm soát và giới hạn.

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 trên một khoản thanh toán mẫu → Ký một khoản thanh toán minh họa 82.000 USD, thay đổi số tiền của nó và xem kiểm tra tính toàn vẹn thất bại. Bộ xác thực của bạn có thể sử dụng sinh trắc học hoặc mã PIN thiết bị. Trang cũng cung cấp một mô phỏng phần mềm riêng. Không chế độ nào gửi thanh toán hoặc thiết lập ủy quyền sản xuất.

Xác minh bất kỳ biên nhận nào trong trình duyệt của bạn — dán nó vào, không có gì được tải lên.

---

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

Tự chạy nó: 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

Nhiệm vụ. Nguồn quyền hạn định nghĩa công việc hữu hạn. Nó có thể là một chương trình vận hành được khách hàng ký, khả năng giới hạn, quyết định con người bắt buộc, túc số hoặc một thành phần bên dựa vào của bằng chứng gốc.

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

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

Quyền hạn con người mới khi được yêu cầu. Một chính sách có thể yêu cầu quyết định WebAuthn/passkey ràng buộc với hành động chính xác và băm hiển thị xác định. Điều này thu hẹp khoảng cách “những gì bạn thấy là những gì bạn ký”; nó không chứng minh sự hiểu biết, sự khôn ngoan, tính hợp pháp hoặc kết quả.

For enterprise deployments, Gate có thể yêu cầu thêm một xác nhận từ Authorization Server được xác minh độc lập, gắn với chính bằng chứng nhân sự đó, chính hành động đó, ảnh chụp danh tính mà AS thực sự quan sát được, và khóa Resource Server dự kiến. Thời điểm chụp ảnh và tuổi tối đa của bên phụ thuộc được nêu rõ: một token mới không thể làm cho dữ liệu thư mục cũ trở nên hiện hành. Nhánh AS là bằng chứng dưới sự tin cậy do khách hàng ghim; nó không bao giờ tự nó ủy quyền, không chứng minh tình trạng việc làm tức thời, và không biến trình điều phối agent thành một cơ quan có thẩm quyền.

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

---

Tại sao nhà phát triển sử dụng nó

Bắt đầu bằng cách ánh xạ công việc cục bộ, sau đó bảo vệ một bề mặt hành động đã khai báo bằng MCP server hoặc trình bao bọc SDK mỏng. Trình quét đề xuất một bản đồ có thể xem xét; chủ sở hữu định nghĩa nhiệm vụ; Gate sở hữu 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 có quá trình quét nào chứng minh sự trung gian hoàn chỉnh, và việc khám phá một mình không trao 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

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

---

Tại sao doanh nghiệp cần nó

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

Gate và Assurance Plane được quản lý thêm các hoạt động nhiệm vụ, tích hợp, hoạt động bằng chứng, thực hiện lại, hỗ trợ và mức dịch vụ xung quanh giao thức mở. Khách hàng giữ quyền kiểm soát thẩm quyền, gốc tin cậy, thông tin xác thực, chính sách và bằng chứng di động.

---

Tiêu chuẩn

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

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

AEB-07 hiện được công bố, đăng vào 2026-09-25 như một Internet-Draft cá nhân và chưa được chấp nhận, làm cho AEB trở thành điểm tổng hợp sau một quyết định gốc. OAuth, AuthZEN, COAZ, AP2 và các hệ thống cục bộ giữ quyền sở hữu thông tin xác thực, ánh xạ hoạt động và quyết định ủy quyền của chúng. AIMS (draft-ietf-wimse-aims) là một tài liệu nhóm làm việc WIMSE mang tính thông tin, mô tả các tiêu chuẩn hiện có như WIMSE và OAuth; nó không tự phát hành thông tin xác thực hoặc 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ệ: nó ràng buộc hành động cuối cùng khi cần, dẫn xuất một danh tính phát lại gốc cho mỗi khoản cấp, dành trước trước khi vào nhà cung cấp, từ chối nỗ lực thứ hai cho cùng một hành động khi một nỗ lực trước đó đang diễn ra hoặc không chắc chắn, và giữ kết quả không chắc chắn bị khóa cho đến khi hòa giải được xác thực.

CAID-03 được sử dụng khi các biểu diễn được mã hóa độc lập phải được so sánh. Nó không phải là ánh xạ thứ hai bắt buộc khi PEP sở hữu hệ quả đã dẫn xuất và thực thi một quyết định hiện hành trên hoạt động cuối cùng. AEC-06 được sử dụng khi bên phụ thuộc 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 cấu hình khả dụng cho các triển khai cần chúng; chúng không phải là đ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 điều hướng.

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

Danh mục hoạt động hoàn chỉnh là 26 bản ghi Datatracker: 21 bản ghi tác giả đơn và năm bản ghi đồng tác giả, mỗi bản có phạm vi, lịch sử sửa đổi và trạng thái bảo trì được ghi lại riêng. Xem hướng dẫn tiêu chuẩn, danh mục và kiểm kê trạng thái có thể đọc bằng máy.

IETF Internet-Drafts	Đường dẫn ảnh chụp cục bộ hiện tại: kiểm kê trạng thái · kiểm kê đã đăng tác giả đơn · trạng thái trực tiếp có thẩm quyền: IETF Datatracker
Trình xác minh đa ngôn ngữ	JavaScript · Python · Go — cả ba đều được chứng minh đồng thuận trên các vectơ tuân thủ đối kháng, mỗi lần đẩy (npm run conformance). Kiểm tra nhất quán trên các cổng của một nhóm, không phải triển khai độc lập phòng sạch. Riêng biệt, một triển khai Rust từ đặc tả do bên ngoài tác giả (nguồn công khai) vượt qua bộ 16-suite/164-vectơ được ghim và chiến dịch thù địch 359 trường hợp được ghim dưới bản dựng lại do người đánh giá kiểm soát từ cây nguồn bất biến. Bằng chứng xây dựng được kiểm tra của nó vẫn được ký bởi người triển khai, không được chứng thực bởi bên thứ ba (tuyên bố có chữ ký); chấp nhận phòng sạch nghiêm ngặt chờ tuyên bố được chứng thực bởi bên thứ ba đã sửa và khóa người 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ữ trong không gian trạng thái đã cấu hình; đây không phải là tinh chỉnh triển khai hoặc 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 tổng hợp bao phủ thách thức, CAID, hai phê duyệt, ghim nhà phát hành và thẩm quyền, chế độ xem sổ đăng ký, thu hồi, tiêu thụ, thực thi và sáu ranh giới yêu cầu chuyên dụng. Hai mươi bổ đề Tamarin xác minh — 17 nghĩa vụ tất cả các dấu vết và 3 nhân chứng tồn tại dấu vết; tám biến thể làm suy yếu có chủ đích tạo ra các dấu vết tấn công cụ thể khi các kiểm tra chịu lực bị loại bỏ (formal/tamarin/).
Phân phối MCP	gói npm @emilia-protocol/mcp-server · việc công bố Registry chính thức được theo dõi riêng trong MCP-REGISTRY.md; danh sách tổng hợp không được suy ra từ một trong hai trạng thái
Giấy phép	Apache-2.0

Ba cổng tham chiếu cùng nhóm (JS / Python / Go) đồng thuận trên tất cả 21 bộ và 340 vectơ. Riêng biệt, một triển khai Rust do bên ngoài tác giả được dựng lại từ cây nguồn công khai được ghim vượt qua bộ phòng sạch 16-suite/164-vectơ được ghim và chiến dịch thù địch 359 trường hợp, chạy lại trong làn CI riêng của nó trên mỗi thay đổi. Các bộ chấp nhận AEC mới hơn và giải quyết bốn kết quả không được gán cho Rust. Đó là bằng chứng tương tác bên ngoài, không phải chấp nhận xây dựng phòng sạch nghiêm ngặt; hồ sơ CI tổng hợp ghi số chấp nhận nghiêm ngặt là không chờ 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 thẩm quyền

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

---

Điểm chứng minh

Chỉ số	Giá trị
Trường hợp kiểm thử tự động	10.700+ trên 650+ tệp; tất cả các trường hợp áp dụng cho nền tảng 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ữ 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 hoặc 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 nhóm đỏ được lập danh mục	86 — RED_TEAM_CASES.md
Trạng thái bảo mật phát hành	Kiểm tra bảo mật kho lưu trữ vượt qua; mọi phát hiện Strix trên các thay đổi được kiểm toán đều được khắc phục với phạm vi hồi quy và chuỗi đánh giá của nó đượ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 vectơ · 21 bộ: biên nhận · xác nhận thiết bị · giải quyết bốn kết quả · túc số đa bên · thu hồi · Ràng buộc kết quả (ngữ nghĩa + mật mã thực) · tham gia nhà phát hành Authority Document/Proof · chứng thực thời gian · biên nhận tin cậy (x2 cấu hình) · 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ệ · chứng thực người 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). Trình xác minh JS / Python / Go đồng thuận (node conformance/run.mjs). Đường cơ sở Rust bên ngoài vẫn là 164 vectơ / 16 bộ. Xem CONFORMANCE.md.
Bắt tay tạo p95	575ms tại 50 VUs — PERFORMANCE_PROOF.md

Tuổi thọ mật mã (với ranh giới triển khai rõ ràng)

Bằng chứng dự kiến được xác minh nhiều năm sau phải tồn tại lâu hơn các thuật toán mà nó được ký dưới đó. EP cung cấp bốn khả năng có giới hạn cho việc đó, 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 các byte chuẩn hóa, với bộ thuật toán được yêu cầu được cam kết vào các byte đã ký để việc loại bỏ một nhánh phá vỡ chữ ký còn lại. Khả năng này là tùy chọn khi triển khai; một khi trình ký kép được phê duyệt được đăng ký và chính sách cho phép nhánh PQ của nó, tư thế Gate không được ghim sẽ phân giải thành phát hành kép theo mặc định. Nếu không, nó vẫn chỉ dùng cổ điển với một lý do được đặt tên. 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 trình ký bên ngoài và bộ điều hợp AWS KMS được triển khai, nhưng không có cuộc gọi ký AWS trực tiếp, khóa sản xuất, xác minh bên phụ thuộc hoặc xác thực FIPS ML-DSA nào được tuyên bố. Xem conformance/hybrid-receipts/ và lib/pq-custody-aws-kms.ts.
• Cấu hình Tuyên bố có chữ ký SCITT (EP-SCITT-STATEMENT-v1). Một hình dạng Tuyên bố có chữ ký RFC 9943 hoàn chỉnh cho biên nhận EP, bao gồm tiêu đề được bảo vệ CWT Claims. Ranh giới: không có Transparency Service nào chấp nhận tuyên bố EP; đăng ký bên ngoài là một bước riêng biệt, có kiểm soát và chưa có bước nào đượ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ý dưới một thuật toán lão hóa có thể được neo lại dưới một thuật toán hiện tại trước khi thuật toán cũ yếu đi. Ranh giới: chứng thực lại phải xảy ra trước khi bị xâm phạm; nó không thể sửa chữa bằng chứng sau khi sự việc đã xảy ra.
• Chế độ triển khai FIPS (EP-FIPS-MODE-v1). Chạy các hoạt động cổ điển thông qua nhà cung cấp được xác thực FIPS 140-3 do người vận hành cung cấp, với đường dẫn ML-DSA bị khóa sau một xác nhận triển khai chưa được xác thực rõ ràng. Ranh giới: điều này đạt được "thuật toán dựa trên FIPS, với chế độ triển khai nhà cung cấp được xác thực" và phụ thuộc vào nhà cung cấp của người vận hành và ranh giới chứng chỉ đã khai báo; nó không phải là tuyên bố tuân thủ chung chung, và không có gì ở đây được xác thực FIPS. Xem FIPS-MODE.md.

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

---

Đối tượng giao thức cốt lõi

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

---

Bắt đầu nhanh

1. Cài đặt chính xác runtime bảo vệ cục bộ, sau đó chạy npx @emilia-protocol/scan@0.5.0 protect ./tools.json --action sendWire --apply --verify, thay thế sendWire bằng một công cụ có hậu quả được khai báo chính xác.
2. Xem lại Bản đồ thẩm quyền, bản kê khai hành động, các trường vật chất, ranh giới đã chọn và các điểm mù có tên đã tạo.
3. Chạy lệnh --reviewed --crossing-profile <launch-profile> riêng biệt để tạo 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 nhiệm vụ vận hành và bất kỳ quy tắc ngoại lệ con người mới hoặc đa số cần thiết nào.
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 và đối chiếu trước khi bật thực thi.

Demo 90 giây · Bắt đầu nhanh · Hướng dẫn tác nhân · Dự thảo 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ự động, không phải hệ thống danh tính, ví, điểm uy tín, đường ray thanh toán hoặc công cụ chính sách phổ quát.

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

Xem CONFORMANCE.md · SECURITY.md · THREAT_MODEL.md · GOVERNANCE.md · Neutrality Covenant