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

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

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

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

Email

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

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

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

एजेंट और API

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

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

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

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

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

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

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

निष्पादन परत

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

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

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

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

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

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

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

Source Envelope

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

Action Effect

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

Execution Grant

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

Execution Claim

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

Action Receipt

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

एजेंट और harness · Beta

एक पुनरुत्पादनीय प्रयोगशाला किसी कोडिंग एजेंट की घोषित सीमाओं को MCP, शेल, किसी स्क्रिप्ट या सीधे API कॉल के ज़रिए तोड़ने की कोशिश करती है, परिणाम को एजेंट के बाहर से देखती है और फिर वास्तविक कार्य को उसी प्रोफ़ाइल के तहत चलाती है। केवल वही सटीक बदलाव बाहर जाता है जिसकी समीक्षा हुई हो, Execution Guardian के ज़रिए।

पद्धति और उसकी सीमाएँ देखें
और गहराई में जाएँ · निष्पादन परत

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

एक्सेस यह नियंत्रित करता है कि सॉफ़्टवेयर कहाँ तक पहुँच सकता है। 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 को अधिलेखित करने के बजाय अमान्य कर देता है।

अधिकार

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

कोई ऑपरेशन किस अधिकार की माँग करता है, यह प्रोटोकॉल तय करता है। कॉल करने वाला उसे चुन नहीं सकता, मॉडल उसके पक्ष में तर्क नहीं दे सकता, और जिस अनुरोध को उसकी ज़रूरत है उसी के भीतर उसे घटाया नहीं जा सकता। 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 के दायरे से बाहर हैं।

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

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

For the single-grant chain, the protocol, the code and the verifier are complete and auditable today. Bounded delegation — one approval for several exact steps — is a separate profile still in design and simulation, and its known gaps are published. We do not call a connector stable until we have published evidence of 100 real executions against a live provider — including fault injection, replay rejection and proof that the credential could not have done more — bound to the exact commit that produced them. Production execution requires explicit opt-in and connector eligibility, and until a connector clears that gate its Guardian refuses to run outside sandbox mode. A trust product that asks you to take its word for it has already failed.

पैकेज

@securestamp/action-proof-verify

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

@securestamp/action-proof-verify
@securestamp/action-proof

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

@securestamp/action-proof
@securestamp/execution-guardian

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

@securestamp/execution-guardian
@securestamp/execution-guardian-mcp

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

@securestamp/execution-guardian-mcp

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

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

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

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

एजेंटों के लिए 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

Action Proof — Execution Authorization

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

Bounded delegation — Task Contract

The specification for a signed, revisable mandate: tenant, actors, Guardian, revision, steps, budget, validity window, policy and revocation — plus the deliberate exclusions and the known gaps of the local runtime, listed until they close.

एजेंट और harness प्रयोगशाला

HP0–HP2 प्रोफ़ाइल और LR0–LR2 प्रयोगशाला स्तर, परीक्षणों के पीछे विफलताओं के परिवार, मार्ग के अनुसार प्रमाण की प्रयोज्यता, Execution Guardian के ज़रिए सटीक निर्यात, स्टॉप और अभियान बजट — और वह जो प्रयोगशाला सिद्ध नहीं करती।

यहाँ लागू

Email

Gmail · Outlook · Apple Mail

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

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

एजेंट

MCP क्लाइंट और सहायक

APIs

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

Workflows

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

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

कहाँ से शुरू करें

चार रास्ते, इस पर निर्भर कि क्या करना है।

DNS, ईमेल हेडर, REST API या MCP सर्वर से भरोसा घोषित करें और उसकी जाँच करें। हर तरीके के साथ उसका उदाहरण और दस्तावेज़ है।

DNS TXT record

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

Email header

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

REST API

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

MCP Server

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

और गहराई में जाएँ · इंटीग्रेशन के बिंदु

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

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

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_..." 
})

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

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

उन डेवलपर्स और संस्थानों के लिए दस्तावेज़ जो स्वायत्त सॉफ़्टवेयर को काम सौंपते हैं। इसमें बताया गया है कि Break the Mandate से MCP सर्वर, एजेंट और हार्नेस को कैसे सुरक्षित करें — आपकी नेटिव फ़ाइलों पर Doctor, एक पुनरुत्पादनीय लैब, Exact Export और रन नियंत्रण; सटीक प्रभाव को अधिकृत करने के लिए Action Proof, ऐसी रसीदों के साथ जो ऑफ़लाइन सत्यापित होती हैं; Task Contract के साथ सीमित प्रत्यायोजन; संदेशों के लिए Proof of Origin, Proof of Intent, SSF और Action Verdict, पहले से प्रकाशित Gmail और Outlook प्लगइन के साथ; हर प्रोफ़ाइल का साक्ष्य-स्तर; और इन सबकी ईमानदार सीमाएँ।

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

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

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

भरोसे का मॉडल

API संदर्भ

REST एंडपॉइंट

Execution Governance

MCP · एजेंट · हार्नेस

Execution Authorization

Action Proof · delegation · evidence

ईमेल प्लगइन

Gmail और Outlook प्रकाशित · अनुमतियाँ

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

तकनीकी 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 पूछ सकें।

संपर्क

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

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

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