CAPTCHA एक साधारण विचार है: आगंतुक के सामने एक ऐसा task रखें जिसे लोग हल कर सकें और machines नहीं, और जो पास हो उसे आगे जाने दें। वर्षों तक यह एक उचित समझौता था। लोगों ने कुछ सेकंड गंवाए, और सबसे खराब automation धीमी पड़ गई।
तीन चीज़ें बदलीं। Machines tasks हल करने में अच्छी हो गईं। लोग उन्हें हल करते-करते थक गए। और आगंतुकों का एक नया प्रकार आया: AI agents जो वास्तविक ग्राहकों की ओर से कार्य कर रहे हैं, और AI assistants के साथ काम करने वाले लोग। "क्या आप human हैं?" पूछने वाला test इनमें से किसी के लिए भी अच्छा जवाब नहीं देता।
Proof of Actor एक अलग दृष्टिकोण अपनाता है। हर आगंतुक का परीक्षण करने के बजाय, यह आपके application को बताता है कि कौन या क्या कार्य कर रहा है, निष्कर्ष के पीछे के साक्ष्य के साथ, और आपके code को तय करने देता है कि challenge की आवश्यकता है भी या नहीं।
संक्षिप्त संस्करण
| CAPTCHA | Proof of Actor | |
|---|---|---|
| मुख्य प्रश्न | क्या यह आगंतुक एक human test पास कर सकता है? | कौन या क्या कार्य कर रहा है, और evidence क्या है? |
| लागत कौन उठाता है | हर वह आगंतुक जो challenge देखता है | कोई नहीं; classification background में होती है |
| संभावित उत्तर | पास या फेल | Human, Human + AI, Agent या Unknown, साथ में एक basis |
| वैध AI agents | रोके जाते हैं, या test के चारों ओर काम करने के लिए मजबूर होते हैं | पहचाने जाते हैं, और सही अनुभव की ओर route किए जाते हैं |
| AI assistants का उपयोग करने वाले लोग | किसी भी अन्य आगंतुक की तरह व्यवहार किया जाता है | एक अलग class, Human + AI |
| अस्पष्ट traffic | वही test पास करना होता है | Unknown, एक fallback के साथ जिसे आप प्रति route चुनते हैं |
| यह कहाँ लागू होता है | वे pages जहां आप इसे रखते हैं | हर route जिसे आपका integration कवर करता है |
| install पर default behavior | दिखाई देने वाली challenge | Observation; जब तक आप policy नहीं जोड़ते, कुछ नहीं बदलता |
test बनाम evidence
CAPTCHA जानकारी का एक bit पैदा करता है: आगंतुक पास हुआ या फेल। यह नहीं बताता कि आगंतुक कौन था, क्या वह किसी assistant के साथ काम कर रहा था, या परिणाम पर आपको कितनी confidence रखनी चाहिए। और यह वह bit आगंतुक से काम करवाकर पैदा करता है।
Proof of Actor एक classification और उसका evidence basis देता है। एक Verified परिणाम का मतलब है कि एक जांची जा सकने वाली assertion मान्य की गई थी, जैसे किसी published key के विरुद्ध request signature की जाँच। एक Declared परिणाम का मतलब है कि किसी client या आपके अपने application ने उसे बताया। एक Inferred परिणाम को inference के रूप में labeled किया जाता है। Unknown का मतलब है कि evidence किसी निर्धारण का समर्थन नहीं करता। आपकी team हर परिणाम पढ़ सकती है और देख सकती है कि वह किस पर आधारित है, और आगंतुक को कुछ भी करने की आवश्यकता नहीं होती।
हर किसी को चुनौती देने की लागत
हर challenge आपके सर्वोत्तम users पर friction थोपता है ताकि आपके सबसे खराब users की गति कम हो सके। sign-up page पर, यह conversions की कीमत पर आता है। checkout पर, यह revenue की कीमत पर आता है। accessibility के स्तर पर, यह लोगों को पूरी तरह बाहर कर सकता है। teams यह लागत केवल इसलिए स्वीकार करती हैं क्योंकि उनके पास यह बेहतर signal नहीं होता कि दूसरी तरफ कौन है।
actor context के साथ, समझौता बदल जाता है। आप human-directed sessions के लिए सामान्य experience बनाए रख सकते हैं, जहां evidence मजबूत हो वहां challenge छोड़ सकते हैं, और उसे उन संकीर्ण मामलों के लिए reserve कर सकते हैं जहां वह अभी भी value जोड़ता है: उदाहरण के लिए, password change या किसी high-value action पर Unknown परिणाम। अधिकांश visitors को फिर कभी challenge नहीं दिखती।
वैध agents को puzzle नहीं, एक path चाहिए
CAPTCHA software को रोकने के लिए बनाया गया है। यह तब समझ में आता था जब आपकी pages पर आने वाला लगभग सारा software अवांछित था। अब ऐसा नहीं है।
आज एक assistant किसी ग्राहक के लिए आपके plans की तुलना कर सकता है, एक agent आपके app के माध्यम से meeting बुक कर सकता है, और एक AI client task पूरा करने के लिए आपके MCP server को call कर सकता है। उन्हें रोकना आपके ग्राहकों को रोकना है। लोगों के लिए बनाए गए pages और puzzles के माध्यम से उन्हें मजबूर करना brittle automation पैदा करता है जो हर redesign पर टूट जाती है।
Proof of Actor agents को पहचानता है, और signed requests के साथ यह सत्यापित कर सकता है कि उनके पीछे कौन-सी key और operator हैं। तब आपका application challenge से बेहतर कुछ कर सकता है: एक structured API serve करें, एक agent-friendly flow दें, या automation के लिए उपयुक्त rate limit लागू करें। AI agents को structured content देना guide दिखाती है कैसे।
एक verified identity permission के समान नहीं है। एक valid signature आपको बताता है कि किस key ने request पर sign किया; वह agent कोई action कर सकता है या नहीं, यह आपका authorization decision है। Proof of Actor इन दो प्रश्नों को अलग रखता है।
AI के साथ काम करने वाले लोग अभी भी आपके users हैं
एक व्यक्ति जो assistant की मदद से support message तैयार करता है, या AI सहायता के साथ form भरता है, वह एक customer है। एक human test उनके बारे में कुछ उपयोगी नहीं कहता: या तो वे पास हो जाते हैं, या उनका व्यवहार असामान्य दिखने के कारण उन्हें block कर दिया जाता है।
Proof of Actor उन्हें अपनी अलग class, Human + AI, देता है, जब assistance घोषित की जाती है या किसी supported integration के माध्यम से observable होती है। इससे आप AI-drafted submissions को सही team के लिए label कर सकते हैं, यह अध्ययन कर सकते हैं कि assisted users आपके product में कैसे आगे बढ़ते हैं, और उनके अनुभव को सहज रख सकते हैं। AI-assisted interaction glossary entry में और पढ़ें।
अनिश्चित मामलों को जानबूझकर संभालना
कुछ traffic हमेशा अस्पष्ट रहेगा। CAPTCHA इसे हर जगह एक ही तरीके से संभालता है: हर कोई test लेता है।
Proof of Actor Unknown को एक first-class परिणाम के रूप में लौटाता है, जिसे default रूप से कभी human नहीं माना जाता और malicious भी नहीं माना जाता। आप risk के अनुसार प्रति route fallback चुनते हैं:
- Public pages और documentation: allow करें, और standard experience बनाए रखें।
- Sign-up और contact forms: allow करें, अपनी सामान्य abuse controls के साथ।
- Account changes: अपना मौजूदा re-authentication flow बनाए रखें।
- High-impact actions: review की ओर route करें, या यदि आप फिर भी चाहते हैं तो यहां challenge लागू करें।
यहीं challenge अभी भी अपनी जगह कमा सकता है: एक sensitive route पर एक जानबूझकर चुना गया policy outcome, न कि हर आगंतुक पर एक toll।
निर्णय कहाँ रहता है
CAPTCHA widget उसी क्षण तय करता है जब वह दिखाया जाता है, उस page पर जहां आपने उसे रखा है, और केवल एक बार।
Proof of Actor के साथ, आपका application निर्णय लेता है, आपके integration द्वारा कवर किए गए हर route पर: server middleware, Next.js, edge, एक approved browser integration, एक generic HTTP API या आपका MCP server। Policies actor class और basis को साथ में उपयोग करती हैं: allow, adapt, challenge, review या rate-limit। वे आपके code में, आपके business logic के बाकी हिस्से के पास रहती हैं, और आप उन्हें page को redesign किए बिना बदल सकते हैं।
इसे चरणबद्ध तरीके से लागू करना
Proof of Actor observation mode में शुरू होता है। इसे install करने से आपके users को दिखाई देने वाली कोई चीज़ नहीं बदलती। blanket challenges से दूर जाने का एक समझदारी भरा path इस प्रकार दिखता है:
- Observe करें। अपने मौजूदा challenges को बनाए रखें और Proof of Actor जोड़ें। हर route पर actor mix और Unknown rate देखें।
- Compare करें। प्रत्येक challenged route के लिए देखें कि कितनी challenges human sessions, AI-assisted users और verified agents पर पड़ती हैं।
- Preview करें। ऐसा policy लिखें जो evidence मजबूत होने पर challenge को छोड़ दे और sensitive actions पर Unknown के लिए उसे बनाए रखे। वास्तविक traffic के विरुद्ध उसका प्रभाव preview करें।
- Enforce करें। नीति को एक समय में एक route पर चालू करें, documented fallback और rollback switch के साथ।
actor-aware policies को सुरक्षित रूप से लागू करने guide हर चरण को विस्तार से कवर करती है।
CAPTCHA कब फिर भी समझ में आता है
Challenges कुछ स्थानों पर अब भी उपयोगी उपकरण बने रहते हैं: किसी sensitive action के विरुद्ध अस्पष्ट traffic का burst, active abuse के तहत कोई form, या ऐसा route जहां आपके पास अभी तक कोई अन्य signal नहीं है। Proof of Actor आपसे यह उपकरण फेंक देने को नहीं कहता। यह आपको यह context देता है कि आप इसका उपयोग केवल वहीं करें जहां यह मदद करता है।
शुरुआत करें
Proof of Actor private beta में है। चयनित founding developer teams को सहमत usage limits के भीतर 12 महीनों तक मुफ्त access, और इसे बनाने वाली team से direct support मिल सकता है। early access के लिए आवेदन करें और हमें बताएं कि आप आज किन routes पर challenge करते हैं।