AI ഏജന്റ് കണ്ടെത്തൽ

വെബ്സൈറ്റുകൾക്കായുള്ള AI ഏജന്റ് കണ്ടെത്തൽ, ഓരോ ഫലത്തിന്റെയും പിന്നിലെ തെളിവുകളോടെ

നിങ്ങളുടെ വെബ്സൈറ്റിലെ ഇടപെടലുകളിൽ ഏതൊക്കെ ആളുകളിൽ നിന്നാണ്, AI യുമായി ചേർന്ന് പ്രവർത്തിക്കുന്ന ആളുകളിൽ നിന്നാണ്, സ്വയംഭരണ ഏജന്റുകളിൽ നിന്നാണ്, അല്ലെങ്കിൽ തെളിവ് ഇതുവരെ തിരിച്ചറിയാൻ കഴിയാത്ത ഉറവിടങ്ങളിൽ നിന്നാണ് എന്നത് കാണുക. ഓരോ ഫലവും അത് അടിസ്ഥാനമാക്കിയിരിക്കുന്നതു എന്താണെന്ന് കാണിക്കുന്നു.

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

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

നിങ്ങളുടെ വെബ്സൈറ്റിന് ഇപ്പോൾ ഒരിലധികം തരത്തിലുള്ള സന്ദർശകർ ഉണ്ട്

വെബിന്റെ ചരിത്രത്തിന്റെ ഭൂരിഭാഗത്തും, ഒരു വെബ്സൈറ്റ് ഒരു ലളിതമായ മാതൃക കരുതിയിരുന്നു: ഒരു മനുഷ്യൻ browser തുറക്കുന്നു, ചുറ്റി നോക്കുന്നു, പിന്നെ maybe sign in ചെയ്യുന്നു. Analytics, rate limits, onboarding flows, security checks എന്നിവ എല്ലാം ആ മനുഷ്യനെ ആശ്രയിച്ചായിരുന്നു രൂപകൽപ്പന ചെയ്തിരുന്നത്.

അത് ഇനി യഥാർത്ഥ traffic നെ വിവരിക്കുന്നില്ല. ഇന്ന് ഒരു single website തനിയെ browse ചെയ്യുന്ന ആളുകൾക്കും, അവരുടെ വേണ്ടി എന്തെങ്കിലും ചുരുക്കാനോ പൂരിപ്പിക്കാനോ ഒരു AI assistant നോട് പറയുന്ന ആളുകൾക്കും, മറ്റൊരാളുടെ പേരിൽ pages വായിച്ച് endpoints വിളിക്കുന്ന autonomous agents കൾക്കും, crawlers ഉം scripts ഉം അടങ്ങിയ നീണ്ട tail നും സേവനം നൽകുന്നു. AI providers ഇവയിൽ പല സന്ദർശകരെയും തങ്ങൾ തന്നെ രേഖപ്പെടുത്തുന്നു: ഉദാഹരണത്തിന് OpenAI അതിന്റെ search crawler, training crawler, കൂടാതെ ഒരു ChatGPT ഉപയോക്താവ് ഒരു ചോദ്യം ചോദിക്കുമ്പോൾ pages സന്ദർശിക്കുന്ന fetcher എന്നിവയ്ക്കായി വേറിട്ട user agents പ്രസിദ്ധീകരിക്കുന്നു (OpenAI crawler documentation), Anthropic ClaudeBot, Claude-User, Claude-SearchBot എന്നിവയ്ക്കും അതേ രീതിയിലാണ് ചെയ്യുന്നത് (Anthropic crawler documentation). ഇവയിൽ ചില സന്ദർശകർ സ്വാഗതാർഹരാണ്. ചിലർക്കു വേറിട്ട അനുഭവം വേണം. ചിലർക്ക് എന്തെങ്കിലും sensitive ആയി ചെയ്യുന്നതിന് മുമ്പ് കൂടുതൽ സൂക്ഷ്മമായ പരിശോധന വേണം.

ഈ ഇടപെടലുകളിൽ പലതും ആദ്യ നോട്ടത്തിൽ ഒരേപോലെ തോന്നുന്നതാണ് പ്രശ്നം. ഒരു login tells you which account is in use. അത് ഒരു person clicking ആണോ, ആ session വഴിയായി ഒരു assistant പ്രവർത്തിക്കുന്നതാണോ, അല്ലെങ്കിൽ മറ്റൊരിടത്തെ ഉപയോക്താവിനായി ഒരു automated client നിങ്ങളുടെ pricing page വായിക്കുന്നതാണോ എന്നത് പറയുന്നില്ല. വെബ്സൈറ്റുകൾക്കായുള്ള AI agent detection എന്നത് ഈ വിടവ് തെളിവുകളോടെ അടയ്ക്കുന്നതിനെക്കുറിച്ചാണ്, അതുവഴി നിങ്ങളുടെ ടീം എല്ലാ traffic നെയും ഒരേപോലെ കൈകാര്യം ചെയ്യാതെ ഓരോ actor തരത്തിനും അനുയോജ്യമായി പ്രതികരിക്കാം. ഉൾപ്പെട്ടിരിക്കുന്ന signals നെ കുറിച്ചുള്ള പ്രായോഗിക walkthrough ന് ഒരു വെബ്സൈറ്റ് traffic AI agents നിന്നാണോ എന്നത് എങ്ങനെ തിരിച്ചറിയാം വായിക്കുക, production site ലെ ഇത് എങ്ങനെയാണെന്ന് കാണാൻ websites use case കാണുക.

ഒരൊറ്റ bot score എന്തുകൊണ്ട് മതിയാകുന്നില്ല

പല tools ഈ ചോദ്യം ഒരു സംഖ്യയിലൂടെ മറുപടി പറയുന്നു: ഒരു bot score, ഒരു risk score, ഒരു visitor എത്ര human ആണെന്ന് അവകാശപ്പെടുന്ന ഒരു percentage. ആകർഷണം വ്യക്തമാണ്. ഒരു സംഖ്യ rule ലേക്ക് ഇടുന്നത് എളുപ്പമാണ്.

പ്രശ്നം, ഒരൊറ്റ സംഖ്യ കാരണം മറയ്ക്കുന്നതാണ്. ഒരു score ഒരു session probably automated ആണെന്ന് പറഞ്ഞാൽ, ആ നിഗമനം ഒരു verified signature യിലാണോ, ആരും copy ചെയ്യാൻ കഴിയുന്ന ഒരു user-agent string ലാണോ, അല്ലെങ്കിൽ വേഗത്തിൽ ടൈപ്പ് ചെയ്യുന്ന ഒരു മനുഷ്യനുമായി കൂടിയും ഒത്തുപോകുന്ന ഒരു pattern ലാണോ ആധാരമാക്കിയിരിക്കുന്നത് എന്ന് നിങ്ങളുടെ ടീമിന് കാണാൻ കഴിയില്ല. ആ score ഒരു block അല്ലെങ്കിൽ challenge നയിക്കുമ്പോൾ, അത് ചെയ്യുന്ന ഓരോ പിശകും അതിനെ customer, colleague, auditor എന്നിവർക്ക് വിശദീകരിക്കാൻ മാർഗമില്ലാതെ നിങ്ങൾ ഏറ്റെടുക്കുന്നു.

Proof of Actor വേറിട്ട സമീപനം സ്വീകരിക്കുന്നു. ഓരോ ഫലവും നാല് വ്യക്തമായ classes ലൊന്നാണ്, Human, AI-assisted അല്ലെങ്കിൽ agent: app traffic നുള്ള ഒരു taxonomy ൽ വിശദീകരിച്ചിരിക്കുന്നതുപോലെ, ഓരോ ഫലവും അത് അടിസ്ഥാനമാക്കിയിരിക്കുന്നത് എന്താണെന്ന് പറയുന്നു. നിങ്ങൾക്ക് conclusion ഉം evidence ഉം ഒരുമിച്ച് കാണാം, അതിനാൽ ശക്തമായ ഫലങ്ങളെ വിശ്വസിക്കാനും, ദുർബലമായവ ചോദ്യം ചെയ്യാനും, തെളിവിന്റെ ഗുണനിലവാരത്തിന് അനുയോജ്യമായ policies നിർമ്മിക്കാനും കഴിയും.

നിങ്ങളുടെ വെബ്സൈറ്റിൽ AI agents കണ്ടെത്താൻ നാലു ഘട്ടങ്ങൾ

നിങ്ങൾ ഇതിനകം കൈവശമുള്ള tools ഉപയോഗിച്ച് നിങ്ങളുടെ വെബ്സൈറ്റിൽ AI agents കണ്ടെത്തൽ ആരംഭിക്കാം. ഈ നാലു ഘട്ടങ്ങൾ vendor-neutral ആണ്, നിങ്ങൾ Proof of Actor ഉപയോഗിക്കുന്നുണ്ടോ ഇല്ലയോ എന്നതിനെക്കാൾ സ്വതന്ത്രമായി പ്രവർത്തിക്കുന്നു; ഒരു വെബ്സൈറ്റ് traffic AI agents നിന്നാണോ എന്നത് എങ്ങനെ തിരിച്ചറിയാം എന്ന blog post ഇവയിൽ ഓരോന്നും കൂടുതൽ വിശദമായി ഉൾക്കൊള്ളുന്നു.

സ്വയം തിരിച്ചറിയുന്ന agents പട്ടികയിടുക. AI providers പ്രസിദ്ധീകരിക്കുന്ന user agents കൾക്കായി നിങ്ങളുടെ server അല്ലെങ്കിൽ CDN logs തിരയുക. OpenAI OAI-SearchBot, GPTBot, ChatGPT-User എന്നിവ രേഖപ്പെടുത്തുന്നു, കൂടാതെ ഒരു ഉപയോക്താവ് ChatGPT യോട് ഒരു ചോദ്യം ചോദിക്കുമ്പോഴാണ് ChatGPT-User pages സന്ദർശിക്കുന്നതെന്നും, സ്വയമേവ crawl ചെയ്യുന്നില്ലെന്നും പറയുന്നു. Anthropic ClaudeBot, Claude-User, Claude-SearchBot എന്നിവ രേഖപ്പെടുത്തുന്നു. ഇതിലൂടെ route അടിസ്ഥാനത്തിൽ agent traffic ന്റെ ആദ്യ, declared ദൃശ്യമാണ് ലഭിക്കുന്നത്.
string നെ വിശ്വസിക്കുന്നതിന് മുമ്പ് claims പരിശോധിക്കുക. ഒരു user agent self-reported ആണ്, അതിനാൽ copy ചെയ്യാൻ എളുപ്പമാണ്. operator ന്റെ സ്വന്തം verification method നോട് അത് ഒത്തുപോകുന്നുണ്ടോ എന്ന് പരിശോധിക്കുക: Google Googlebot നായി reverse DNS lookup ന്റെയും തുടർന്ന് forward DNS lookup ന്റെയും, കൂടാതെ പ്രസിദ്ധീകരിച്ച IP range files ന്റെയും ഉപയോഗം വിവരിക്കുന്നു (Google: verifying Googlebot); Bing Bingbot നായി അതേ reverse, forward DNS check വിവരിക്കുന്നു (Bing: verifying Bingbot); OpenAI അതിന്റെ ഓരോ user agent നും IP range files പ്രസിദ്ധീകരിക്കുന്നു. ഒരു client HTTP Message Signatures ഉപയോഗിച്ച് അതിന്റെ requests sign ചെയ്യുന്നുവെങ്കിൽ, RFC 9421 ൽ നിർവചിച്ചതുപോലെ, operator ന്റെ പ്രസിദ്ധീകരിച്ച key യോട് signature പരിശോധിക്കുക.
ഓരോ ഫലത്തെയും അതിന്റെ തെളിവോടെ ലേബൽ ചെയ്യുക, Unknown നിലനിർത്തുക. ഓരോ നിഗമനവും verified, declared അല്ലെങ്കിൽ inferred ആണോ എന്ന് രേഖപ്പെടുത്തുക. ഒരു verified അല്ലെങ്കിൽ declared agent നുമായും പൊരുത്തപ്പെടാത്തതും വ്യക്തമായ human pattern കാണിക്കാത്തതുമായ traffic നെ മനുഷ്യൻ അല്ലെങ്കിൽ bot എന്നതിലേക്ക് ബലമായി തള്ളാതെ Unknown ആയി ലേബൽ ചെയ്യണം. ഉപയോഗപ്രദമായ ഒരു റിപ്പോർട്ടിനെയും വെറും അനുമാനത്തെയും വേർതിരിക്കുന്ന ഘട്ടമാണിത്.
പ്രവർത്തിക്കുന്നതിന് മുമ്പ് route പ്രകാരം നിരീക്ഷിക്കുക. കുറച്ച് ആഴ്ചകളോളം ഫലങ്ങളെ route ഉം workflow ഉം അനുസരിച്ച് വിഭജിക്കുക: public content, signup, account settings, APIs. അതിനു ശേഷം മാത്രമേ actor context ഏറ്റവും പ്രധാനമായ route ന് ഒരു പരിമിതമായ policy എഴുതൂ, Unknown ന് വ്യക്തമായ fallback സഹിതം.

Proof of Actor ഈ ഘട്ടങ്ങൾ നിങ്ങളുടെ application ൽ തന്നെ സ്വയം പ്രവർത്തിപ്പിക്കുന്നു: നിങ്ങളുടെ integration കാണാൻ കഴിയുന്ന signals അത് ശേഖരിക്കുന്നു, basis സഹിതം ഒരു class മടക്കിനൽകുന്നു, route പ്രകാരം Unknown പിന്തുടരുന്നു, policy നിങ്ങളുടെ code ലേക്ക് വിടുന്നു.

വെബ്സൈറ്റുകളിൽ AI agents കണ്ടെത്തുന്നത് Proof of Actor എങ്ങനെ ചെയ്യുന്നു

Proof of Actor ഒരു ലളിതമായ പാതയെ ചുറ്റിപ്പറ്റിയാണ് നിർമ്മിച്ചിരിക്കുന്നത്: നിങ്ങളുടെ integration നിരീക്ഷിക്കാൻ കഴിയുന്ന signals, വ്യക്തമായ basis ഉള്ള ഒരു classification, പിന്നെ നിങ്ങളുടെ കൈകളിൽ തന്നെ തുടരുന്ന ഒരു തീരുമാനം. പൂർണ്ണ പ്രവാഹം How It Works പേജിൽ വായിക്കാം. ഇവിടെ ചുരുക്കം ഇതാണ്.

നിങ്ങളുടെ integration ല നിന്നുള്ള signals

ഓരോ integration ഉം അതിന്റെ context അനുവദിക്കുന്നതെല്ലാം കാണുന്നു. ഒരു server-side integration request context, protocol details, കൂടാതെ client പിന്തുണയ്ക്കുന്നുവെങ്കിൽ request signature ഉം കാണുന്നു. ഒരു browser integration അത് പ്രവർത്തിക്കുന്ന pages ലെ interaction signals കാണുന്നു. ഒരു application സ്വന്തമായ declarations രേഖപ്പെടുത്താനും കഴിയും, ഉദാഹരണത്തിന് ഒരു ഉപയോക്താവ് ഉള്ളടക്കം AI സഹായത്തോടെ draft ചെയ്തതായി അടയാളപ്പെടുത്തുന്നത്, അല്ലെങ്കിൽ ഒരു agent client സ്വയം പേരിടുന്നത് പോലുള്ളത്.

Proof of Actor യഥാർത്ഥത്തിൽ ഉണ്ടായിരിക്കുന്ന തെളിവുകളോടെയാണ് പ്രവർത്തിക്കുന്നത്. നിങ്ങളുടെ വെബ്സൈറ്റ് നിരീക്ഷിക്കാൻ കഴിയാത്ത കാര്യങ്ങൾ കാണുന്നു എന്ന് അത് നടിക്കില്ല.

പ്രത്യേക അർത്ഥമുള്ള നാല് classes

ഓരോ ഇടപെടലും നാല് classes ലൊന്നിലാണ് എത്തുന്നത്:

Human: കാണാനാകുന്ന signals മനുഷ്യൻ നയിച്ച ഇടപെടൽ സൂചിപ്പിക്കുന്നു.
Human + AI: AI സഹായം declared ചെയ്തിട്ടുണ്ട്, അല്ലെങ്കിൽ അത് കാണാൻ കഴിയുന്ന പിന്തുണയ്ക്കുന്ന ഒരു integration വഴി നിരീക്ഷിച്ചിട്ടുണ്ട്.
Agent: automated അല്ലെങ്കിൽ agent-origin ഇടപെടൽ, സ്ഥിരീകരിക്കാവുന്ന identity അല്ലെങ്കിൽ സൂക്ഷ്മമായി യോഗ്യതപ്പെടുത്തിയ inference വഴി പിന്തുണയ്ക്കപ്പെട്ടത്.
Unknown: ലഭ്യമായ തെളിവ് വിശ്വസനീയമായ ഒരു നിഗമനത്തെ പിന്തുണയ്ക്കുന്നില്ല.

ഓരോ class നും വ്യക്തമായ നിർവചനവും വ്യക്തമായ പരിധിയും ഉണ്ട്. ഒരു Human ഫലം ഒരു verified identity അല്ല. ഒരു Agent ഫലം ആ agent authorized ആണെന്ന പ്രസ്താവന അല്ല. ഒരു Unknown ഫലം ഒരു ആരോപണവും അല്ല. പൂർണ്ണ taxonomy കാണാൻ Detection & Limitations പേജ് വായിക്കുക.

ഓരോ ഫലത്തിലും ഒരു basis

class നൊപ്പം, ഓരോ ഫലത്തിനും അതിന്റെ basis ഉണ്ട്: verified, declared, inferred അല്ലെങ്കിൽ unknown. പ്രസിദ്ധീകരിച്ച key യിൽ നിന്നുള്ള സാധുവായ signature ഉള്ള request ആ പരിശോധനയ്ക്ക് verified ആണ്. തന്നെ ഒരു agent ആണെന്ന് പേരിടുന്ന client അത് declared ചെയ്തിട്ടുണ്ട്. automation നോട് പൊരുത്തപ്പെടുന്ന behavior pattern ഒരു inference ആണ്. ഈ വ്യത്യാസമാണ് നിങ്ങളുടെ policies കൃത്യമായിരിക്കാനാക്കുന്നത്. read-only route ലെ ഒരു verified signed agent ഉം account settings page ലെ ഒരു self-declared client ഉം ഒരേ വിധം കൈകാര്യം ചെയ്യേണ്ടതില്ല, Proof of Actor ഉപയോഗിക്കുമ്പോൾ അതിന് ആവശ്യമുമില്ല. evidence basis എന്ന glossary entry ഓരോന്നും കൂടുതൽ വിശദമായി വിശദീകരിക്കുന്നു.

നിങ്ങളുടെ ടീമിന് ലഭിക്കുന്നത്: Detect, Understand, Route

Proof of Actor മൂന്ന് കഴിവുകൾ ഒരുമിച്ച് പ്രവർത്തിക്കുന്ന ഒരു product ആണ്.

Detect

നിങ്ങളുടെ integration ന് ലഭ്യമായ actor signals ശേഖരിച്ച് verified assertions നെ behavioral inferences ൽ നിന്ന് വേർതിരിക്കുക. Unknown traffic ഒരു guess ലേക്ക് ലയിപ്പിക്കാതെ അതിന്റെ സ്വന്തം category ആയി ദൃശ്യമായി തുടരുന്നു. ആത്മവിശ്വാസത്തോടെ പറയാൻ കഴിയുന്ന interactions ഏതൊക്കെയെന്ന്, കൂടുതൽ തെളിവ് ആവശ്യമായവ ഏതൊക്കെയെന്ന് നിങ്ങൾക്ക് എല്ലായ്പ്പോഴും അറിയാം.

Understand

നിങ്ങളുടെ AI agent traffic നെ context ൽ കാണുക. route പ്രകാരവും സമയപ്രകാരവും interaction types പരിശോധിക്കുക, human, AI-assisted, agent, unknown activity എന്നിവയിലെ trends പിന്തുടരുക, ഏതെങ്കിലും classification തുറന്ന് എന്താണ് അറിയപ്പെടുന്നതെന്നും എന്താണ് അറിയപ്പെടാത്തതെന്നും ഫലം എന്തിലാണ് ആശ്രയിക്കുന്നതെന്നും കാണുക. product, platform, security ടീമുകൾക്ക് ഇവിടെ വെബ്സൈറ്റ് ഉപയോഗിക്കുന്നത് ആരാണെന്നതിന്റെ പങ്കിടാവുന്നതും വിശദീകരിക്കാവുന്നതുമായ ഒരു ദൃശ്യം ലഭിക്കുന്നു.

Route

നിശ്ചിത ഇടപെടലുകൾ allow ചെയ്യാനും, adapt ചെയ്യാനും, challenge ചെയ്യാനും, review ചെയ്യാനും, limit ചെയ്യാനും നിങ്ങളുടെ സ്വന്തം policies ഉപയോഗിക്കുക. നിങ്ങളുടെ documentation വായിക്കുന്ന ഒരു verified agent ന് structured response നൽകുക. മനുഷ്യൻ നയിക്കുന്ന sessions ന് standard experience നിലനിർത്തുക. നിങ്ങളുടെ സ്വന്തം conditions ആവശ്യപ്പെടുമ്പോൾ sensitive account മാറ്റത്തിന് കൂടുതൽ ശക്തമായ check ആവശ്യപ്പെടുക. ഓരോ route ലും Unknown ഫലങ്ങൾക്കും timeouts നും വ്യക്തമായ fallback തിരഞ്ഞെടുക്കുക. enforcement എല്ലായ്പ്പോഴും നിങ്ങളുടെ application ൽ, നിങ്ങളുടെ ടീം സ്ഥിരീകരിക്കുന്ന policies പ്രകാരമാണ് നടക്കുന്നത്.

നിങ്ങളുടെ വെബ്സൈറ്റിനൊപ്പം ചേരാൻ രൂപകൽപ്പന ചെയ്തതാണ്, അതിനെ മാറ്റിസ്ഥാപിക്കാനല്ല

Proof of Actor നിങ്ങൾ ഇതിനകം പ്രവർത്തിപ്പിക്കുന്ന tools നൊപ്പം ചേർന്ന് പ്രവർത്തിക്കുന്നു. ഇത് നിങ്ങളുടെ authentication, നിങ്ങളുടെ authorization model, അല്ലെങ്കിൽ നിലവിലുള്ള abuse controls എന്നിവ മാറ്റിസ്ഥാപിക്കുന്നില്ല. അവയ്ക്ക് actor context ചേർക്കുകയാണ് ചെയ്യുന്നത്.

ഒരു സാധാരണ website integration actor context ഏറ്റവും പ്രധാനമാകുന്ന routes ലാണ് ആരംഭിക്കുന്നത്: agents വ്യാപകമായി വായിക്കുന്ന public content, signup, onboarding flows, account settings, മറ്റ് sensitive actions, കൂടാതെ site പ്രവർത്തിപ്പിക്കുന്ന ഏതൊരു API യും. Founding ടീമുകൾ നമ്മുടെ engineers നോടൊപ്പം പ്രവർത്തിച്ച് ആ routes തിരഞ്ഞെടുക്കുകയും, scope ലെ signals സമ്മതിക്കുകയും, ഏതൊരു code ഉം ഷിപ്പ് ചെയ്യുന്നതിനുമുമ്പ് data കൈകാര്യം ചെയ്യൽ എങ്ങനെ ആകണമെന്ന് സ്ഥിരീകരിക്കുകയും ചെയ്യുന്നു.

Decision layer നിങ്ങളുടെ code ൽ തന്നെ ഉള്ളതിനാൽ, experience ന്‍റെ നിയന്ത്രണം നിങ്ങൾക്കുതന്നെ തുടരുന്നു. ഏതെങ്കിലും rule മാറ്റങ്ങൾക്ക് മുമ്പ് ആഴ്ചകളോളം ഫലങ്ങൾ internal dashboard ല് കാണിക്കാം, തുടർന്ന് ഒരു route നു വേണ്ടി ഒരു narrow policy മാത്രം ഓണാക്കാം, പിന്നെ ഫലങ്ങൾ നിങ്ങളുടെ വിശ്വാസം നേടുമ്പോൾ മാത്രമേ വ്യാപിപ്പിക്കൂ. Unknown traffic കൈകാര്യം ചെയ്യുന്നത് എന്ന guide ആ ആദ്യ rules എങ്ങനെ രൂപകൽപ്പന ചെയ്യാമെന്ന് വിശദീകരിക്കുന്നു.

നിരീക്ഷണ മോഡിൽ ആരംഭിക്കുക

AI agent detection ൽ നിന്ന് മൂല്യം ലഭിക്കാൻ ഏറ്റവും വേഗത്തിലുള്ള വഴി തടയുന്നതല്ല, നിരീക്ഷിക്കുന്നതാണ്. നിരീക്ഷണ മോഡിൽ, Proof of Actor നിങ്ങളുടെ വെബ്സൈറ്റ് അതില്ലാത്തതുപോലെ തന്നെ പ്രതികരിക്കുമ്പോൾ ഫലങ്ങൾ രേഖപ്പെടുത്തുന്നു. തുടർന്ന് നിങ്ങളുടെ ടീം ഇതിനകം മനസ്സിലാക്കുന്ന outcomes മായിച്ച് classifications താരതമ്യം ചെയ്യാം: support tickets, known integrations, internal tools, നിങ്ങൾ ഇതിനകം തിരിച്ചറിയുന്ന crawlers.

ഏതൊരു enforcement നും മുമ്പ് ഇത് നിങ്ങൾക്ക് മൂന്ന് കാര്യങ്ങൾ നൽകുന്നു:

ഒരു baseline. route അനുസരിച്ച് നിങ്ങളുടെ traffic എത്ര ഭാഗം human-directed, AI-assisted, agent-driven, അല്ലെങ്കിൽ unknown ആണെന്ന്.
തെളിവിലുള്ള ആത്മവിശ്വാസം. നിങ്ങളുടെ വെബ്സൈറ്റിൽ ഏത് signals ശക്തമാണെന്നും coverage എവിടെയാണ് വളരണം വേണ്ടതെന്നും.
മികച്ച policies. യാഥാർത്ഥ്യ patterns അടിസ്ഥാനമാക്കി assumptions ൽ അല്ലാതെ രൂപകൽപ്പന ചെയ്ത rules, ആരെയും ബാധിക്കുന്നതിന് മുമ്പ് false positives പരിശോധിച്ചവ.

ഒരു policy തയ്യാറായാൽ, അത് രൂപകൽപ്പന ചെയ്തിരുന്ന specific workflow ന് നിങ്ങൾ അത് enable ചെയ്യുന്നു, പിന്നെ ഏത് സമയത്തും അത് adjust ചെയ്യാനുള്ള കഴിവ് നിലനിർത്തുന്നു.

തെളിവ് അടിസ്ഥാനമാക്കിയ കണ്ടെത്തൽ അപ്രസന്നമായ scores നെക്കാൾ എങ്ങനെ ജയിക്കുന്നു

വെബ്സൈറ്റുകൾ ഇതിനകം agents, assistants, AI യുമായി ചേർന്ന് പ്രവർത്തിക്കുന്ന ആളുകൾ എന്നിവയെ ഒപ്പം സേവിക്കുന്നു. ഇത് നന്നായി കൈകാര്യം ചെയ്യുന്ന ടീമുകൾ ഏറ്റവും കർശനമായ filters ഉള്ളവരായിരിക്കില്ല. അവർ അവരുടെ തീരുമാനങ്ങൾ വിശദീകരിക്കാൻ കഴിയുന്നവരായിരിക്കും.

തെളിവ് അടിസ്ഥാനമാക്കിയ ഫലങ്ങൾ ആ വിശദീകരണം നൽകുന്നു. ഒരു support agent ഒരു user ന് അധിക verification step എന്തിന് കണ്ടുവെന്ന് ചോദിച്ചാൽ, ബാധകമായ തെളിവിനെയും policy യെയും നിങ്ങൾ കാണിക്കാം. ഒരു agent operator അവന്റെ signed requests structured response ആയി എന്തുകൊണ്ട് സേവിക്കപ്പെട്ടു എന്ന് ചോദിച്ചാൽ, നിങ്ങൾക്ക് verified basis കാണിക്കാം. തെളിവ് കുറവായിരിക്കുമ്പോൾ, ഫലം Unknown എന്ന് പറയുന്നു, പിന്നെ നിങ്ങൾ deliberate ആയി തിരഞ്ഞെടുത്ത fallback അതിനെ കൈകാര്യം ചെയ്യുന്നു.

ഈ സമീപനം വെബിനൊപ്പം വളരുകയും ചെയ്യുന്നു. കൂടുതൽ agent operators അവരുടെ requests sign ചെയ്യുമ്പോഴും, IETF Web Bot Auth working group പോലുള്ള standards work, automated clients ക്കായുള്ള cryptographic authentication standardize ചെയ്യുന്നതിലേക്ക് charter ചെയ്തിരിക്കുന്നത്, HTTP message signatures ന്റെ മുകളിൽ നിർമ്മിക്കുമ്പോഴും, നിങ്ങളുടെ traffic ന്റെ കൂടുതൽ ഭാഗം inferred അല്ലെങ്കിൽ unknown നിന്ന് verified ലേക്ക് മാറുന്നു, അതിനാൽ നിങ്ങളുടെ policies പുനരെഴുതാതെ തന്നെ കൂടുതൽ കൃത്യമാകുന്നു.

founding developer program ൽ ചേരുക

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

നിങ്ങളുടെ വെബ്സൈറ്റ് ആളുകൾക്കും, AI-assisted ഉപയോക്താക്കൾക്കും, agents ക്കും സേവനം നൽകുന്നുവെങ്കിൽ, അടുത്തത് എന്ത് സംഭവിക്കണമെന്ന് തീരുമാനിക്കുന്നതിന് മുമ്പ് അത് ആരാണ് ഉപയോഗിക്കുന്നത് എന്ന് അറിയാൻ നിങ്ങൾ ആഗ്രഹിക്കുന്നുവെങ്കിൽ, early access ന് അപേക്ഷിക്കുക. നിങ്ങളുടെ വെബ്സൈറ്റിനെക്കുറിച്ചും നിങ്ങൾ ഏറ്റവും കൂടുതൽ മനസ്സിലാക്കാൻ ആഗ്രഹിക്കുന്ന interaction നെയും കുറിച്ച് ഞങ്ങളോട് പറയുക, നിലവിലുള്ള beta യോട് അത് യോജിക്കുന്നുണ്ടോ എന്ന് ഞങ്ങൾ പരിശോധിക്കും.

ആദ്യം വിശദാംശങ്ങൾ കാണണമോ? Proof of Actor പരിശോധിക്കുക, എങ്ങനെ പ്രവർത്തിക്കുന്നു വായിക്കുക, അല്ലെങ്കിൽ തെളിവ് കൃത്യമായി എന്തെല്ലാം സ്ഥാപിക്കാനാകും, എന്തെല്ലാം കഴിയില്ല എന്ന് അവലോകനം ചെയ്യുക.

ഉറവിടങ്ങൾ

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.

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

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 വായിക്കുക

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

Proof of Actor ഉപയോഗിച്ച് വെബ്സൈറ്റുകൾക്കായുള്ള AI ഏജന്റ് കണ്ടെത്തൽ എങ്ങനെ പ്രവർത്തിക്കുന്നു?

നിങ്ങളുടെ integration വഴി ലഭ്യമായ സിഗ്നലുകൾ Proof of Actor ശേഖരിക്കുന്നു, ഉദാഹരണത്തിന് request signatures, client declarations, interaction signals എന്നിവ, പിന്നെ അതിന്റെ അടിസ്ഥാനത്തോടുകൂടി ഒരു വർഗീകരണം നൽകുന്നു: verified, declared, inferred അല്ലെങ്കിൽ unknown.

ഇത് ഇൻസ്റ്റാൾ ചെയ്താൽ ഏതെങ്കിലും സന്ദർശകരെ തടയുമോ?

ഇല്ല. Proof of Actor നിരീക്ഷണ മോഡിലാണ് ആരംഭിക്കുന്നത്. നിങ്ങളുടെ ടീം ഫലങ്ങൾ പരിശോധിക്കുന്നതിനിടെ നിങ്ങളുടെ വെബ്സൈറ്റ് മുമ്പുപോലെ തന്നെയാകും പ്രവർത്തിക്കുക, പിന്നീട് ഏതെങ്കിലും policy പ്രയോഗിക്കണോ എന്ന് നിങ്ങൾ തീരുമാനിക്കാം.

മറ്റൊരു tab ൽ ആരെങ്കിലും AI ഉപയോഗിച്ചതാണോ എന്ന് ഇത് പറയുമോ?

ഒരു വെബ്സൈറ്റിനും മറ്റൊരു tab ലെയോ മറ്റൊരു ഉപകരണത്തിലെയോ പ്രവർത്തനം കാണാൻ കഴിയില്ല. പിന്തുണയ്ക്കുന്ന ഒരു integration വഴി അത് declared ആണെങ്കിൽ അല്ലെങ്കിൽ observable ആണെങ്കിൽ Proof of Actor AI സഹായം റിപ്പോർട്ട് ചെയ്യുന്നു, മറ്റെല്ലാം രൂപകൽപ്പനപ്രകാരം വ്യക്തമായി തന്നെ നിലനിർത്തുന്നു.

തെളിവ് വ്യക്തമല്ലെങ്കിൽ എന്താണ് സംഭവിക്കുന്നത്?

ഫലം Unknown ആണ്. Unknown ഒരു first-class result ആണ്, സ്വാഭാവികമായി മനുഷ്യനായി ഒരിക്കലും കണക്കാക്കില്ല, ദോഷകരമെന്നായും ഒരിക്കലും കണക്കാക്കില്ല. ഓരോ route-ും അതിനെ എങ്ങനെ കൈകാര്യം ചെയ്യണമെന്ന് നിങ്ങളുടെ policy തീരുമാനിക്കുന്നു.

Proof of Actor ആരെ ലക്ഷ്യമാക്കി നിർമ്മിച്ചതാണ്?

SaaS applications, websites, APIs, MCP servers എന്നിവ പ്രവർത്തിപ്പിക്കുന്നതും, ഒരു അനുഭവം അല്ലെങ്കിൽ access policy തിരഞ്ഞെടുക്കുന്നതിന് മുമ്പ് ആരാണ് അല്ലെങ്കിൽ എന്താണ് പ്രവർത്തിക്കുന്നത് എന്ന് മനസ്സിലാക്കാൻ ആഗ്രഹിക്കുന്നതുമായ ടീമുകൾക്കായി.

എനിക്ക് എങ്ങനെ പ്രവേശനം ലഭിക്കും?

Proof of Actor private beta യിലാണുള്ളത്. early access ന് അപേക്ഷിക്കുക. തിരഞ്ഞെടുത്ത founding developer ടീമുകൾക്ക് സമ്മതിച്ച usage limits ഉള്ളിൽ 12 months വരെ free access ലഭിക്കാം.

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

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

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

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