मुख्य सामग्री पर जाएँ
securestamp.org
Execution Authorization · Action Proof

सटीक प्रभाव के प्राधिकरण के लिए
एक भरोसे का प्रोटोकॉल।

SecureStamp डिजिटल भरोसे को स्रोत और मंशा से लेकर निष्पादन तक बढ़ाता है। स्वीकृत निर्णय सीमित निष्पादन अधिकार बन जाते हैं, जिन्हें ग्राहक द्वारा नियंत्रित नीति सीमित करती है और जिनके बाद स्वतंत्र रूप से सत्यापन योग्य प्रमाण रहता है।

विनिर्देश पढ़ेंइंटीग्रेशन देखेंAction Proof पढ़ें

Email

Gmail, Outlook और Apple Mail — इनबॉक्स में स्रोत का प्रमाण

आधिकारिक चैनल

WhatsApp, Telegram और वह परिधि जो कोई ब्रांड घोषित करता है

एजेंट और API

MCP टूल, API और स्वायत्त वर्कफ़्लो

प्रोटोकॉल की संरचना

कार्रवाई से पहले भरोसा। निष्पादन के बाद प्रमाण।

एक ही भरोसे का स्टैक, हर सतह पर लागू।

SecureStamp कोई ईमेल जाँचने वाला टूल नहीं है जिस पर एजेंट फ़ीचर जोड़ दिया गया हो। स्रोत, मंशा, निष्पादन का प्राधिकरण और निष्पादन का प्रमाण — ये एक ही शृंखला की चार परतें हैं, और वह शृंखला एक जैसी चलती है, चाहे निर्देश इनबॉक्स में आए, किसी मैसेंजर में आए, या MCP टूल कॉल से।

SecureStamp भरोसे को निर्देश से लेकर परिणाम तक बढ़ाता है।

भरोसे का स्टैक

स्रोत

यह कहाँ से आया? डोमेन, हेडर, हस्ताक्षर, घोषित पहचान और चैनल की परिधि। यह सहायक प्रमाण है — ज़रूरी, पर कभी मुख्य शीर्षक नहीं।

मंशा

क्या माँगा जा रहा है? माँगी गई कार्रवाई को पहले पढ़ा और पहले बताया जाता है: भुगतान करना, मंज़ूरी देना, क्रेडेंशियल सौंपना, कोई टूल चलाना। यह एक इनपुट संकेत है, प्रमाण नहीं।

Execution Authorization

किस सटीक प्रभाव की अनुमति है? स्वीकृत निर्णय स्पष्ट शर्तों के तहत एक ही मानक ऑपरेशन के लिए सीमित, एक-बार-उपयोग वाला अधिकार बन जाता है।

निष्पादन का प्रमाण

कौन-सा प्राधिकरण खर्च हुआ, और निष्पादन बिंदु कौन-सा परिणाम स्थापित कर सका? एक हस्ताक्षरित रसीद, जिसे कोई भी ऑफ़लाइन जाँच सकता है।

यहाँ लागू

Email

Gmail · Outlook · Apple Mail

आधिकारिक चैनल

WhatsApp · Telegram · घोषित परिधियाँ

एजेंट

MCP क्लाइंट और कोपायलट

APIs

सीधे इंटीग्रेशन

Workflows

ऑटोमेशन और सौंपी गई सेवाएँ

Execution Authorization वहाँ हर जगह लागू होता है जहाँ अधिकार सॉफ़्टवेयर को सौंपा जाता है, सिर्फ़ AI एजेंट तक सीमित नहीं। किसी और की ओर से काम करने वाला ऑटोमेशन, वर्कफ़्लो या सौंपी गई सेवा वही सवाल खड़ा करती है: आख़िर किस सटीक प्रभाव को मंज़ूरी मिली थी?

प्रोटोकॉल की थीसिस

नई परिधि अब कार्रवाई है।

पहले हमने उपकरणों को मैलवेयर और ट्रोजन से बचाया। फिर इनबॉक्स को फ़िशिंग से बचाया। अब सॉफ़्टवेयर हमारी ओर से काम करता है, और सवाल सिर्फ़ यह नहीं रहा कि वह कहाँ तक पहुँच सकता है — बल्कि यह कि वह क्या बदल सकता है।

संदेश, घटनाएँ और प्रॉम्प्ट API, टूल कॉल, वर्कफ़्लो और डिजिटल मुद्रा लेन-देन शुरू कर सकते हैं। SecureStamp ऐसे सत्यापन योग्य संकेत देता है, इससे पहले कि कोई संवाद कार्रवाई बन जाए।

पहचान यह नियंत्रित करती है कि किसी सिस्टम तक कौन पहुँच सकता है। SecureStamp यह सीमित करता है कि स्वायत्त सॉफ़्टवेयर ठीक कौन-सा प्रभाव पैदा कर सकता है।

इनबॉक्स तो सिर्फ़ शुरुआत थी।
एक्सेस होना कार्रवाई का अधिकार नहीं है।
जहाँ भी अधिकार सॉफ़्टवेयर को सौंपा जाता है।

चार परतें

प्रमाणीकरण पहचान स्थापित करता है। एक्सेस कंट्रोल पहुँच सीमित करता है। Execution Authorization प्रभाव को सीमित करता है।

  1. प्रमाणीकरण

    कौन, या क्या, कार्रवाई कर रहा है?

  2. एक्सेस प्राधिकरण

    वह किन संसाधनों तक पहुँच सकता है?

  3. Execution Authorization

    वह ठीक कौन-सा प्रभाव पैदा कर सकता है?

  4. निष्पादन का प्रमाण

    कौन-सा प्राधिकरण खर्च हुआ, और निष्पादन बिंदु कौन-सा परिणाम स्थापित कर सका?

चौथा सवाल जान-बूझकर ऐसे लिखा गया है। जो परिणाम स्थापित नहीं हो सकता, वह अनिर्धारित ही रहता है, और इस स्टैक की कोई परत इसके उलट होने का दिखावा नहीं करती।

हम कहाँ खड़े हैं

SecureStamp वहीं से शुरू होता है जहाँ निर्णय ख़त्म होता है।

पहचान, नीति और अनुमोदन प्रणालियाँ तय करती हैं कि कोई कार्रवाई आगे बढ़नी चाहिए या नहीं। SecureStamp उस स्वीकृत निर्णय को उस सटीक प्रभाव से बाँधता है जिसे निष्पादित किया जा सकता है।

तय करना

क्या अनुमति मिलनी चाहिए? इसका उत्तर पहचान, नीति इंजन, अनुमोदन और लोग देते हैं।

प्राधिकृत करना

ठीक कौन-सा प्रभाव अनुमत है? यही वह परत है जो SecureStamp जोड़ता है।

निष्पादित करना

उस प्रभाव को ग्राहक की शर्तों के भीतर, ग्राहक द्वारा नियंत्रित बिंदु पर लागू करना।

सत्यापित करना

कौन-सा प्राधिकरण खर्च हुआ, और निष्पादन बिंदु कौन-सा परिणाम स्थापित कर सका?

SecureStamp पहचान, नीति इंजन, अनुमोदन वर्कफ़्लो या प्रदाता API की जगह नहीं लेता। यह उनके स्वीकृत निर्णयों को सटीक, निष्पादन-योग्य प्रभावों से बाँधता है।

SecureStamp सत्यापन योग्य संकेत और सीमित प्राधिकरण देता है। यह आंतरिक नीतियों, अनुमतियों, sandboxing, मानवीय मंज़ूरी या मौजूदा सुरक्षा नियंत्रणों की जगह नहीं लेता।

01

उपकरण

पहली आधुनिक परिधि उपकरण थी: मैलवेयर, ट्रोजन, ख़तरनाक फ़ाइलें और स्थानीय व्यवहार।

02

इनबॉक्स

फिर जोखिम संदेशों की ओर गया: मिलते-जुलते डोमेन, नक़ली लिंक, अटैचमेंट, भुगतान की जल्दबाज़ी और पहचान की नक़ल।

03

कार्रवाइयाँ

अब एक निर्देश टूल खोल सकता है, API बुला सकता है, चालान प्रोसेस कर सकता है, डेटा हिला सकता है या भुगतान तैयार कर सकता है।

04

Trust checks

SecureStamp पढ़ता है कि कोई संदेश क्या माँग रहा है — भुगतान, अनुमोदन, क्रेडेंशियल देना, कोई टूल चलाना — और उत्तर देने, भुगतान करने, डेटा साझा करने या वर्कफ़्लो चलाने से पहले स्रोत, चैनल और संदर्भ के प्रमाणों से उसे पुष्ट करता है।

चैनल-निरपेक्ष

एक चैनल-निरपेक्ष मानक

SecureStamp किसी एक इनबॉक्स, ऐप या उद्योग के लिए नहीं बना। प्रोटोकॉल संकेतों को स्रोत, चैनल, घोषित मंशा और कार्रवाई के इर्द-गिर्द व्यवस्थित करता है। यह ईमेल, मैसेजिंग, QR, वेबसाइट, चालान, टिकट, API, एजेंट और डिजिटल मुद्रा लेन-देन पर लागू हो सकता है।

EmailWhatsAppTelegramWebQRचालानTicketsAPIsWorkflowsMCPएजेंटडिजिटल मुद्रा लेन-देन

सौंपा गया अधिकार

जहाँ भी अधिकार सॉफ़्टवेयर को सौंपा जाता है।

कोई एजेंट, कोई ऑटोमेशन, कोई वर्कफ़्लो या किसी और की ओर से काम करने वाली सौंपी गई सेवा — सब वही एक सवाल खड़ा करते हैं। एक्सेस अनुमति बताती है कि वे कहाँ तक पहुँच सकते हैं; वह यह परिभाषित नहीं करती कि इस लेन-देन के लिए ठीक कौन-सा प्रभाव स्वीकृत हुआ।

किसी निर्देश पर काम करने से पहले स्रोत और घोषित मंशा की जाँच करें।
जवाब देने से पहले प्रतिपक्ष के आधिकारिक चैनल की पुष्टि करें।
बड़े असर वाले ऑपरेशन को व्यापक एक्सेस से नहीं, एक सटीक प्रभाव से बाँधें।
प्राधिकरण एक बार खर्च करें, फिर कभी नहीं।
निष्पादन को उसी बिंदु पर रखें जिसे संगठन नियंत्रित करता है।
अस्पष्ट परिणामों को आँख मूँदकर दोहराने के बजाय मिलान करें।
ऐसा हस्ताक्षरित प्रमाण रखें जिसे हमारे बिना भी जाँचा जा सके।
इन सबको आंतरिक नीति और मानवीय मंज़ूरी के साथ जोड़ें।

एजेंटों के लिए MCP

SecureStamp MCP Server

Public Beta

MCP वह रास्ता है जिससे AI ऐप्लिकेशन टूल, डेटा और वर्कफ़्लो तक पहुँचते हैं। SecureStamp उस पहुँच के आगे खड़ा होता है: कुछ भी चलने से पहले सॉफ़्टवेयर पूछता है कि निर्देश असल में क्या माँग रहा है, प्रतिपक्ष कौन है, और वह ठीक कौन-सा प्रभाव पैदा कर सकता है।

SecureStamp प्राधिकृत करता है; वह आपके डाउनस्ट्रीम प्रदाता के क्रेडेंशियल कभी नहीं रखता। जब किसी ऑपरेशन को सचमुच चलना होता है, तो हस्ताक्षरित grant उस Execution Guardian तक जाता है जिसे आप चलाते हैं, और प्रदाता को सिर्फ़ वही daemon छूता है।

read_message_request(...)analyze_message_intent(...)verify_counterparty(...)get_safe_next_step(...)authorize_action(...)create_action_challenge(...)issue_action_receipt(...)get_source_envelope(...)request_execution_grant(...)get_execution_status(...)

वैचारिक प्रवाह

agent → read_message_request → analyze_message_intent → get_safe_next_step → request_execution_grant → Execution Guardian → ActionReceiptV3

Signal Framework

SSF: SecureStamp Signal Framework

SSF पहले माँगी गई कार्रवाई को, फिर सामग्री, स्रोत, प्रमाणीकरण, चैनल और संदर्भ के संकेतों को व्यवस्थित करता है, ताकि लोगों, सिस्टम और एजेंट के लिए एक सरल और ऑडिट-योग्य परिणाम बने।

Requested Action

जवाब देना, खोलना, भुगतान करना, ट्रांसफ़र करना, मंज़ूरी देना, डेटा साझा करना, टूल बुलाना या वर्कफ़्लो चलाना।

Content Signals

जल्दबाज़ी, लिंक, अटैचमेंट, क्रेडेंशियल, भुगतान के निर्देश और बैंक खाते में बदलाव।

Origin Signals

डोमेन, संगठन, घोषित पहचान, भेजने वाला।

Technical Signals

SPF, DKIM, DMARC, DNS TXT, हेडर, हस्ताक्षर, कुंजियाँ और receipts।

Channel Signals

ईमेल, वेब, WhatsApp, Telegram, QR, API, सपोर्ट, बिलिंग और टिकट।

Verdict Layer

Trust, Signal और Action Verdict: एक पठनीय और ऑडिट-योग्य परिणाम, जो पहले माँगी गई कार्रवाई बताता है और उसके नीचे स्रोत के प्रमाण दिखाता है।

तीन इनपुट संकेत, उसके बाद प्राधिकरण

Proof of Origin बताता है कि निर्देश कहाँ से आया। Proof of Intent बताता है कि वह क्या माँग रहा है। Action Verdict सुझाता है कि आगे बढ़ना चाहिए या नहीं। तीनों ऐसे संकेत हैं जो निर्णय को पोसते हैं — और निर्णय अभी प्राधिकरण नहीं है।

Proof of Intent

क्या माँगा जा रहा है? एक इनपुट संकेत जो माँगी गई कार्रवाई को पहले बताता है। यह इस बात का प्रमाण नहीं कि क्या प्राधिकृत हुआ।

Proof of Origin

यह कहाँ से आया? डोमेन, संगठन, चैनल, भेजने वाला, स्टैम्प और तकनीकी संकेत। सहायक प्रमाण।

Action Verdict

क्या यह आगे बढ़ना चाहिए? एक निर्णय-संकेत। उस निर्णय के बाद जो होता है, वही Execution Authorization है।

निष्पादन परत

Public Beta · प्रोडक्शन एक्सेस नियंत्रित

निर्णय प्रमाण नहीं होता।

verdict यह सुझा सकता है कि कोई कार्रवाई आगे बढ़नी चाहिए या नहीं। पर वह अपने आप में यह साबित नहीं करता कि ठीक कौन-सा प्रभाव प्राधिकृत हुआ, उसके पीछे कौन-सा अधिकार था, प्राधिकरण दोबारा इस्तेमाल हुआ या नहीं, और निष्पादन पर क्या परिणाम देखा गया।

Action Proof वही प्रमाण-शृंखला बनाता है। स्वीकृत निर्णय एक सीमित, निष्पादन-योग्य अधिकार बन जाता है: एक सटीक प्रभाव, एक अधिकार, एक समय-सीमा, एक बार का उपयोग — जिसे कोई भी ऑफ़लाइन जाँच सकता है।

एक्सेस होना कार्रवाई का अधिकार नहीं है

एक्सेस यह नियंत्रित करता है कि सॉफ़्टवेयर कहाँ तक पहुँच सकता है। Execution Authorization यह सीमित करता है कि वह ठीक कौन-सा प्रभाव पैदा कर सकता है।

संसाधन प्राधिकरण बताता है कि कोई principal किस तक पहुँच सकता है। Execution Authorization बताता है कि वह किसी लेन-देन-विशिष्ट कौन-से प्रभाव को पैदा कर सकता है। fine-grained एक्सेस भी लेन-देन को अपरिभाषित छोड़ देता है: कौन-सा संसाधन, कितनी राशि, कौन-सा गंतव्य, कितनी बार।

प्रभाव को प्राधिकृत करें, सिर्फ़ टूल तक की पहुँच को नहीं।

ग्राहक द्वारा नियंत्रित सीमा

आपकी नीति ही ऊपरी सीमा है।

SecureStamp Cloud किसी प्राधिकरण को और सँकरा कर सकता है। वह उसे उस नीति से चौड़ा नहीं कर सकता जिसे आपके संगठन ने हस्ताक्षरित करके स्थानीय रूप से स्थापित किया है। क्लाउड प्राधिकरण ज़रूरी है, पर अकेले कभी पर्याप्त नहीं।

प्रभावी अनुमति

प्रभावी अनुमति =
      क्लाउड grant
    ∩ हस्ताक्षरित स्थानीय नीति
    ∩ अडैप्टर की शर्तें
    ∩ kill switches
  • स्थानीय नीति एक दस्तावेज़ है जिसे आपका संगठन अपनी कुंजी से हस्ताक्षरित करता है और Guardian के साथ स्थापित करता है। यह tenant, gateway, ऑपरेशन, अडैप्टर manifest, स्वीकृत अधिकार और नीति संस्करण, संसाधन, पैरामीटर, मौद्रिक सीमाएँ, समवर्तीता और नेटवर्क गंतव्य तय करती है।
  • यह रचना से ही deny-only है। इसमें ऐसा कोई फ़ील्ड नहीं जो वह दे सके जो क्लाउड ने नहीं दिया।
  • वैध हस्ताक्षरित स्थानीय नीति के बिना प्रोडक्शन मोड में शुरू करना चेतावनी नहीं देता: शुरुआत में ही अस्वीकार कर दिया जाता है।
  • kill switch वैश्विक स्तर पर और प्रति प्रदाता, ऑपरेशन, tenant व gateway मौजूद हैं — और फिर स्वयं स्थानीय नीति के भीतर भी। ये पहले से जारी grant को रोक देते हैं।
  • नीतियों में अनिवार्य समीक्षा तिथि और वैकल्पिक समाप्ति होती है। समाप्त हो चुकी नीति नए बदलाव रोक देती है, जबकि स्थिति, प्रमाण, पुनःपठन और मिलान अछूते रहते हैं।
  • कुंजी पुनर्प्राप्ति M-of-N और ऑफ़लाइन है। SecureStamp का सपोर्ट उस नियंत्रण की जगह नहीं ले सकता, और यही तो बात है।
  • क्लाउड कंट्रोल प्लेन समझौता हो जाने पर भी वह स्थानीय रूप से अनुमत अधिकार से आगे नहीं जा सकता।

ग्राहक द्वारा होस्ट

हम प्राधिकृत करते हैं। आप निष्पादित करते हैं।

Guardian आपके परिवेश में चलता है और प्रदाता के क्रेडेंशियल रखता है। SecureStamp Cloud को प्रदाता के क्रेडेंशियल नहीं मिलते और वह कभी आपके प्रदाता को कॉल नहीं करता।

  • प्रदाता के क्रेडेंशियल root के स्वामित्व वाली फ़ाइलों के रूप में माउंट होते हैं — कभी एनवायरनमेंट वेरिएबल या इनलाइन कॉन्फ़िगरेशन के रूप में नहीं।
  • मॉडल के सबसे नज़दीक की प्रक्रिया, MCP bridge, को न प्रदाता क्रेडेंशियल चाहिए न क्लाउड SDK।
  • प्रभाव उस स्थिति से तय होता है जिसे daemon खुद पढ़ता है, कभी उन पैरामीटर से नहीं जो मॉडल ने दिए।
  • पिछली स्थिति बदलाव से ठीक पहले फिर से पढ़ी जाती है; कोई सारभूत परिवर्तन grant को अधिलेखित करने के बजाय अमान्य कर देता है।

प्रमाण शृंखला

पाँच कड़ियाँ, हर एक अलग पक्ष द्वारा हस्ताक्षरित

प्राधिकरण का क्रिप्टोग्राफ़िक प्रमाण। निष्पादन के परिणाम का हस्ताक्षरित साक्ष्य।

Source Envelope

प्लगइन वही हस्ताक्षरित करता है जो व्यक्ति ने वास्तव में देखा — डिवाइस पर, ऐसी कुंजी से जो कभी बाहर नहीं जाती। संदेश का मूल पाठ कभी प्रेषित नहीं होता।

Action Effect

Guardian — मॉडल नहीं — प्रदाता की स्थिति पढ़ता है और सटीक प्रभाव को सामान्यीकृत करता है: प्रदाता, ऑपरेशन, संसाधन, पैरामीटर और पिछली स्थिति का digest।

Execution Grant

SecureStamp Cloud उस प्रभाव-digest, मंज़ूरी देने वाले अधिकार, प्रचलित नीति संस्करण और एक समय-सीमा से बँधा एकल-उपयोग grant हस्ताक्षरित करता है। maxUses हमेशा 1 होता है।

Execution Claim

आपका Guardian उस grant का दावा अपने ही ledger के विरुद्ध करता है। दोबारा चलाया गया grant किसी भी प्रदाता से संपर्क होने से पहले अस्वीकार हो जाता है।

Action Receipt

Guardian खर्च हुए प्राधिकरण, निष्पादन संदर्भ और जो परिणाम वह स्थापित कर सका, उसे उस स्थानीय नीति के digest के साथ हस्ताक्षरित करता है जिसने उसे सीमित किया।

अधिकार

कोई अनुरोध अपनी अनुमति स्वयं लेकर नहीं आता।

कोई ऑपरेशन किस अधिकार की माँग करता है, यह प्रोटोकॉल तय करता है। कॉल करने वाला उसे चुन नहीं सकता, मॉडल उसके पक्ष में तर्क नहीं दे सकता, और जिस अनुरोध को उसकी ज़रूरत है उसी के भीतर उसे घटाया नहीं जा सकता। quorum प्रोफ़ाइल हस्ताक्षरित नीति स्नैपशॉट हैं, अधिकार-मान नहीं: standard और elevated इंसानों के लिए लेबल हैं, जबकि प्रमाण threshold, अनुमोदकों की सूची और नीति के hash पर टिका है।

none

कभी निष्पादन नहीं देता। यह इसलिए है ताकि उसकी अनुपस्थिति निहित नहीं, स्पष्ट हो।

policy_delegated

उस नीति के भीतर स्वायत्तता जो संगठन ने पहले से तय की है, और केवल डिवाइस पर हस्ताक्षरित अनुरोध के लिए। सहसंबद्ध अनुरोध के लिए कभी नहीं।

human_mfa

नामित व्यक्ति एक जीवित MFA सत्र के विरुद्ध मंज़ूरी देता है। वहाँ प्रयुक्त जहाँ प्रभाव सीमित और व्यवहार में प्रतिवर्ती हो।

quorum

M-of-N स्वतंत्र अनुमोदक, हर एक का अपना MFA सत्र, पहले से तय नीति के विरुद्ध। अनुरोध करने वाला अपना ही अनुरोध कभी मंज़ूर नहीं कर सकता। हर विशेषाधिकार देने के लिए अनिवार्य।

विफलता में सुरक्षा

अज्ञात, अज्ञात ही रहता है।

प्रदाता की अस्पष्ट प्रतिक्रिया मिलान होने तक अनिर्धारित रहती है। स्थिति बदलने वाले ऑपरेशन आँख मूँदकर दोबारा नहीं चलाए जाते।

कोई भुगतान API एक बदलाव प्राप्त करने के बाद टाइमआउट हो जाता है। उसे दोहराने से प्रभाव दोगुना हो सकता है। SecureStamp विफलता मानकर दोबारा कोशिश नहीं करता: Guardian प्रदाता की स्थिति का मिलान करता है और indeterminate लौटा सकता है। अस्पष्टता प्रथम श्रेणी का परिणाम है और उसे कभी सफलता में नहीं बदला जाता।

स्वतंत्र सत्यापन

शृंखला जाँचिए, हमसे पूछे बिना।

सत्यापनकर्ता एक प्रकाशित पैकेज है जिसे नेटवर्क एक्सेस नहीं है। यह किसी proof bundle के हर digest और हर हस्ताक्षर को ऑफ़लाइन दोबारा गणना करता है, जिसमें नीति स्नैपशॉट का hash और हस्ताक्षरित स्थानीय नीति का digest शामिल है। receipts को SecureStamp से संपर्क किए बिना ऑफ़लाइन जाँचा जा सकता है, और सत्यापन किसी चालू SecureStamp सेवा पर निर्भर नहीं है।

bash
npx --package @securestamp/action-proof-verify action-proof-verify bundle.json

सत्यापनकर्ता उन कलाकृतियों से पहले आता है जिन्हें वह जाँचता है। कोई नया receipt या bundle संस्करण तब तक जारी नहीं होता जब तक कोई जारी सत्यापनकर्ता उसे पहले से स्वीकार न करता हो।

कनेक्टर

वही निष्पादन बिंदु लाइए जो आप पहले से इस्तेमाल करते हैं।

SecureStamp का प्राधिकरण मॉडल प्रदाता-निरपेक्ष है। ये संदर्भ कनेक्टर हैं, कोई बंद सूची नहीं। कोई कनेक्टर कैसे जुड़ता है और SecureStamp उसके लिए कितनी ज़िम्मेदारी लेता है — ये दो अलग सवाल हैं, और हम उन्हें जानबूझकर अलग रखते हैं।

यह कैसे जुड़ता है

प्रमाणित अडैप्टर

एक मॉड्यूल जिसे हमने लिखा, जाँचा और प्रकाशित प्रमाणन साक्ष्य से बाँधा।

घोषणात्मक HTTPS अडैप्टर

origin, मेथड और path इंस्टॉल के समय तय। मॉडल से कोई मनमाना URL, मेथड या header नहीं, कोई redirect नहीं, सख़्त schema, नियतात्मक idempotency।

SDK / sidecar

उन प्रोटोकॉल के लिए जो घोषणात्मक अनुबंध पूरा नहीं कर सकते — Unix socket के ऊपर।

इसकी गारंटी कैसे घोषित होती है

SecureStamp Certified

हमने लिखा, हमने जाँचा, और हमने साक्ष्य प्रकाशित किए।

Partner Attested

एक नामित पार्टनर इसकी ज़िम्मेदारी लेता है, और bundle यह कहता है।

Customer Defined

इसे आपने बनाया। शृंखला फिर भी सत्यापित होती है, और bundle साफ़ शब्दों में कहता है कि SecureStamp ने उस कनेक्टर का कोड प्रमाणित नहीं किया।

अडैप्टर प्राधिकृत प्रभाव को प्रदाता-विशिष्ट निष्पादन में बदलते हैं। वे दिए गए अधिकार को फिर से परिभाषित नहीं करते।

Stripe

refund.createhuman_mfa

Okta

group.add_userhuman_mfa

AWS

iam.attach_role_policyquorum

Google Cloud

iam.project_binding.addquorum

Azure

rbac.role_assignment.createquorum

Microsoft Entra

pim.directory_role_assignment.createquorum

आपके मौजूदा कंट्रोल प्लेन में फ़िट बैठता है

उन्हीं नियंत्रणों के साथ काम करता है जो आपके पास पहले से हैं।

SecureStamp पहचान, नीति इंजन, अनुमोदन वर्कफ़्लो या प्रदाता API की जगह नहीं लेता। यह उनके स्वीकृत निर्णयों को सटीक, निष्पादन-योग्य प्रभावों से बाँधता है।

प्रमाण की सीमाएँ

कोई receipt क्या स्थापित करता है और क्या नहीं।

कोई Action Receipt यह साबित करता है कि किसी नामांकित Guardian से क्या गुज़रा और वह Guardian कौन-सा परिणाम स्थापित कर सका। यह साबित नहीं करता कि SecureStamp के बाहर कोई कार्रवाई नहीं हुई, न ही प्रदाता खाते का कानूनी स्वामित्व स्थापित करता है।

प्रमाण की सीमा वही नामांकित निष्पादन मार्ग है।

उस मार्ग के बाहर की गई कार्रवाइयाँ receipt के दायरे से बाहर हैं।

रिलीज़ स्थिति

ये पैकेज अब भी बीटा क्यों कहते हैं।

प्रोटोकॉल, कोड और सत्यापनकर्ता आज पूर्ण और ऑडिट-योग्य हैं। पर हम किसी कनेक्टर को तब तक stable नहीं कहते जब तक किसी जीवित प्रदाता के विरुद्ध 100 वास्तविक निष्पादनों का साक्ष्य प्रकाशित न कर दें — जिसमें फ़ॉल्ट इंजेक्शन, रीप्ले अस्वीकृति और यह प्रमाण शामिल हो कि वह क्रेडेंशियल इससे अधिक कुछ नहीं कर सकता था — और उसे ठीक उसी commit से बाँध दें जिसने उन्हें पैदा किया। प्रोडक्शन निष्पादन के लिए स्पष्ट opt-in और कनेक्टर पात्रता चाहिए, और जब तक कोई कनेक्टर वह द्वार पार नहीं करता, उसका Guardian sandbox मोड के बाहर चलने से इनकार करता है। जो भरोसे का उत्पाद आपसे कहे कि बस मान लीजिए, वह पहले ही विफल हो चुका है।

पैकेज

@securestamp/action-proof-verify

ऑफ़लाइन सत्यापनकर्ता और उसके सत्यापन अनुबंध। जो कुछ वह जाँचता है, उन सबसे पहले प्रकाशित।

@securestamp/action-proof

अनुबंध, हस्ताक्षर और proof bundle।

@securestamp/execution-guardian

ग्राहक द्वारा होस्ट किया गया daemon और उसके प्रदाता कनेक्टर।

@securestamp/execution-guardian-mcp

MCP bridge। रचना से ही न क्रेडेंशियल, न क्लाउड SDK।

Trust Levels

Trust Level स्रोत बताता है। Action Verdict कार्रवाई तय करने में मदद करता है।

स्तर L1-L5 सत्यापन योग्य स्रोत-प्रमाण को श्रेणी देते हैं। वे यह दावा नहीं करते कि सामग्री सच है या कि कोई कार्रवाई अपने आप होनी चाहिए।

L1

पंजीकृत

वह डोमेन या संगठन SecureStamp में पंजीकृत है।

L2

संरेखित

SPF, DKIM, DMARC या DNS जैसे तकनीकी संकेत संरेखित हैं।

L3

हस्ताक्षरित

संदेश, चैनल या घटना में हस्ताक्षरित और सत्यापन योग्य टोकन शामिल है।

L4

नोटरीकृत

बाद के ऑडिट के लिए सत्यापन योग्य अखंडता संदर्भ या रसीद मौजूद है।

L5

प्रमाणित

स्रोत के पीछे की संगठनात्मक पहचान की अतिरिक्त प्रमाणों के साथ समीक्षा की गई।

स्रोत सत्यापित होने का मतलब कार्रवाई स्वीकृत होना नहीं है

Trust Level स्रोत-प्रमाण की मज़बूती बताता है। Action Verdict किसी ठोस कार्रवाई को SSF, संदर्भ और नीति से आँकता है। वैध स्रोत भी ऐसी कार्रवाई माँग सकता है जिसकी समीक्षा ज़रूरी हो।

इंटीग्रेशन के बिंदु

भरोसा घोषित करने और पूछने के चार तरीके

DNS TXT record

_securestamp.[domain] के अंतर्गत एक TXT रिकॉर्ड प्रकाशित करें। सत्यापनकर्ता सबडोमेन हल करते हैं और निजी सामग्री देखे बिना घोषित स्रोत की पुष्टि करते हैं।

  • —v=1 — प्रोटोकॉल संस्करण
  • —id=<stamp_id> — सत्यापन योग्य पहचानकर्ता
  • —url=<verify_url> — कैनोनिकल सत्यापन URL
DNS zone
_securestamp.example.com.  3600  IN  TXT
  "securestamp=v=1;
   id=f47ac10b-58cc-4372-a567-0e02b2c3d479;
   url=https://securestamp.org/verify/eyJhbG..."

Email header

बाहर जाने वाले संदेशों में X-SecureStamp जोड़ें ताकि क्लाइंट, प्लगइन और गेटवे हस्ताक्षरित संकेतों से स्रोत और स्थिति पूछ सकें।

  • —भेजने वाले या अधिकृत नोड द्वारा हस्ताक्षरित टोकन
  • —न्यूनतम claims: stampId, domain, orgId, score, exp
  • —सत्यापन के लिए सार्वजनिक कुंजी या सत्यापन योग्य संदर्भ
SMTP header
X-SecureStamp: v=1;
  token=eyJhbGciOiJFUzI1NiJ9.eyJzdGFtcElkIjoiZjQ3YWMxM...;
  verify=https://securestamp.org/verify/eyJhbG...

REST API

संवेदनशील निर्देशों को सादे रूप में सहेजे बिना डोमेन, चैनल या कार्रवाइयाँ पूछें। उत्तरों में संकेत, reasons और Trust Receipts शामिल हो सकते हैं।

  • —डोमेन और चैनलों के लिए trust check
  • —संवेदनशील कार्रवाइयों के लिए Action Verdict
  • —ऑडिट के लिए सत्यापन योग्य receipts
  • —जहाँ लागू हो, सार्वजनिक सत्यापनकर्ता और registry
request
GET https://securestamp.org/v1/trust/example.com
response
{
  "domain": "example.com",
  "trustLevel": "L3",
  "signals": { "spf": "pass", "dkim": "pass", "dmarc": "pass" },
  "actionVerdict": "needs_confirmation",
  "receiptRef": "tr_01h..." 
}

MCP Server

सक्रिय Agent Trust layer जिससे agents tool calls, APIs, workflows और sensitive operations से पहले trust checks पूछ सकते हैं।

  • —SecureStamp MCP Server
  • —Tool call checks
  • —निष्पादन से पहले Action Verdict
  • —जब नीति माँगे तब मानवीय मंज़ूरी
MCP tool call
securestamp.get_action_verdict({
  origin: "billing@example.com",
  action: "payment_request",
  amount: "1200.00",
  destination: "acct_..." 
})

Official Channel Signal

संवाद वाली सतहों पर आधिकारिक चैनल का सत्यापन

Signal से आप पूछ सकते हैं कि कोई नंबर, बॉट, हैंडल, लिंक, अकाउंट या संपर्क बिंदु किसी संस्था की घोषित आधिकारिक परिधि में आता है या नहीं। यह WhatsApp, Telegram, वेब, QR, सपोर्ट, बिलिंग और उन बाक़ी चैनलों की परत है जहाँ कोई व्यक्ति या एजेंट संवेदनशील निर्देश पा सकता है।

आधिकारिक परिधि

ईमेल, WhatsApp, Telegram, वेब, QR, सपोर्ट और बिलिंग चैनलों को सत्यापन योग्य रिकॉर्ड से मिलाता है।

SSF से जुड़ा

चैनल के संकेत Trust, Action Verdict और receipts में जाते हैं, बिना किसी ब्रांड को पूर्ण गारंटी बनाए।

ईमानदार सीमा

Signal आधिकारिक परिधि में सदस्यता जाँचता है। यह साबित नहीं करता कि हर संदेश सच है।

WhatsApp बॉटTelegram बॉटsecurestamp.online पर उत्पाद देखें

Receipts, registry और ऑडिट

स्क्रीनशॉट पर निर्भर हुए बिना ऑडिट-योग्य प्रमाण

हर प्रासंगिक पूछताछ या घोषणा एक सत्यापन योग्य receipt बना सकती है। receipts से स्रोत, चैनल, घोषित मंशा और Action Verdict की जाँच होती है, बिना किसी इंटरफ़ेस पर आँख मूँदकर भरोसा किए।

Trust Receipts

हस्ताक्षरित receipts, जिनमें संकेत, अनुमत संदर्भ, टाइमस्टैम्प और सत्यापन योग्य संदर्भ का सार होता है।

Registry

जब प्रवाह अनुमति दे, तो टोकन, receipts और सार्वजनिक संदर्भ बिना प्रमाणीकरण के जाँचे जा सकते हैं।

ऑडिट

संगठन receipts को अपनी आंतरिक नीतियों, मंज़ूरियों और अनुपालन नियंत्रणों के साथ जोड़ सकते हैं।

सार्वजनिक शब्दावली

उपयोगकर्ताओं, सपोर्ट और इंटीग्रेटर्स के लिए साझा भाषा

The glossary explains SecureStamp, email, cryptography, Signal, E2EE, API and infrastructure terms so a non-technical person or junior developer can understand what they are reading.

शब्दावली खोलें

SecureStamp Terms

Concepts created or defined by SecureStamp to explain trust, stamps, receipts and verifiable perimeters.

Email, Domains and Authentication

Classic abbreviations used when SecureStamp explains whether a sender or domain is properly authenticated.

Cryptography and Security

Terms needed to understand signatures, encryption, keys, verifiable logs and enterprise recovery.

Protocols, APIs and Infrastructure

Common language for junior developers and integrators reading APIs, plugins, dashboards or runbooks.

फ़ेडरेटेड नेटवर्क

फ़ेडरेटेड नेटवर्क और स्वीकृत नोड

SecureStamp Foundation साझा रिकॉर्ड लिखने और सत्यापित करने के लिए स्वीकृत नोड का नेटवर्क समन्वित करती है। नोड चलाने के लिए तकनीकी समीक्षा, SLA और गवर्नेंस सिद्धांतों से तालमेल ज़रूरी है।

01

आवेदन भेजें

संगठन, क्षेत्र, परिचालन क्षमता, अपेक्षित SLA, तकनीकी दायरा और घोषित उपयोग-मामला शामिल करें।

02

तकनीकी समीक्षा

फ़ाउंडेशन क्षमता, परिचालन सुरक्षा, कवरेज और संभावित हितों के टकराव का मूल्यांकन करती है।

03

क्रेडेंशियल जारी

स्वीकृति मिलने पर संचालक को नेटवर्क में शामिल होने के लिए क्रेडेंशियल और इंटीग्रेशन आवश्यकताएँ मिलती हैं।

04

ऑडिट किया गया संचालन

नोड को उपलब्धता, सार्वजनिक health, परिचालन ट्रेसेबिलिटी और घटना-प्रतिक्रिया प्रक्रियाएँ बनाए रखनी होंगी।

नोड के दायित्व

30-दिन की अवधि में लक्षित अपटाइम ≥ 99%
/v1/health एंडपॉइंट प्रकाशित करना
कुंजियाँ और क्रेडेंशियल रोटेट करने योग्य रखना
प्रासंगिक विसंगतियाँ फ़ाउंडेशन को बताना
मंज़ूरी के बिना सत्यापन नीतियाँ बदलना
बिना अधिकार आंतरिक डेटा या संवेदनशील संकेत उजागर करना
नोड चलाने का अनुरोध करेंअपना अनुरोध यहाँ भेजें nodes@securestamp.org

सत्यापन योग्य registry

स्टैम्प, receipts और सार्वजनिक संदर्भ जाँचें

SecureStamp द्वारा जारी हर स्टैम्प, receipt या सार्वजनिक संदर्भ जाँचा जा सकता है, बिना इस साइट को व्यावसायिक लैंडिंग पेज बनाए। फ़ाउंडेशन मानक और पूछताछ बिंदु बनाए रखती है।

सार्वजनिक सत्यापनकर्ता खोलें
securestamp.org/verify/[token]

तकनीकी FAQ

डेवलपर और इंटीग्रेटर के अक्सर पूछे जाने वाले सवाल

SecureStamp Foundation क्या है?

वह संस्था जो खुला SecureStamp मानक प्रकाशित और संचालित करती है, ताकि काम करने से पहले स्रोत, मंशा, चैनल और कार्रवाई की जाँच हो सके।

यह प्रोटोकॉल कौन-सी समस्या हल करता है?

यह लोगों, सिस्टमों और एजेंटों को जवाब देने, भुगतान करने, डेटा साझा करने, API बुलाने या वर्कफ़्लो चलाने से पहले सत्यापन योग्य संकेत पूछने में मदद करता है।

भरोसे का स्टैक और सतहें कैसे जुड़ी हैं?

भरोसे का स्टैक है — स्रोत, मंशा, Execution Authorization और निष्पादन का प्रमाण। सतहें हैं — ईमेल, आधिकारिक चैनल, एजेंट, API और वर्कफ़्लो। ये दो अलग-अलग अक्ष हैं: वही स्टैक हर सतह पर लागू होता है, और Execution Authorization एक परत है, कभी अपने आप में सतह नहीं।

Proof of Origin क्या है?

सत्यापन योग्य प्रमाण कि कोई डोमेन, चैनल, भेजने वाला या संगठन किसी पंजीकृत स्रोत से मेल खाता है।

Execution Authorization क्या है?

स्वीकृत निर्णय को ऐसे सीमित और लेन-देन-विशिष्ट अधिकार से बाँधने की प्रक्रिया, जो सॉफ़्टवेयर को स्पष्ट शर्तों के तहत एक परिभाषित प्रभाव पैदा करने देती है। एक्सेस कंट्रोल यह सीमित करता है कि सॉफ़्टवेयर कहाँ तक पहुँच सकता है; Execution Authorization यह सीमित करता है कि वह ठीक कौन-सा प्रभाव पैदा कर सकता है।

Action Verdict क्या है?

निष्पादन से पहले किसी ठोस कार्रवाई का मूल्यांकन। संकेतों और नीति के अनुसार यह अनुमति, समीक्षा, अस्वीकृति या मानवीय मंज़ूरी की सिफ़ारिश कर सकता है।

SSF क्या है?

SecureStamp Signal Framework: स्रोत, प्रमाणीकरण, चैनल, सामग्री, संदर्भ, कार्रवाई और verdict के संकेतों के लिए एक साझा भाषा।

SecureStamp MCP Server क्या है?

developer preview में एक दिशा, जिससे एजेंट संवेदनशील टूल कॉल से पहले Model Context Protocol के ज़रिए trust check पूछ सकें।

दस्तावेज़ और विनिर्देश

प्रोटोकॉल दस्तावेज़

विनिर्देश में Proof of Origin, Proof of Intent, SSF, Action Verdict, इंटीग्रेशन के बिंदु, receipts, ईमानदार सीमाएँ और एजेंटों के लिए MCP की दिशा शामिल है।

प्रोटोकॉल v0.1

खुला विनिर्देश

तकनीकी व्हाइटपेपर

भरोसे का मॉडल

API संदर्भ

REST एंडपॉइंट

विनिर्देश या प्रोटोकॉल के डिज़ाइन पर सवाल? protocol@securestamp.org

संपर्क

हमसे संपर्क करें

हर पता सीधे सही टीम तक जाता है। कोई टिकट सिस्टम नहीं — असली लोग।

info@securestamp.org

सामान्य जानकारी

SecureStamp, फ़ाउंडेशन, या शुरुआत कैसे करें — इनसे जुड़े सवाल।

nodes@securestamp.org

नोड आवेदन

फ़ेडरेटेड नेटवर्क में स्वीकृत नोड चलाने के लिए आवेदन करें।

protocol@securestamp.org

प्रोटोकॉल और तकनीकी

विनिर्देश से जुड़े सवाल, कार्यान्वयन की बारीकियाँ, प्रस्तावित बदलाव।

security@securestamp.org

सुरक्षा प्रकटीकरण

प्रोटोकॉल या इंफ़्रास्ट्रक्चर की कमज़ोरियों का ज़िम्मेदार प्रकटीकरण।

abuse@securestamp.org

दुरुपयोग और निरस्तीकरण

दुरुपयोग या समझौता किए गए स्टैम्प की सूचना दें, या आपात निरस्तीकरण माँगें।

foundation@securestamp.org

फ़ाउंडेशन और गवर्नेंस

साझेदारी, गवर्नेंस प्रस्ताव, संस्थागत सहयोग।

SecureStamp Foundation — AI एजेंट और MCP टूल के लिए Execution Authorization