सत्यापित स्वचालन

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

जब कोई स्वचालित क्लाइंट अपने अनुरोधों पर हस्ताक्षर करता है, तो आपका application उस हस्ताक्षर की जाँच कर सकता है और कॉलर को उसी के अनुसार संभाल सकता है। Proof of Actor उस जाँच को एक स्पष्ट, रूट करने योग्य परिणाम में बदलता है.

Early Access प्राप्त करें यह कैसे काम करता है, देखें

द्वारा Toshendra Sharmaसंस्थापक और CEO, AgentCredia · Updated November 13, 2026

सभी स्वचालित traffic एक जैसा नहीं होता

स्वचालित clients हर minute आपकी application तक पहुँचते हैं: search crawlers, monitoring tools, partner integrations, किसी user के लिए pages fetch करने वाले AI assistants, और tasks पूरे करने वाले autonomous agents। वर्षों तक, अधिकांश applications के पास उन्हें अलग करने का एकमात्र तरीका user-agent header था, एक ऐसी string जिसे कोई भी client किसी भी value पर set कर सकता है।

यह application teams को कठिन स्थिति में डाल देता है। सभी automation को संदेह की दृष्टि से देखें, तो आप legitimate agents का experience खराब कर देते हैं जिन पर आपके customers निर्भर करते हैं। Header पर भरोसा करें, तो आप किसी भी व्यक्ति को खुद को किसी प्रसिद्ध crawler के रूप में प्रस्तुत करने का मौका दे देते हैं।

सत्यापित स्वचालित अनुरोध इस समीकरण को बदलते हैं। जब कोई स्वचालित client अपनी requests पर उस कुंजी के साथ हस्ताक्षर करता है जिसे उसने प्रकाशित किया है, तो आपका application signature की जाँच कर सकता है और cryptographically जान सकता है कि किस client ने अनुरोध पर हस्ताक्षर किया। Proof of Actor उस जाँच को एक एकल, सुसंगत actor result का हिस्सा बनाता है जिस पर आपका code route कर सकता है। यह जाँच क्या स्थापित करती है और क्या नहीं, इसे और करीब से समझने के लिए signed AI agent requests क्या साबित करती हैं पढ़ें।

अनुरोध हस्ताक्षर कैसे काम करते हैं

स्वचालित traffic के लिए उभरता हुआ दृष्टिकोण HTTP message signatures का उपयोग करता है, जिसे RFC 9421 में standardize किया गया है, जो बताता है कि HTTP message के components पर signatures कैसे बनाए, encode किए और verify किए जाएँ। Client प्रत्येक request के चुने हुए हिस्सों पर private key से हस्ताक्षर करता है और signature तथा उसके parameters को headers में शामिल करता है। वह संबंधित public key को उस identifier से जुड़े स्थान पर publish करता है जिसे वह नियंत्रित करता है, आम तौर पर उसका domain।

जब अनुरोध आता है, receiver published key को fetch या lookup करता है, signed content को reconstruct करता है, और signature की जाँच करता है। यदि वह validate हो जाता है, तो अनुरोध उसी key के holder द्वारा signed था। स्वचालित traffic के signing पर काम IETF Web Bot Auth working group में जारी है, जिसका charter crawlers और end users की ओर से कार्य करने वाले AI agents जैसे स्वचालित clients की cryptographic authentication को कवर करता है; Web Bot Auth glossary entry इसका सार प्रस्तुत करती है। signed AI agent requests क्या साबित करती हैं पर blog post एक verified request को end to end समझाती है, और APIs use case दिखाता है कि verification सबसे पहले कहाँ लाभ देता है।

signed agent requests को verify करना पर guide mechanics को विस्तार से कवर करता है, जिसमें timestamps, replay windows और key caching शामिल हैं।

एक सत्यापित हस्ताक्षर क्या साबित करता है, और क्या नहीं

सत्यापित स्वचालित अनुरोधों को ठीक से संभालने का सबसे महत्वपूर्ण भाग यही भेद है।

एक मान्य signature साबित करता है कि अनुरोध उस published identifier से जुड़ी कुंजी के साथ signed था। यदि कुंजी किसी operator के domain की है, तो अनुरोध उस operator की key रखने वाले client से आया था।

एक मान्य signature यह साबित नहीं करता:

agent को किसने निर्देश दिया, या क्या किसी व्यक्ति ने इस action के लिए अनुरोध किया था;
कि किसी व्यक्ति ने agent को authority delegated की;
operator के पीछे की वास्तविक कानूनी पहचान;
कि अनुरोधित action आपकी application में सुरक्षित है या अनुमति प्राप्त है।

ये अलग प्रश्न हैं। आपका application अपनी credentials, authorization model और policy के साथ उनका उत्तर देता है। Proof of Actor इन्हें जानबूझकर अलग रखता है, और Detection & Limitations वाला page स्पष्ट करता है कि evidence का हर प्रकार क्या स्थापित कर सकता है।

Proof of Actor सत्यापित स्वचालित अनुरोधों को कैसे संभालता है

Detect

आपका integration request context भेजता है, जिसमें कोई भी signature headers शामिल होते हैं, Proof of Actor को। Signatures को published keys के विरुद्ध checked किया जाता है। जो requests validate होती हैं, उन्हें verified आधार के साथ दर्ज किया जाता है। जो clients केवल अपना नाम बताते हैं, उन्हें declared के रूप में दर्ज किया जाता है। Behavioural patterns inferred के रूप में दर्ज होते हैं। जब पर्याप्त आधार नहीं होता, परिणाम Unknown होता है। जब तक cryptographic check पास न हो, कुछ भी verified नहीं माना जाता।

Understand

देखें कि कौन से verified operators आपकी application को call करते हैं, वे कौन से routes उपयोग करते हैं, कितनी बार करते हैं, और यह declared तथा unknown automation से कैसे तुलना करता है। हर result पर दिया गया evidence summary बताता है कि कौन सी key और कौन सा identifier शामिल था, ताकि आपकी team किसी भी request की जल्दी जाँच कर सके।

Route

अपनी policies में आधार का उपयोग करें। सामान्य patterns में शामिल हैं:

read-only routes पर verified agents को एक structured response दें, जैसे API या page का Markdown version।
जिन verified operators को आप पहचानते हैं, उनके लिए rate limits बढ़ाएँ, जबकि declared clients के लिए standard limits बनाए रखें।
signature चाहे जो कहे, हर write route पर अपनी मौजूदा authorization बनाए रखें।
हर route पर unsigned और Unknown callers के लिए एक स्पष्ट fallback define करें।

आपकी policies निर्णय लेती हैं; Proof of Actor evidence देता है।

user-agent header पर्याप्त क्यों नहीं है

User-agent strings declarations हैं। कोई भी client कोई भी value भेज सकता है, और user-agent spoofing के लिए कोई खास कौशल नहीं चाहिए। यही कारण है कि crawler operators अपनी स्वयं की checks प्रकाशित करते हैं: Google Googlebot को verify करने के लिए reverse और forward DNS lookups तथा published IP ranges document करता है, Bing Bingbot को verify करने के लिए DNS check document करता है, और OpenAI अपने प्रत्येक crawlers and user agents के लिए IP range files publish करता है। Proof of Actor user-agent claim को declared evidence मानता है, कभी verification नहीं। इसका मतलब है कि बिना मान्य signature के किसी प्रसिद्ध crawler होने का दावा करने वाला client declared या inferred basis के साथ report किया जाएगा, और आपकी policy उसे उस client से अलग तरह से संभाल सकती है जिसने अपनी पहचान साबित की है।

यही कारण है कि सत्यापित स्वचालित अनुरोध मूल्यवान हैं: वे आपको उन clients तक भरोसा बढ़ाने का एक भरोसेमंद तरीका देते हैं जो वह भरोसा अर्जित करते हैं, बिना उसे उन सभी तक बढ़ाए जो केवल उनका header कॉपी करते हैं।

पहचान evidence, credentials और authorization

किसी भी ऐसी application में जो स्वचालित clients को सेवा देती है, तीन layers साथ काम करती हैं:

Identity evidence: इस request पर किस client ने हस्ताक्षर किया? इसका उत्तर एक verified signature देता है।
Credentials: कौन सा account जिम्मेदार है? इसका उत्तर आपका API key, token या session देता है।
Authorization: क्या यह caller यह action कर सकता है? इसका उत्तर आपका permission model देता है।

Proof of Actor पहली layer को मजबूत करता है और उसे visible बनाता है। यह identity या delegation credentials जारी नहीं करता, और आपकी authorization की जगह नहीं लेता। Layers को अलग रखना ही आपको low-risk routes पर verified agents के लिए उदार और high-impact वाले मामलों में सावधान बनने देता है।

यह कहाँ fit होता है

Proof of Actor आपके gateway, authentication और rate limiting के साथ बैठता है। Integrations server-side middleware के रूप में, edge पर, आपके MCP server में या एक generic HTTP integration के माध्यम से चलते हैं, और हर founding team के साथ hands-on delivery दी जाती है। यदि आपका traffic मुख्यतः APIs और tools का है, तो APIs और MCP Servers use cases उन patterns को दिखाते हैं जो सबसे अधिक महत्वपूर्ण हैं।

Observation mode में शुरुआत करें

हर integration observation mode में शुरू होता है। Results को इस तरह दर्ज किया जाता है कि आपकी application किस तरह respond करती है, वह बदले नहीं, ताकि आप देख सकें कि आपके automated traffic का कितना हिस्सा verified है, कौन से operators signing कर रहे हैं, और unknown rate कहाँ सबसे अधिक है। Policies बाद में route by route आती हैं, जब evidence उनका समर्थन करता है। How It Works पूरे flow को समझाता है।

Practical details जो verification को भरोसेमंद बनाते हैं

Signature checking उतना ही अच्छा होता है जितने अच्छे उसके आसपास के details होते हैं। कुछ practices production में सत्यापित स्वचालित अनुरोधों को भरोसेमंद बनाती हैं।

Freshness जाँचें

RFC 9421 created और expires signature parameters define करता है, और signed requests आम तौर पर इन्हें ले जाते हैं। एक छोटे window के बाहर की signatures reject करें, ताकि captured request को बाद में replay न किया जा सके।

Keys को समझदारी से cache करें

हर request पर किसी operator की published keys fetch करना latency बढ़ाता है। उन्हें उचित अवधि के लिए cache करें और जब signature unknown key identifier के साथ fail हो तब refresh करें, ताकि key rotation false failures का कारण न बने।

Request के सही हिस्सों पर sign करें

केवल timestamp को cover करने वाला signature बहुत कम साबित करता है। जाँचें कि signed components में method, path और host शामिल हों, ताकि signature उसी request से जुड़ जाए जिसे आपकी application वास्तव में received करती है।

Evidence रिकॉर्ड करें

हर verified request के साथ key identifier, published identifier और result रखें। जब कुछ असामान्य होता है, तो आपकी team ठीक-ठीक देख सकती है कि किस client ने क्या और कब signed किया।

Proof of Actor इन checks को Detect step के हिस्से के रूप में संभालता है और outcome को उस basis के रूप में report करता है जिसे आपकी policies पढ़ सकती हैं, इसलिए आपका application code सरल बना रहता है।

Founding developer program में शामिल हों

Proof of Actor private beta में है। चुनी गई founding development teams को agreed usage limits के भीतर, हमारे engineers से direct integration support के साथ, 12 months तक मुफ्त access मिल सकता है।

यदि स्वचालित clients आपकी application तक पहुँचते हैं और आप verified वाले clients को अलग तरीके से संभालना चाहते हैं, तो early access के लिए आवेदन करें। हमें अपनी application और दिखने वाले automated callers के बारे में बताइए, और हम आपको दिखाएँगे कि Proof of Actor कैसे fit होता है।

Sources

RFC 9421: HTTP Message Signatures, IETF, February 2024.
Web Bot Auth (webbotauth) working group charter, IETF.
Verifying Googlebot and other Google crawlers, Google Search Central.
How to verify that Bingbot is Bingbot, Bing Webmaster Blog.
Overview of OpenAI crawlers, OpenAI.

डेवलपर्स के लिए

What your code receives

Every interaction resolves to one result record. Your application reads the class and the basis and applies its own policy.

Result record

{
  "route": "GET /api/v1/catalog",
  "class": "agent",
  "basis": "verified",
  "evidence": [
    { "signal": "http_message_signature", "result": "valid", "keyid": "assistant.example" },
    { "signal": "client_declaration", "value": "assistant.example" }
  ],
  "observed_at": "2026-11-13T10:42:07Z"
}

class: Human, Human + AI, Agent या Unknown।
basis: प्रमाण कितना मजबूत है: verified, declared, inferred या unknown।
evidence: result के पीछे के signals, ताकि आपकी team कारण देख सके।

observation mode में शुरू करें: results को अपने logs के पास record करें और जब तक आप कोई policy न चुनें, कुछ न बदलें। Node.js integration guide पढ़ें

अक्सर पूछे जाने वाले प्रश्न

सत्यापित स्वचालित अनुरोध क्या है?

यह किसी स्वचालित क्लाइंट का अनुरोध है जिसका क्रिप्टोग्राफ़िक हस्ताक्षर किसी ज्ञात पहचानकर्ता, जैसे ऑपरेटर के डोमेन, के लिए प्रकाशित कुंजी के विरुद्ध मान्य होता है। यह दिखाता है कि किस client ने अनुरोध पर हस्ताक्षर किया।

क्या सत्यापित हस्ताक्षर का मतलब है कि agent अधिकृत है?

नहीं। एक हस्ताक्षर अनुरोध को किसी कुंजी और उसके प्रकाशित पहचानकर्ता से जोड़ता है। वह client कोई action कर सकता है या नहीं, यह एक अलग authorization निर्णय है जिसे आपका application लेता है।

उन स्वचालित clients का क्या जिनके अनुरोध हस्ताक्षरित नहीं होते?

Proof of Actor फिर भी उन्हें वर्गीकृत करता है, जहाँ उपलब्ध हो वहाँ declared और inferred evidence का उपयोग करते हुए, और जब evidence पर्याप्त नहीं होता तो Unknown रिपोर्ट करता है। हर परिणाम अपना आधार बताता है।

क्या user-agent string किसी client को सत्यापित कर सकता है?

नहीं। user-agent strings को आसानी से नकल किया जा सकता है, इसलिए उन्हें declaration माना जाता है, verification नहीं। क्रिप्टोग्राफ़िक हस्ताक्षर ही किसी अनुरोध को verifiable बनाते हैं।

मैं शुरुआत कैसे करूँ?

जल्दी पहुँच के लिए आवेदन करें। Founding teams observation mode में शुरू करते हैं और चुनी गई teams को agreed usage limits के भीतर 12 months तक free मिल सकते हैं।

जानें कि आपका app कौन उपयोग कर रहा है।

founding developers के छोटे समूह के लिए private beta।

Early Access प्राप्त करें मूल्य निर्धारण देखें

क्या पहले बात करना पसंद करेंगे? founders से बात करें