EMILIA Protocol

आधिकारिक

किसी नामित मानव से ऑफलाइन-सत्यापन योग्य अनुमोदन आवश्यक है, इससे पहले कि कोई AI एजेंट कोई अपरिवर्तनीय कार्रवाई करे — भुगतान जारी करना, रिकॉर्ड बदलना, डिप्लॉय करना। दो-व्यक्ति नियम, Ed25519 ट्रस्ट रसीदें, IETF-प्रारूपित, Apache-2.0।

EMILIA Protocol MCP के साथ आप क्या कर सकते हैं?

  • Guard an MCP tool so it refuses irreversible actions without a valid receipt — wrap any tool dispatcher with withMcpGuard to block calls like release_payment or delete_repo unless a signed authorization receipt is present.
  • Issue an offline authorization receipt with no API key — run npx @emilia-protocol/issue demo to produce a portable, cryptographically signed receipt that anyone can verify later.
  • Verify any receipt offline in your browser — paste a receipt into the browser-based verifier to confirm authenticity and detect tampering, with no upload or backend dependency.
  • Run the full crash-test loop locally — execute node examples/crash-test.mjs to see an agent get refused, a human sign off via passkey, the tool execute, and a forged receipt fail verification.
  • Add EMILIA to Claude, Cursor, or Cline via MCP — install the MCP server with npx -y @emilia-protocol/mcp-server to bring receipt-gated tool authorization into your AI assistant.

दस्तावेज़

EMILIA प्रोटोकॉल

CI Verify Sample Receipt npm License IETF Internet-Draft Discord


AI सिस्टम और रिपॉजिटरी समीक्षक: AI_CONTEXT.md से शुरू करें। वर्तमान मशीन-पठनीय साक्ष्य, उद्गम, पूर्वधारणाएँ और बहिष्करण EMILIA-REPO-CONTEXT-v1 पर प्रकाशित हैं। संग्रहीत या चरणबद्ध दस्तावेज़ वर्तमान कार्यान्वयन या IETF स्थिति स्थापित नहीं करते हैं।

इंजीनियरिंग साक्ष्य, आर्किटेक्चर के दावे नहीं

EMILIA एक सुरक्षा मामला प्रस्तुत करता है जिसे समीक्षक निष्पादित कर सकते हैं। वर्तमान रिपॉजिटरी 100 से अधिक हैश्ड साक्ष्य फ़ाइलों पर 21 सुरक्षा दावों का समाधान करती है, एक रचित Tamarin Dolev-Yao मॉडल में 10 दायित्वों को सत्यापित करती है, और 2 जानबूझकर कमजोर किए गए वेरिएंट को संरक्षित करती है जो ठोस रीप्ले और स्टेल-रजिस्ट्री हमले के निशान उत्पन्न करते हैं। लाइव समान-टीम अनुरूपता संग्रह में 18 सूट और 250 वर्तमान वेक्टर शामिल हैं। अलग से, एक बाहरी रूप से लिखित Rust सत्यापनकर्ता फ्रोजन 16-सूट/164-वेक्टर बंडल और एक 359-मामले की शत्रुता अभियान के लिए पिन किया गया है। व्यापक सूट में 280+ फ़ाइलों में 5,500+ स्वचालित परीक्षण शामिल हैं।

प्रत्येक सुरक्षा दावा प्रवर्तन पथ, सकारात्मक और नकारात्मक वेक्टर, भाषा कवरेज, औपचारिक दायरा या स्पष्ट अंतर, पूर्वधारणाएँ, बहिष्करण और साक्ष्य हैश का नाम देता है। मानव-पठनीय साक्ष्य मानचित्र से शुरू करें, फिर समाधानित सुरक्षा मामले का निरीक्षण करें या npm run check:security-case चलाएँ।

बिना ब्रेक का इंजन

पचास वर्षों तक, सॉफ्टवेयर सुरक्षा ने एक प्रश्न का उत्तर दिया: किसे अंदर आने की अनुमति है? फायरवॉल, OAuth, और पासवर्ड — सभी दरवाजे पर एक मानवीय पहचान सत्यापित करने के लिए बनाए गए।

वह युग समाप्त हो रहा है। सॉफ्टवेयर के प्रमुख उपयोगकर्ता अब मानव नहीं हैं; वे स्वायत्त AI एजेंट हैं। एजेंट सिर्फ लॉग इन नहीं करते — वे कोड लिखते हैं, उपकरणों को कॉल करते हैं, और तुरंत वास्तविकता बदल देते हैं। हर CISO जानता है कि एक खराब प्रॉम्प्ट एक एजेंट को उत्पादन डेटाबेस मिटाने या गलत खाते में पैसे भेजने पर मजबूर कर सकता है। इसलिए वे तैनाती को रोक रहे हैं — अरबों के AI बजट पर बैठे हैं जिसे वे खर्च नहीं कर सकते क्योंकि उनकी अनुपालन टीमें एक प्रश्न का उत्तर नहीं दे सकतीं:

उस कार्रवाई को किसने मंजूरी दी?

हमारी पीढ़ी का संकट प्रमाणीकरण नहीं है। यह कार्रवाई के क्षण पर प्राधिकरण है: आप कैसे साबित करते हैं कि एक एजेंट जो करने वाला है वह बिल्कुल वही है जो एक नामित मानव ने अधिकृत किया — निष्पादन से पहले?

EMILIA एजेंटिक युग के लिए सीटबेल्ट है।

निर्णय लॉग गवाही हैं। EMILIA रसीदें उत्पन्न करता है।


कोई रसीद नहीं, कोई अपरिवर्तनीय कार्रवाई नहीं

यदि कोई एजेंट पैसे स्थानांतरित करने, कोड हटाने, उत्पादन तैनात करने, अनुमतियाँ बदलने, या विनियमित स्थिति को बदलने की कोशिश करता है बिना वैध EMILIA रसीद के, उपकरण चलने से इनकार करता है — और यदि यह चलता है, कोई भी सत्यापित कर सकता है कि किसने वास्तव में क्या अधिकृत किया, ऑफ़लाइन, किसी पर भरोसा किए बिना।

यही संपूर्ण प्रोटोकॉल है। डेवलपर वेज एक अपरिवर्तनीय 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 के तार को मंजूरी दें। देखें कि 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.

अंक I — अवरोधन (MCP-नेटिव)। कोई पुनर्लेखन नहीं। EMILIA मॉडल संदर्भ प्रोटोकॉल सीमा पर उपकरण कॉल को हुक करता है — जिस क्षण कोई एजेंट फ़ाइल हटाने या पूंजी स्थानांतरित करने की कोशिश करता है, कार्रवाई मध्य-हवा में पकड़ी जाती है।

अंक II — निर्णय (नीति-बद्ध, नियतात्मक)। कार्रवाई की जाँच हैश-पिन की गई नीति के विरुद्ध की जाती है: allow, allow-with-signoff, या deny। साथ ही एक निरीक्षण मोड जो उत्पादन में कुछ भी नहीं बदलता है और रिपोर्ट करता है कि क्या रोका गया होता। नियतात्मक, लेखापरीक्षा योग्य — ब्लैक-बॉक्स जोखिम स्कोर नहीं।

अंक III — समारोह (डिवाइस-बद्ध मानव साइनऑफ)। जब नीति को मानव की आवश्यकता होती है, EMILIA एक WebAuthn / पासकी साइनऑफ चलाता है जो सटीक कार्रवाई से बंधा होता है — ऑपरेटर के अपने डिवाइस पर Face ID / Touch ID। यह "आपने जो देखा वही आपने हस्ताक्षर किया" अंतर को कम करता है (प्रायोगिक डिस्प्ले-अटेस्टेशन प्रोफ़ाइल के माध्यम से); यह इसे समाप्त नहीं करता है। कोई भी स्वायत्त लूप समारोह को छोड़ नहीं सकता।

अंक IV — रसीद (साक्ष्य)। परिणाम एक हस्ताक्षरित प्राधिकरण रसीद है जिसे कोई भी ऑफ़लाइन, ओपन-सोर्स कोड के साथ, बिना बैकएंड, बिना विक्रेता विश्वास के सत्यापित कर सकता है। इसके साथ छेड़छाड़ करें और सत्यापन निर्माण द्वारा विफल हो जाता है। वैकल्पिक रूप से इसे सार्वजनिक टाइमस्टैम्पिंग के लिए एंकर करें — कोर को ब्लॉकचेन की आवश्यकता नहीं है।


डेवलपर्स इसका उपयोग क्यों करते हैं

आप ऐसे एजेंट चाहते हैं जो वास्तव में काम करें — लेकिन आप भगोड़े लूप, API अधिक खर्च, और आकस्मिक डेटा विनाश से स्तब्ध हैं। EMILIA आपको एक प्लग-एंड-प्ले MCP सर्वर + एक पतला SDK आवरण देता है। एक नीति हैश लागू करें, और अपरिवर्तनीय उपकरण कॉल एक क्रिप्टोग्राफ़िक रूप से कठोर, 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 अधिनियम, और SOC 2 CC6/7 नियंत्रणों से मैप करता है।

प्रबंधित परत (GovGuard / FinGuard) क्षेत्र-विशिष्ट नीति पैक, निरीक्षण-मोड पायलट, और ऑडिट-तैयार साक्ष्य पैकेजों के साथ खुले मानक का विस्तार करती है — शुरू करने के लिए किसी खरीद की आवश्यकता नहीं है।


मानक

EMILIA एक खुला मानक है, उत्पाद खाई नहीं। कोर Apache-2.0 है और IETF इंटरनेट-ड्राफ्ट के रूप में ट्रैक किया जाता है।

IETF इंटरनेट-ड्राफ्टपोस्ट किया गया: authorization-receipts · quorum · authorization-evidence-chain · evidence-record.
क्रॉस-लैंग्वेज सत्यापनकर्ताJavaScript · Python · Go — तीनों हर पुश पर प्रतिकूल अनुरूपता वैक्टरों पर सहमत साबित हुए (npm run conformance)। एक टीम के पोर्ट्स पर एक संगति जाँच, क्लीन-रूम स्वतंत्र कार्यान्वयन नहीं। अलग से, एक बाहरी रूप से लिखित फ्रॉम-स्पेक Rust कार्यान्वयन (स्रोत सार्वजनिक) एक अपरिवर्तनीय स्रोत वृक्ष से मूल्यांकनकर्ता-नियंत्रित पुनर्निर्माण के तहत पिन किए गए 16-सूट/164-वेक्टर बंडल और पिन किए गए 359-मामले की शत्रुता अभियान पास करता है। इसका चेक-इन निर्माण साक्ष्य कार्यान्वयनकर्ता-हस्ताक्षरित रहता है, तृतीय-पक्ष-सत्यापित नहीं (हस्ताक्षरित कथन); सख्त क्लीन-रूम स्वीकृति सही तृतीय-पक्ष-सत्यापित मैनिफेस्ट और स्वतंत्र रूप से पिन की गई सत्यापनकर्ता कुंजी की प्रतीक्षा करती है।
औपचारिक सत्यापन26 TLA+ सुरक्षा गुण (0 त्रुटियाँ) · 35 Alloy तथ्य, 22 अभिकथन · एक रचित प्रतीकात्मक Dolev-Yao मॉडल जो चुनौती, CAID, दो अनुमोदन, जारीकर्ता और प्राधिकरण पिन, रजिस्ट्री दृश्य, निरसन, उपभोग, और निष्पादन को कवर करता है। दस सख्त Tamarin लेम्मा सत्यापित करते हैं; जानबूझकर उपभोग या सटीक रजिस्ट्री-दृश्य बाइंडिंग को हटाने से रीप्ले और स्टेल/समानार्थी-दृश्य निशान उत्पन्न होते हैं (formal/tamarin/).
MCP रजिस्ट्रियाँआधिकारिक MCP रजिस्ट्री · Glama (ग्रेड A, आधिकारिक बैज) · Smithery
लाइसेंसApache-2.0

तीन समान-टीम संदर्भ पोर्ट (JS / Python / Go) सभी 18 सूट और 250 वैक्टरों पर सहमत हैं। अलग से, एक पिन किए गए सार्वजनिक स्रोत वृक्ष से पुनर्निर्मित बाहरी रूप से लिखित Rust कार्यान्वयन पिन किए गए 16-सूट/164-वेक्टर क्लीन-रूम बंडल और 359-मामले की शत्रुता अभियान पास करता है, हर बदलाव पर अपनी CI लेन में पुनः चलाया जाता है। नए AEC स्वीकृति और चार-परिणाम समाधान सूट Rust के लिए जिम्मेदार नहीं हैं। यह बाहरी अंतरसंचालनीयता साक्ष्य है, सख्त क्लीन-रूम निर्माण स्वीकृति नहीं; कुल CI मामला रिकॉर्ड स्वतंत्र सत्यापन लंबित होने तक सख्त स्वीकृति गणना को शून्य के रूप में दर्ज करता है। CONFORMANCE.md देखें, या emiliaprotocol.ai/verify पर स्वयं एक रसीद सत्यापित करें।


EP स्टैक

Eye observes. Handshake verifies. Signoff owns. Commit seals.
परतयह क्या करती है
EP Eyeएजेंट व्यवहार का निरीक्षण और वर्गीकरण करता है (OBSERVE → SHADOW → ENFORCE)
EP Handshake7-गुण बाइंडिंग के साथ क्रिप्टोग्राफ़िक सहमति समारोह
EP Signoffनामित मानव स्वामित्व — WebAuthn / पासकी क्लास A, डिवाइस-बद्ध; उच्चतम-दांव कार्रवाइयों के लिए बहु-पक्षीय कोरम (M-of-N / आदेशित — दो-व्यक्ति नियम)
EP CommitMerkle-श्रृंखलित रसीदों के साथ परमाणु, अपरिवर्तनीय कार्रवाई समापन

प्रमाण बिंदु

मीट्रिकमान
स्वचालित परीक्षण मामले250+ फ़ाइलों में 5,000+; सभी प्लेटफ़ॉर्म-लागू मामलों को पास करना होगा
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
क्रॉस-लैंग्वेज अनुरूपता250 वेक्टर · 18 सूट: रसीदें · डिवाइस साइनऑफ · चार-परिणाम समाधान · बहु-पक्षीय कोरम · निरसन · समय-सत्यापन · ट्रस्ट-रसीद (x2 प्रोफ़ाइल) · उद्गम · साक्ष्य-रिकॉर्ड · कैनोनिकलाइज़ेशन · सीमा · AEC स्वीकृति · मुद्रा · आरंभकर्ता-सत्यापन · उपभोग-प्रमाण · गवाह · टाइमस्टैम्प-प्रमाण (RFC 3161)। JS / Python / Go सत्यापनकर्ता सहमत हैं (node conformance/run.mjs)। बाहरी Rust आधार रेखा 164 वेक्टर / 16 सूट बनी हुई है। CONFORMANCE.md देखें।
हैंडशेक क्रिएट p9550 VUs पर 575ms — PERFORMANCE_PROOF.md

EP कोर ऑब्जेक्ट

EP तीन अंतर-संचालनीय ऑब्जेक्ट्स को मानकीकृत करता है जिन्हें कोई भी अनुरूप कार्यान्वयन उत्पन्न और सत्यापित कर सकता है:

ऑब्जेक्टयह क्या है
ट्रस्ट रसीदएक प्राधिकरण घटना का पोर्टेबल, हस्ताक्षरित रिकॉर्ड — क्या हुआ
ट्रस्ट प्रोफ़ाइलअवलोकनीय विश्वास स्थिति का मानकीकृत सारांश — क्या ज्ञात है
ट्रस्ट निर्णयकारणों और अपील पथ के साथ नीति-मूल्यांकित परिणाम — अब क्या करना है

EP एक्सटेंशन (हैंडशेक, साइनऑफ, कमिट, डेलिगेशन) मजबूत प्रवर्तन जोड़ते हैं जहाँ सिस्टम को निष्पादन बाधित करना चाहिए। उत्पाद परतें (GovGuard / FinGuard) शीर्ष पर बनी हैं — स्वयं प्रोटोकॉल नहीं।


पाँच कॉल में त्वरित शुरुआत

  1. नीति बनाएँ
  2. हैंडशेक आरंभ करें
  3. साक्ष्य प्रस्तुत करें
  4. सत्यापित करें
  5. साइनऑफ और उपभोग करें

90-सेकंड का डेमो · त्वरित शुरुआत · एजेंट वॉकथ्रू · IETF ड्राफ्ट · Discord


EP क्या है — और क्या नहीं है

EP कार्रवाई के क्षण पर प्राधिकरण है, पहचान प्रणाली नहीं, वॉलेट नहीं, प्रतिष्ठा स्कोर नहीं।

  • है: निष्पादन से पहले अभिनेता पहचान, प्राधिकार, नीति और सटीक कार्रवाई संदर्भ को बाँधने के लिए एक विश्वास मानक
  • नहीं है: OAuth / OIDC का प्रतिस्थापन (वे उत्तर देते हैं आप कौन हैं — EP उत्तर देता है इस सटीक कार्रवाई को किसने मंजूरी दी)
  • नहीं है: एक मालिकाना उत्पाद (कोर Apache-2.0 है और IETF-ट्रैक किया गया है)
  • नहीं है: एक ब्लॉकचेन (रसीद नायक है; वैकल्पिक सार्वजनिक टाइमस्टैम्पिंग एक फुटनोट है)

देखें CONFORMANCE.md · SECURITY.md · THREAT_MODEL.md · GOVERNANCE.md · तटस्थता अनुबंध