EMILIA Protocol

EMILIA Protocol

---

Biarkan agen Anda menyiapkan pembayaran. Kendalikan apa yang dapat dilepasnya.

Agen menyiapkan pembayaran pemasok sebesar $82,000. Seseorang menyetujuinya. Lalu jumlah atau tujuan bank berubah. Persetujuan sebelumnya tidak boleh melepaskan pembayaran yang telah berubah.

EMILIA Gate memeriksa kewenangan sebelum alat yang dilindungi dijalankan. Protokol terbuka ini membuat bukti yang dihasilkan dapat diperiksa secara independen berdasarkan kunci tepercaya dan aturan milik verifier. Tetap gunakan penyedia identitas, kerangka kerja agen, dan sistem bisnis Anda yang sudah ada.

Jalankan contoh pembayaran

Dengan Node.js 20.19 atau yang lebih baru dan npm terpasang:

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

Contoh ini menolak panggilan tanpa persetujuan, mengikat persetujuan pada jumlah, mata uang, vendor, dan tujuan, menerima panggilan yang cocok satu kali, serta menolak detail pembayaran yang berubah, pemutaran ulang, dan bukti palsu. Lihat contoh dan batasannya.

Ini adalah demonstrasi lokal: kunci penandatanganan yang dibuat, konsumsi dalam memori, dan alat pembayaran tiruan. Demonstrasi ini tidak menjalankan proses persetujuan manusia yang nyata atau memindahkan uang. Produksi memerlukan kredensial terdaftar, status bersama yang persisten, dan Gate pada setiap jalur menuju kredensial penyedia yang dilindungi. Persetujuan yang valid tidak membuktikan bahwa detail bank itu sah.

Lebih suka browser? Coba passkey untuk pembayaran contoh. Demo terpisah ini menunjukkan integritas tanda terima dengan autentikator platform Anda; tidak ada pembayaran yang dikirim.

Lindungi satu alat yang sudah Anda gunakan

Mulailah dari layanan yang menyimpan kredensial penyedia yang sebenarnya, bukan hanya di dalam proses agen. Pemilik menentukan pekerjaan yang diizinkan dan kapan persetujuan baru diperlukan. Agen dapat bekerja dalam batas tersebut tanpa seseorang harus menyetujui setiap panggilan.

• MCP atau HTTP: Gate Starter memandu Anda melalui satu tindakan yang dilindungi.
• Hugging Face smolagents: bungkus alat yang sudah ada.
• GitHub: Merge Gate mengikat pemeriksaan pada penggabungan yang diusulkan. Pemeriksaan harus diwajibkan dan jalur penggabungan alternatif harus ditutup.

Protokol membuktikan. Gate mencegah pada jalur yang dimediasi sepenuhnya oleh deployment. Gate tidak dapat membatasi jalur pintas. Jika hasil dari penyedia tidak diketahui, siklus hidup produksi mempertahankan ketidakpastian itu untuk rekonsiliasi, alih-alih mencoba ulang secara membabi buta.

Sistem AI dan peninjau repositori: mulai dengan AI_CONTEXT.md. Bukti terkini yang dapat dibaca mesin, asal-usul, asumsi, dan pengecualian dipublikasikan di EMILIA-REPO-CONTEXT-v1. Dokumen yang diarsipkan atau masih dalam tahap persiapan tidak membuktikan implementasi terkini atau status IETF. Bukti uji tuntas publik dan batas klaim: DUE_DILIGENCE.md.

Bukti rekayasa, bukan klaim arsitektur

EMILIA menyediakan kasus keamanan yang dapat dijalankan oleh peninjau. Repositori saat ini menyelesaikan 35 klaim keamanan atas 264 berkas bukti yang di-hash, memverifikasi 20 lemma Tamarin di dua model Dolev-Yao yang dikomposisikan — 17 kewajiban untuk semua jejak dan 3 saksi keterjangkauan jejak eksistensial — serta mempertahankan 8 varian yang sengaja dilemahkan, yang menghasilkan jejak serangan konkret ketika pemeriksaan penentu dihapus. Korpus konformansi tim yang aktif berisi 21 suite dan 340 vektor terkini. Secara terpisah, verifier Rust yang ditulis pihak eksternal dipatok pada bundel beku 16-suite/164-vektor dan kampanye permusuhan 359 kasus. Suite yang lebih luas mencakup lebih dari 10.700 pengujian otomatis di lebih dari 650 berkas.

Permukaan JavaScript produksi dan JSDoc diperiksa oleh compiler dengan TypeScript checkJs; aplikasi aman memiliki proyek compiler kompatibilitasnya sendiri, sementara deklarasi dan SDK TypeScript publik diperiksa dalam mode ketat. Ini adalah cakupan pemeriksaan tipe produksi yang lengkap sesuai konfigurasi, bukan klaim bahwa seluruh repositori telah dikonversi dari JavaScript ke TypeScript atau bahwa setiap proyek JavaScript mengaktifkan opsi strict milik TypeScript.

Setiap klaim keamanan menyebutkan jalur penegakan, vektor positif dan negatif, cakupan bahasa, cakupan formal atau kesenjangan yang dinyatakan secara eksplisit, asumsi, pengecualian, dan hash bukti. Mulailah dengan peta bukti yang dapat dibaca manusia, lalu periksa kasus keamanan yang telah diselesaikan atau jalankan npm run check:security-case.

AEB-1: uji batas antara bukti dan dampak

Paket terbuka AEB-1 Consequence Admission Conformance menguji jalur CAID/AEC yang dikomposisikan pada titik kendali terakhir sebelum tindakan yang berdampak: verifikasi native, penerimaan pihak pengandalan, pengikatan tindakan yang tepat, pencocokan CAID yang diwajibkan, pemenuhan bukti AEC yang diwajibkan, otorisasi lokal, reservasi atomik, kustodi INVOKING, kebenaran hasil penyedia dan dampak yang diamati secara terpisah, perilaku tanpa percobaan ulang membabi buta, serta rekonsiliasi terautentikasi.

Baca batas penerimaan konsekuensi untuk pembagian tanggung jawab yang tepat di seluruh jalur CAID/AEC yang dikomposisikan, jalur native langsung, kustodi AEB, dan bukti hasil penyedia.

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

Paket ini netral format dan dapat dijalankan sendiri. Laporan yang lulus merupakan bukti konformansi yang dinyatakan sendiri, bukan audit, sertifikasi, klaim deployment produksi, atau izin untuk menjalankan tindakan.

Berdasarkan AEB-07, yang dipublikasikan pada 2026-09-25 sebagai Internet-Draft individual dan belum diadopsi oleh kelompok kerja mana pun, CAID hanya digunakan ketika tindakan yang dikodekan secara independen harus digabungkan, dan AEC hanya digunakan ketika kebijakan lokal mewajibkan beberapa komponen bukti. Korpus sintetis terpisah berisi 26 kasus yang memodelkan siklus hidup native langsung tersebut melalui hasil adapter AuthZEN/COAZ-MCP, AP2, OAuth Transaction Token, dan mandat lokal bertanda tangan:

npm run conformance:composition:consequence-admission

Runner korpus ini adalah model siklus hidup mandiri dengan penyimpanan dalam memori dan logika penerimaannya sendiri. Runner ini tidak menjalankan kode @emilia-protocol/verify atau @emilia-protocol/gate yang disertakan, sehingga bukan bukti untuk paket-paket tersebut, yang memiliki suite pengujiannya sendiri. Runner ini juga bukan bukti bahwa protokol native yang disebutkan mematuhi AEB-07.

Untuk bukti eksekusi terfokus atas jalur Gate repositori, jalankan:

npm run proof:gate:reference

Perintah ini menjalankan contoh lokal dan batas layanan terfokus dengan kunci yang dibuat, status dalam memori, dan perilaku penyedia tiruan. Ini merupakan bukti lokal yang berguna, bukan bukti adanya manusia sungguhan, bank eksternal, deployment produksi, atau satu integrasi produksi menyeluruh.

Identitas bukan uraian pekerjaan

Identitas menyatakan siapa atau apa yang melakukan panggilan. Kebijakan menyatakan apa yang secara umum diizinkan. Keduanya tidak mendefinisikan pekerjaan terbatas yang boleh dilakukan pekerja otonom saat ini: misinya, batas tindakan material, anggaran, bukti yang diwajibkan, masa berlaku, aturan delegasi, dan jalur pengecualian.

EMILIA memisahkan pertanyaan-pertanyaan tersebut:

Lapisan	Pertanyaan
Identitas	Siapa atau apa yang hadir?
Kebijakan	Apa yang secara umum diizinkan?
Kewenangan	Pekerjaan tepat apa yang boleh dilakukan agen ini berdasarkan mandat ini?

Kredensial memberikan jangkauan. Kewenangan menentukan pekerjaan. Tidak setiap tindakan memerlukan manusia; setiap tindakan yang berdampak memerlukan kewenangan yang valid.

Pada fondasinya, EP Core tetap menyediakan tiga objek yang dapat dioperasikan bersama: Trust Receipt membawa bukti yang dapat diatribusikan, Trust Profile merepresentasikan status kepercayaan terstruktur, dan Trust Decision mencatat hasil yang dievaluasi berdasarkan kebijakan pihak pengandalan. Lapisan bidang kendali kewenangan menambahkan pengikatan tindakan yang tepat, mandat terbatas, penerimaan, konsumsi, dan bukti hasil tanpa melebur objek-objek tersebut menjadi satu klaim.

---

Tetapkan mandat sekali. Biarkan agen bekerja.

Pelanggan menentukan misi, batas, persyaratan bukti, masa berlaku, dan aturan pengecualian. Kode lokal dapat mempersempit kewenangan tersebut; kode itu tidak dapat menciptakan atau memperluasnya. Gate mengikat setiap permintaan yang dapat dieksekusi pada mandat, mencadangkan kewenangan yang tercakup sebelum masuk ke penyedia, mengizinkan satu upaya penyedia yang diterima untuk instans otorisasi tersebut di dalam domain kewenangan bersama yang persisten, dan hanya melakukan eskalasi ketika kewenangan tidak ada, kedaluwarsa, habis, atau terlalu sempit.

Contoh MCP yang disertakan menjalankan profil kebijakan yang mewajibkan persetujuan pada batas. Contoh-contoh tersebut membuat kunci penandatanganan demonstrasi dan memanggil alat tiruan. Contoh pembayaran mengikat keempat bidang material yang dinyatakan; contoh lainnya menunjukkan pengikatan sumber daya yang lebih sempit. Contoh-contoh tersebut tidak merekam keputusan manusia yang nyata atau menghubungi penyedia:

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

Demo komposisi yang lebih mendalam menjalankan pembayaran terdelegasi yang terikat CAID melalui jalur kapabilitas terbatas Gate yang sebenarnya, lalu memverifikasi sertifikat eksekusi bertanda tangan secara offline:

npm run demo:receipt-program

Demo ini sengaja tidak menyertakan blockchain atau klaim zero-knowledge simulasi. Lihat arsitektur program tanda terima untuk persyaratan status dan kepercayaan produksi.

Mulailah dengan satu tindakan MCP berdampak yang dinyatakan. Pasang runtime lokal yang tepat, lalu buat Gate Starter untuknya dan jalankan pemeriksaan empat kasus yang dibatasi:

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

Pemeriksaan lokal yang dihasilkan menggunakan status demo yang secara eksplisit bersifat sementara dan hanya membuktikan kasus sintetis yang dinyatakan: tidak ada, cocok persis, mutasi, pemutaran ulang, dan alat yang tidak dipindai. Perintah yang ditinjau membuat serah terima dengan batas privasi; perintah itu tidak mengaktifkan Gate. Produksi memerlukan ledger asal-usul yang persisten, penyimpanan konsumsi atomik bersama, kunci yang dipatok, dan wrapper pada setiap jalur menuju kredensial penyedia yang sebenarnya. Lihat examples/mcp/ dan /mcp.

Hentikan tindakan baru tanpa berpura-pura membatalkan tindakan lama

Pembekuan kewenangan darurat Gate memblokir reservasi baru dan mencegah reservasi lama masuk setelah epoch domain kendali yang tercakup berubah. Jika akses ke penyedia terjadi lebih dahulu, upaya tersebut tetap dianggap telah dikonsumsi dan memerlukan rekonsiliasi. Memulihkan kewenangan tidak menghidupkan kembali reservasi lama.

Hal ini memerlukan mediasi lengkap dan status bersama yang otoritatif. Ini tidak menghentikan komputasi, membalikkan dampak, atau langsung menjangkau domain yang terputus. Lihat implementasi dan batas domain kendali.

Coba dalam 30 detik

# 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

Coba passkey platform untuk pembayaran contoh → Tandatangani pembayaran ilustratif sebesar $82,000, ubah jumlahnya, lalu lihat pemeriksaan integritas gagal. Autentikator Anda mungkin menggunakan biometrik atau PIN perangkat. Halaman ini juga menyediakan simulasi perangkat lunak terpisah. Kedua mode tidak mengirim pembayaran atau menetapkan otorisasi produksi.

Verifikasi tanda terima apa pun di browser Anda — tempelkan di sini; tidak ada yang diunggah.

---

Cara kerjanya — satu siklus hidup kewenangan

Jalankan sendiri: node examples/crash-test.mjs — sepenuhnya offline, tanpa kunci 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

Mandat. Sumber kewenangan menentukan pekerjaan terbatas. Sumbernya dapat berupa program operasional yang ditandatangani pelanggan, kapabilitas terbatas, keputusan manusia yang diwajibkan, kuorum, atau komposisi bukti native oleh pihak pengandalan.

Pekerjaan yang tepat. Gate mengikat metode, origin, callee, target, kejadian, dan setiap bidang material ke dalam objek eksekusi kanonis. Niat, prompt, atau teks tiket bukanlah objek tersebut.

Verifikasi, reservasi, dan akses. Artefak native tetap native. Pihak pengandalan mematok profil kepercayaan dan pemetaan, mengevaluasi seluruh persyaratan bukti, membuat keputusan otorisasi lokal yang terpisah, dan mencadangkan kewenangan yang tercakup sebelum adapter pemegang kredensial mengakses penyedia.

Kewenangan manusia yang masih berlaku saat diwajibkan. Kebijakan dapat mewajibkan keputusan WebAuthn/passkey yang terikat pada tindakan tepat dan hash tampilan deterministik. Ini mempersempit kesenjangan “apa yang Anda lihat adalah apa yang Anda tandatangani”; tetapi tidak membuktikan pemahaman, kebijaksanaan, legalitas, atau hasil. Untuk deployment enterprise, Gate juga dapat mewajibkan konfirmasi Authorization Server yang diverifikasi secara independen dan terikat pada bukti manusia yang persis sama, tindakan persis yang sama, snapshot identitas yang benar-benar diamati AS, serta kunci Resource Server yang dituju. Waktu snapshot dan usia maksimum pihak pengandal dinyatakan secara eksplisit: token yang baru tidak dapat membuat data direktori yang usang menjadi terkini. Leg AS merupakan bukti berdasarkan kepercayaan yang dipatok pelanggan; leg ini tidak pernah memberikan otorisasi dengan sendirinya, membuktikan status kepegawaian saat itu juga, atau menjadikan orkestrator agen sebagai otoritas.

Hasil yang jujur. Penerimaan bukanlah eksekusi, dan eksekusi bukanlah dampak. Catatan bertanda tangan dapat diverifikasi secara offline; bukti penyedia dan pengamat tetap terpisah. Respons yang hilang menjadi INDETERMINATE, yaitu keadaan yang harus direkonsiliasi—bukan izin untuk mencoba lagi. Upaya pemulihan adalah tindakan baru yang diotorisasi dan tidak pernah menulis ulang hasil lama.

---

Alasan developer menggunakannya

Mulailah dengan memetakan pekerjaan secara lokal, lalu lindungi satu permukaan tindakan yang dideklarasikan menggunakan server MCP atau wrapper SDK tipis. Pemindai mengusulkan peta yang dapat ditinjau; pemilik menetapkan mandat; Gate mengelola kredensial penyedia dan menegakkan tindakan persis pada jalur yang tercakup. Tidak ada pemindaian yang membuktikan mediasi menyeluruh, dan penemuan saja tidak memberikan otoritas.

# 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

Agen menerima kemampuan untuk melakukan pekerjaan yang dibatasi, bukan kredensial permanen yang dapat ditafsirkan ulang.

---

Alasan perusahaan membutuhkannya

Proses agen dimulai ulang dan model berubah. Mandat pelanggan, status konsumsi, pencabutan, ketidakpastian, dan riwayat pekerjaan harus tetap ada di luar proses tersebut. EMILIA menyimpan status otoritas yang persisten itu di batas pelanggan sambil menerima bukti asing melalui adaptor yang dipatok.

Gate terkelola dan Assurance Plane menambahkan operasi mandat, integrasi, operasi bukti, pelaksanaan ulang, dukungan, dan tingkat layanan di sekitar protokol terbuka. Pelanggan tetap memegang kendali atas otoritas, akar kepercayaan, kredensial, kebijakan, dan bukti portabel.

---

Standar

EMILIA Protocol bersifat terbuka dan berlisensi Apache-2.0. Pekerjaan standarnya diterbitkan sebagai kumpulan Internet-Draft individual. Internet-Draft yang diterbitkan bukan RFC, bukan butir kerja kelompok kerja yang diadopsi, dan bukan dukungan IETF; Datatracker merupakan sumber otoritatif untuk revisi dan status.

Registrasi IANA

Dua nama terdaftar memberikan acuan bersama bagi implementer untuk format EMILIA:

• application/vnd.emilia.authorization-evidence-challenge+json didaftarkan pada 6 Oktober 2026. Nama ini mengidentifikasi objek JSON AE-CHALLENGE-v1 tanpa pembungkus yang didefinisikan dalam spesifikasi serialisasi yang diterbitkan. Respons penolakan HTTP tetap menggunakan application/problem+json.
• canactid: didaftarkan sementara pada 5 Oktober 2026. Nama ini menunjukkan tindakan bertipe yang persis berdasarkan CAID-05. Nomor skema CRI yang telah dikoreksi adalah 1033.

Registrasi ini menerbitkan nama dan spesifikasinya. Registrasi tersebut tidak menetapkan adopsi IETF, dukungan, sertifikasi, atau deployment pelanggan.

Satu permukaan batas konsekuensi

AEB-07 yang saat ini diterbitkan, diposting pada 2026-09-25 sebagai Internet-Draft individual dan belum diadopsi, menjadikan AEB titik komposisi setelah keputusan native. OAuth, AuthZEN, COAZ, AP2, dan sistem lokal tetap memiliki kendali atas kredensial, pemetaan operasi, dan keputusan otorisasinya masing-masing. AIMS (draft-ietf-wimse-aims) adalah dokumen Kelompok Kerja WIMSE yang bersifat Informasional dan memprofilkan standar yang sudah ada seperti WIMSE dan OAuth; dokumen ini tidak menerbitkan kredensial atau keputusan. AEB menerapkan keputusan native pada batas penyedia yang dilindungi: AEB mengikat tindakan akhir bila diperlukan, menurunkan satu identitas replay native per grant, melakukan reservasi sebelum memasuki penyedia, menolak percobaan kedua untuk tindakan yang sama saat percobaan sebelumnya masih berlangsung atau hasilnya belum pasti, serta menjaga hasil yang belum pasti tetap terkunci hingga rekonsiliasi terautentikasi.

CAID-05 digunakan ketika representasi yang dikodekan secara independen harus dibandingkan. Pengenal baru menggunakan skema URI canactid: yang terdaftar sementara di IANA. Registrasi ini bukan adopsi IETF, dukungan, sertifikasi, atau status permanen. CAID bukan pemetaan kedua yang wajib dilakukan jika PEP pemilik konsekuensi sudah menurunkan dan menegakkan keputusan terkini atas operasi akhir. Coba playground tindakan persis atau baca panduan migrasi CAID-04 ke CAID-05. AEC-06 digunakan ketika pihak pengandal mewajibkan beberapa leg bukti. Authorization Receipts, Human Authorization Binding, dan Authority Introduction tetap tersedia sebagai profil untuk deployment yang membutuhkannya; semuanya bukan prasyarat bagi setiap integrasi AEB. Architecture-03 tetap menjadi dokumen navigasi.

Panduan penerimaan konsekuensi menjelaskan batas implementasi dan kasus ketika AEB tidak diperlukan. Profil serah terima native langsung adalah profil implementasi repositori yang menunjukkan bagaimana izin yang sudah ada diteruskan ke Gate tanpa lapisan CAID atau AEC kedua. AEB-07 menetapkan apa yang dibuktikan oleh serah terima gateway tersebut dan bagaimana batas memverifikasinya, tetapi menyerahkan pengodeannya kepada pin deployment; dokumen ini mengutip snapshot profil yang dipatok sebagai salah satu pengodean referensi informatif. Byte -07 yang diajukan secara persis dan catatan publikasinya disimpan di standards/staged/NEXT-AEB-07.

Portofolio aktif lengkap terdiri atas 26 catatan Datatracker: 21 catatan yang ditulis sendiri dan lima catatan yang ditulis bersama, masing-masing dengan cakupan, riwayat revisi, dan status pemeliharaan tercatatnya sendiri. Lihat panduan standar, portofolio, dan inventaris status yang dapat dibaca mesin.

Internet-Draft IETF	Jalur snapshot lokal saat ini: inventaris status · inventaris yang diposting untuk catatan yang ditulis sendiri · status langsung otoritatif: IETF Datatracker
Verifier lintas bahasa	JavaScript · Python · Go — ketiganya terbukti sepakat pada vektor konformansi adversarial, setiap push (npm run conformance). Ini adalah pemeriksaan konsistensi di antara port milik satu tim, bukan implementasi independen yang dibuat dari nol. Secara terpisah, implementasi Rust yang ditulis pihak eksternal berdasarkan spesifikasi (sumber tersedia untuk publik) lulus bundel 16 suite/164 vektor yang dipatok dan kampanye adversarial 359 kasus yang dipatok melalui pembangunan ulang yang dikendalikan evaluator dari pohon sumber yang tidak dapat diubah. Bukti konstruksi yang disertakan dalam repositori tetap ditandatangani implementer, bukan disahkan pihak ketiga (pernyataan bertanda tangan); penerimaan ketat yang dibuat dari nol menunggu manifes yang telah dikoreksi dan disahkan pihak ketiga serta kunci pengesah yang dipatok secara independen.
Bukti model formal	26 properti keselamatan TLA+ terbatas terpenuhi dalam ruang status yang dikonfigurasi; ini bukan penyempurnaan implementasi atau bukti tak terbatas · 35 fakta Alloy, 32 asersi di empat model · dua model simbolik Dolev-Yao gabungan yang mencakup challenge, CAID, dua persetujuan, pin penerbit dan otoritas, tampilan registri, pencabutan, konsumsi, eksekusi, dan enam batas klaim khusus. Dua puluh lemma Tamarin terverifikasi — 17 kewajiban untuk semua jejak dan 3 saksi jejak yang ada; delapan varian yang sengaja dilemahkan menghasilkan jejak serangan konkret ketika pemeriksaan penentu dihapus (formal/tamarin/).
Distribusi MCP	Paket npm @emilia-protocol/mcp-server · publikasi Registry resmi dilacak secara terpisah di MCP-REGISTRY.md; keberadaan dalam daftar agregator tidak disimpulkan dari salah satu status tersebut
Lisensi	Apache-2.0

Tiga port referensi dari tim yang sama (JS / Python / Go) sepakat pada seluruh 21 suite dan 340 vektor. Secara terpisah, implementasi Rust yang ditulis pihak eksternal dan dibangun ulang dari pohon sumber publik yang dipatok lulus bundel clean-room 16 suite/164 vektor yang dipatok serta kampanye adversarial 359 kasus, yang dijalankan ulang di jalur CI tersendiri pada setiap perubahan. Suite penerimaan AEC yang lebih baru dan suite resolusi empat hasil tidak diklaim untuk Rust. Ini merupakan bukti interoperabilitas eksternal, bukan penerimaan konstruksi clean-room yang ketat; catatan kasus CI agregat mencatat jumlah penerimaan ketat sebagai nol sambil menunggu pengesahan independen. Lihat CONFORMANCE.md, atau verifikasi sendiri sebuah tanda terima di emiliaprotocol.ai/verify.

---

Tumpukan otoritas

Lapisan	Fungsinya
Mandat	Menetapkan misi, batasan, bukti, kedaluwarsa, delegasi, dan aturan pengecualian.
CAID / tindakan persis	Membandingkan makna material ketika otorisasi dan eksekusi menggunakan representasi yang dikodekan secara independen; tidak memberikan otorisasi.
AEC	Jika diwajibkan, mengevaluasi apakah bukti yang diverifikasi dan dicocokkan secara independen memenuhi persyaratan multi-leg pihak pengandal; tidak memberikan otorisasi.
AEB / Gate	Menerapkan keputusan otorisasi native atau lokal pada batas konsekuensi, mencadangkan otoritas yang tercakup, dan mengendalikan akses ke penyedia.
Bukti hasil	Memisahkan pemanggilan, respons penyedia, dampak yang diamati, dan ketidakpastian.

---

Poin pembuktian

Metrik	Nilai
Kasus pengujian otomatis	10.700+ di lebih dari 650 file; semua kasus yang berlaku untuk platform harus lulus
Properti keselamatan TLA+	26 invarian terbatas terpenuhi dalam ruang status yang dikonfigurasi; bukan bukti penyempurnaan implementasi atau bukti tak terbatas — lihat PROOF_STATUS.md
Asersi relasional Alloy	35 fakta + 32 asersi di empat model — diverifikasi di CI
Kasus red-team yang dikatalogkan	86 — RED_TEAM_CASES.md
Status keamanan rilis	Pemeriksaan keamanan repositori lulus; setiap temuan Strix pada perubahan yang diaudit telah diperbaiki dengan cakupan regresi dan utas tinjauannya telah diselesaikan
Konformansi (7/7)	node conformance/ep-conformance-test.js https://www.emiliaprotocol.ai
Konformansi lintas bahasa	340 vektor · 21 suite: tanda terima · persetujuan perangkat · resolusi empat hasil · kuorum multipihak · pencabutan · Outcome Binding (semantik + kripto nyata) · gabungan penerbit Authority Document/Proof · pengesahan waktu · trust-receipt (2 profil) · provenance · evidence-record · kanonisasi · batas · penerimaan AEC · mata uang · pengesahan pemrakarsa · bukti konsumsi · saksi · bukti stempel waktu (RFC 3161). Verifier JS / Python / Go sepakat (node conformance/run.mjs). Baseline Rust eksternal tetap 164 vektor / 16 suite. Lihat CONFORMANCE.md.
p95 pembuatan handshake	575ms pada 50 VU — PERFORMANCE_PROOF.md

Keberlanjutan kriptografis (dengan batas deployment yang dinyatakan secara eksplisit)

Bukti yang dimaksudkan untuk diverifikasi bertahun-tahun kemudian harus tetap dapat diverifikasi setelah algoritme yang digunakan untuk menandatanganinya tidak lagi berlaku. EP menyediakan empat kemampuan terbatas untuk itu, masing-masing dengan batas persis yang menjadi bagian dari klaim:

• Tanda tangan hibrida (EP-RECEIPT-HYBRID-v1). Ed25519 dan ML-DSA-65 atas byte kanonis yang sama, dengan set algoritma yang diwajibkan dikomitmenkan ke dalam byte yang ditandatangani sehingga penghapusan satu komponen membuat tanda tangan yang tersisa tidak valid. Kapabilitas ini bersifat opt-in saat deployment; setelah penanda tangan ganda yang disetujui didaftarkan dan kebijakan mengizinkan komponen PQ-nya, postur Gate yang tidak dipatok akan secara default memilih penerbitan ganda. Jika tidak, sistem tetap hanya menggunakan algoritma klasik dengan alasan yang disebutkan. Verifikator v1 menolak receipt hibrida dengan benar, alih-alih menerima salah satu komponennya. Kontrak penanda tangan eksternal dan adaptor AWS KMS telah diimplementasikan, tetapi tidak ada klaim bahwa pemanggilan penandatanganan AWS langsung, kunci produksi, verifikasi pihak pengandalan, atau validasi FIPS ML-DSA telah dilakukan. Lihat conformance/hybrid-receipts/ dan lib/pq-custody-aws-kms.ts.
• Profil Signed Statement SCITT (EP-SCITT-STATEMENT-v1). Bentuk Signed Statement RFC 9943 yang lengkap untuk receipt EP, termasuk header terlindungi CWT Claims. Batasan: belum ada Transparency Service yang menerima pernyataan EP; pendaftaran eksternal merupakan langkah terpisah yang memerlukan persetujuan, dan belum ada yang dilakukan. Lihat EP-RECEIPT-SCITT-PROFILE.md.
• Atestasi ulang (EP-EVIDENCE-REATTESTATION-v1). Bukti yang ditandatangani dengan algoritma yang mulai usang dapat ditambatkan ulang menggunakan algoritma terkini sebelum algoritma lama melemah. Batasan: atestasi ulang harus dilakukan sebelum kompromi; tindakan ini tidak dapat memperbaiki bukti setelah kejadian.
• Mode deployment FIPS (EP-FIPS-MODE-v1). Menjalankan operasi klasik melalui penyedia tervalidasi FIPS 140-3 yang disediakan operator, dengan jalur ML-DSA dibatasi hingga ada pengakuan eksplisit bahwa implementasinya belum tervalidasi. Batasan: ini mendukung klaim "algoritma berbasis FIPS, dengan mode deployment penyedia tervalidasi" dan bergantung pada penyedia operator serta batas sertifikat yang dinyatakan; ini bukan klaim kepatuhan menyeluruh, dan tidak ada yang di sini tervalidasi FIPS. Lihat FIPS-MODE.md.

Program hibrida di seluruh stack (setiap permukaan tanda tangan internal) dipetakan di pq-hybrid-program.md dan belum selesai; sampai selesai, tidak ada klaim menyeluruh tentang seluruh stack.

---

Objek protokol inti

Objek	Penjelasan
Program otoritas / kapabilitas terbatas	Mandat terbatas dengan cakupan, anggaran atau unit, masa berlaku, delegasi, dan aturan penggunaan yang dinyatakan secara eksplisit.
CAID	Pengenal kanonis untuk satu tindakan material berdasarkan profil pemetaan bernama; kecocokan bukanlah otorisasi.
Persyaratan bukti dan hasil AEC	Aturan pihak pengandalan yang dipatok serta evaluasi SATISFIED, UNSATISFIED, atau INDETERMINATE.
Catatan penerimaan dan kustodi AEB	Catatan di sisi eksekutor mengenai otorisasi, reservasi, masuknya penyedia, dan status rekonsiliasi.
Bukti otorisasi dan hasil	Artefak native atau EP portabel yang mempertahankan batas penerbit, cakupan, dan klaimnya secara persis.

---

Mulai cepat

1. Instal runtime guard lokal yang persis, lalu jalankan npx @emilia-protocol/scan@0.6.0 protect ./tools.json --action sendWire --apply --verify, dengan mengganti sendWire menggunakan satu tool konsekuensial yang dideklarasikan secara persis.
2. Tinjau Authority Map yang dihasilkan, manifes tindakan, kolom material, batas yang dipilih, dan titik buta yang disebutkan.
3. Jalankan perintah --reviewed --crossing-profile <launch-profile> yang terpisah untuk membuat serah terima khusus pemilik dan ruang kerja Lab yang belum disegel dari byte yang tidak diubah tersebut.
4. Instal Gate pada jalur yang memiliki kredensial penyedia dan status penggunaan persisten.
5. Tetapkan mandat operasional serta aturan pengecualian untuk manusia baru atau kuorum.
6. Jalankan kasus penolakan, tindakan persis, replay, timeout, dan rekonsiliasi sebelum mengaktifkan penegakan.

Demo 90 detik · Mulai cepat · Panduan agen · Draf IETF · Discord

---

Apa itu EP — dan bukan

EMILIA adalah infrastruktur otoritas untuk pekerjaan otonom, bukan sistem identitas, dompet, skor reputasi, jalur penyelesaian, atau mesin kebijakan universal.

• Adalah: bidang kendali untuk mandat operasional terbatas, verifikasi tindakan persis, status penerimaan persisten, ketidakpastian yang dinyatakan secara jujur, dan bukti portabel pada jalur eksekutor yang tercakup.
• Bukan: pengganti OAuth/OIDC, identitas beban kerja, atau mesin kebijakan. Semua itu tetap menjadi masukan native berdasarkan pin pihak pengandalan.
• Bukan: persyaratan agar manusia menyetujui setiap tindakan. Mandat dapat mengizinkan pekerjaan otomatis dalam batas yang ditetapkan dan meminta otoritas baru hanya saat mencapai batas tersebut.
• Bukan: bukti bahwa tindakan yang diterima berhasil dijalankan atau menimbulkan dampak yang dimaksud.
• Bukan: kendali protokol proprieter. Inti proyek berlisensi Apache-2.0 dan Internet-Drafts merupakan pengajuan individual, bukan RFC atau dukungan IETF.

Lihat CONFORMANCE.md · SECURITY.md · THREAT_MODEL.md · GOVERNANCE.md · Kovenan Netralitas