മനുഷ്യൻ vs ഏജന്റ് ട്രാഫിക്

മനുഷ്യ, AI സഹായിത, ഏജന്റ് ട്രാഫിക് തമ്മിൽ വേർതിരിക്കുക

ഓരോ ഇടപെടലിനും വ്യക്തമായ ഒരു ക്ലാസും വ്യക്തമായ ഒരു അടിസ്ഥാനവും നൽകുക, അങ്ങനെ നിങ്ങളുടെ application ആളുകൾക്കും, AI യുമായി പ്രവർത്തിക്കുന്ന ആളുകൾക്കും, സ്വയംപ്രവർത്തിക്കുന്ന agents-ക്കും ഓരോരുത്തർക്കും യോജിക്കുന്ന വിധത്തിൽ സേവനം നൽകാൻ കഴിയട്ടെ.

Early Access നേടുക ഇത് എങ്ങനെ പ്രവർത്തിക്കുന്നു എന്ന് പര്യവേക്ഷണം ചെയ്യുക

രചിച്ചത് Toshendra SharmaFounder & CEO, AgentCredia · Updated November 13, 2026

രണ്ട് വിഭാഗങ്ങൾ ഇനി മതിയാകുന്നില്ല

വർഷങ്ങളോളം, ട്രാഫിക് രണ്ട് ബക്കറ്റുകളാക്കി വിഭജിച്ചിരുന്നു: മനുഷ്യരും bots ഉം. മനുഷ്യർക്ക് product ലഭിച്ചു. bots block ചെയ്യപ്പെട്ടു, rate-limit ചെയ്തു, അല്ലെങ്കിൽ അവഗണിക്കപ്പെട്ടു.

ആ വിഭജനം ഇനി നിലനിൽക്കുന്നില്ല. ചില automated സന്ദർശകർ യഥാർത്ഥ customers ന്റെ പേരിൽ പ്രവർത്തിക്കുന്ന agents ആണ്: ഒരു assistant plans താരതമ്യം ചെയ്യുന്നത്, നിങ്ങളുടെ API വഴി data എടുത്തുകൊണ്ടിരിക്കുന്ന ഒരു agent, ഒരു task പൂർത്തിയാക്കാൻ നിങ്ങളുടെ MCP server വിളിക്കുന്ന ഒരു tool. AI providers ഇപ്പോൾ ഇത്തരം user-initiated access സ്വയം രേഖപ്പെടുത്തുന്നു: OpenAI പറയുന്നു, ഒരു ഉപയോക്താവ് ChatGPT ക്ക് ഒരു ചോദ്യം ചോദിക്കുമ്പോൾ അതിന്റെ ChatGPT-User agent pages സന്ദർശിക്കുന്നതായി (OpenAI crawler documentation), കൂടാതെ Anthropic അതേ ലക്ഷ്യത്തിനായി Claude-User നെ പട്ടികപ്പെടുത്തുന്നു (Anthropic crawler documentation). അതേ സമയം, ചില ആളുകൾ AI യുമായി കൈകോർത്ത് പ്രവർത്തിക്കുന്നു, സന്ദേശങ്ങൾ draft ചെയ്യുന്നു, forms പൂരിപ്പിക്കുന്നു, ഒരു assistant നെ കൂടെ കൂട്ടി products വഴി സഞ്ചരിക്കുന്നു. ഇതെല്ലാം മനുഷ്യൻ അല്ലെങ്കിൽ bot എന്ന രണ്ടിലൊന്നായി force ചെയ്യുന്നത് ഇരുവശത്തും മോശം തീരുമാനങ്ങൾ സൃഷ്ടിക്കുന്നു. നിയമാനുസൃത agents block ചെയ്യപ്പെടുന്നു, കൂടാതെ യഥാർത്ഥ ആളുകൾ അവരുടെ പെരുമാറ്റം അസാധാരണമായി തോന്നുന്നതിനാൽ challenge ചെയ്യപ്പെടുന്നു.

നല്ല തീരുമാനങ്ങളിലേക്ക് നയിക്കുന്ന വിധത്തിൽ മനുഷ്യ, AI ഏജന്റ് ട്രാഫിക് വേർതിരിക്കാൻ കൂടുതൽ classes ഉം ഓരോ result നെയും എത്രത്തോളം വിശ്വസിക്കാം എന്നറിയുന്നതും ആവശ്യമാണ്. website traffic AI agents ല്‍ നിന്നാണോ എന്ന് എങ്ങനെ തിരിച്ചറിയാം എന്ന blog post ഇത് സാധ്യമാക്കുന്ന signals വിശദീകരിക്കുന്നു, കൂടാതെ SaaS apps use case ഈ distinction product തീരുമാനങ്ങളെ എവിടെയാണ് മാറ്റുന്നതെന്ന് കാണിക്കുന്നു.

നാല് classes, ഓരോന്നിനും കൃത്യമായ അർത്ഥം

Proof of Actor interactions നെ നാല് classes ആയി classify ചെയ്യുന്നു. ഓരോന്നിനും ഒരു നിർവചനവും വ്യക്തമായ ഒരു പരിധിയും ഉണ്ട്, അതിനാൽ നിങ്ങളുടെ ടീമിലെ ആരും evidence പിന്തുണക്കുന്നതിലധികം ഒരു result ൽ നിന്ന് വായിക്കുകയില്ല. ഈ taxonomy യുടെ reasoning അറിയാൻ Human, AI-assisted or agent: a taxonomy for app traffic വായിക്കുക.

Human

supported ആയ observable signals മനുഷ്യർ നയിക്കുന്ന ഇടപെടൽ സൂചിപ്പിക്കുന്നു. ഈ class ഇടപെടൽ ആരാണ് നയിക്കുന്നത് എന്നതിനെക്കുറിച്ചാണ്, identity യെക്കുറിച്ചല്ല. ഒരു Human result ആ വ്യക്തി ആരാണെന്ന് verify ചെയ്യുന്നില്ല, കൂടാതെ എവിടെയും AI ഉപയോഗിച്ചിട്ടില്ലെന്ന് അവകാശപ്പെടുന്നുമില്ല.

Human + AI

AI സഹായം പ്രഖ്യാപിച്ചിട്ടുണ്ട്, അല്ലെങ്കിൽ അത് യഥാർത്ഥത്തിൽ കാണാൻ കഴിയുന്ന supported integration വഴി നിരീക്ഷിച്ചിട്ടുണ്ട്. ഉദാഹരണങ്ങളിൽ, നിങ്ങളുടെ സ്വന്തം disclosure control വഴി ഒരു user AI യിൽ drafted ആയി content അടയാളപ്പെടുത്തുന്നത്, അല്ലെങ്കിൽ ഒരു signed-in user നു വേണ്ടി നിങ്ങളുടെ application ലെ built-in assistant ഒരു action നിർവഹിച്ചതായി റിപ്പോർട്ട് ചെയ്യുന്നത് ഉൾപ്പെടുന്നു. കൂടുതൽ അറിയാൻ AI-assisted interaction glossary entry കാണുക.

Agent

automated അല്ലെങ്കിൽ agent-origin ഇടപെടൽ, valid request signature from a published key പോലുള്ള verifiable identity വഴി, അല്ലെങ്കിൽ വളരെ സൂക്ഷ്മമായി qualified inference വഴി supported ആയത്. ഒരു Agent result പ്രവർത്തിക്കുന്നത് ആരാണെന്ന് വിവരിക്കുന്നു. അത് agent authorized ആണോ, safe ആണോ, അല്ലെങ്കിൽ ഒരു വ്യക്തിയിൽ നിന്നുള്ള valid delegation നോടുകൂടി പ്രവർത്തിക്കുന്നതാണോ എന്ന് അർത്ഥമാക്കുന്നില്ല. autonomous agents കുറിച്ച് കൂടുതൽ വായിക്കുക.

Unknown

ലഭ്യമായ evidence വിശ്വസനീയമായ determination നു പിന്തുണ നൽകുന്നില്ല. Unknown ഒരു honest ഉം ഉപകാരപ്രദവുമായ result ആണ്: ഇത് നിങ്ങളുടെ coverage എവിടെയാണ് അവസാനിക്കുന്നത് എന്ന് കാണിക്കുന്നു, കൂടാതെ uncertain cases അപ്രതീക്ഷിതമായി അല്ല, ബോധപൂർവ്വം കൈകാര്യം ചെയ്യാൻ നിങ്ങളുടെ policies ക്ക് അനുവദിക്കുന്നു.

ഓരോ class നും ഒരു basis ഉണ്ടാകും

മനുഷ്യ, ഏജന്റ് ട്രാഫിക് വേർതിരിക്കുന്നത് ജോലിയുടെ പകുതിമാത്രമാണ്. മറ്റേ പകുതി ഓരോ conclusion ഉം എത്ര ശക്തമാണ് എന്നറിയുന്നതാണ്. അതുകൊണ്ടാണ് ഓരോ Proof of Actor result നും ഒരു basis ഉണ്ടാകുന്നത്:

Verified: പരിശോധിക്കാവുന്ന ഒരു assertion validate ചെയ്തതാണ്, ഉദാഹരണത്തിന് published key against checked ചെയ്ത request signature.
Declared: client അല്ലെങ്കിൽ നിങ്ങളുടെ application അതു പറഞ്ഞു, ഉദാഹരണത്തിന് ഒരു agent സ്വയം പേരെടുക്കുന്നത് അല്ലെങ്കിൽ ഒരു user AI സഹായം വെളിപ്പെടുത്തുന്നത്.
Inferred: behavioral അല്ലെങ്കിൽ contextual signals ൽ നിന്ന് എടുത്ത conclusion, എപ്പോഴും inference എന്ന ലേബലോടെ.
Unknown: determination നു മതിയായ evidence ഇല്ല.

class ഉം basis ഉം ചേർന്നതാണ് കൃത്യമായ rules നിർമ്മിക്കാൻ നിങ്ങളെ സഹായിക്കുന്നത്. ഒരു verified agent ഉം ഒരു inferred agent ഉം രണ്ടും agents തന്നെയാണ്, പക്ഷേ ആദ്യത്തേതിന് structured API നൽകുകയും രണ്ടാമത്തേതിനെ standard rate limit ൽ കൈകാര്യം ചെയ്യുകയും നിങ്ങൾ ആഗ്രഹിക്കാം. ഒരു declared AI-assisted submission ഉം ഒരു human session ഉം സാധാരണയായി മുന്നോട്ട് പോകാം, support team നു സഹായകമായ ഒരു label സഹിതം. പൂർണ്ണ taxonomy Detection & Limitations ൽ കാണാം.

classification എങ്ങനെ നടക്കുന്നു

Proof of Actor ഓരോ ഇടപെടലിനും evidence-first path തന്നെയാണ് പിന്തുടരുന്നത്. പൂർണ്ണ വിശദീകരണം How It Works ൽ ലഭ്യമാണ്.

നിങ്ങളുടെ integration കാണാൻ കഴിയുന്ന signals

RFC 9421 ൽ നിർവചിച്ചതുപോലെ HTTP Message Signatures ഉപയോഗിച്ച്, അവരുടെ keys പ്രസിദ്ധീകരിക്കുന്ന automated clients ലെ Request signatures. IETF Web Bot Auth working group automation clients ഈ രീതിയിൽ authenticate ചെയ്യുന്നത് standardize ചെയ്യാൻ charter ചെയ്തതാണ്.
സ്വയം തിരിച്ചറിയുന്ന clients ലെ Declarations, ഉദാഹരണത്തിന് AI crawlers, fetchers എന്നിവയുടെ documented user agents, കൂടാതെ AI സഹായം ഉൾപ്പെട്ടിരിക്കുന്നുവെന്ന് അറിയുന്ന നിങ്ങളുടെ സ്വന്തം application ല്‍ നിന്നുള്ള വിവരങ്ങൾ.
server-side integration ന് ലഭ്യമായ Request context, ഉദാഹരണത്തിന് headers ഉം protocol details ഉം.
പ്രവർത്തിക്കുന്ന pages ലെ അംഗീകൃത browser integration ല്‍ നിന്നുള്ള Interaction signals.

signals മുതൽ ഒരു result വരെ

signals പരിശോധിക്കുന്നു, basis പ്രകാരം label ചെയ്യുന്നു, തുടർന്ന് സംയോജിപ്പിക്കുന്നു. ശക്തമായ verified evidence ആത്മവിശ്വാസമുള്ള result നൽകുന്നു. ദുർബലമായോ വിരുദ്ധമായോ evidence യോഗ്യമായ inference അല്ലെങ്കിൽ Unknown നൽകുന്നു. ഒരു timeout അല്ലെങ്കിൽ നഷ്ടപ്പെട്ട signal ഒരിക്കലും Human result ആകുന്നില്ല. output ഒരു class, ഒരു basis, കൂടാതെ നിങ്ങളുടെ ടീമിലെ ഏവർക്കും വായിക്കാവുന്ന ഒരു evidence summary ആണ്.

ട്രാഫിക് വേർതിരിച്ച ശേഷം നിങ്ങൾക്ക് ചെയ്യാൻ കഴിയുന്നത്

Proof of Actor മൂന്ന് capabilities നെ ചുറ്റിപ്പറ്റിയാണ് ക്രമീകരിച്ചിരിക്കുന്നത്: Detect, Understand, Route.

ഓരോ ഇടപെടലിന്റെയും പിന്നിലെ actor നെ Detect ചെയ്യുക

ഓരോ context ലും ലഭ്യമായ signals ശേഖരിക്കുക, verified assertions നെ inferences ൽ നിന്ന് വേർതിരിക്കുക. Unknown visible ആയി തന്നെ വെക്കുക.

ഓരോ actor ഉം നിങ്ങളുടെ product എങ്ങനെ ഉപയോഗിക്കുന്നു എന്ന് Understand ചെയ്യുക

route പ്രകാരവും സമയത്തിനനുസരിച്ചും human, AI-assisted, agent, unknown activity യുടെ mix കാണുക. ഏതൊരു result ഉം തുറന്ന് എന്താണ് known, എന്തല്ല എന്ന് നോക്കുക. agents ഏത് routes ലാണ് കൂടിച്ചേരുന്നത്, AI സഹായം ഏത് workflows ലാണ് സാധാരണമാകുന്നത് എന്ന് കണ്ടെത്തുക.

ഓരോ actor നെയും ശരിയായ experience ലേക്ക് Route ചെയ്യുക

evidence അവ പിന്തുണക്കുമ്പോൾ നിങ്ങളുടെ സ്വന്തം 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 ചെയ്യുക, അതിലൂടെ ശരിയായ ടീം അവ കൈകാര്യം ചെയ്യും.
sensitive actions ല്‍ നിങ്ങളുടെ സ്വന്തം conditions ആവശ്യപ്പെടുന്നിടത്ത് കൂടുതൽ ശക്തമായ credentials ചോദിക്കുക.
ഓരോ route ലും Unknown നു വ്യക്തമായ fallback തിരഞ്ഞെടുക്കുക, ഉദാഹരണത്തിന് public pages അനുവദിക്കുകയും account changes ല്‍ നിലവിലുള്ള checks നിലനിർത്തുകയും ചെയ്യുക.

rolling out actor-aware policies safely എന്ന guide ൽ observation മുതൽ enforcement ലേക്ക് ഓരോ route വീതം എങ്ങനെ നീങ്ങാം എന്ന് ഉൾക്കൊള്ളുന്നു.

നിങ്ങളുടെ users നു ഇത് എന്തുകൊണ്ട് പ്രധാനമാണ്

ഇത് ശരിയായി ചെയ്യുന്നത് നിങ്ങളുടെ application ഉപയോഗിക്കുന്ന എല്ലാവർക്കും നല്ലതാണ്.

അസ്പഷ്ടമായ score ന്റെ അടിസ്ഥാനത്തിൽ ആളുകളെ challenge ചെയ്യാത്തതിനാൽ അവർക്ക് കൂടുതൽ സുഗമമായ experience ലഭിക്കുന്നു. യോജിക്കുന്ന workflows ൽ പ്രഖ്യാപിച്ച AI assistance ന് support ലഭിക്കുന്നു. നിയമാനുസൃത agents തങ്ങളുടെ ജോലി ചെയ്യാൻ വിശ്വസനീയവും structured ഉം ആയ ഒരു മാർഗം ലഭിക്കുന്നു, ഇത് നിങ്ങളുടെ interface ലെ scraping ഉം load ഉം കുറയ്ക്കുന്നു. നിങ്ങളുടെ ടീമിന് explainable decisions ലഭിക്കുന്നു, അതിനാൽ support conversations, incident reviews, policy changes എന്നിവ guesswork ന് പകരം evidence ൽ ആശ്രയിക്കുന്നു.

കുഴപ്പത്തിന്റെ ഏറ്റവും സാധാരണമായ ഉറവിടങ്ങളിൽ ഒന്ന് account തന്നെയാണ്. signed-in session ഏത് account ആണ് ഉപയോഗത്തിലിരിക്കുന്നത് എന്ന് പറയുന്നു. ഇപ്പോഴത്തെ ഇടപെടൽ ആരാണ് നയിക്കുന്നത് എന്ന് അത് പറയുന്നില്ല. അതേ account ഉടമ രാവിലെ settings വഴി click ചെയ്യാനും, ഉടമ ആവശ്യപ്പെട്ട ഒരു assistant ഉച്ചയ്ക്ക് report export ചെയ്യാനും, വൈകുന്നേരം ഒരു API key വഴി പ്രവർത്തിക്കുന്ന agent ഉപയോഗിക്കാനും കഴിയും.

ഈ മൂന്നിനെയും ഒരേ രീതിയിൽ പരിഗണിക്കുന്നത് ഇരുവശത്തും പ്രശ്നങ്ങൾ സൃഷ്ടിക്കുന്നു. account ലെ ഓരോ request ഉം ഉടമ തന്നെയാണെന്ന് കരുതിയാൽ, ഒരു agent ഒരു person നായി രൂപകൽപ്പന ചെയ്ത workflows വരെ എത്താം. അസാധാരണമായ ഓരോ request ഉം ആക്രമണമാണെന്ന് കരുതിയാൽ, ഉടമയുടെ സ്വന്തം tools block ചെയ്യപ്പെടും. actor നെ account ൽ നിന്ന് വേർതിരിക്കുന്നത് നിങ്ങളുടെ application authentication, authorization എന്നിവ അവ 그대로 നിലനിർത്താൻ അനുവദിക്കുന്നു, കൂടാതെ ഇപ്പോൾ ആരാണ് പ്രവർത്തിക്കുന്നത് എന്നതിനേക്കുറിച്ചുള്ള നഷ്ടപ്പെട്ട context കൂട്ടിച്ചേർക്കുകയും ചെയ്യുന്നു. അതാണ് agents ക്ക് human-only workflows തുറന്നുവെക്കാതെ structured access നൽകാൻ സഹായിക്കുന്നത്.

observation mode ൽ ആരംഭിക്കുക

ഓരോ deployment ഉം observation mode ൽ ആരംഭിക്കുന്നു. നിങ്ങളുടെ application മുൻപുപോലെ തന്നെ പ്രതികരിക്കുമ്പോൾ Proof of Actor results രേഖപ്പെടുത്തുന്നു. നിങ്ങളുടെ ടീം human, AI-assisted, agent, unknown activity എന്നിവയുടെ ഒരു baseline നിർമ്മിക്കുന്നു, അത് നിങ്ങൾക്ക് ഇതിനകം അറിയാവുന്ന outcomes നോടു താരതമ്യം ചെയ്യുന്നു, ഒറ്റ rule പോലും മാറുന്നതിന് മുമ്പ് ഏതെങ്കിലും false positives review ചെയ്യുന്നു. ഒരു policy ready ആയാൽ, അത് ഒരു workflow ന് enable ചെയ്ത് അവിടെ നിന്ന് വ്യാപിപ്പിക്കുക.

founding developer program ല്‍ ചേരുക

Proof of Actor ചെറിയ application ടീമുകളുടെ ഒരു കൂട്ടത്തിനൊപ്പം private beta യിലാണ്. തിരഞ്ഞെടുക്കപ്പെടുന്ന founding developers agreement ചെയ്ത usage limits നുള്ളിൽ, hands-on feedback ന്റെ പ്രതിഫലമായി, up to 12 months of free access ലഭിക്കാം. ഞങ്ങളുടെ engineers ല്‍ നിന്ന് നേരിട്ടുള്ള integration support, capabilities ലേക്ക് early access, priorities ൽ സ്വാധീനം എന്നിവ നിങ്ങൾക്ക് ലഭിക്കും.

നിങ്ങളുടെ application ൽ മനുഷ്യ, AI ഏജന്റ് ട്രാഫിക് വേർതിരിക്കേണ്ടതുണ്ടെങ്കിൽ, early access നു അപേക്ഷിക്കുക ಮತ್ತು നിങ്ങൾ ഏറ്റവും കൂടുതൽ മനസ്സിലാക്കാൻ ആഗ്രഹിക്കുന്ന interaction കുറിച്ച് ഞങ്ങളെ അറിയിക്കുക.

Proof of Actor പര്യവേക്ഷണം ചെയ്യുക, how it works വായിക്കുക, അല്ലെങ്കിൽ 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.

ഡെവലപ്പർമാർക്കായി

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-ൽ ആരംഭിക്കുക: നിങ്ങളുടെ logs-ിന് ഒപ്പം results രേഖപ്പെടുത്തുക, നിങ്ങൾ ഒരു policy തിരഞ്ഞെടുക്കും വരെ ഒന്നും മാറ്റരുത്. Node.js integration guide വായിക്കുക

പതിവായി ചോദിക്കുന്ന ചോദ്യങ്ങൾ

മനുഷ്യ, AI ഏജന്റ് ട്രാഫിക് നിങ്ങൾ എങ്ങനെ വേർതിരിക്കുന്നു?

നിങ്ങളുടെ integration ന് നിരീക്ഷിക്കാനാവുന്ന request signatures, client declarations, request context, browser interaction signals എന്നിവ പോലുള്ള signals Proof of Actor സംയോജിപ്പിച്ച്, വ്യക്തമായ basis ഉള്ള ഒരു class തിരികെ നൽകുന്നു.

എന്തുകൊണ്ടാണ് Human + AI എന്ന ഒരു class ഉള്ളത്?

ചില ആളുകൾ അവരുടെ അടുത്ത് ഒരു AI assistant നെ കൂട്ടുപിടിച്ചാണ് പ്രവർത്തിക്കുന്നത്. അവരെ പൂർണ്ണമായും മനുഷ്യരായി അല്ലെങ്കിൽ പൂർണ്ണമായും automated ആയി കണക്കാക്കുന്നത് പ്രധാനപ്പെട്ട context നഷ്ടപ്പെടുത്തുന്നു. പ്രഖ്യാപിച്ചോ supported integration വഴി കാണാനാവുന്നതോ ആയ assistance നെ Human + AI ഉൾക്കൊള്ളുന്നു.

ഒരു Agent result എന്നത് bad bot നോടു തുല്യമാണോ?

അല്ല. പല agents ഉം നിയമാനുസൃത പങ്കാളികളാണ്. Agent result എന്നത് ആരാണ് പ്രവർത്തിക്കുന്നത് എന്നതാണ് വിവരിക്കുന്നത്, action അനുവദനീയമാണോ എന്നല്ല. ഓരോ agent നെ എങ്ങനെ serve ചെയ്യണമെന്ന് നിങ്ങളുടെ policies തീരുമാനിക്കും.

ട്രാഫിക് classify ചെയ്യാനാകില്ലെങ്കിൽ എന്താകും?

അത് Unknown ആയി റിപ്പോർട്ട് ചെയ്യപ്പെടും, ഒരു first-class result ആയി. Unknown നെ ഒരിക്കലും Human ആയി മാറ്റില്ല, കൂടാതെ default ആയി malicious ആയി കണക്കാക്കില്ല.

എനിക്ക് എന്തെങ്കിലും block ചെയ്യേണ്ടതുണ്ടോ?

അല്ല. നിങ്ങൾ observation mode ൽ ആരംഭിക്കുന്നു, results review ചെയ്യുന്നു, നിങ്ങളുടെ ടീം അവ യോജിച്ചതാണെന്ന് ഉറപ്പുള്ളിടത്ത് മാത്രമേ policies enable ചെയ്യൂ.

നിങ്ങളുടെ app ഉപയോഗിക്കുന്നത് ആരാണെന്ന് അറിയുക.

ചെറിയൊരു founding developers ഗ്രൂപ്പിനായുള്ള private beta.

Early Access നേടുക വിലകൾ കാണുക

ആദ്യം സംസാരിക്കണമോ? സ്ഥാപകരുമായി സംസാരിക്കുക