EMILIA Protocol MCP Server

ทางการ

กำหนดให้ต้องได้รับการอนุมัติแบบออฟไลน์ที่ตรวจสอบได้จากบุคคลที่มีชื่อ ก่อนที่เอเจนต์ AI จะดำเนินการที่ไม่สามารถย้อนกลับได้ เช่น การปล่อยการชำระเงิน การเปลี่ยนแปลงบันทึก หรือการปรับใช้ ใช้กฎสองคน, Ed25519 Trust Receipts, ร่างโดย IETF, Apache-2.0

GitHub

เอกสาร

EMILIA Protocol

เครื่องยนต์ที่ไร้เบรก

เป็นเวลาห้าสิบปีที่ความปลอดภัยของซอฟต์แวร์ตอบคำถามเดียว: ใครได้รับอนุญาตให้เข้า? ไฟร์วอลล์, OAuth และรหัสผ่าน — ทั้งหมดถูกสร้างขึ้นเพื่อยืนยันตัวตนมนุษย์ที่ประตู

ยุคนั้นกำลังสิ้นสุดลง ผู้ใช้ซอฟต์แวร์หลักไม่ใช่มนุษย์อีกต่อไป แต่เป็นเอเจนต์ AI อัตโนมัติ เอเจนต์ไม่เพียงแค่เข้าสู่ระบบ — พวกมันเขียนโค้ด เรียกใช้เครื่องมือ และเปลี่ยนแปลงความเป็นจริงได้ทันที CISO ทุกคนรู้ว่าคำสั่งที่ไม่ดีเพียงคำสั่งเดียวสามารถทำให้เอเจนต์ล้างฐานข้อมูลการผลิตหรือโอนเงินไปยังบัญชีผิดได้ ดังนั้นพวกเขาจึง บล็อกการปรับใช้ — นั่งทับงบประมาณ AI หลายพันล้านที่ใช้ไม่ได้เพราะทีมปฏิบัติตามกฎระเบียบไม่สามารถตอบคำถามเดียวได้:

ใครอนุมัติการกระทำนั้น?

วิกฤตของยุคเราไม่ใช่การยืนยันตัวตน แต่เป็น การอนุญาต ณ ขณะกระทำ: คุณจะพิสูจน์ได้อย่างไรว่า สิ่งที่เอเจนต์กำลังจะทำ คือ สิ่งที่มนุษย์ที่ระบุชื่อได้อนุญาตไว้อย่างแน่นอน — ก่อนที่มันจะดำเนินการ?

EMILIA คือเข็มขัดนิรภัยสำหรับยุคเอเจนต์

บันทึกการตัดสินใจคือคำให้การ EMILIA สร้างใบเสร็จ

ไม่มีใบเสร็จ ไม่มีการกระทำที่ย้อนกลับไม่ได้

หากเอเจนต์พยายามเคลื่อนย้ายเงิน ลบโค้ด ปรับใช้โปรดักชัน เปลี่ยนสิทธิ์ หรือเปลี่ยนแปลง สถานะที่ถูกควบคุม โดยไม่มีใบเสร็จ EMILIA ที่ถูกต้อง เครื่องมือจะปฏิเสธการทำงาน — และถ้ามันทำงาน ใครก็ตามสามารถตรวจสอบได้ว่าใครอนุมัติอะไรอย่างแน่นอน แบบออฟไลน์ โดยไม่ต้องเชื่อใจใคร

นั่นคือโปรโตคอลทั้งหมด ลิ่มสำหรับนักพัฒนาคือ wrapper หนึ่งรอบเครื่องมือ 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

ห่อตัวจัดส่งเครื่องมือของคุณเองในการผลิต — ดู examples/mcp/ และ /mcp:

import { withMcpGuard } from '@emilia-protocol/mcp-guard';
const guarded = withMcpGuard(handleTool, {
  annotations: { release_payment: { irreversible: true, action: 'payment.release' } },
}); // missing receipt → refused, never a silent pass

ลองใช้ใน 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

ลองการลงนามด้วย Face ID จริง → อนุมัติการโอนเงิน $82,000 ด้วย passkey ของคุณเอง ดูว่าสถานะ VERIFIED เป็นอย่างไร ปลอมแปลงใบเสร็จ ดูมันล้มเหลว

ตรวจสอบใบเสร็จใดๆ ในเบราว์เซอร์ของคุณ — วางมันลงไป ไม่มีอะไรถูกอัปโหลด

วิธีการทำงาน — สี่องก์

EMILIA crash test — an autonomous agent tries to wire $82,000; the policy engine holds it, a named human signs off on their own device, the receipt verifies offline, and a forged copy fails.

รันด้วยตัวคุณเอง: node examples/crash-test.mjs — ออฟไลน์เต็มรูปแบบ ไม่มีคีย์ API

  [ INTENT ]          [ DECISION ]           [ CEREMONY ]           [ RECEIPT ]
  Agent calls a     Policy-bound, hash-    Named human signs     Signed, offline-
  tool via MCP   →  pinned: allow /     →  the EXACT action  →  verifiable proof.
                    allow-with-signoff /   on their own          Tamper it:
                    deny  (+observe        device (passkey).      fails by design.
                    mode: zero change      What they saw =
                    to production)         what they signed.

องก์ที่ 1 — การสกัดกั้น (เนทีฟ MCP). ไม่มีการเขียนใหม่ EMILIA เกี่ยวการเรียกเครื่องมือที่ขอบเขต Model Context Protocol — ช่วงเวลาที่เอเจนต์พยายามลบไฟล์หรือเคลื่อนย้ายทุน การกระทำจะถูกจับกลางอากาศ

องก์ที่ 2 — การตัดสินใจ (ผูกกับนโยบาย, กำหนดได้). การกระทำถูกตรวจสอบกับนโยบายที่ตรึงด้วยแฮช: allow, allow-with-signoff, หรือ deny. บวกกับ โหมดสังเกตการณ์ ที่ไม่เปลี่ยนแปลงอะไรในการผลิตและรายงานสิ่งที่ จะ ถูกระงับ กำหนดได้ ตรวจสอบได้ — ไม่ใช่คะแนนความเสี่ยงแบบกล่องดำ

องก์ที่ 3 — พิธีการ (การลงนามมนุษย์ที่ผูกกับอุปกรณ์). เมื่อนโยบายต้องการมนุษย์ EMILIA รัน การลงนาม WebAuthn / passkey ที่ผูกกับการกระทำที่แน่นอน — Face ID / Touch ID บนอุปกรณ์ของผู้ปฏิบัติงานเอง สิ่งที่มนุษย์เห็นคือสิ่งที่พวกเขาลงนาม ไม่มีสคริปต์ใดปลอมแปลงได้ ไม่มีลูปอัตโนมัติใดข้ามได้

องก์ที่ 4 — ใบเสร็จ (หลักฐาน). ผลลัพธ์คือ ใบเสร็จการอนุญาตที่ลงนามแล้ว ที่ใครก็ตามสามารถตรวจสอบได้ แบบออฟไลน์ ด้วยโค้ดโอเพนซอร์ส ไม่มีแบ็กเอนด์ ไม่ต้องเชื่อใจผู้ขาย แก้ไขมันและการตรวจสอบจะล้มเหลวโดยโครงสร้าง สามารถยึดโยงมันสำหรับการประทับเวลาสาธารณะได้ — แกนหลักไม่ต้องการบล็อกเชน

ทำไมนักพัฒนาถึงใช้มัน

คุณต้องการเอเจนต์ที่ ทำสิ่งต่างๆ ได้จริง — แต่คุณเป็นอัมพาตเพราะลูปที่ควบคุมไม่ได้ การใช้จ่าย API เกิน และการทำลายข้อมูลโดยไม่ตั้งใจ EMILIA ให้ เซิร์ฟเวอร์ MCP แบบ plug-and-play + SDK wrapper แบบบาง แก่คุณ ใช้แฮชนโยบาย และการเรียกเครื่องมือที่ย้อนกลับไม่ได้จะได้รับชั้นการอนุมัติและหลักฐานที่แข็งแกร่งทางการเข้ารหัส ซึ่งแมปกับ NIST-AI-RMF — โดยไม่ต้องสร้างเวิร์กโฟลว์การอนุมัติหรือโครงสร้างพื้นฐานการตรวจสอบตั้งแต่ต้น

# 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

เอเจนต์ของคุณไม่สามารถวิ่งหนีสายจูงของมันได้

ทำไมองค์กรถึงต้องการมัน

ทุกการเปลี่ยนแพลตฟอร์มสร้างพื้นฐานความปลอดภัยใหม่: เว็บได้ SSL, คลาวด์ได้ Okta / IAM, เศรษฐกิจเอเจนต์ต้องการ ความเชื่อใจระดับการกระทำ องค์กรต่างๆ กำลังนั่งทับงบประมาณ AI ที่การปฏิบัติตามกฎระเบียบไม่ให้ใช้ — EMILIA คือกุญแจที่ปลดล็อกพวกมัน โดยเปลี่ยนเอเจนต์ที่คาดเดาไม่ได้ให้เป็นโครงสร้างพื้นฐานที่พร้อมตรวจสอบ ซึ่งแมปแบบพื้นฐานต่อพื้นฐานกับ NIST AI RMF, EU AI Act และการควบคุม SOC 2 CC6/7

ชั้นที่มีการจัดการ (GovGuard / FinGuard) ขยายมาตรฐานเปิดด้วยแพ็คนโยบายเฉพาะภาคส่วน ไพล็อตโหมดสังเกตการณ์ และแพ็คเกจหลักฐานที่พร้อมตรวจสอบ — โดยไม่ต้องมีการจัดซื้อเพื่อเริ่มต้น

มาตรฐาน

EMILIA เป็นมาตรฐานเปิด ไม่ใช่คูเมืองผลิตภัณฑ์ แกนหลักคือ Apache-2.0 และถูกติดตามเป็น Internet-Draft ของ IETF


IETF Internet-Drafts	โพสต์แล้ว: authorization-receipts · quorum. จัดฉากใน `standards/`: authorization-evidence-chain (EP-AEC, การประกอบ) · evidence-record (EP-EVIDENCE-RECORD, การเก็บรักษาระยะยาว). แผนที่ภาคสนาม: การสำรวจภาพรวม.
ตัวตรวจสอบข้ามภาษา	JavaScript · Python · Go — ทั้งสามพิสูจน์แล้วว่าเห็นพ้องกับเวกเตอร์ความสอดคล้องที่เป็นปฏิปักษ์ ทุก push (`npm run conformance`). นั่นคือมาตรฐาน IETF สำหรับมาตรฐานจริง: การนำไปใช้ที่ทำงานร่วมกันได้อิสระหลายตัว
การตรวจสอบอย่างเป็นทางการ	26 คุณสมบัติความปลอดภัย TLA+ (0 ข้อผิดพลาด) · 35 ข้อเท็จจริง Alloy, 22 การยืนยัน — ทั้งคู่รันใน CI
รีจิสทรี MCP	รีจิสทรี MCP อย่างเป็นทางการ · Glama (เกรด A, ตราทางการ) · Smithery
ใบอนุญาต	Apache-2.0

การนำไปใช้ที่เป็นอิสระสามตัวพิสูจน์แล้วว่าเห็นพ้อง — ดู CONFORMANCE.md, หรือตรวจสอบใบเสร็จด้วยตัวคุณเองที่ emiliaprotocol.ai/verify.

สแต็ก EP

Eye observes. Handshake verifies. Signoff owns. Commit seals.

ชั้น	สิ่งที่มันทำ
EP Eye	สังเกตและจำแนกพฤติกรรมเอเจนต์ (OBSERVE → SHADOW → ENFORCE)
EP Handshake	พิธีการยินยอมทางการเข้ารหัสที่มีการผูก 7 คุณสมบัติ
EP Signoff	ความเป็นเจ้าของมนุษย์ที่ระบุชื่อ — WebAuthn / passkey Class A, ผูกกับอุปกรณ์; องค์ประชุมหลายฝ่าย (M-of-N / เรียงลำดับ — กฎสองคน) สำหรับการกระทำที่มีเดิมพันสูงสุด
EP Commit	การปิดการกระทำแบบอะตอมมิก ไม่เปลี่ยนรูป พร้อมใบเสร็จที่เชื่อมโยงด้วย Merkle

จุดพิสูจน์

เมตริก	ค่า
การทดสอบอัตโนมัติ	4,220 ใน 173 ไฟล์
คุณสมบัติความปลอดภัย TLA+	26 ตรวจสอบแล้ว (T1–T26), 0 ข้อผิดพลาด — ดู PROOF_STATUS.md
การยืนยันเชิงสัมพันธ์ Alloy	35 ข้อเท็จจริง + 22 การยืนยันในสองโมเดล — ตรวจสอบใน CI
กรณีทีมแดงที่จัดทำรายการ	85 — RED_TEAM_CASES.md
ข้อค้นพบด้านความปลอดภัยที่แก้ไขแล้ว	31
ความสอดคล้อง (7/7)	`node conformance/ep-conformance-test.js https://www.emiliaprotocol.ai`
ความสอดคล้องข้ามภาษา	8 ชุด — ใบเสร็จ · การลงนามอุปกรณ์ · องค์ประชุมหลายฝ่าย · การเพิกถอน · การรับรองเวลา · ใบเสร็จความเชื่อใจ · ที่มา · บันทึกหลักฐาน — ตัวตรวจสอบ JS / Python / Go เห็นพ้อง (`node conformance/run.mjs`)
Handshake create p95	575ms ที่ 50 VUs — PERFORMANCE_PROOF.md

ออบเจกต์หลักของ EP

EP กำหนดมาตรฐานออบเจกต์ที่ทำงานร่วมกันได้สามตัวที่การนำไปใช้ที่สอดคล้องใดๆ สามารถผลิตและตรวจสอบได้:

ออบเจกต์	มันคืออะไร
Trust Receipt	บันทึกที่ลงนามแล้วแบบพกพาของเหตุการณ์การอนุญาต — สิ่งที่เกิดขึ้น
Trust Profile	สรุปมาตรฐานของสถานะความเชื่อใจที่สังเกตได้ — สิ่งที่รู้
Trust Decision	ผลลัพธ์ที่ประเมินตามนโยบายพร้อมเหตุผลและเส้นทางอุทธรณ์ — สิ่งที่ต้องทำตอนนี้

ส่วนขยาย EP (Handshake, Signoff, Commit, Delegation) เพิ่มการบังคับใช้ที่แข็งแกร่งขึ้นเมื่อระบบต้องจำกัดการดำเนินการ ชั้นผลิตภัณฑ์ (GovGuard / FinGuard) ถูกสร้างขึ้นด้านบน — ไม่ใช่ตัวโปรโตคอลเอง

เริ่มต้นอย่างรวดเร็วในห้าคำสั่ง

สร้างนโยบาย
เริ่มต้น handshake
นำเสนอหลักฐาน
ตรวจสอบ
ลงนามและใช้งาน

เดโม 90 วินาที · เริ่มต้นอย่างรวดเร็ว · คำแนะนำเอเจนต์ · IETF Draft · Discord

EP คืออะไร — และไม่ใช่อะไร

EP คือการอนุญาต ณ ขณะกระทำ ไม่ใช่ระบบระบุตัวตน ไม่ใช่กระเป๋าเงิน ไม่ใช่คะแนนชื่อเสียง

คือ: มาตรฐานความเชื่อใจสำหรับการผูกตัวตนผู้กระทำ อำนาจ นโยบาย และบริบทการกระทำที่แน่นอน ก่อน การดำเนินการ
ไม่ใช่: การแทนที่ OAuth / OIDC (สิ่งเหล่านั้นตอบ คุณคือใคร — EP ตอบ ใครอนุมัติการกระทำที่แน่นอนนี้)
ไม่ใช่: ผลิตภัณฑ์ที่เป็นกรรมสิทธิ์ (แกนหลักคือ Apache-2.0 และติดตามโดย IETF)
ไม่ใช่: บล็อกเชน (ใบเสร็จคือฮีโร่; การประทับเวลาสาธารณะที่เป็นทางเลือกคือเชิงอรรถ)

ดู CONFORMANCE.md · SECURITY.md · THREAT_MODEL.md · GOVERNANCE.md