EMILIA Protocol MCP Server
आधिकारिककिसी नामित मानव से ऑफलाइन-सत्यापन योग्य अनुमोदन आवश्यक है, इससे पहले कि कोई AI एजेंट कोई अपरिवर्तनीय कार्रवाई करे — भुगतान जारी करना, रिकॉर्ड बदलना, डिप्लॉय करना। दो-व्यक्ति नियम, Ed25519 ट्रस्ट रसीदें, IETF-प्रारूपित, Apache-2.0।
दस्तावेज़
EMILIA प्रोटोकॉल
बिना ब्रेक का इंजन
पचास वर्षों तक, सॉफ़्टवेयर सुरक्षा ने एक प्रश्न का उत्तर दिया: किसे अंदर आने की अनुमति है? फ़ायरवॉल, 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 कैसा दिखता है। रसीद जाली बनाएँ। इसे विफल होते देखें।
अपने ब्राउज़र में कोई भी रसीद सत्यापित करें — इसे पेस्ट करें, कुछ भी अपलोड नहीं किया जाता है।
यह कैसे काम करता है — चार अंक

इसे स्वयं चलाएँ:
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। standards/ में मंचित: authorization-evidence-chain (EP-AEC, संरचना) · evidence-record (EP-EVIDENCE-RECORD, दीर्घकालिक अवधारण)। फ़ील्ड मैप: landscape survey। |
| क्रॉस-लैंग्वेज सत्यापनकर्ता | JavaScript · Python · Go — तीनों हर पुश पर प्रतिकूल अनुरूपता वैक्टर पर सहमत सिद्ध (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 / पासकी क्लास A, डिवाइस-बद्ध; उच्चतम-दांव कार्रवाइयों के लिए बहु-पक्षीय कोरम (M-of-N / आदेशित — दो-व्यक्ति नियम) |
| EP Commit | Merkle-श्रृंखलित रसीदों के साथ परमाणु, अपरिवर्तनीय कार्रवाई समापन |
प्रमाण बिंदु
| मीट्रिक | मान |
|---|---|
| स्वचालित परीक्षण | 173 फ़ाइलों में 4,220 |
| 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) |
| हैंडशेक क्रिएट p95 | 50 VUs पर 575ms — PERFORMANCE_PROOF.md |
EP कोर ऑब्जेक्ट
EP तीन अंतर-संचालनीय ऑब्जेक्ट्स का मानकीकरण करता है जिन्हें कोई भी अनुरूप कार्यान्वयन उत्पन्न और सत्यापित कर सकता है:
| ऑब्जेक्ट | यह क्या है |
|---|---|
| ट्रस्ट रसीद | एक प्राधिकरण घटना का पोर्टेबल, हस्ताक्षरित रिकॉर्ड — क्या हुआ |
| ट्रस्ट प्रोफ़ाइल | अवलोकनीय विश्वास स्थिति का मानकीकृत सारांश — क्या ज्ञात है |
| ट्रस्ट निर्णय | कारणों और अपील पथ के साथ नीति-मूल्यांकित परिणाम — अब क्या करना है |
EP एक्सटेंशन (हैंडशेक, साइनऑफ़, कमिट, डेलिगेशन) मजबूत प्रवर्तन जोड़ते हैं जहाँ सिस्टम को निष्पादन बाधित करना चाहिए। उत्पाद परतें (GovGuard / FinGuard) शीर्ष पर बनी हैं — स्वयं प्रोटोकॉल नहीं।
पाँच कॉल में त्वरित शुरुआत
- नीति बनाएँ
- हैंडशेक आरंभ करें
- साक्ष्य प्रस्तुत करें
- सत्यापित करें
- साइनऑफ़ करें और उपभोग करें
90-सेकंड का डेमो · त्वरित शुरुआत · एजेंट वॉकथ्रू · IETF ड्राफ्ट · Discord
EP क्या है — और क्या नहीं है
EP कार्रवाई के क्षण पर प्राधिकरण है, पहचान प्रणाली नहीं, वॉलेट नहीं, प्रतिष्ठा स्कोर नहीं।
- है: निष्पादन से पहले अभिनेता पहचान, प्राधिकार, नीति, और सटीक कार्रवाई संदर्भ को बांधने के लिए एक विश्वास मानक
- नहीं है: OAuth / OIDC का प्रतिस्थापन (वे उत्तर देते हैं आप कौन हैं — EP उत्तर देता है इस सटीक कार्रवाई को किसने अनुमोदित किया)
- नहीं है: एक मालिकाना उत्पाद (मूल Apache-2.0 है और IETF-ट्रैक किया गया है)
- नहीं है: एक ब्लॉकचेन (रसीद नायक है; वैकल्पिक सार्वजनिक टाइमस्टैम्पिंग एक फुटनोट है)
CONFORMANCE.md · SECURITY.md · THREAT_MODEL.md · GOVERNANCE.md देखें