CAPTCHA ही एक सोपी कल्पना आहे: visitor समोर असा task ठेवा जो लोक सोडवू शकतात आणि machines नाही, आणि जो पास होतो त्याला पुढे जाऊ द्या. अनेक वर्षे हा एक योग्य तडजोडीचा मार्ग होता. लोकांनी काही सेकंद गमावले, आणि सर्वात वाईट automation मंदावले.
तीन गोष्टी बदलल्या. Machines त्या tasks सोडवण्यात चांगल्या झाल्या. लोकांना त्या सोडवणे कंटाळवाणे वाटू लागले. आणि visitor चा एक नवा प्रकार आला: खऱ्या customers साठी कृती करणारे AI agents, आणि AI सहाय्यकांसोबत काम करणारे लोक. "तुम्ही मानव आहात का?" असा प्रश्न विचारणाऱ्या test कडे यापैकी कोणासाठीही चांगले उत्तर नाही.
Proof of Actor वेगळा दृष्टिकोन घेते. प्रत्येक visitor ची चाचणी घेण्याऐवजी, ते तुमच्या application ला निष्कर्षामागील evidence सह कोण किंवा काय कृती करत आहे ते सांगते, आणि challenge आवश्यक आहे की नाही हे ठरवण्याचा निर्णय तुमच्या code ला देते.
संक्षिप्त रूप
| CAPTCHA | Proof of Actor | |
|---|---|---|
| मुख्य प्रश्न | हा visitor human test पास करू शकतो का? | कोण किंवा काय कृती करत आहे, आणि evidence काय आहे? |
| खर्च कोण उचलतो | challenge पाहणारा प्रत्येक visitor | कोणीही नाही; classification पार्श्वभूमीत होते |
| शक्य उत्तरे | Pass किंवा fail | Human, Human + AI, Agent किंवा Unknown, तसेच एक basis |
| legitimate AI agents | थांबवले जातात, किंवा test भोवती मार्ग काढायला भाग पाडले जातात | ओळखले जातात, आणि योग्य अनुभवाकडे route केले जातात |
| AI सहाय्यक वापरणारे लोक | इतर कोणत्याही visitor प्रमाणे हाताळले जातात | एक वेगळी class, Human + AI |
| अस्पष्ट traffic | तोच test पास करावा लागतो | Unknown, route नुसार तुम्ही निवडलेला fallback |
| कुठे लागू होते | तुम्ही जिथे ठेवता ती पृष्ठे | तुमचा integration ज्या प्रत्येक route ला कव्हर करतो तो सर्व |
| install केल्यावर default वर्तन | Visible challenge | Observation; जोपर्यंत तुम्ही policy जोडत नाही तोपर्यंत काहीही बदलत नाही |
test विरुद्ध evidence
CAPTCHA एकच माहितीची bit देते: visitor पास झाला की अपयशी ठरला. visitor कोण होता, तो सहाय्यकाशी काम करत होता का, किंवा परिणामाबद्दल तुम्ही किती confident असावे हे ती सांगत नाही. आणि ती माहिती visitor कडून काम करून घेऊन तयार करते.
Proof of Actor एक classification आणि त्याचा evidence basis देते. Verified result म्हणजे तपासता येणारे assertion validate झाले, जसे की प्रकाशित key विरुद्ध तपासलेला request signature. Declared result म्हणजे client किंवा तुमच्या own application ने ते जाहीर केले. Inferred result ला inference म्हणून label केले जाते. Unknown म्हणजे evidence ठरवण्यासाठी पुरेसा नाही. तुमची team प्रत्येक result वाचू शकते आणि तो कशावर आधारलेला आहे ते पाहू शकते, आणि visitor ला काहीही करावे लागत नाही.
सर्वांची challenge घेण्याची किंमत
प्रत्येक challenge म्हणजे तुमच्या सर्वोत्तम users वर ठेवलेला friction, ज्यामुळे तुमच्या सर्वात वाईट ones चा वेग कमी होतो. sign-up page वर यामुळे conversions कमी होतात. checkout वर यामुळे revenue कमी होतो. accessibility च्या दृष्टीने, यामुळे काही लोक पूर्णपणे बाहेर पडू शकतात. Teams ही किंमत स्वीकारतात कारण दुसऱ्या बाजूला कोण आहे याचा त्यांच्याकडे चांगला signal नसतो.
Actor context मुळे हा trade बदलतो. human-directed sessions साठी तुम्ही normal experience ठेवू शकता, evidence मजबूत असेल तिथे challenge टाळू शकता, आणि फक्त जिथे तो अजूनही मूल्य देतो तिथेच तो राखू शकता: उदाहरणार्थ, password change किंवा उच्च-मूल्य action वर Unknown result. बहुतेक visitors ना पुन्हा challenge दिसत नाही.
legitimate agents ना puzzle नव्हे तर path हवा असतो
CAPTCHA software थांबवण्यासाठी तयार केले आहे. तुमच्या pages ला भेट देणारे जवळजवळ सर्व software अवांछित असताना ते अर्थपूर्ण होते. आता ते तसं राहिलेले नाही.
आज एक assistant ग्राहकासाठी तुमचे plans compare करू शकतो, एक agent तुमच्या app मधून meeting book करू शकतो, आणि एक AI client task पूर्ण करण्यासाठी तुमच्या MCP server ला call करू शकतो. त्यांना थांबवल्यास तुमचे customers थांबतात. लोकांसाठी बनवलेल्या pages आणि puzzles मधून त्यांना जबरदस्तीने नेल्यास brittle automation तयार होते, जे प्रत्येक redesign वर तुटते.
Proof of Actor agents ओळखते, आणि signed requests सह ते त्यांच्या मागे कोणते key आणि operator आहेत ते verify करू शकते. त्यानंतर तुमचे application challenge पेक्षा चांगले काही करू शकते: structured API serve करणे, agent-friendly flow देणे, किंवा automation साठी योग्य असा rate limit लागू करणे. AI agents ना structured content देणे ही guide हे कसे करायचे ते दाखवते.
Verified identity म्हणजे permission सारखीच गोष्ट नाही. वैध 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 मधून दिसून आल्यावर report केली जाते. यामुळे तुम्ही AI-drafted submissions योग्य team साठी label करू शकता, assisted users तुमच्या product मधून कसे जातात ते अभ्यासू शकता, आणि त्यांचा अनुभव सुरळीत ठेवू शकता. अधिक माहितीसाठी AI-assisted interaction glossary entry पहा.
अनिश्चित cases जाणीवपूर्वक हाताळणे
काही traffic नेहमीच अस्पष्ट असेल. CAPTCHA सर्व ठिकाणी तेच करते: सर्वांनाच test द्यावा लागतो.
Proof of Actor Unknown ला first-class result म्हणून परत करते, default ने कधीच human म्हणून आणि malicious म्हणूनही कधीच treat करत नाही. 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 ला अजूनही स्थान मिळू शकते: संवेदनशील route वर एक जाणीवपूर्वक policy outcome म्हणून, प्रत्येक visitor वर लादलेला 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 पासून दूर जाण्याचा योग्य मार्ग असा दिसतो:
- 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 वर policy सुरू करा, documented fallback आणि rollback switch सह.
actor-aware policies safely रोल out करणे ही guide प्रत्येक टप्पा तपशीलात समाविष्ट करते.
CAPTCHA अजूनही केव्हा अर्थपूर्ण ठरते
काही ठिकाणी challenges अजूनही उपयुक्त tool राहतात: संवेदनशील action वर अस्पष्ट traffic चा अचानक वाढलेला भार, सक्रिय abuse असलेला form, किंवा असा route जिथे तुमच्याकडे अजून दुसरा signal नाही. Proof of Actor हा tool टाकून देण्यास सांगत नाही. तो तो फक्त जिथे मदत करतो तिथे वापरण्यासाठी context देतो.
सुरुवात करा
Proof of Actor private beta मध्ये आहे. निवडलेल्या founding developer teams ना ठरलेल्या usage limits अंतर्गत 12 months पर्यंत मोफत access मिळू शकतो, आणि ते तयार करणाऱ्या team कडून थेट support मिळेल. early access साठी apply करा आणि आज तुम्ही कोणत्या routes वर challenge देता ते आम्हाला सांगा.