अब आपकी website पर visitors के एक से अधिक प्रकार हैं
Web के अधिकांश इतिहास में, एक website एक सरल मॉडल मान सकती थी: एक व्यक्ति browser खोलता है, इधर-उधर click करता है, और शायद sign in करता है। Analytics, rate limits, onboarding flows और security checks सभी उसी व्यक्ति को ध्यान में रखकर बनाए गए थे।
अब वह model वास्तविक traffic का वर्णन नहीं करता। आज एक ही website उन लोगों को सेवा देती है जो अपने आप browse करते हैं, उन लोगों को जो किसी AI assistant से किसी चीज़ का summary बनाने या उसे उनके लिए भरने के लिए कहते हैं, उन autonomous agents को जो किसी और की ओर से pages पढ़ते हैं और endpoints call करते हैं, और crawlers तथा scripts के एक लंबे tail को। AI providers इन visitors में से कई को स्वयं document करते हैं: उदाहरण के लिए OpenAI अपने search crawler, training crawler और उस fetcher के लिए अलग-अलग user agents प्रकाशित करता है जो तब pages visit करता है जब कोई ChatGPT user question पूछता है (OpenAI crawler documentation), और Anthropic भी ClaudeBot, Claude-User और Claude-SearchBot के लिए ऐसा ही करता है (Anthropic crawler documentation). इनमें से कुछ visitors welcome हैं। कुछ को अलग experience की आवश्यकता होती है। कुछ को कोई sensitive action करने से पहले करीब से देखने की जरूरत होती है।
चुनौती यह है कि इनमें से अधिकतर interactions पहली नज़र में समान दिखते हैं। Login आपको बताता है कि कौन-सा account उपयोग में है। यह नहीं बताता कि कोई व्यक्ति click कर रहा है, कोई assistant उस session के माध्यम से acting कर रहा है, या कोई automated client आपके pricing page को किसी दूसरे स्थान के user के लिए पढ़ रहा है। वेबसाइटों के लिए AI agent detection इस gap को evidence के साथ बंद करने के बारे में है, ताकि आपकी team traffic के सभी प्रकार को एक जैसा मानने के बजाय हर actor प्रकार पर उचित प्रतिक्रिया दे सके। शामिल signals के practical walkthrough के लिए कैसे पता करें कि website traffic AI agents से आता है पढ़ें, और production site पर यह कैसा दिखता है, इसके लिए websites use case देखें।
एक single bot score क्यों पर्याप्त नहीं है
कई tools इस प्रश्न का उत्तर एक number से देते हैं: bot score, risk score, या एक percentage जो यह दावा करती है कि कोई visitor कितना human है। इसका appeal स्पष्ट है। एक number को rule में डालना आसान होता है।
समस्या यह है कि एक single number reasoning को छिपा देता है। जब कोई score कहता है कि session शायद automated है, तो आपकी team यह नहीं देख सकती कि वह निष्कर्ष किसी verified signature पर आधारित है, किसी user-agent string पर जो कोई भी copy कर सकता है, या किसी ऐसे pattern पर जो तेज़ typing करने वाले human से भी मेल खाता है। जब वह score block या challenge को drive करता है, तो आप उसकी हर गलती उसके explanation के बिना अपने ऊपर ले लेते हैं, चाहे ग्राहक हो, colleague हो या auditor।
Proof of Actor एक अलग दृष्टिकोण अपनाता है। हर result चार स्पष्ट classes में से एक होता है, जैसा कि Human, AI-assisted or agent: a taxonomy for app traffic में समझाया गया है, और हर result बताता है कि वह किस पर आधारित है। आप conclusion और evidence को साथ देखते हैं, जिसका अर्थ है कि आप मजबूत results पर भरोसा कर सकते हैं, कमजोर results पर सवाल उठा सकते हैं, और evidence की quality के अनुरूप policies बना सकते हैं।
अपनी website पर AI agents का पता चार चरणों में कैसे लगाएँ
आप अपनी website पर AI agents का पता उन tools से लगाना शुरू कर सकते हैं जो आपके पास पहले से हैं। ये चार चरण vendor-neutral हैं और तब भी काम करते हैं चाहे आप Proof of Actor उपयोग करें या नहीं; कैसे पता करें कि website traffic AI agents से आता है वाला blog post इन्हें और विस्तार से समझाता है।
- उन agents की सूची बनाइए जो स्वयं को घोषित करते हैं। अपने server या CDN logs में उन user agents को खोजें जिन्हें AI providers प्रकाशित करते हैं। OpenAI OAI-SearchBot, GPTBot और ChatGPT-User को document करता है, और बताता है कि ChatGPT-User pages तब visit करता है जब कोई user ChatGPT से question पूछता है, न कि automatically crawl करने के लिए। Anthropic ClaudeBot, Claude-User और Claude-SearchBot को document करता है। इससे आपको route के अनुसार agent traffic की एक पहली, declared तस्वीर मिलती है।
- String पर भरोसा करने के बजाय claims को verify करें। User agent self-reported होता है और उसे copy करना आसान है। इसे operator की अपनी verification method के विरुद्ध जांचें: Google reverse DNS lookup के बाद forward DNS lookup, तथा published IP range files का वर्णन करता है, Googlebot के लिए (Google: verifying Googlebot); Bing Bingbot के लिए वही reverse और forward DNS check बताता है (Bing: verifying Bingbot); OpenAI अपने प्रत्येक user agent के लिए IP range files प्रकाशित करता है। जहाँ client अपने requests पर HTTP Message Signatures से sign करता है, जिसे RFC 9421 में defined किया गया है, वहाँ signature को operator की published key से जांचें।
- हर result को उसके evidence के साथ label करें, और Unknown को बनाए रखें। यह record करें कि हर conclusion verified है, declared है या inferred है। जो traffic किसी verified या declared agent से मेल नहीं खाता और human जैसा कोई स्पष्ट pattern नहीं दिखाता, उसे Unknown label किया जाना चाहिए, human या bot में जबरन नहीं डाला जाना चाहिए। यही वह चरण है जो एक उपयोगी report को केवल एक अनुमान से अलग करता है।
- कार्रवाई करने से पहले route के अनुसार observe करें। कुछ हफ्तों के लिए results को route और workflow के आधार पर तोड़ें: public content, signup, account settings, APIs। उसके बाद ही उस route के लिए एक संकीर्ण policy लिखें जहाँ actor context सबसे अधिक मायने रखता है, और Unknown के लिए एक स्पष्ट fallback रखें।
Proof of Actor इन चरणों को आपके application के भीतर automate करता है: यह उन signals को इकट्ठा करता है जिन्हें आपकी integration देख सकती है, आधार के साथ class लौटाता है, route के अनुसार Unknown को track करता है, और policy आपके code पर छोड़ देता है।
Proof of Actor वेबसाइटों पर AI agents का पता कैसे लगाता है
Proof of Actor एक सरल path के चारों ओर बनाया गया है: वे signals जिन्हें आपकी integration observe कर सकती है, एक स्पष्ट basis वाली classification, और एक decision जो आपके हाथ में रहता है। आप पूरा flow How It Works page पर पढ़ सकते हैं। यहाँ संक्षिप्त version है।
आपकी integration से signals
हर integration वही देखती है जिसकी अनुमति उसका context देता है। एक server-side integration request context, protocol details और, जब client इसका support करता है, request signature देखती है। एक browser integration उन pages पर interaction signals देखती है जहाँ वह चलती है। एक application अपनी declarations भी record कर सकता है, जैसे कोई user AI assistance के साथ content को drafted चिह्नित करे, या कोई agent client अपना नाम बताए।
Proof of Actor उसी evidence के साथ काम करता है जो वास्तव में मौजूद है। यह उन चीज़ों को देखने का दिखावा नहीं करता जिन्हें आपकी website observe नहीं कर सकती।
चार classes जिनका विशिष्ट अर्थ है
हर interaction इन चार classes में से एक में आता है:
- Human: observable signals human-directed interaction का संकेत देते हैं.
- Human + AI: AI assistance घोषित की गई थी, या एक supported integration के माध्यम से observe की गई थी जो इसे देख सकती है.
- Agent: automated या agent-origin interaction, जो verifiable identity या सावधानी से qualified inference द्वारा समर्थित है.
- Unknown: उपलब्ध evidence reliable determination का support नहीं करता.
हर class के साथ एक स्पष्ट definition और एक स्पष्ट limit आती है। Human result verified identity नहीं है। Agent result यह statement नहीं है कि agent authorized है। Unknown result एक आरोप नहीं है। आप पूरी taxonomy Detection & Limitations page पर पढ़ सकते हैं।
हर result पर एक basis
Class के साथ-साथ, हर result अपनी basis भी रखता है: verified, declared, inferred या unknown। एक request जो published key से valid signature लेकर आती है, उस check के लिए verified होती है। जो client खुद को agent के रूप में नामित करता है, उसने उसे declared किया है। ऐसा behavior pattern जो automation से मेल खाता है, एक inference है। यही अंतर आपकी policies को precise बनाता है। एक verified signed agent और एक read-only route तथा एक self-declared client और एक account settings page को एक जैसे handle नहीं किया जाना चाहिए, और Proof of Actor के साथ ऐसा करना आवश्यक नहीं है। evidence basis glossary entry हर एक को और विस्तार से समझाती है।
आपकी team को क्या मिलता है: Detect, Understand, Route
Proof of Actor एक ही product है जिसकी तीन capabilities साथ मिलकर काम करती हैं।
Detect
उन actor signals को इकट्ठा करें जो आपकी integration के लिए उपलब्ध हैं और verified assertions को behavioral inferences से अलग करें। Unknown traffic guess में मिलाए जाने के बजाय अपनी अलग category के रूप में visible रहता है। आप हमेशा जानते हैं कि किन interactions के बारे में आप confidence के साथ बोल सकते हैं और किन्हें अधिक evidence की आवश्यकता है।
Understand
अपने AI agent traffic को context में देखें। route और समय के अनुसार interaction types explore करें, human, AI-assisted, agent और unknown activity में trends का पालन करें, और किसी भी classification को खोलकर देखें कि क्या ज्ञात है, क्या ज्ञात नहीं है, और result किस पर आधारित है। यही वह जगह है जहाँ product, platform और security teams को यह समझने की एक साझा, explainable तस्वीर मिलती है कि website का उपयोग कौन कर रहा है।
Route
विशिष्ट interactions को allow, adapt, challenge, review या limit करने के लिए अपनी policies का उपयोग करें। आपकी documentation पढ़ने वाले verified agent को एक structured response दें। human-directed sessions के लिए standard experience बनाए रखें। जब आपकी अपनी conditions मांगें, तो sensitive account change पर एक stronger check के लिए कहें। Unknown results और timeouts के लिए route by route एक explicit fallback चुनें। Enforcement हमेशा आपके application में होती है, उन policies के तहत जिन्हें आपकी team पुष्टि करती है।
आपकी website में fit होने के लिए बनाया गया है, उसे replace करने के लिए नहीं
Proof of Actor उन tools के साथ-साथ चलता है जिन्हें आप पहले से चलाते हैं। यह आपकी authentication, आपके authorization model या आपके मौजूदा abuse controls को replace नहीं करता। यह उनमें actor context जोड़ता है।
एक typical website integration उन routes से शुरू होती है जहाँ actor context सबसे महत्वपूर्ण है: public content जिसे agents भारी मात्रा में पढ़ते हैं, signup और onboarding flows, account settings और अन्य sensitive actions, और कोई भी API जो site को power करती है। Founding teams हमारे engineers के साथ मिलकर उन routes को चुनते हैं, scope में signals पर सहमत होते हैं, और code ship होने से पहले data handling की पुष्टि करते हैं।
क्योंकि decision layer आपके code में रहता है, आप experience पर नियंत्रण बनाए रखते हैं। आप rule changes से पहले हफ्तों तक internal dashboard में results दिखा सकते हैं, फिर एक route के लिए एक narrow policy चालू कर सकते हैं, और फिर trust बढ़ने पर विस्तार कर सकते हैं। unknown traffic handling वाला guide उन शुरुआती rules को design करने का तरीका बताता है।
observation mode में शुरू करें
AI agent detection से value पाने का सबसे तेज़ तरीका है पहले देखना, ब्लॉक करना नहीं। observation mode में, Proof of Actor results record करता है जबकि आपकी website बिल्कुल वैसे ही जवाब देती है जैसे यह उसके बिना देती। फिर आपकी team classifications की तुलना उन outcomes से कर सकती है जिन्हें आप पहले से समझते हैं: support tickets, known integrations, internal tools, और वे crawlers जिन्हें आप पहले से पहचानते हैं।
यह enforcement से पहले आपको तीन चीज़ें देता है:
- एक baseline. आपके traffic का कितना हिस्सा human-directed, AI-assisted, agent-driven या unknown है, route के अनुसार.
- evidence में confidence. आपकी website पर कौन-से signals मजबूत हैं और coverage कहाँ बढ़ाने की आवश्यकता है.
- बेहतर policies. वास्तविक patterns पर आधारित rules, assumptions पर नहीं, और false positives की समीक्षा किसी पर असर पड़ने से पहले की जाती है.
जब कोई policy तैयार हो जाती है, आप उसे उसी specific workflow के लिए enable करते हैं जिसके लिए उसे design किया गया था, और आप किसी भी समय उसे adjust करने की क्षमता बनाए रखते हैं।
opaque scores की तुलना में evidence-backed detection क्यों बेहतर है
Websites पहले से ही agents, assistants और AI के साथ काम करने वाले लोगों को side by side सेवा देती हैं। जो teams इसे अच्छी तरह संभालती हैं, वे सबसे आक्रामक filters वाली नहीं होंगी। वे वे होंगी जो अपने decisions समझा सकें।
Evidence-backed results आपको वह explanation देते हैं। जब कोई support agent पूछता है कि किसी user को extra verification step क्यों दिखा, तो आप evidence और लागू policy की ओर इशारा कर सकते हैं। जब कोई agent operator पूछता है कि उसकी signed requests को structured response क्यों मिला, तो आप verified basis दिखा सकते हैं। जब evidence कमज़ोर होता है, result Unknown कहता है, और आपका fallback उसे उस तरीके से handle करता है जिसे आपने जानबूझकर चुना था।
यह approach web के साथ भी scale करती है। जैसे-जैसे अधिक agent operators अपनी requests sign करते हैं और IETF Web Bot Auth working group जैसे standards work, जो automated clients के लिए cryptographic authentication standardize करने के लिए chartered है, HTTP message signatures पर build करता है, आपका अधिक traffic inferred या unknown से verified की ओर जाता है, और आपकी policies बिना rewrite किए अधिक precise हो जाती हैं।
founding developer program से जुड़ें
Proof of Actor कुछ application teams के एक छोटे समूह के साथ private beta में है। चुने गए founding developers को agreed usage limits के भीतर up to 12 months का free access मिल सकता है, hands-on product feedback के बदले में। आपको हमारे engineers से direct integration support, capabilities उपलब्ध होते ही early access, और हम आगे क्या build करते हैं उस पर वास्तविक influence मिलता है।
यदि आपकी website लोगों, AI-assisted users और agents को सेवा देती है, और आप यह जानना चाहते हैं कि आगे क्या होगा यह तय करने से पहले इसका उपयोग कौन कर रहा है, तो early access के लिए apply करें। हमें अपनी website और उस interaction के बारे में बताइए जिसे आप सबसे अधिक समझना चाहते हैं, और हम समीक्षा करेंगे कि क्या यह current beta के लिए उपयुक्त है।
पहले details देखना चाहते हैं? Proof of Actor explore करें, how it works पढ़ें, या ठीक से review करें कि evidence क्या स्थापित कर सकता है और क्या नहीं।
Sources
- RFC 9421: HTTP Message Signatures, IETF, February 2024.
- Web Bot Auth (webbotauth) working group charter, IETF.
- Overview of OpenAI crawlers, OpenAI.
- Does Anthropic crawl data from the web, and how can site owners block the crawler?, Anthropic.
- Verifying Googlebot and other Google crawlers, Google Search Central.
- How to verify that Bingbot is Bingbot, Bing Webmaster Blog.