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 ในทุกเส้นทางไปยังข้อมูลรับรองของผู้ให้บริการที่ได้รับการคุ้มครอง การอนุมัติที่ถูกต้องไม่ได้ยืนยันว่ารายละเอียดธนาคารนั้นถูกต้องตามจริง

ถนัดใช้เบราว์เซอร์มากกว่าใช่ไหม ลองใช้ passkey กับการชำระเงินตัวอย่าง เดโมแยกนี้แสดงความถูกต้องครบถ้วนของใบรับรองด้วยตัวตรวจสอบสิทธิ์ของแพลตฟอร์มคุณ โดยไม่มีการส่งการชำระเงิน

ปกป้องเครื่องมือที่คุณใช้อยู่แล้วหนึ่งรายการ

เริ่มที่บริการซึ่งเก็บข้อมูลรับรองจริงของผู้ให้บริการ ไม่ใช่แค่ภายในกระบวนการของเอเจนต์ เจ้าของระบบกำหนดงานที่อนุญาตและเงื่อนไขที่ต้องขออนุมัติใหม่ เอเจนต์ทำงานภายในขอบเขตเหล่านั้นได้โดยไม่ต้องให้บุคคลอนุมัติทุกครั้งที่เรียกใช้

• MCP หรือ HTTP: Gate Starter แนะนำขั้นตอนการครอบคลุมการดำเนินการหนึ่งรายการ
• Hugging Face smolagents: ห่อหุ้มเครื่องมือที่มีอยู่
• GitHub: Merge Gate ผูกการตรวจสอบเข้ากับการผสานที่เสนอ ต้องกำหนดให้การตรวจสอบนี้เป็นข้อบังคับและปิดเส้นทางการผสานทางเลือก

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

ระบบ AI และผู้ตรวจสอบ repository: เริ่มจาก AI_CONTEXT.md หลักฐานที่เครื่องอ่านได้ในปัจจุบัน แหล่งที่มา สมมติฐาน และข้อยกเว้น เผยแพร่ไว้ที่ EMILIA-REPO-CONTEXT-v1 เอกสารที่เก็บถาวรหรืออยู่ระหว่างจัดเตรียมไม่ได้ยืนยันการติดตั้งใช้งานในปัจจุบันหรือสถานะ IETF หลักฐานสำหรับการตรวจสอบสถานะและขอบเขตของข้อกล่าวอ้างที่เปิดเผยต่อสาธารณะ: DUE_DILIGENCE.md

หลักฐานทางวิศวกรรม ไม่ใช่ข้อกล่าวอ้างด้านสถาปัตยกรรม

EMILIA มาพร้อมกรณีความปลอดภัยที่ผู้ตรวจสอบสามารถเรียกใช้ได้ repository ปัจจุบันแก้ไขข้อกล่าวอ้างด้านความปลอดภัย 35 ข้อจากไฟล์หลักฐานที่แฮชไว้ 264 ไฟล์ ตรวจสอบ บทตั้ง Tamarin 20 ข้อในโมเดล Dolev-Yao ที่ประกอบกัน 2 โมเดล — ภาระผูกพันแบบ all-traces 17 ข้อ และพยานการเข้าถึงแบบ exists-trace 3 ข้อ — และ เก็บรักษารูปแบบที่จงใจทำให้อ่อนแอลง 8 รูปแบบ ซึ่งสร้างร่องรอยการโจมตีที่เป็นรูปธรรมเมื่อถอดการตรวจสอบที่สำคัญออก คลังทดสอบความสอดคล้องภายในทีมเดียวกันที่ใช้งานอยู่มี 21 ชุดทดสอบและเวกเตอร์ปัจจุบัน 340 รายการ แยกต่างหากจากกัน ตัวตรวจสอบ Rust ที่เขียนโดยบุคคลภายนอกถูกตรึงไว้กับชุดข้อมูลที่หยุดเปลี่ยนแปลงแล้วซึ่งมี 16 ชุดทดสอบ/164 เวกเตอร์ และแคมเปญทดสอบความทนทานต่อการโจมตี 359 กรณี ชุดทดสอบที่กว้างกว่านี้มี การทดสอบอัตโนมัติมากกว่า 10,700 รายการในไฟล์มากกว่า 650 ไฟล์

พื้นผิว JavaScript สำหรับใช้งานจริงและ JSDoc ได้รับการตรวจสอบชนิดข้อมูลด้วยคอมไพเลอร์ TypeScript checkJs; แอปที่ปลอดภัยมีโปรเจกต์คอมไพเลอร์เพื่อความเข้ากันได้ของตัวเอง ขณะที่ declarations และ TypeScript SDK สาธารณะได้รับการตรวจสอบในโหมด strict นี่คือความครอบคลุมการตรวจสอบชนิดข้อมูลของโค้ดใช้งานจริงตามการกำหนดค่าที่ครบถ้วน ไม่ได้หมายความว่า repository ทั้งหมดถูกแปลงจาก JavaScript เป็น TypeScript หรือทุกโปรเจกต์ JavaScript เปิดใช้ตัวเลือก strict ของ TypeScript

ข้อกล่าวอ้างด้านความปลอดภัยแต่ละข้อระบุเส้นทางการบังคับใช้ เวกเตอร์เชิงบวกและเชิงลบ ความครอบคลุมของภาษา ขอบเขตการพิสูจน์อย่างเป็นทางการหรือช่องว่างที่ระบุไว้อย่างชัดเจน สมมติฐาน ข้อยกเว้น และแฮชหลักฐาน เริ่มจาก แผนที่หลักฐานสำหรับมนุษย์อ่าน จากนั้นตรวจสอบ กรณีความปลอดภัยที่แก้ไขแล้ว หรือเรียกใช้ npm run check:security-case

AEB-1: ทดสอบขอบเขตระหว่างหลักฐานกับผลที่เกิดขึ้น

ชุดทดสอบแบบเปิด AEB-1 Consequence Admission Conformance ทดสอบเส้นทาง CAID/AEC ที่ประกอบกัน ณ จุดควบคุมสุดท้ายก่อน การดำเนินการที่มีผลตามมา ได้แก่ การตรวจสอบแบบ native การยอมรับโดย relying party การผูกกับการดำเนินการที่แน่นอน การจับคู่ CAID ที่กำหนด การทำให้หลักฐาน AEC ที่กำหนดครบถ้วน การอนุญาตในเครื่อง การจองแบบ atomic การดูแลรักษา INVOKING การแยกความจริงของผลลัพธ์จากผู้ให้บริการออกจากความจริงของผลที่สังเกตได้ การไม่ลองใหม่โดยไม่ตรวจสอบ และการกระทบยอดที่ผ่านการยืนยันตัวตน

อ่านเรื่องขอบเขตการอนุญาตให้เกิดผลตามมา เพื่อดู การแบ่งหน้าที่อย่างชัดเจนระหว่างเส้นทาง CAID/AEC ที่ประกอบกัน เส้นทาง native โดยตรง การดูแลรักษา AEB และหลักฐานผลลัพธ์จากผู้ให้บริการ

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

ชุดทดสอบนี้ไม่ผูกกับรูปแบบใดรูปแบบหนึ่งและเรียกใช้ได้ด้วยตนเอง รายงานที่ผ่านเป็น หลักฐานความสอดคล้องที่ผู้ทดสอบรับรองเอง ไม่ใช่การตรวจสอบ การรับรอง การกล่าวอ้างว่าใช้งานจริง หรือการอนุญาตให้ดำเนินการ

ภายใต้ AEB-07 ซึ่งเผยแพร่เมื่อ 2026-09-25 ในฐานะ Internet-Draft โดยบุคคลทั่วไปและ ไม่ได้รับการรับรองจาก working group ใด CAID ใช้เฉพาะเมื่อจำเป็นต้องเชื่อมการดำเนินการที่เข้ารหัสแยกจากกัน และ AEC ใช้เฉพาะเมื่อนโยบายในเครื่องกำหนดให้ต้องมีหลักฐานหลายส่วน คลังทดสอบสังเคราะห์แยกต่างหาก 26 กรณีจำลองวงจรการทำงานแบบ native โดยตรงนี้ผ่านผลลัพธ์ของอะแดปเตอร์ AuthZEN/COAZ-MCP, AP2, OAuth Transaction Token และ local signed-mandate:

npm run conformance:composition:consequence-admission

ตัวเรียกใช้คลังทดสอบเป็นโมเดลวงจรการทำงานแบบ standalone ที่มีที่เก็บข้อมูลในหน่วยความจำและตรรกะการอนุญาตของตัวเอง ไม่ได้เรียกใช้โค้ด @emilia-protocol/verify หรือ @emilia-protocol/gate ที่จัดส่งมาด้วย จึงไม่ใช่หลักฐานสำหรับแพ็กเกจเหล่านั้น ซึ่งมีชุดทดสอบของตนเอง และยังไม่ใช่หลักฐานว่าโปรโตคอล native ที่ระบุไว้เป็นไปตาม AEB-07

หากต้องการพิสูจน์เส้นทาง Gate ของ repository โดยตรง ให้เรียกใช้:

npm run proof:gate:reference

คำสั่งนี้ทดสอบตัวอย่างในเครื่องและขอบเขตบริการเฉพาะ โดยใช้คีย์ที่สร้างขึ้น สถานะในหน่วยความจำ และพฤติกรรมผู้ให้บริการจำลอง เป็นหลักฐานในเครื่องที่มีประโยชน์ แต่ไม่ใช่หลักฐานว่ามีมนุษย์จริง ธนาคารภายนอก การติดตั้งใช้งานจริง หรือการผสานรวมใช้งานจริงแบบครบวงจร

ข้อมูลระบุตัวตนไม่ใช่คำอธิบายงาน

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

EMILIA แยกคำถามเหล่านี้ออกจากกัน:

ชั้น	คำถาม
ข้อมูลระบุตัวตน	ใครหรืออะไรอยู่ในระบบ?
นโยบาย	โดยทั่วไปอนุญาตอะไร?
อำนาจ	เอเจนต์นี้ทำงานใดได้อย่างแน่นอนภายใต้อาณัติฉบับนี้?

ข้อมูลรับรองให้สิทธิ์เข้าถึง อำนาจกำหนดงาน ไม่ใช่ทุกการดำเนินการที่ต้องมีมนุษย์ แต่ทุกการดำเนินการที่มีผลตามมาต้องมีอำนาจที่ถูกต้อง

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

---

กำหนดอาณัติครั้งเดียว แล้วปล่อยให้เอเจนต์ทำงาน

ลูกค้ากำหนดภารกิจ ขีดจำกัด ข้อกำหนดด้านหลักฐาน วันหมดอายุ และกฎข้อยกเว้น โค้ดในเครื่องอาจจำกัดอำนาจนั้นให้แคบลงได้ แต่สร้างหรือขยายอำนาจไม่ได้ 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

เดโมการประกอบระบบเชิงลึกจะดำเนินการชำระเงินที่มอบหมายและผูกกับ CAID ผ่าน เส้นทาง bounded-capability จริงของ Gate จากนั้นตรวจสอบใบรับรองการดำเนินการที่ลงนามแบบออฟไลน์:

npm run demo:receipt-program

เดโมนี้จงใจไม่รวมบล็อกเชนหรือข้อกล่าวอ้างเรื่อง zero-knowledge จำลอง ดู สถาปัตยกรรม receipt-program สำหรับข้อกำหนดด้านสถานะและความเชื่อถือของระบบใช้งานจริง

เริ่มจากการดำเนินการ MCP ที่มีผลตามมาซึ่งประกาศไว้หนึ่งรายการ ติดตั้ง runtime ในเครื่องที่ตรงตามข้อกำหนด จากนั้นสร้าง 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 ระบบใช้งานจริงต้องมีบัญชีแหล่งที่มาถาวร ที่เก็บข้อมูลการใช้สิทธิ์แบบ atomic ที่ใช้ร่วมกัน คีย์ที่ตรึงไว้ และ wrapper ในทุกเส้นทางไปยังข้อมูลรับรองจริงของผู้ให้บริการ ดู examples/mcp/ และ /mcp

หยุดการดำเนินการใหม่โดยไม่แสร้งว่าการดำเนินการเก่าถูกย้อนกลับแล้ว

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

การทำเช่นนี้ต้องอาศัยการควบคุมอย่างครบถ้วนและสถานะร่วมที่เชื่อถือได้ แต่ไม่ได้หยุดการประมวลผล ย้อนกลับผลที่เกิดขึ้น หรือเข้าถึงโดเมนที่ขาดการเชื่อมต่อได้ทันที ดู การติดตั้งใช้งานและข้อจำกัดของ control-domain

ทดลองใช้ใน 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 ของอุปกรณ์ หน้านี้ยังมีการจำลองด้วยซอฟต์แวร์แยกต่างหากด้วย ไม่ว่าโหมดใดก็ไม่ส่งการชำระเงินหรือสร้างการอนุญาตสำหรับระบบใช้งานจริง

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

---

วิธีทำงาน — วงจรอำนาจหนึ่งชุด

เรียกใช้ด้วยตนเอง: node examples/crash-test.mjs — ทำงานออฟไลน์ทั้งหมด ไม่ต้องใช้ API key

  [ 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

อาณัติ แหล่งที่มาของอำนาจกำหนดงานที่มีขอบเขตแน่นอน อาจเป็นโปรแกรมปฏิบัติการที่ลูกค้าลงนาม bounded capability การตัดสินใจจากมนุษย์ที่กำหนดให้ต้องมี มติจากองค์คณะ หรือการประกอบหลักฐาน native โดย relying party

งานที่แน่นอน Gate ผูก method, origin, callee, target, occurrence และทุกฟิลด์สำคัญเข้ากับออบเจ็กต์ที่เรียกใช้ได้แบบ canonical เจตนา prompt หรือข้อความใน ticket ไม่ใช่ออบเจ็กต์ดังกล่าว

ตรวจสอบ จอง และเข้าสู่ระบบ อาร์ติแฟกต์ native ยังคงเป็น native relying party ตรึงโปรไฟล์ความเชื่อถือและการแมป ประเมินข้อกำหนดหลักฐานทั้งหมด ตัดสินใจอนุญาตแยกต่างหากในเครื่อง และจองอำนาจที่ครอบคลุมก่อนที่อะแดปเตอร์ซึ่งถือข้อมูลรับรองจะเข้าสู่ผู้ให้บริการ

อำนาจจากมนุษย์ที่ยังมีผลเมื่อกำหนดให้ต้องมี นโยบายอาจกำหนดให้ต้องมีการตัดสินใจผ่าน WebAuthn/passkey ที่ผูกกับการดำเนินการที่แน่นอนและแฮชการแสดงผลแบบกำหนดแน่นอน วิธีนี้ช่วยลดช่องว่างระหว่าง “สิ่งที่คุณเห็นคือสิ่งที่คุณลงนาม” แต่ไม่ได้พิสูจน์ว่าผู้ใช้เข้าใจ มีวิจารณญาณ ถูกต้องตามกฎหมาย หรือได้ผลลัพธ์ตามต้องการ สำหรับการติดตั้งใช้งานในองค์กร Gate สามารถกำหนดให้ต้องมีการยืนยันจาก Authorization Server ที่ตรวจสอบโดยอิสระ และผูกกับหลักฐานจากมนุษย์รายการนั้นโดยเฉพาะ การกระทำเดียวกันนั้นโดยเฉพาะ สแนปช็อตข้อมูลระบุตัวตนที่ AS สังเกตเห็นจริง และคีย์ของ Resource Server ที่ตั้งใจใช้ เวลาของสแนปช็อตและอายุสูงสุดที่ relying party ยอมรับได้ระบุไว้อย่างชัดเจน: โทเค็นที่ยังใหม่ไม่อาจทำให้ข้อมูลไดเรกทอรีที่ล้าสมัยกลายเป็นข้อมูลปัจจุบันได้ ส่วนของ AS เป็นหลักฐานภายใต้ความเชื่อถือที่ลูกค้ากำหนดไว้ล่วงหน้า โดยตัวมันเองไม่ใช่การอนุญาต ไม่ได้พิสูจน์สถานะการจ้างงาน ณ ขณะนั้น และไม่ได้ทำให้ตัวประสานงานเอเจนต์กลายเป็นผู้มีอำนาจ

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

---

เหตุใดนักพัฒนาจึงใช้สิ่งนี้

เริ่มจากทำแผนผังงานในเครื่อง จากนั้นปกป้องพื้นผิวการกระทำที่ประกาศไว้หนึ่งรายการด้วย MCP server หรือ thin 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 จดทะเบียนเมื่อวันที่ 6 ตุลาคม 2026 โดยระบุถึงออบเจ็กต์ JSON แบบเปล่า AE-CHALLENGE-v1 ที่กำหนดไว้ใน ข้อกำหนดการทำซีเรียลไลซ์ที่เผยแพร่แล้ว การตอบกลับปฏิเสธของ HTTP ยังคงใช้ application/problem+json
• canactid: จดทะเบียนชั่วคราวเมื่อวันที่ 5 ตุลาคม 2026 โดยระบุชื่อการกระทำแบบระบุชนิดอย่างแม่นยำ ภายใต้ CAID-05 หมายเลข CRI ที่แก้ไขแล้วคือ 1033

การจดทะเบียนเหล่านี้เผยแพร่ชื่อและข้อกำหนดของชื่อดังกล่าว แต่ไม่ได้ยืนยันการรับรองจาก IETF การรับรองมาตรฐาน การรับรองคุณสมบัติ หรือการติดตั้งใช้งานของลูกค้า

พื้นผิวเดียวสำหรับขอบเขตผลกระทบ

AEB-07 ฉบับปัจจุบันที่เผยแพร่ ลงวันที่ 2026-09-25 ในฐานะ Internet-Draft รายฉบับและยังไม่ได้รับการรับรอง กำหนดให้ AEB เป็นจุดประกอบหลังการตัดสินใจแบบ native OAuth, AuthZEN, COAZ, AP2 และระบบภายในยังคงเป็นเจ้าของข้อมูลรับรอง การแมปการดำเนินการ และการตัดสินใจอนุญาตของตนเอง AIMS (draft-ietf-wimse-aims) เป็นเอกสาร Informational ของคณะทำงาน WIMSE ที่กำหนดแนวทางการใช้มาตรฐานที่มีอยู่ เช่น WIMSE และ OAuth โดยตัวมันเองไม่ได้ออกข้อมูลรับรองหรือการตัดสินใจ AEB นำการตัดสินใจแบบ native ไปใช้ที่ขอบเขตผู้ให้บริการที่ได้รับการปกป้อง โดยผูกกับการกระทำสุดท้ายเมื่อจำเป็น สร้างอัตลักษณ์สำหรับป้องกันการเล่นซ้ำแบบ native หนึ่งรายการต่อหนึ่งสิทธิ์ สำรองสิทธิ์ก่อนเข้าสู่ผู้ให้บริการ ปฏิเสธความพยายามครั้งที่สองสำหรับการกระทำเดียวกันขณะที่ความพยายามก่อนหน้ายังดำเนินอยู่หรือมีผลลัพธ์ไม่แน่นอน และคงสถานะผลลัพธ์ที่ไม่แน่นอนไว้จนกว่าจะกระทบยอดด้วยการยืนยันตัวตน

ใช้ CAID-05 เมื่อต้องเปรียบเทียบการแทนข้อมูลที่เข้ารหัสแยกจากกัน ตัวระบุใหม่ใช้รูปแบบ URI canactid: ที่จดทะเบียนชั่วคราวกับ IANA การจดทะเบียนนี้ไม่ใช่การรับรองจาก IETF การรับรองมาตรฐาน การรับรองคุณสมบัติ หรือสถานะถาวร CAID ไม่ใช่การแมปชั้นที่สองซึ่งจำเป็นต้องทำ หาก PEP ที่รับผิดชอบต่อผลกระทบได้สร้างและบังคับใช้การตัดสินใจปัจจุบันจากการดำเนินการสุดท้ายอยู่แล้ว ทดลองใช้สนามทดสอบการกระทำที่ระบุไว้อย่างแม่นยำ หรืออ่าน คู่มือการย้ายจาก CAID-04 ไป CAID-05 ใช้ AEC-06 เมื่อ relying party ต้องการหลักฐานหลายส่วน โปรไฟล์ Authorization Receipts, Human Authorization Binding และ Authority Introduction ยังคงมีให้ใช้สำหรับการติดตั้งใช้งานที่ต้องการ แต่ไม่ใช่ข้อกำหนดเบื้องต้นสำหรับการผสานระบบ AEB ทุกกรณี Architecture-03 ยังคงเป็นเอกสารนำทาง

คู่มือการอนุมัติผลกระทบ ระบุขอบเขตการติดตั้งใช้งานและกรณีที่ไม่จำเป็นต้องใช้ AEB โปรไฟล์การส่งต่อแบบ native โดยตรง เป็นโปรไฟล์การติดตั้งใช้งานใน repository ที่แสดงวิธีส่งต่อการอนุญาตที่มีอยู่ไปยัง Gate โดยไม่ต้องเพิ่มชั้น CAID หรือ AEC อีกชั้น AEB-07 ระบุว่าการส่งต่อไปยังเกตเวย์ดังกล่าวรับรองสิ่งใด และขอบเขตตรวจสอบสิ่งนั้นอย่างไร แต่ปล่อยให้การเข้ารหัสข้อมูลเป็นไปตามการกำหนดค่าของการติดตั้งใช้งาน โดยอ้างถึงสแนปช็อตที่กำหนดไว้ล่วงหน้าของโปรไฟล์นี้เป็นรูปแบบการเข้ารหัสอ้างอิงเพื่อประกอบความเข้าใจ ไบต์ -07 ที่ส่งจริงและบันทึกการเผยแพร่เก็บไว้ใน standards/staged/NEXT-AEB-07

ชุดเอกสารที่ยังใช้งานอยู่ทั้งหมดมีระเบียน Datatracker 26 รายการ: ระเบียนที่เขียนโดยผู้เขียนคนเดียว 21 รายการ และระเบียนที่เขียนร่วมกัน 5 รายการ โดยแต่ละรายการมีขอบเขต ประวัติการแก้ไข และสถานะการบำรุงรักษาที่บันทึกไว้เป็นของตนเอง ดู คู่มือมาตรฐาน, ชุดเอกสาร และ บัญชีสถานะแบบเครื่องอ่านได้

IETF Internet-Drafts	พาธสแนปช็อตในเครื่องปัจจุบัน: บัญชีสถานะ · บัญชีรายการที่เผยแพร่ซึ่งเขียนโดยผู้เขียนคนเดียว · สถานะสดที่มีอำนาจ: IETF Datatracker
ตัวตรวจสอบข้ามภาษา	JavaScript · Python · Go — ทั้งสามภาษาพิสูจน์แล้วว่าให้ผลตรงกันกับเวกเตอร์ทดสอบความสอดคล้องเชิงปฏิปักษ์ ในทุก push (npm run conformance) เป็นการตรวจสอบความสอดคล้องระหว่างพอร์ตของทีมเดียวกัน ไม่ใช่การติดตั้งใช้งานอิสระแบบ clean-room นอกจากนี้ การติดตั้งใช้งาน Rust ที่เขียนจากข้อกำหนดโดยผู้พัฒนาภายนอก (เผยแพร่ซอร์สแล้ว) ผ่านชุดทดสอบที่ตรึงไว้ 16 ชุด/164 เวกเตอร์ และแคมเปญทดสอบความทนทานต่อการโจมตี 359 กรณีที่ตรึงไว้ ภายใต้การสร้างใหม่ที่ควบคุมโดยผู้ประเมินจากแผนผังซอร์สที่ไม่เปลี่ยนแปลง หลักฐานการสร้างที่เช็กอินไว้ยังคงลงนามโดยผู้ติดตั้งใช้งาน ไม่ใช่การรับรองโดยบุคคลที่สาม (คำแถลงที่ลงนาม); การยอมรับแบบ clean-room อย่างเข้มงวดต้องรอ manifest ที่ได้รับการรับรองจากบุคคลที่สามฉบับแก้ไข และคีย์ผู้รับรองที่ตรึงไว้อย่างอิสระ
หลักฐานจากแบบจำลองเชิงรูปแบบ	คุณสมบัติความปลอดภัย TLA+ แบบมีขอบเขต 26 ข้อเป็นจริงในปริภูมิสถานะที่กำหนดค่าไว้; นี่ไม่ใช่การพิสูจน์การปรับปรุงให้สอดคล้องกับการติดตั้งใช้งานหรือการพิสูจน์แบบไม่จำกัด · ข้อเท็จจริง Alloy 35 ข้อ และ assertions 32 ข้อในสี่โมเดล · แบบจำลอง Dolev-Yao เชิงสัญลักษณ์แบบประกอบสองชุด ครอบคลุม challenge, CAID, การอนุมัติสองรายการ, การตรึง issuer และ authority, มุมมอง registry, การเพิกถอน, การใช้สิทธิ์, การดำเนินการ และขอบเขตการกล่าวอ้างเฉพาะหกข้อ เลมมา Tamarin ยี่สิบข้อผ่านการตรวจสอบ — ข้อผูกพันแบบ all-traces 17 ข้อ และพยานแบบ exists-trace 3 ข้อ; รูปแบบที่จงใจทำให้อ่อนลงแปดแบบสร้างร่องรอยการโจมตีที่เป็นรูปธรรมเมื่อเอาการตรวจสอบที่มีบทบาทสำคัญออก (formal/tamarin/)
การเผยแพร่ MCP	แพ็กเกจ npm @emilia-protocol/mcp-server · ติดตามการเผยแพร่บน Registry อย่างเป็นทางการแยกต่างหากใน MCP-REGISTRY.md; จะไม่อนุมานรายการใน aggregator จากสถานะใดสถานะหนึ่ง
สัญญาอนุญาต	Apache-2.0

พอร์ตอ้างอิงสามชุดที่พัฒนาโดยทีมเดียวกัน (JS / Python / Go) ให้ผลตรงกันในชุดทดสอบทั้ง 21 ชุดและเวกเตอร์ 340 รายการ นอกจากนี้ การติดตั้งใช้งาน Rust ที่เขียนโดยผู้พัฒนาภายนอกและสร้างใหม่จากแผนผังซอร์สสาธารณะที่ตรึงไว้ ผ่านชุดทดสอบ clean-room ที่ตรึงไว้ 16 ชุด/164 เวกเตอร์ และแคมเปญทดสอบความทนทานต่อการโจมตี 359 กรณี ซึ่งรันซ้ำใน CI lane ของตนเองทุกครั้งที่มีการเปลี่ยนแปลง ชุดทดสอบการยอมรับ AEC รุ่นใหม่กว่าและชุดทดสอบการแก้ไขผลลัพธ์สี่สถานะไม่ได้ระบุว่า Rust ผ่าน นี่คือหลักฐานการทำงานร่วมกันจากภายนอก ไม่ใช่การยอมรับการสร้างแบบ clean-room อย่างเข้มงวด; ระเบียนกรณีทดสอบ CI โดยรวมระบุจำนวนการยอมรับแบบเข้มงวดเป็นศูนย์จนกว่าจะมีการรับรองโดยอิสระ ดู CONFORMANCE.md หรือทดลองตรวจสอบใบรับรองด้วยตนเองที่ emiliaprotocol.ai/verify

---

ลำดับชั้นอำนาจ

ชั้น	หน้าที่
ขอบเขตอำนาจ	กำหนดภารกิจ ข้อจำกัด หลักฐาน วันหมดอายุ การมอบหมาย และกฎข้อยกเว้น
CAID / การกระทำที่ระบุไว้อย่างแม่นยำ	เปรียบเทียบความหมายที่มีสาระสำคัญ เมื่อการอนุญาตและการดำเนินการใช้รูปแบบแทนข้อมูลที่เข้ารหัสแยกจากกัน; ไม่ได้ทำหน้าที่อนุญาต
AEC	เมื่อจำเป็น จะประเมินว่าหลักฐานที่ตรวจสอบและจับคู่โดยอิสระเป็นไปตามข้อกำหนดหลายส่วนของ relying party หรือไม่; ไม่ได้ทำหน้าที่อนุญาต
AEB / Gate	นำการตัดสินใจอนุญาตแบบ native หรือภายในไปใช้ที่ขอบเขตผลกระทบ สำรองอำนาจที่ครอบคลุม และควบคุมการเข้าสู่ผู้ให้บริการ
หลักฐานผลลัพธ์	แยกการเรียกใช้ การตอบกลับจากผู้ให้บริการ ผลกระทบที่สังเกตได้ และความไม่แน่นอนออกจากกัน

---

จุดพิสูจน์

ตัวชี้วัด	ค่า
กรณีทดสอบอัตโนมัติ	มากกว่า 10,700 กรณีในไฟล์มากกว่า 650 ไฟล์; กรณีทั้งหมดที่ใช้ได้กับแพลตฟอร์มนั้นต้องผ่าน
คุณสมบัติความปลอดภัย TLA+	อินวาเรียนต์แบบมีขอบเขต 26 ข้อเป็นจริงในปริภูมิสถานะที่กำหนดค่าไว้; ไม่ใช่การพิสูจน์การปรับปรุงให้สอดคล้องกับการติดตั้งใช้งานหรือการพิสูจน์แบบไม่จำกัด — ดู PROOF_STATUS.md
assertions เชิงสัมพันธ์ของ Alloy	ข้อเท็จจริง 35 ข้อ + assertions 32 ข้อในสี่โมเดล — ตรวจสอบแล้วใน CI
กรณีทีม red-team ที่จัดทำรายการไว้	86 — RED_TEAM_CASES.md
สถานะความปลอดภัยของรีลีส	การตรวจสอบความปลอดภัยของ repository ผ่าน; ข้อค้นพบจาก Strix ทุกข้อในการเปลี่ยนแปลงที่ตรวจสอบได้รับการแก้ไขพร้อมการทดสอบ regression และปิดเธรดการตรวจทานแล้ว
ความสอดคล้อง (7/7)	node conformance/ep-conformance-test.js https://www.emiliaprotocol.ai
ความสอดคล้องข้ามภาษา	340 เวกเตอร์ · 21 ชุดทดสอบ: receipts · device signoffs · การแก้ไขผลลัพธ์สี่สถานะ · multi-party quorum · การเพิกถอน · Outcome Binding (เชิงความหมาย + real-crypto) · การเชื่อมโยงผู้ออก Authority Document/Proof · time-attestation · trust-receipt (2 โปรไฟล์) · provenance · evidence-record · canonicalization · boundary · การยอมรับ AEC · currency · initiator-attestation · consumption-proof · witness · timestamp-proof (RFC 3161) ตัวตรวจสอบ JS / Python / Go ให้ผลตรงกัน (node conformance/run.mjs) ส่วนฐานข้อมูล Rust ภายนอกยังคงอยู่ที่ 164 เวกเตอร์ / 16 ชุดทดสอบ ดู CONFORMANCE.md
p95 ของการสร้าง handshake	575ms ที่ 50 VUs — PERFORMANCE_PROOF.md

อายุการใช้งานของการเข้ารหัส (พร้อมขอบเขตการติดตั้งใช้งานที่ระบุไว้อย่างชัดเจน)

หลักฐานที่ต้องตรวจสอบได้ในอีกหลายปีข้างหน้าต้องมีอายุยืนกว่าอัลกอริทึมที่ใช้ลงนาม EP มีความสามารถที่กำหนดขอบเขตไว้สี่อย่างเพื่อรองรับเรื่องนี้ โดยแต่ละอย่างมีขอบเขตที่แน่นอนซึ่งเป็นส่วนหนึ่งของข้อกล่าวอ้าง:

• ลายเซ็นแบบไฮบริด (EP-RECEIPT-HYBRID-v1). ใช้ Ed25519 และ ML-DSA-65 กับไบต์มาตรฐานชุดเดียวกัน โดยกำหนดชุดอัลกอริทึมที่จำเป็นไว้ในไบต์ที่ลงนาม เพื่อให้การตัดลายเซ็นส่วนหนึ่งออกทำให้ลายเซ็นที่เหลือใช้ไม่ได้ ความสามารถนี้เลือกเปิดใช้ได้เมื่อติดตั้งใช้งาน เมื่อมีการลงทะเบียนผู้ลงนามคู่ที่ได้รับอนุมัติและนโยบายอนุญาตให้ใช้ส่วน PQ แล้ว ท่าทีของ Gate ที่ไม่ได้ปักหมุดจะเลือกออกลายเซ็นคู่เป็นค่าเริ่มต้น มิฉะนั้นจะคงใช้เฉพาะลายเซ็นแบบคลาสสิก พร้อมระบุเหตุผล v1 verifier ปฏิเสธใบรับรองแบบไฮบริดอย่างชัดเจน แทนที่จะยอมรับลายเซ็นเพียงส่วนเดียว มีการติดตั้งใช้งานสัญญาผู้ลงนามภายนอกและ AWS KMS adapter แล้ว แต่ไม่ได้อ้างว่ามีการเรียกลงนามจริงผ่าน AWS, มีคีย์สำหรับใช้งานจริง, มีการตรวจสอบโดย relying party หรือมีการตรวจสอบความถูกต้องตาม FIPS ของ ML-DSA ดู conformance/hybrid-receipts/ และ lib/pq-custody-aws-kms.ts
• โปรไฟล์ SCITT Signed Statement (EP-SCITT-STATEMENT-v1). รูปแบบ Signed Statement ตาม RFC 9943 ที่ครบถ้วนสำหรับใบรับรอง EP รวมถึง protected header ของ CWT Claims ขอบเขต: ยังไม่มี Transparency Service ยอมรับ statement ของ 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	กฎที่ relying party ปักหมุดไว้ และการประเมิน SATISFIED, UNSATISFIED หรือ INDETERMINATE
บันทึกการรับเข้าและการดูแลรักษา AEB	บันทึกฝั่ง executor เกี่ยวกับสถานะการอนุญาต การจอง การเข้าสู่ provider และการกระทบยอด
หลักฐานการอนุญาตและผลลัพธ์	อาร์ติแฟกต์แบบ native หรือ EP ที่พกพาได้ โดยคงผู้ออก ขอบเขต และขอบเขตของคำกล่าวอ้างเดิมไว้อย่างครบถ้วน

---

เริ่มต้นใช้งานอย่างรวดเร็ว

1. ติดตั้งรันไทม์ guard ในเครื่องที่ตรงตามข้อกำหนดทุกประการ จากนั้นเรียกใช้ npx @emilia-protocol/scan@0.6.0 protect ./tools.json --action sendWire --apply --verify โดยแทนที่ sendWire ด้วยเครื่องมือที่มีผลกระทบซึ่งประกาศไว้แบบตรงกันทุกประการหนึ่งรายการ
2. ตรวจสอบ Authority Map, action manifest, ฟิลด์ที่มีสาระสำคัญ, ขอบเขตที่เลือก และจุดบอดที่ระบุชื่อซึ่งสร้างขึ้น
3. เรียกใช้คำสั่ง --reviewed --crossing-profile <launch-profile> แยกต่างหากเพื่อสร้าง handoff ที่เจ้าของเท่านั้นเข้าถึงได้ และพื้นที่ทำงาน Lab ที่ยังไม่ปิดผนึกจากไบต์เดิมที่ไม่มีการเปลี่ยนแปลง
4. ติดตั้ง Gate บนเส้นทางที่เป็นเจ้าของข้อมูลรับรองของ provider และสถานะการใช้สิทธิ์แบบถาวร
5. กำหนดข้อกำหนดการปฏิบัติงานและกฎข้อยกเว้นสำหรับการยืนยันจากมนุษย์ใหม่หรือองค์ประชุม
6. ทดสอบกรณีการปฏิเสธ การดำเนินการที่ตรงกันทุกประการ การเล่นซ้ำ การหมดเวลา และการกระทบยอดก่อนเปิดใช้การบังคับใช้นโยบาย

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

---

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

EMILIA คือโครงสร้างพื้นฐานด้านอำนาจสำหรับงานอัตโนมัติ ไม่ใช่ระบบระบุตัวตน กระเป๋าเงิน คะแนนชื่อเสียง ช่องทางชำระบัญชี หรือกลไกนโยบายสากล

• เป็น: ระนาบควบคุมสำหรับข้อกำหนดการปฏิบัติงานที่มีขอบเขตจำกัด การตรวจสอบการดำเนินการที่ตรงกันทุกประการ สถานะการรับเข้าที่คงทน การระบุความไม่แน่นอนอย่างตรงไปตรงมา และหลักฐานที่พกพาได้บนเส้นทาง executor ที่ครอบคลุม
• ไม่ใช่: สิ่งทดแทน OAuth/OIDC, workload identity หรือ policy engine สิ่งเหล่านั้นยังคงเป็นอินพุตแบบ native ภายใต้การปักหมุดของ relying party
• ไม่ใช่: ข้อกำหนดให้มนุษย์อนุมัติทุกการดำเนินการ ข้อกำหนดมอบอำนาจอาจอนุญาตให้ทำงานอัตโนมัติภายในขอบเขตจำกัด และกำหนดให้ต้องมีอำนาจใหม่เฉพาะเมื่อถึงขีดจำกัด
• ไม่ใช่: หลักฐานว่าการดำเนินการที่รับเข้าแล้วสำเร็จหรือก่อให้เกิดผลตามที่ตั้งใจไว้
• ไม่ใช่: การควบคุมโปรโตคอลแบบกรรมสิทธิ์เฉพาะ ส่วนหลักเป็น Apache-2.0 และ Internet-Drafts เป็นเอกสารที่ผู้เขียนส่งเป็นรายบุคคล ไม่ใช่ RFC หรือการรับรองจาก IETF

ดู CONFORMANCE.md · SECURITY.md · THREAT_MODEL.md · GOVERNANCE.md · พันธสัญญาความเป็นกลาง