താരതമ്യം

Proof of Actor vs ബോട്ട് മാനേജ്മെന്റ്: വ്യത്യസ്ത ചോദ്യങ്ങൾ, ഒരു stack

ബോട്ട് മാനേജ്മെന്റ് ദുരുപയോഗ ഓട്ടോമേഷനിൽ നിന്ന് നിങ്ങളുടെ infrastructure-നെ സംരക്ഷിക്കുന്നു. Proof of Actor നിങ്ങളുടെ application-ന് ആളുകൾ, AI-assisted users, agents എന്നിവയെ വ്യത്യസ്തമായി സേവിക്കാൻ ആവശ്യമായ actor context നൽകുന്നു. ഇവ എങ്ങനെ താരതമ്യം ചെയ്യുന്നു, ഒരുമിച്ച് എങ്ങനെ പ്രവർത്തിക്കുന്നു എന്നതാണ് ഇവിടെ.

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

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

ചുരുക്ക ഉത്തരം

ബോട്ട് മാനേജ്മെന്റ് automated traffic edge-ൽ തന്നെ നിർത്തണോ എന്ന് തീരുമാനിക്കുന്നു. Proof of Actor നിങ്ങളുടെ application-നെ ആരോ എന്തോ പ്രവർത്തിക്കുന്നു എന്ന് പറയുന്നു, Human, Human + AI, Agent അല്ലെങ്കിൽ Unknown, അതിന് പിന്നിലെ evidence-ോടെ, അതിനാൽ നിങ്ങളുടെ സ്വന്തം code-ന് ശരിയായ experience തിരഞ്ഞെടുക്കാം. ഇവ വ്യത്യസ്ത ചോദ്യങ്ങൾക്ക് ഉത്തരം നൽകുന്നു, അതുകൊണ്ടാണ് മിക്ക ടീമുകളും രണ്ടും ഒരുമിച്ച് പ്രവർത്തിപ്പിക്കുന്നത്.

മിക്ക web ചരിത്രത്തിലും, automated traffic-ന് security stack-ൽ ഒരേയൊരു ജോലി മാത്രമേ ഉണ്ടായിരുന്നുള്ളൂ: തിരിച്ചറിയപ്പെടുക, പിന്നെ നിർത്തപ്പെടുക. ബോട്ട് മാനേജ്മെന്റ് ആ ജോലിക്കായി വളർന്നു. അത് നിങ്ങളുടെ infrastructure-ന്റെ edge-ൽ ഇരുന്നു, requests score ചെയ്യുകയും ദുരുപയോഗം പോലെ തോന്നുന്നവ block ചെയ്യുകയോ challenge ചെയ്യുകയോ ചെയ്യുന്നു. അത് അതിൽ വളരെ നല്ലതാണ്, നിങ്ങൾ അത് നിലനിർത്തണം.

AI agents applications-ന് അറിയേണ്ടത് മാറ്റി. ഇന്ന് automated requests-ന്റെ വളരുന്നൊരു പങ്ക് യഥാർത്ഥ customers-ക്കായി പ്രവർത്തിക്കുന്ന agents-ൽ നിന്നാണ് വരുന്നത്: plans താരതമ്യം ചെയ്യുന്ന ഒരു assistant, ഒരു support ticket file ചെയ്യുന്ന ഒരു agent, ഒരു task പൂർത്തിയാക്കാൻ നിങ്ങളുടെ MCP server വിളിക്കുന്ന ഒരു client. അതേസമയം, പലരും നിങ്ങളുടെ product-നെ ഒരു AI assistant ഒപ്പം ഉപയോഗിക്കുന്നു. ഇവ attacks അല്ല. ഇവ users ആണ്, block page-ന് പകരം ശരിയായ experience അവർക്കർഹമാണ്.

അതാണ് Proof of Actor നിറയ്ക്കുന്ന gap. ഈ page രണ്ട് categories-യും വ്യക്തമായി താരതമ്യം ചെയ്യുന്നു, അതുവഴി ഓരോന്നും എവിടെയാണ് പെടുന്നത് എന്ന് നിങ്ങൾക്ക് കാണാം.

ചുരുക്കം

	ബോട്ട് മാനേജ്മെന്റ്	Proof of Actor
പ്രധാന ചോദ്യം	ഈ request നിർത്തണോ?	ആരോ എന്തോ പ്രവർത്തിക്കുന്നു, evidence എന്താണ്?
എവിടെയാണ് പ്രവർത്തിക്കുന്നത്	edge-ൽ, നിങ്ങളുടെ application-ന്റെ മുന്നിൽ	നിങ്ങളുടെ application, API അല്ലെങ്കിൽ MCP server-ന്റെ ഉള്ളിൽ
സാധാരണ output	allow, block അല്ലെങ്കിൽ challenge; പലപ്പോഴും ഒരു score	Human, Human + AI, Agent അല്ലെങ്കിൽ Unknown, കൂടാതെ ഒരു basis
AI-assisted ആളുകളെ എങ്ങനെ കാണുന്നു	സാധാരണയായി മറ്റ് ആളുകളിൽ നിന്ന് വേർതിരിക്കാനാവില്ല	വ്യത്യസ്ത class, Human + AI
വ്യക്തമല്ലാത്ത traffic-നെ എങ്ങനെ കാണുന്നു	പലപ്പോഴും challenge ചെയ്യുകയോ block ചെയ്യുകയോ ചെയ്യുന്നു	Unknown, നിങ്ങൾ ഓരോ route-ിലും തിരഞ്ഞെടുക്കുന്ന fallback-ോടെ
response ആരാണ് തീരുമാനിക്കുന്നത്	edge rule set	നിങ്ങളുടെ application code
install ചെയ്തപ്പോൾ default behavior	Enforcement	Observation; നിങ്ങൾ ഒരു policy ചേർക്കുന്നതുവരെ ഒന്നും മാറില്ല
മികച്ചത്	credential stuffing, scraping abuse, volumetric attacks നിർത്തൽ	ഓരോ actor-നുമുള്ള product, analytics, policy തീരുമാനങ്ങൾ

ഈ page-ന്റെ ബാക്കി ഓരോ row-യും വിശദീകരിക്കുന്നു.

രണ്ട് വ്യത്യസ്ത ചോദ്യങ്ങൾ

ബോട്ട് മാനേജ്മെന്റ് ഒരു protection ചോദ്യം ഉത്തരം നൽകുന്നു. അതിന്റെ ലക്ഷ്യം ദുരുപയോഗ ഓട്ടോമേഷൻ നിങ്ങളുടെ infrastructure-ൽ നിന്നും, accounts-ൽ നിന്നും, inventory-ൽ നിന്നും അകറ്റുക എന്നതാണ്. അത് ശേഖരിക്കുന്ന ഓരോ signal-ും ആ ലക്ഷ്യത്തിനായി സേവിക്കുന്നു, അതിന്റെ output ഒരു തീരുമാനമാണ്: request കടത്തിവിടുക, block ചെയ്യുക, അല്ലെങ്കിൽ അതിന്റെ മുന്നിൽ ഒരു challenge വയ്ക്കുക.

Proof of Actor ഒരു understanding ചോദ്യം ഉത്തരം നൽകുന്നു. ഓരോ interaction-ക്കും ആരോ എന്തോ ആണ് drive ചെയ്യുന്നത് എന്ന് നിങ്ങളുടെ application-ന് പറയുക എന്നതാണ് അതിന്റെ ലക്ഷ്യം, അതിനാൽ നിങ്ങൾ അത് എങ്ങനെ serve ചെയ്യണമെന്ന് തീരുമാനിക്കാം. അതിന്റെ output request-നെക്കുറിച്ചുള്ള ഒരു verdict അല്ല. ഇത് evidence ഉള്ള ഒരു classification ആണ്:

Human: observable signals മനുഷ്യൻ നയിച്ച interaction സൂചിപ്പിക്കുന്നു.
Human + AI: ഒരു person AI സഹായത്തോടെ interaction നയിച്ചു, അത് declared ആയോ observed ആയോ ആണ്.
Agent: automated അല്ലെങ്കിൽ agent-origin interaction, verifiable identity അല്ലെങ്കിൽ qualified inference-ോടെ പിന്തുണയ്ക്കപ്പെടുന്നത്.
Unknown: evidence വിശ്വസനീയമായ നിഗമനത്തെ പിന്തുണയ്ക്കുന്നില്ല.

ഓരോ result-ും അതിന്റെ evidence basis കൂടി പറയുന്നു: verified, declared, inferred അല്ലെങ്കിൽ unknown. അതാണ് ഒരു product തീരുമാനത്തിന് ആവശ്യമുള്ള വിവരം, protection score-ന് അതിനെ കൈവഹിക്കാൻ രൂപകൽപ്പന ചെയ്തിട്ടില്ല.

ഓരോന്നും എവിടെയാണ് പ്രവർത്തിക്കുന്നത്

ബോട്ട് മാനേജ്മെന്റ് സാധാരണയായി network edge-ലോ reverse proxy-ലോ, മറ്റെല്ലാറ്റിനും മുന്നിലോ ആണ് പ്രവർത്തിക്കുന്നത്. protection-നായി ആ സ്ഥാനം കൃത്യമാണ്. അത് traffic നേരത്തെ കാണുന്നു, attacks നിങ്ങൾക്ക് ചെലവ് വരുന്നതിന് മുമ്പ് തന്നെ ഏറ്റെടുക്കുന്നു, നിങ്ങളുടെ origin servers-നെ ശുദ്ധമായി സൂക്ഷിക്കുന്നു.

Proof of Actor നിങ്ങളുടെ application logic ഉള്ളിടത്താണ് പ്രവർത്തിക്കുന്നത്: server middleware, Next.js, നിങ്ങൾ നിയന്ത്രിക്കുന്ന edge layer, അംഗീകൃത browser integration, ഒരു generic HTTP API, അല്ലെങ്കിൽ നിങ്ങളുടെ MCP server. ആ സ്ഥാനം നിങ്ങളുടെ application അറിയുന്നതിലേക്ക് പ്രവേശനം നൽകുന്നു: ഏത് route ആണ് വിളിക്കപ്പെടുന്നത്, ഏത് workflow-ലാണ് അത് ഉള്ളത്, നിങ്ങളുടെ സ്വന്തം assistant ഒരു action ചെയ്തോ, ഒരു client സ്വയം പ്രഖ്യാപിച്ചോ തുടങ്ങിയവ. പൂർണ്ണ പട്ടികയ്ക്ക് integration paths കാണുക.

ഈ രണ്ടും വ്യത്യസ്ത സ്ഥലങ്ങളിൽ പ്രവർത്തിക്കുന്നതിനാൽ, ഒരേ ജോലി അവർക്ക് വേണ്ടി മത്സരിക്കേണ്ടതില്ല. ഒരു request നിങ്ങളുടെ ബോട്ട് മാനേജ്മെന്റ് കടന്ന്, നിങ്ങളുടെ application-ൽ എത്തി, തുടർന്ന് response രൂപപ്പെടുത്തുന്ന actor context ലഭിക്കാം.

scores versus evidence

പല protection products അവരുടെ വിധിയെ ഒരു score ആയി രേഖപ്പെടുത്തുന്നു. block decision-നായി ഒരു score കാര്യക്ഷമമാണ്: ഒരു threshold തിരഞ്ഞെടുക്കുക, അതിന് മുകളിൽ പ്രവർത്തിക്കുക. ചോദ്യം "ഈ actor-ന് ഏത് experience നൽകണം?" ആകുമ്പോൾ അത് വളരെ കുറച്ച് ഉപകാരപ്രദമാണ്.

ഒരു score ഒരു low-risk request ഒരു person-ൽ നിന്നോ, ഒരു assistant-ോടൊപ്പം പ്രവർത്തിക്കുന്ന person-ൽ നിന്നോ, അല്ലെങ്കിൽ നല്ല രീതിയിൽ പെരുമാറുന്ന ഒരു agent-ൽ നിന്നോ വന്നതാണോ എന്ന് പറയില്ല. നിഗമനത്തിന്റെ ഏത് ഭാഗങ്ങൾ verified ആയിരുന്നു, ഏത് inferred ആയിരുന്നു എന്നും അത് പറയില്ല. കൂടാതെ അതിനെ ഒരു number-ലേക്ക് തള്ളാതെ "ഞങ്ങൾക്ക് അറിയില്ല" എന്നും പ്രകടിപ്പിക്കാൻ കഴിയില്ല.

Proof of Actor ആ വ്യത്യാസങ്ങൾ നിലനിർത്തുന്നു. ഒരു verified agent result എന്നാൽ ഒരു request signature പ്രസിദ്ധീകരിച്ച key-നെതിരെ പരിശോധിച്ചതാണ്, ഉദാഹരണത്തിന് HTTP Message Signatures വഴി. ഒരു declared result എന്നാൽ ഒരു client അല്ലെങ്കിൽ നിങ്ങളുടെ സ്വന്തം application അത് പ്രഖ്യാപിച്ചതാണ്. ഒരു inferred result inference ആയി ലേബൽ ചെയ്യപ്പെടുന്നു. Unknown hidden default അല്ല, ഒരു first-class answer ആണ്. നിങ്ങളുടെ ടീമിന് ഓരോ result-ഉം വായിച്ച് അതിന്റെ അടിസ്ഥാനമായി എന്താണെന്ന് കൃത്യമായി കാണാം.

AI-assisted ആളുകൾ bots അല്ല

മിക്ക applications-ലും ഏറ്റവും വേഗത്തിൽ വളരുന്ന സംഘം AI-യോടൊപ്പം പ്രവർത്തിക്കുന്ന ആളുകളാണ്. അവർ ഒരു assistant-ോടെ messages തയ്യാറാക്കുന്നു, സഹായത്തോടെ forms പൂരിപ്പിക്കുന്നു, AI tool ഒപ്പം നിങ്ങളുടെ product-ിലൂടെ മുന്നേറുന്നു. Protection tooling ഇവരെ മറ്റ് ആളുകളിൽ നിന്ന് വേർതിരിക്കാൻ നിർമ്മിച്ചതല്ല, അതിന് അങ്ങനെ ചെയ്യാനുള്ള കാരണവും ഇല്ല.

നിങ്ങളുടെ product പലപ്പോഴും അങ്ങനെ ചെയ്യുന്നു. ശരിയായ ടീം അവ കൈകാര്യം ചെയ്യാൻ AI-drafted support tickets-നെ label ചെയ്യാൻ, onboarding-ിലൂടെ AI-assisted users എങ്ങനെ നീങ്ങുന്നു എന്ന് അളക്കാൻ, അല്ലെങ്കിൽ അവർക്കായി കൂടുതൽ സുഗമമായ path നൽകാൻ നിങ്ങൾ ആഗ്രഹിക്കാം. Proof of Actor ആ group-ന് സ്വന്തം class, Human + AI, നൽകുന്നു, കൂടാതെ പിന്തുണയുള്ള integration വഴി assistance declared ആയോ observable ആയോ ചെയ്താൽ മാത്രമേ അത് റിപ്പോർട്ട് ചെയ്യൂ. കൂടുതൽ അറിയാൻ AI-assisted interaction glossary entry കാണുക.

Unknown ഒരു ഉത്തരം ആണ്, ഭീഷണി അല്ല

ഓരോ classifier-ും വിശദീകരിക്കാൻ കഴിയാത്ത traffic നേരിടും. Protection systems caution-ലേക്ക് ചായാൻ നിർമ്മിച്ചതാണ്, അതിനാൽ വ്യക്തമല്ലാത്ത traffic പലപ്പോഴും ഒരു challenge-നെ നേരിടും. edge-ൽ അത് യുക്തിസഹമായ ഒരു തിരഞ്ഞെടുപ്പാണ്.

നിങ്ങളുടെ application-ന്റെ ഉള്ളിൽ, ഒരൊറ്റ cautious default പലപ്പോഴും ശരിയായ തിരഞ്ഞെടുപ്പല്ല. ഒരു public documentation page-ലേക്കുള്ള unknown request-നും ഒരു account password മാറ്റാനുള്ള unknown request-നും വളരെ വ്യത്യസ്ത handling ആവശ്യമുണ്ട്. Proof of Actor Unknown-നെ സ്വന്തം result ആയി തിരികെ നൽകുന്നു, കൂടാതെ ഓരോ route-ിലും fallback സജ്ജമാക്കാൻ അനുവദിക്കുന്നു: public pages-ൽ allow ചെയ്യുക, account changes-ൽ നിങ്ങളുടെ നിലവിലെ checks നിലനിർത്തുക, high-impact actions-ൽ review-ലേക്ക് route ചെയ്യുക. Unknown traffic കൈകാര്യം ചെയ്യൽ ഗൈഡ് patterns വിശദീകരിക്കുന്നു.

response ആരാണ് തീരുമാനിക്കുന്നത്

ബോട്ട് മാനേജ്മെന്റിൽ, edge-ലുള്ള rule set ആണ് തീരുമാനിക്കുന്നത്. നിങ്ങളുടെ properties മുഴുവൻ തീരുമാനങ്ങൾ സ്ഥിരതയോടെ നിലനിർത്താനും അത് കാര്യക്ഷമമാണ്.

Proof of Actor-ൽ, നിങ്ങളുടെ application ആണ് തീരുമാനിക്കുന്നത്. product actor context നൽകുന്നു; നിങ്ങളുടെ code policy പ്രയോഗിക്കുന്നു. verified agents-ന് ആളുകൾക്കായി നിർമ്മിച്ച pages-ന് പകരം structured API നൽകാനും, human sessions-ിന് standard experience നിലനിർത്താനും, AI-assisted submissions-ന് label നൽകാനും, നിങ്ങളുടെ own conditions ആവശ്യപ്പെടുമ്പോൾ sensitive actions-ൽ കൂടുതൽ ശക്തമായ credentials ചോദിക്കാനും നിങ്ങൾക്ക് കഴിയും. Policies ഓരോ route-നുമ്, actor class-നുമ്, basis-നുമ് അനുസരിച്ച് എഴുതപ്പെടുന്നു, അവ ബാക്കി business logic-ന്റെ സമീപത്താണ് നിലനിൽക്കുന്നത്.

ആദ്യം observation

ബോട്ട് മാനേജ്മെന്റ് സാധാരണയായി enforce ചെയ്യാൻ install ചെയ്യപ്പെടുന്നു, കാരണം അതിന്റെ മുഴുവൻ മൂല്യവും ദുരുപയോഗം നിർത്തുന്നതിലാണ്.

Proof of Actor observation mode-ലാണ് ആരംഭിക്കുന്നത്. അത് install ചെയ്താൽ നിങ്ങളുടെ application എങ്ങനെ പെരുമാറുന്നു എന്നതിൽ ഒന്നും മാറില്ല. ഓരോ route-ലുമുള്ള നിങ്ങളുടെ യഥാർത്ഥ actor mix നിങ്ങൾ കാണുന്നു, evidence പരിശോധിക്കുന്നു, ഒരു policy യഥാർത്ഥ traffic-ിനെതിരെ ഉണ്ടാക്കുന്ന effect preview ചെയ്യുന്നു, നിങ്ങൾ തയ്യാറാകുമ്പോൾ മാത്രം, ഓരോ route-ഉം ഒരുമിച്ച് അല്ലാതെ, enforce ചെയ്യുന്നു. actor-aware policies സുരക്ഷിതമായി roll out ചെയ്യൽ ഗൈഡ് പ്രക്രിയ വിശദീകരിക്കുന്നു.

ഈ രണ്ട് എങ്ങനെ ഒരുമിച്ച് പ്രവർത്തിക്കുന്നു

ഏറ്റവും ശക്തമായ setup രണ്ട്-ഉം ഉപയോഗിക്കുന്നു, ഓരോന്നും സ്വന്തം layer-ൽ:

edge-ൽ, ബോട്ട് മാനേജ്മെന്റ് credential stuffing, scraping abuse, volumetric attacks എന്നിവ നിർത്തുന്നു.
നിങ്ങളുടെ application-ൽ, Proof of Actor കടന്നുപോയ traffic-നെ Human, Human + AI, Agent അല്ലെങ്കിൽ Unknown ആയി, അതിന്റെ basis-ോടെ, classifies ചെയ്യുന്നു.
നിങ്ങളുടെ code-ൽ, policies ആ context ഉപയോഗിച്ച് experience തിരഞ്ഞെടുക്കുന്നു: verified agent-ിന് structured API, ഒരു person-ിന് normal flow, AI-assisted submission-ന് label, Unknown-യ്ക്ക് explicit fallback.
നിങ്ങളുടെ analytics-ൽ, ഏത് route-ുകളും workflows-ഉം ഓരോ actor class-ഉം ഉപയോഗിക്കുന്നു എന്ന് നിങ്ങളുടെ ടീം കാണുന്നു, അതുവഴി product, security ഒരേ picture-ൽ നിന്നാണ് പ്രവർത്തിക്കുന്നത്.

edge decision actor result-ിന് അടുത്തായി record ചെയ്യുന്നത് picture പൂർണ്ണമാക്കുന്നു: protection എന്ത് ചെയ്തു, യഥാർത്ഥത്തിൽ ആരാണ് പ്രവർത്തിച്ചത്.

ഏതെന്ന് തിരഞ്ഞെടുക്കണം

നിങ്ങളുടെ പ്രധാന പ്രശ്നം abuse ആണെങ്കിൽ ബോട്ട് മാനേജ്മെന്റ് തിരഞ്ഞെടുക്കുക: account takeover ശ്രമങ്ങൾ, inventory hoarding, aggressive scraping, അല്ലെങ്കിൽ traffic floods.

നിങ്ങളുടെ പ്രധാന ചോദ്യം നിങ്ങളുടെ users-നെക്കുറിച്ചാണെങ്കിൽ Proof of Actor തിരഞ്ഞെടുക്കുക: നിങ്ങളുടെ product-നെ agent-ുകൾ എത്രമാത്രം already ഉപയോഗിക്കുന്നു, ഏത് agents നിങ്ങളുടെ API അല്ലെങ്കിൽ MCP server വിളിക്കുന്നു, AI-assisted people എവിടെയാണ് ബുദ്ധിമുട്ടുന്നത്, ഏതെല്ലാം routes actor-aware policy ആവശ്യപ്പെടുന്നു.

ഒരു production application, API അല്ലെങ്കിൽ MCP server പ്രവർത്തിപ്പിക്കുന്ന മിക്ക ടീമുകൾക്കും ഈ രണ്ടിനും ഉത്തരം വേണം, അതുകൊണ്ടാണ് അവ ഒരേ stack-ൽ പെട്ടിരിക്കുന്നത്.

തുടങ്ങുക

Proof of Actor private beta-യിലാണ്. തിരഞ്ഞെടുത്ത founding developer ടീമുകൾക്ക് സമ്മതിച്ച usage limits-ന്റെ ഉള്ളിൽ, ഇതിനെ നിർമ്മിക്കുന്ന ടീമിൽ നിന്ന് നേരിട്ടുള്ള പിന്തുണയോടെ, 12 months വരെ സൗജന്യ access ലഭിക്കാം. early access-ന് അപേക്ഷിക്കുക ಮತ್ತು നിങ്ങൾക്ക് മനസ്സിലാക്കാൻ ആഗ്രഹിക്കുന്ന application, interaction എന്നിവയെക്കുറിച്ച് ഞങ്ങളോട് പറയുക.

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

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 ബോട്ട് മാനേജ്മെന്റിനെ മാറ്റിസ്ഥാപിക്കുമോ?

ഇല്ല. ബോട്ട് മാനേജ്മെന്റ് credential stuffing, scraping abuse, volumetric attacks പോലുള്ള ദുരുപയോഗ ഓട്ടോമേഷൻ നിങ്ങളുടെ application-ൽ എത്തുന്നതിനുമുമ്പ് നിർത്തുന്നു. Proof of Actor നിങ്ങളുടെ application-ന്റെ ഉള്ളിൽ പ്രവർത്തിച്ച് product, policy തീരുമാനങ്ങൾക്കായി actor context നൽകുന്നു. രണ്ടും നിലനിർത്തുക.

Product തീരുമാനങ്ങൾ എടുക്കാൻ bot score ഉപയോഗിക്കാത്തത് എന്തുകൊണ്ട്?

ഒരു bot score request നിർത്തണോ എന്ന ചോദ്യത്തിന് ഉത്തരം നൽകാനാണ് നിർമ്മിച്ചിരിക്കുന്നത്. ഒരു person AI-യോടൊപ്പം പ്രവർത്തിച്ചിരുന്നോ, ഏത് agent ആണ് വിളിക്കുന്നത്, score ഏത് evidence-ിലാണ് അടിസ്ഥാനപ്പെടുന്നത് എന്നൊന്നും അതിൽ സാധാരണയായി പറയില്ല. Proof of Actor ഒരു class ഉം explicit basis ഉം നൽകുന്നു, product തീരുമാനങ്ങൾക്ക് അതാണ് ആവശ്യം.

ഈ രണ്ടിനും signals പങ്കിടാനാകുമോ?

അതെ. നിങ്ങളുടെ application edge controls-ന്റെ outcome Proof of Actor result-ിനൊപ്പം record ചെയ്യാം, അതുവഴി ഒരേ request-ിന് protection decision ഉം actor context ഉം നിങ്ങളുടെ ടീമിന് കാണാം.

Proof of Actor traffic block ചെയ്യുമോ?

ഇല്ല. ഇത് observation mode-ൽ തുടങ്ങി, നിങ്ങൾ ഒരു policy എഴുതുന്നതുവരെ ഒന്നും മാറ്റുന്നില്ല. Enforcement എപ്പോഴും നിങ്ങളുടെ സ്വന്തം application code-ലാണ് നിലകൊള്ളുന്നത്.

ആദ്യം ഏതാണ് ചേർക്കേണ്ടത്?

നിങ്ങൾക്ക് active abuse നേരിടുന്നുണ്ടെങ്കിൽ ആദ്യം ബോട്ട് മാനേജ്മെന്റ് തുടങ്ങുക. നിങ്ങൾ ഇതിനകം നിങ്ങളുടെ product ഉപയോഗിക്കുന്ന ആളുകൾ, AI-assisted users, agents എന്നിവയെ മനസ്സിലാക്കാനും അവരെ സേവിക്കാനും ആഗ്രഹിക്കുന്നുവെങ്കിൽ Proof of Actor ചേർക്കുക. മിക്ക production ടീമുകളും അവസാനം രണ്ടും ഉപയോഗിക്കുന്നു.

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

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

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

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