दो श्रेणियाँ अब पर्याप्त नहीं हैं
कई वर्षों तक ट्रैफ़िक को दो हिस्सों में बाँटा गया: humans और bots। Humans को product मिलता था। Bots को block, rate-limit या ignore किया जाता था.
अब यह विभाजन पर्याप्त नहीं है। कुछ automated visitors ऐसे agents होते हैं जो वास्तविक customers की ओर से काम करते हैं: एक assistant जो plans की तुलना कर रहा है, एक agent जो आपके API के जरिए data खींच रहा है, एक tool जो काम पूरा करने के लिए आपके MCP server को call कर रहा है। AI providers अब इस तरह की user-initiated access को खुद भी document करते हैं: OpenAI कहता है कि उसका ChatGPT-User agent तब pages visit करता है जब कोई user ChatGPT से कोई सवाल पूछता है (OpenAI crawler documentation), और Anthropic इसी उद्देश्य के लिए Claude-User को सूचीबद्ध करता है (Anthropic crawler documentation). साथ ही, कुछ लोग AI के साथ कंधे से कंधा मिलाकर काम करते हैं, messages draft करते हैं, forms भरते हैं और अपने पास एक assistant रखते हुए products में navigate करते हैं। यह सब या तो human या bot में जबरन डालना दोनों दिशाओं में गलत decisions देता है। वैध agents block हो जाते हैं, और वास्तविक लोगों को चुनौती दी जाती है क्योंकि उनका behavior असामान्य दिखता है.
अच्छे decisions तक पहुँचने के लिए मानव और AI एजेंट ट्रैफ़िक में अंतर करना हो, तो आपको अधिक categories चाहिए और यह भी जानना होगा कि हर result पर कितना भरोसा किया जा सकता है। कैसे पता करें कि website traffic AI agents से आ रहा है वाला blog post उन signals को समझाता है जो इसे संभव बनाते हैं, और SaaS apps use case दिखाता है कि यह distinction product decisions को कहाँ बदलती है.
चार वर्ग, हर एक का सटीक अर्थ
Proof of Actor interactions को चार वर्गों में classify करता है। हर एक की एक परिभाषा और एक स्पष्ट सीमा होती है, ताकि आपकी team में कोई भी किसी result से उतना ही अर्थ निकाले जितना evidence support करता है। इस taxonomy के पीछे का reasoning जानने के लिए Human, AI-assisted or agent: a taxonomy for app traffic पढ़ें.
Human
supported observable signals मानव-निर्देशित interaction की ओर इशारा करते हैं। यह class इस बात से जुड़ी है कि interaction कौन निर्देशित कर रहा है, identity से नहीं। Human result यह verify नहीं करता कि व्यक्ति कौन है, और यह यह दावा भी नहीं करता कि कहीं भी AI का उपयोग नहीं हुआ.
Human + AI
AI सहायता declared थी, या एक supported integration के माध्यम से observed थी जो वास्तव में उसे देख सकती है। उदाहरणों में वह user शामिल है जो आपके अपने disclosure control के जरिए content को AI के साथ drafted के रूप में चिह्नित करता है, या आपका application यह रिपोर्ट करता है कि उसके built-in assistant ने किसी signed-in user के लिए कोई action किया। अधिक जानकारी AI-assisted interaction glossary entry में पढ़ें.
Agent
स्वचालित या agent-origin interaction, जिसे verifiable identity से support मिला हो, जैसे published key से validated एक valid request signature, या एक carefully qualified inference. Agent result यह बताता है कि कौन act कर रहा है। इसका मतलब यह नहीं है कि agent authorized है, safe है, या किसी व्यक्ति की valid delegation के साथ काम कर रहा है। autonomous agents के बारे में और पढ़ें.
Unknown
उपलब्ध evidence किसी reliable determination को support नहीं करता। Unknown एक ईमानदार और उपयोगी result है: यह दिखाता है कि आपकी coverage कहाँ समाप्त होती है, और यह आपकी policies को uncertain cases को accident से नहीं बल्कि जानबूझकर handle करने देता है.
हर class के साथ एक basis आता है
मानव और agent ट्रैफ़िक को अलग करना काम का सिर्फ आधा हिस्सा है। दूसरा आधा यह जानना है कि हर निष्कर्ष कितना मजबूत है। इसी वजह से हर Proof of Actor result के साथ एक basis होता है:
- Verified: एक जाँची जा सकने वाली assertion validated होती है, उदाहरण के लिए published key के against checked एक request signature.
- Declared: client या आपका application ने इसे बताया, उदाहरण के लिए कोई agent अपने बारे में स्वयं बताता है या कोई user AI सहायता का disclosure करता है.
- Inferred: behavioral या contextual signals से निकाला गया निष्कर्ष, जिसे हमेशा inference के रूप में label किया जाता है.
- Unknown: determination के लिए पर्याप्त evidence नहीं.
class और basis का यह संयोजन ही आपको सटीक rules बनाने देता है। एक verified agent और एक inferred agent दोनों agents हैं, लेकिन हो सकता है आप पहले वाले को structured API देना चाहें और दूसरे पर standard rate limit लागू करें। एक declared AI-assisted submission और एक human session दोनों सामान्य रूप से आगे बढ़ सकते हैं, एक ऐसे label के साथ जो आपकी support team की मदद करता है। पूरी taxonomy आपको Detection & Limitations में मिल जाएगी.
classification कैसे होती है
Proof of Actor हर interaction के लिए वही evidence-first path अपनाता है। पूरी व्याख्या How It Works पर उपलब्ध है.
वे signals जिन्हें आपका integration देख सकता है
- Request signatures automated clients से, जो अपने keys publish करते हैं, HTTP Message Signatures का उपयोग करते हुए जैसा कि RFC 9421 में परिभाषित है। IETF Web Bot Auth working group को इसी तरीके से automated clients को authenticate करने के standard बनाने का दायित्व दिया गया है.
- Declarations clients से जो अपनी पहचान बताते हैं, जैसे AI crawlers और fetchers के documented user agents, और आपके अपने application से जब उसे पता होता है कि AI सहायता शामिल है.
- Request context जो किसी server-side integration को उपलब्ध हो, जैसे headers और protocol details.
- Interaction signals किसी approved browser integration से उन pages पर जहाँ वह चलता है.
signals से result तक
Signals की जाँच की जाती है, basis के अनुसार label किया जाता है और उन्हें combine किया जाता है। मजबूत verified evidence एक confident result देता है। कमजोर या परस्पर विरोधी evidence एक qualified inference या Unknown देता है। कोई timeout या missing signal कभी Human result नहीं बनता। output एक class, एक basis और एक evidence summary होता है जिसे आपकी team का कोई भी सदस्य पढ़ सकता है.
ट्रैफ़िक अलग हो जाने के बाद आप क्या कर सकते हैं
Proof of Actor तीन क्षमताओं के इर्द-गिर्द संगठित है: Detect, Understand और Route.
हर interaction के पीछे के actor को Detect करें
हर context में उपलब्ध signals इकट्ठा करें और verified assertions को inferences से अलग करें। Unknown को visible रखें.
समझें कि हर actor आपके product का उपयोग कैसे करता है
route के अनुसार और समय के साथ human, AI-assisted, agent और unknown activity का mix देखें। किसी भी result को खोलकर देखें कि क्या ज्ञात है और क्या नहीं। उन routes को पहचानें जहाँ agents केंद्रित हैं और उन workflows को जहाँ AI सहायता सामान्य है.
हर actor को सही experience पर Route करें
जब evidence उन्हें support करे, तब अपनी policies लागू करें। एक public website पर websites use case दिखाता है कि ये choices real routes पर कैसे लागू होती हैं:
- verified agents को human-shaped pages के बजाय structured response या API दें.
- human-directed sessions के लिए standard experience बनाए रखें.
- AI-assisted submissions को label करें ताकि सही team उन्हें संभाले.
- संवेदनशील actions पर stronger credentials माँगें जब आपकी अपनी conditions इसकी माँग करें.
- हर route पर Unknown के लिए एक explicit fallback चुनें, जैसे public pages को अनुमति देना और account changes पर मौजूदा checks बनाए रखना.
rolling out actor-aware policies safely वाला guide बताता है कि observation से enforcement तक एक बार में एक route कैसे ले जाया जाए.
यह आपके users के लिए क्यों महत्वपूर्ण है
इसे सही करना हर उस व्यक्ति के लिए अच्छा है जो आपका application उपयोग करता है.
लोगों को अधिक सहज experience मिलता है क्योंकि उन्हें किसी vague score की ताकत पर challenge नहीं किया जाता। AI के साथ काम करने वाले लोगों को उन workflows में disclosed assistance के लिए support मिलता है जहाँ यह fit बैठता है। वैध agents को अपना काम करने का एक reliable, structured तरीका मिलता है, जिससे scraping और आपके interface पर load कम होता है। आपकी team को explainable decisions मिलते हैं, इसलिए support conversations, incident reviews और policy changes अनुमान के बजाय evidence पर आधारित होते हैं.
login actor नहीं है
सबसे आम भ्रम के स्रोतों में से एक account स्वयं है। signed-in session आपको बताता है कि कौन सा account use में है। यह नहीं बताता कि current interaction कौन निर्देशित कर रहा है। वही account सुबह settings में क्लिक करने वाले उसके owner द्वारा, दोपहर में report export करने के लिए owner द्वारा माँगे गए assistant द्वारा, और शाम को API key के जरिए काम करने वाले agent द्वारा उपयोग किया जा सकता है.
इन तीनों को एक जैसा मानना दोनों दिशाओं में समस्याएँ पैदा करता है। यदि account पर हर request को owner की ही request मान लिया जाए, तो एक agent उन workflows तक पहुँच सकता है जो किसी person के लिए बनाए गए थे। यदि हर असामान्य request को attack मान लिया जाए, तो owner के अपने tools block हो जाते हैं। actor को account से अलग करने से आपका application authentication और authorization को बिल्कुल वैसे ही रख सकता है जैसे वे हैं, और इस समय कौन act कर रहा है, इस बारे में गायब context जोड़ सकता है। यही context agents को structured access देने को संभव बनाता है, बिना human-only workflows को उनके लिए खोलने के.
observation mode में शुरू करें
हर deployment observation mode से शुरू होता है। Proof of Actor परिणाम record करता है जबकि आपका application बिल्कुल पहले की तरह respond करता है। आपकी team human, AI-assisted, agent और unknown activity का baseline बनाती है, उसे उन outcomes से तुलना करती है जिन्हें आप पहले से जानते हैं, और एक भी rule बदलने से पहले किसी भी false positive की review करती है। जब कोई policy तैयार हो जाती है, तब आप उसे एक workflow के लिए enable करते हैं और वहीं से विस्तार करते हैं.
founding developer program से जुड़ें
Proof of Actor कुछ application teams के एक छोटे समूह के साथ private beta में है। चुने गए founding developers agreed usage limits के भीतर up to 12 months की free access प्राप्त कर सकते हैं, hands-on feedback के बदले। आपको हमारे engineers से direct integration support, capabilities तक early access, और priorities पर influence मिलता है.
यदि आपको अपने application में मानव और AI एजेंट ट्रैफ़िक में अंतर करना है, तो early access के लिए apply करें और हमें उस interaction के बारे में बताएं जिसे आप सबसे अधिक समझना चाहते हैं.
Proof of Actor देखें, यह कैसे काम करता है पढ़ें, या बिल्कुल देखें कि evidence क्या स्थापित कर सकता है.
स्रोत
- 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.