मानव विरुद्ध एजेंट ट्रॅफिक

human, AI-assisted आणि agent ट्रॅफिक वेगळा ओळखा

प्रत्येक interaction ला स्पष्ट class आणि स्पष्ट आधार द्या, म्हणजे तुमचे application people, people working with AI आणि autonomous agents यांना प्रत्येकाच्या अपेक्षेनुसार सेवा देऊ शकेल.

लवकर प्रवेश मिळवा ते कसे कार्य करते ते अन्वेषित करा

लेखक Toshendra Sharmaसंस्थापक आणि CEO, AgentCredia · Updated November 13, 2026

दोन श्रेणी आता पुरेशा नाहीत

वर्षानुवर्षे, traffic दोन गटांत विभागला जात होता: human आणि bot. Humans ला product मिळायचा. Bots ना block, rate-limit किंवा ignore केले जायचे.

तो विभाग आता टिकत नाही. काही automated visitors हे real customers च्या वतीने काम करणारे agents असतात: plan compare करणारा assistant, तुमच्या API मधून data आणणारा agent, task पूर्ण करण्यासाठी तुमच्या MCP server ला call करणारे tool. AI providers आता अशा user-initiated access चे स्वतः दस्तऐवजीकरण करतात: OpenAI म्हणते की त्याचा ChatGPT-User agent user ने ChatGPT ला प्रश्न विचारल्यावर pages visits करतो (OpenAI crawler documentation), आणि Anthropic त्याच उद्देशासाठी Claude-User सूचीबद्ध करते (Anthropic crawler documentation). त्याच वेळी, काही लोक AI सोबत हातात हात घालून काम करतात, messages draft करतात, forms भरतात आणि assistant सोबत products navigate करतात. हे सर्व human किंवा bot मध्ये जबरदस्तीने बसवल्यास दोन्ही दिशांनी चुकीचे निर्णय होतात. Legitimate agents block होतात, आणि real people ना त्यांच्या वर्तनामुळे असामान्य वाटल्याने challenge केले जाते.

योग्य निर्णयांकडे नेणाऱ्या पद्धतीने human आणि AI agent ट्रॅफिक वेगळा ओळखण्यासाठी अधिक classes लागतात, आणि प्रत्येक result वर किती विश्वास ठेवता येईल हेही माहीत असणे आवश्यक आहे. website traffic AI agents कडून येतो का हे कसे ओळखावे या blog post मध्ये हे शक्य करणारे signals समजावले आहेत, आणि SaaS apps use case मध्ये हा distinction product decisions कसा बदलतो ते दाखवले आहे.

चार classes, प्रत्येकाचा नेमका अर्थ

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 human-directed interaction दर्शवतात. हा वर्ग interaction कोण direction करत आहे याबद्दल आहे, identity बद्दल नाही. Human result व्यक्ती कोण आहे हे verify करत नाही, आणि कुठेही AI वापरले गेले नव्हते असा दावा करत नाही.

Human + AI

AI assistance घोषित केलेली होती, किंवा supported integration द्वारे दिसून आली जी ते प्रत्यक्ष पाहू शकते. उदाहरणांमध्ये user ने तुमच्या स्वतःच्या disclosure control द्वारे content AI सह drafted म्हणून mark करणे, किंवा तुमच्या application ने signed-in user साठी built-in assistant ने action पार पाडल्याचे report करणे यांचा समावेश होतो. अधिक माहितीसाठी AI-assisted interaction glossary entry वाचा.

Agent

Automated किंवा agent-origin interaction, जे verifiable identity द्वारे समर्थित आहे, जसे की प्रकाशित key कडून valid request signature, किंवा काळजीपूर्वक qualified inference. Agent result कोण कृती करत आहे ते सांगतो. याचा अर्थ agent authorized आहे, safe आहे किंवा एखाद्या person कडून valid delegation सह काम करत आहे असा होत नाही. autonomous agents बद्दल अधिक वाचा.

Unknown

Available evidence reliable determination ला support करत नाही. Unknown हा प्रामाणिक आणि उपयुक्त result आहे: तो coverage कुठे संपते ते दाखवतो, आणि अनिश्चित cases चा सामना policies ने जाणीवपूर्वक करण्याची मुभा देतो, चुकून नाही.

प्रत्येक वर्गासोबत basis असतो

Human आणि agent ट्रॅफिक वेगळे करणे हे कामाचा फक्त अर्धा भाग आहे. दुसरा अर्धा भाग म्हणजे प्रत्येक निष्कर्ष किती मजबूत आहे हे जाणणे. म्हणूनच प्रत्येक Proof of Actor result सोबत एक basis असतो:

Verified: check करता येणारा दावा validate केलेला, उदाहरणार्थ published key विरुद्ध तपासलेला request signature.
Declared: client किंवा तुमच्या application ने सांगितलेले, उदाहरणार्थ स्वतःला नाव देणारा agent किंवा AI assistance उघड करणारा user.
Inferred: behavioral किंवा contextual signals मधून काढलेला निष्कर्ष, नेहमी inference म्हणून label केलेला.
Unknown: determination साठी पुरावा अपुरा आहे.

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 मार्ग अनुसरते. संपूर्ण स्पष्टीकरण How It Works येथे आहे.

तुमच्या integration ला दिसू शकणारे signals

प्रकाशित keys असलेल्या automated clients कडून येणारे request signatures, RFC 9421 मध्ये परिभाषित केलेल्या HTTP Message Signatures वापरून. IETF Web Bot Auth working group ला automated clients या पद्धतीने authenticate कसे करतात हे standardize करण्याचा mandate आहे.
स्वतःची ओळख देणाऱ्या clients कडून येणारे declarations, जसे AI crawlers आणि fetchers चे documented user agents, आणि तुमच्या स्वतःच्या application कडून जेव्हा त्याला AI assistance involved आहे हे माहीत असते.
server-side integration ला उपलब्ध request context, जसे headers आणि protocol details.
ज्या pages वर ते चालते तिथल्या approved browser integration कडून येणारे interaction signals.

Signals पासून result पर्यंत

Signals तपासले जातात, basis नुसार label केले जातात आणि एकत्र केले जातात. मजबूत verified evidence confident result देते. कमकुवत किंवा परस्परविरोधी evidence qualified inference किंवा Unknown देते. Timeout किंवा missing signal कधीही Human result बनत नाही. Output मध्ये class, basis आणि evidence summary असते, जे तुमच्या team मधील कोणीही वाचू शकते.

ट्रॅफिक वेगळे झाल्यावर तुम्ही काय करू शकता

Proof of Actor तीन capabilities भोवती मांडले आहे: Detect, Understand आणि Route.

प्रत्येक interaction मागचा actor Detect करा

प्रत्येक context मध्ये उपलब्ध signals गोळा करा आणि verified assertions ला inferences पासून वेगळे करा. Unknown visible ठेवा.

प्रत्येक actor तुमचा product कसा वापरतो ते Understand करा

Route नुसार आणि वेळेनुसार human, AI-assisted, agent आणि unknown activity यांचे मिश्रण पहा. कोणत्याही result वर open करून काय माहित आहे आणि काय नाही ते पाहा. एजंट्स कुठे जास्त集中 आहेत आणि AI assistance सामान्य आहे असे workflows ओळखा.

प्रत्येक actor ला योग्य experience कडे Route करा

Evidence त्यांना support करताच तुमची स्वतःची policies लागू करा. public website वर, websites use case दाखवतो की या निवडी real routes शी कशा जोडल्या जातात:

Verified agents ना human-shaped pages ऐवजी structured response किंवा API द्या.
Human-directed sessions साठी standard experience ठेवा.
AI-assisted submissions label करा, जेणेकरून योग्य team त्यांची हाताळणी करेल.
संवेदनशील actions वर, तुमच्या स्वतःच्या conditions मागणी करतील तेव्हा अधिक मजबूत credentials मागा.
प्रत्येक route साठी Unknown साठी explicit fallback निवडा, जसे public pages allow करणे आणि account changes वर existing checks ठेवणे.

rolling out actor-aware policies safely या guide मध्ये observation मधून enforcement कडे एका वेळी एका route वर कसे जावे ते समाविष्ट आहे.

हे तुमच्या users साठी का महत्त्वाचे आहे

हे योग्य करणे तुमचे application वापरणाऱ्या प्रत्येकासाठी चांगले आहे.

लोकांना अधिक सुसंगत अनुभव मिळतो कारण त्यांना vague score च्या जोरावर challenge केले जात नाही. AI सोबत काम करणाऱ्या लोकांना workflows मध्ये, जिथे ते बसते, disclosed assistance साठी support मिळतो. Legitimate agents ना त्यांची कामे करण्यासाठी reliable, structured मार्ग मिळतो, ज्यामुळे scraping आणि तुमच्या interface वरचा load कमी होतो. तुमच्या team ला explainable decisions मिळतात, त्यामुळे support conversations, incident reviews आणि policy changes guesswork ऐवजी evidence वर आधारलेले असतात.

गोंधळाचा सर्वात सामान्य स्रोत म्हणजे account स्वतः. signed-in session तुम्हाला कोणते account वापरात आहे ते सांगते. तो current interaction कोण direction करत आहे ते सांगत नाही. सकाळी settings मधून क्लिक करणारा मालक, दुपारी report export करण्यास सांगितलेला assistant, आणि संध्याकाळी API key द्वारे काम करणारा agent हे तिघेही तेच account वापरू शकतात.

या तिघांनाही एकसारखे हाताळल्यास दोन्ही दिशांनी समस्या निर्माण होतात. account वरील प्रत्येक request मालकाचीच आहे असे गृहीत धरल्यास agent त्या workflows मध्ये जाऊ शकतो जे एखाद्या person साठी डिझाइन केले होते. प्रत्येक असामान्य request हल्ला आहे असे गृहीत धरल्यास मालकाची स्वतःची tools block होतात. Actor ला account पासून वेगळे केल्याने तुमच्या application ला authentication आणि authorization जशाच्या तशाच ठेवता येतात, आणि सध्या कोण कृती करत आहे याबद्दलचा हरवलेला context जोडता येतो. हाच context agents ना structured access देणे human-only workflows त्यांच्यासाठी खुले न करता शक्य करतो.

Observation mode मध्ये सुरुवात करा

प्रत्येक deployment observation mode मध्ये सुरू होते. Proof of Actor तुमचे application नेमके पूर्वीप्रमाणे response देत असताना results नोंदवते. तुमची team human, AI-assisted, agent आणि unknown activity चा baseline तयार करते, तो आधीच माहित असलेल्या outcomes शी तुलना करते, आणि एकही rule बदलण्यापूर्वी कोणतेही false positives review करते. Policy तयार झाल्यावर, तुम्ही ती एका workflow साठी enable करता आणि तिथून विस्तारता.

Founding developer program मध्ये सहभागी व्हा

Proof of Actor private beta मध्ये application teams च्या एका लहान गटासोबत आहे. निवडलेल्या founding developers ना, agreed usage limits च्या मर्यादेत, hands-on feedback च्या बदल्यात 12 months पर्यंत free access मिळू शकतो. तुम्हाला आमच्या engineers कडून direct integration support, capabilities कडे early access, आणि priorities वर influence मिळतो.

तुमच्या application मध्ये human आणि AI agent ट्रॅफिक वेगळा ओळखायचा असेल, तर early access साठी अर्ज करा आणि तुम्हाला सर्वात जास्त समजून घ्यायची असलेली interaction आम्हाला सांगा.

Proof of Actor explore करा, how it works वाचा, किंवा नेमके what the evidence can establish ते पहा.

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.

विकसकांसाठी

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 च्या शेजारी नोंदवा आणि तुम्ही policy निवडेपर्यंत काहीही बदलू नका. Node.js integration guide वाचा

वारंवार विचारले जाणारे प्रश्न

human आणि AI agent ट्रॅफिक तुम्ही कसे वेगळे ओळखता?

Proof of Actor तुमची integration ज्या signals पाहू शकते ते एकत्र करते, जसे की request signatures, client declarations, request context आणि browser interaction signals, आणि स्पष्ट basis सह class परत करते.

Human + AI असा वर्ग का आहे?

काही लोक AI assistant सोबत काम करतात. त्यांना पूर्णपणे human किंवा पूर्णपणे automated मानल्यास महत्त्वाचा context हरवतो. Human + AI हा असा assistance कव्हर करतो जो declared आहे किंवा supported integration द्वारे observable आहे.

Agent result म्हणजे bad bot सारखेच का?

नाही. अनेक agents वैध participants असतात. Agent result कोण कृती करत आहे हे सांगतो, कृती परवानगीची आहे की नाही हे नाही. प्रत्येक agent ला कसे serve करायचे हे तुमच्या policies ठरवतात.

traffic classify होऊ शकत नसेल तर काय?

तो Unknown म्हणून report केला जातो, जो एक first-class result आहे. Unknown कधीही Human मध्ये convert होत नाही आणि default ने malicious म्हणून treat केला जात नाही.

मला काही block करावे लागेल का?

नाही. तुम्ही observation mode मध्ये सुरू करता, results review करता, आणि तुमच्या टीमला ज्या policies योग्य वाटतात तिथेच त्या enable करता.

तुमचे app कोण वापरत आहे ते जाणून घ्या.

founding developers च्या छोट्या गटासाठी private beta.

लवकर प्रवेश मिळवा किमती पहा

आधी बोलणे पसंत आहे? founders शी बोला