AI ഏജന്റ് തിരിച്ചറിയൽ

APIകൾക്കായുള്ള AI ഏജന്റ് തിരിച്ചറിയൽ

നിങ്ങളുടെ APIയ്ക്ക് ഏതെ key request ഉണ്ടാക്കിയെന്നു ഇതിനകം അറിയാം. അതിന് പിന്നിൽ ഏതുതരം actor ആയിരുന്നുവെന്ന് Proof of Actor പറയുന്നു, അതിനെ പിന്തുണക്കുന്ന തെളിവ് എന്താണെന്നും പറയുന്നു, തുടർന്ന് എന്ത് സംഭവിക്കണം എന്ന് നിങ്ങളുടെ code തീരുമാനിക്കട്ടെ.

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

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

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

ഒരു API key നിങ്ങൾക്ക് ആരുടെ account ആണ് call ചെയ്യുന്നതെന്ന് പറയുന്നു, പക്ഷേ requestയ്ക്ക് പിന്നിൽ ഏത് തരത്തിലുള്ള client ആണെന്നു പറയില്ല. ലഭ്യമായിടത്ത് request signatures ഉം client declarations ഉം ഉപയോഗിച്ച് Proof of Actor ഓരോ API request നും actor context ചേർക്കുന്നു, അതുവഴി നിങ്ങൾക്ക് ഓരോ actor class നും route നും അനുസരിച്ച് limits ന്റെയും policies ന്റെയും പരിധികൾ സജ്ജമാക്കാം.

നിങ്ങളുടെ API key അറിയുന്നു. actor അറിയുന്നില്ല.

ഓരോ API request നും ആരാണ് ഇതിന് പണം നൽകുന്നത് എന്നതിന്റെ ചില തെളിവുകൾ ഉണ്ടാകും: ഒരു API key, ഒരു OAuth token, ഒരു session. ആ തെളിവ് ഒരു ചോദ്യം നന്നായി മറുപടി നൽകുന്നു. കോൾക്ക് ഉത്തരവാദി ഏത് account ആണെന്ന് അത് പറയുന്നു. ഇപ്പോൾ call ചെയ്യുന്നത് യഥാർത്ഥത്തിൽ എന്താണെന്ന് അത് പറയുന്നില്ല.

ഒരു ഏക API key ഒരു terminal ൽ ടെസ്റ്റ് ചെയ്യുന്ന developer, ഒരു schedule പ്രകാരം പ്രവർത്തിക്കുന്ന backend job, ഒരു AI assistant വഴി പ്രവർത്തിക്കുന്ന ഒരു person, കൈയിൽ key നൽകി ഒരു task പൂർത്തിയാക്കാൻ പറഞ്ഞ autonomous agent എന്നിവ ഉപയോഗിക്കാം. ഇവ വളരെ വ്യത്യസ്തമായ actors ആണ്. അവയ്ക്ക് വ്യത്യസ്ത rhythms ഉം, വ്യത്യസ്ത failure modes ഉം, വ്യത്യസ്ത risk profiles ഉം ഉണ്ട്. അവയെല്ലാം ഒരേ രീതിയിൽ കൈകാര്യം ചെയ്യുന്നതിലൂടെ, നിങ്ങളുടെ customers ആശ്രയിക്കുന്ന legitimate automation നിങ്ങൾ അതിയായി നിയന്ത്രിക്കുകയോ, അല്ലെങ്കിൽ unattended agent നിയന്ത്രിക്കരുതായിരിക്കുന്ന നിങ്ങളുടെ API ഭാഗങ്ങളെ വേണ്ടത്ര സംരക്ഷിക്കാതിരിക്കുകയോ ചെയ്യും.

APIകൾക്കായുള്ള AI agent തിരിച്ചറിയൽ ആ gap അടയ്ക്കുന്നു. key ൽ നിന്ന് എല്ലാം അനുമാനിക്കുന്നതിന് പകരം, ഓരോ request ന്റെയും പിന്നിലെ actor ന്റെ വർഗ്ഗീകരണവും അതിനെ പിന്തുണയ്ക്കുന്ന തെളിവും നിങ്ങൾക്ക് ലഭിക്കും. അതാണ് Proof of Actor നൽകാൻ രൂപകൽപ്പന ചെയ്തിരിക്കുന്നത്, കൂടാതെ APIs use case API ടീമുകൾ അത് route by route എങ്ങനെ പ്രയോഗിക്കുന്നു എന്ന് കാണിക്കുന്നു.

API ടീമുകൾക്ക് ഇപ്പോൾ actor context എന്തുകൊണ്ട് ആവശ്യമുണ്ട്

APIകളിലേക്കുള്ള automated traffic പുതിയത് അല്ല. scripts, integrations, crawlers എന്നിവ എപ്പോഴും ചിത്രത്തിന്റെ ഭാഗമായിരുന്നു. മാറിയത് automation ന്റെ സ്വഭാവമാണ്. AI agents documentation വായിക്കാനും, calls ചേർത്തുകൊണ്ട് മുന്നോട്ട് പോകാനും, സൃഷ്ടിപരമായി retry ചെയ്യാനും, ഓരോ ഘട്ടവും ശ്രദ്ധിക്കാത്ത ആളുകൾക്ക് വേണ്ടി പ്രവർത്തിക്കാനും കഴിയും. അവയിൽ പലതും ഉപകാരപ്രദവും സ്വാഗതാർഹവുമാണ്. ചിലത് മോശമായി നിർമ്മിച്ചതാണ്. കുറെ hostile ആണ്.

actor context ഇല്ലാതെ, API ടീമുകൾ സാധാരണയായി കട്ടിയുള്ള tools ലേക്കാണ് മടങ്ങുന്നത്:

ഓരോ key ക്കുമുള്ള rate limits, good agents നെയും bad agents നെയും ഒരുപോലെ മന്ദഗതിയാക്കുന്നത്.
User-agent rules, client ഒരു header മാറ്റുന്ന നിമിഷം തന്നെ തകരുന്നത്.
Blanket blocks, legitimate automation നിങ്ങളുടെ web app scrape ചെയ്യാൻ തള്ളിവിടുന്നത്.

actor context നിങ്ങളെ കൃത്യതയോടെ പ്രതികരിക്കാൻ സഹായിക്കുന്നു. നിങ്ങൾ അറിയുന്ന operator ന്റെ ഒരു signed agent ന് read routes ൽ ഉയർന്ന limit നൽകാം. write route ലേക്ക് എത്തുന്ന unknown caller ന് ശക്തമായ credential ആവശ്യപ്പെടാം. ഒരു AI assistant ഉപയോഗിക്കുന്ന മനുഷ്യന് സാധാരണ അനുഭവം തുടരാം. ലക്ഷ്യം agents നെ നിർത്തുക അല്ല. ഓരോ തരത്തിലുള്ള caller നും ശരിയായ പാത നൽകുക തന്നെയാണ്. ഒരു signed request എന്ത് പറയുകയും എന്ത് പറയാതിരിക്കുകയും ചെയ്യുന്നു എന്നത് അറിയാൻ signed AI agent requests എന്ത് തെളിയിക്കുന്നു വായിക്കുക.

Proof of Actor ൽ AI agent തിരിച്ചറിയൽ എങ്ങനെ പ്രവർത്തിക്കുന്നു

Proof of Actor ഓരോ request നും ഒരേ evidence-first flow പിന്തുടരുന്നു. മുഴുവൻ വിശദീകരണം How It Works ൽ വായിക്കാം; API ടീമുകൾക്കായുള്ള ചുരുക്കം ഇതാ.

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

നിങ്ങളുടെ integration ആ context ൽ ലഭ്യമായ signals Proof of Actor ലേക്ക് നൽകുന്നു. ഒരു API യിൽ, സാധാരണയായി അതിൽ headers, protocol details പോലുള്ള request context, client നൽകുന്ന ഏതെങ്കിലും cryptographic request signatures, കൂടാതെ client തനിയെ കുറിച്ച് നൽകുന്ന ഏതെങ്കിലും declarations എന്നിവ ഉൾപ്പെടുന്നു. ഓരോ signal നും അത് എവിടെ നിന്നാണ് വന്നതെന്ന് ലേബൽ ചെയ്യുന്നു.

2. basis ഉള്ള classification

signals പരിശോധിച്ച് കൂട്ടിച്ചേർത്ത് നാല് public classes ലെ ഒന്നാക്കി മാറ്റുന്നു:

Human: കാണാൻ കഴിയുന്ന signals human-directed interaction സൂചിപ്പിക്കുന്നു.
Human + AI: AI സഹായം പ്രഖ്യാപിക്കപ്പെട്ടിട്ടുണ്ടോ അല്ലെങ്കിൽ അത് നിരീക്ഷിക്കാൻ കഴിയുന്ന integration വഴി കണ്ടെത്തപ്പെട്ടിട്ടുണ്ടോ എന്നത്.
Agent: automation അല്ലെങ്കിൽ agent-origin traffic, സ്ഥിരീകരിക്കാവുന്ന identity അല്ലെങ്കിൽ സൂക്ഷ്മമായി യോഗ്യമായ inference പിന്തുണയ്ക്കുന്നു.
Unknown: വിശ്വസനീയമായ നിർണ്ണയത്തിന് തെളിവ് മതിയാവുന്നില്ല.

ഓരോ result നും അതിന്റെ basis കൂടെയുണ്ട്: Verified, Declared, Inferred അല്ലെങ്കിൽ Unknown. API ടീമുകൾ ഏറ്റവും വിലമതിക്കുന്ന ഭാഗം ഇതാണ്. പ്രസിദ്ധീകരിച്ച key ന് എതിരായി സാധുത തെളിയിക്കുന്ന നിങ്ങളുടെ HTTP message signature, RFC 9421 ൽ നിർവ്വചിച്ചിരിക്കുന്നതുപോലെ, verified ആയി റിപ്പോർട്ട് ചെയ്യപ്പെടുന്നു. ഒരു client താനെ agent ആണെന്ന് പറയുകയാണെങ്കിൽ അത് declared ആയി റിപ്പോർട്ട് ചെയ്യപ്പെടുന്നു. automated പോലെ തോന്നുന്ന pattern inferred ആയി റിപ്പോർട്ട് ചെയ്യപ്പെടുന്നു. ഫലം cryptography യിലാണോ heuristic ലാണോ ആശ്രയിക്കുന്നത് എന്ന് നിങ്ങൾക്ക് ഒരിക്കലും സംശയിക്കേണ്ടതില്ല. evidence basis ഉത്തരത്തിന്റെ ഭാഗമാണ്.

3. നിങ്ങളുടെ code പ്രവർത്തിക്കാൻ കഴിയുന്ന ഒരു result

result class, basis, വായിക്കാൻ കഴിയുന്ന evidence summary എന്നിവയോടെ നിങ്ങളുടെ application ലേക്ക് തിരികെ വരുന്നു. അതിനോട് എന്ത് ചെയ്യണമെന്ന് നിങ്ങളുടെ code തീരുമാനിക്കുന്നു. observation mode ൽ, നിങ്ങൾ അതിനെ രേഖപ്പെടുത്തുക മാത്രം ചെയ്യുന്നു. തയ്യാറായാൽ, അതിനെ അടിസ്ഥാനമാക്കി route ചെയ്യാം.

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

Proof of Actor ഒരു product ആണ്, മൂന്ന് capabilities സഹിതം.

Detect

നിങ്ങളുടെ API കാണാൻ കഴിയുന്ന actor signals ശേഖരിച്ച് verified assertions നെ behavioral inferences ൽ നിന്ന് വേർതിരിക്കുക. Signed agent requests, declared clients, automation signals, Unknown results എന്നിവ എല്ലാം വ്യത്യസ്തമായി സൂക്ഷിക്കുന്നു, അതിനാൽ ഒന്നും മിണ്ടാതെ ഒരൊറ്റ score ലേക്ക് ലയിക്കുന്നില്ല.

Understand

ഏത് actors ആണ് ഏത് routes വിളിക്കുന്നത്, അത് സമയത്തിനൊപ്പം എങ്ങനെ മാറുന്നു, ഓരോ classification ന്റെയും പിന്നിൽ എന്ത് തെളിവ് ആണ് ഉള്ളത് എന്നിവ കാണുക. unknown rate ദൃശ്യമായിത്തന്നെ നിലനിൽക്കുന്നു, അതിലൂടെ നിങ്ങളുടെ coverage എവിടെയാണ് അവസാനിക്കുന്നത്, എവിടെയാണ് ശക്തമായ signal സഹായകരമാകുന്നത് എന്നിവ കൃത്യമായി അറിയാം.

Route

route നും risk tier നും അനുസരിച്ച് policies എഴുതുക: allow, adapt, challenge, review അല്ലെങ്കിൽ rate-limit. verified agents ന് read-only endpoints ൽ ഘടിതവും ഉദാരവുമായ പാത നിലനിർത്തുക. high-impact operations ൽ ശക്തമായ credentials ചോദിക്കുക. Unknown നും timeouts നും വ്യക്തമായ fallback നിർവ്വചിക്കുക, അതുവഴി എന്തു സംഭവിച്ചാലും നിങ്ങളുടെ API പ്രവചനയോഗ്യമായി പെരുമാറും. ഓരോ policy യും എങ്ങനെ fail ആകണമെന്ന്, open ആണോ closed ആണോ എന്നത്, ആ route ൽ ഒരു പിഴവിന്റെ ചെലവ് അടിസ്ഥാനമാക്കി നിങ്ങൾ തീരുമാനിക്കുന്നു.

Identity evidence, credentials, authorization എന്നവ മൂന്നു വ്യത്യസ്ത കാര്യങ്ങളാണ്

agent-aware API design ൽ ഏറ്റവും പൊതുവായ പിഴവ് മൂന്ന് വേറിട്ട ചോദ്യങ്ങളെ ഒന്നാക്കുന്നതാണ്. Proof of Actor അവയെ വേർതിരിച്ചു നിർത്തുന്നു, നിങ്ങളുടെ design ഉം അങ്ങനെ തന്നെ ആകണം.

Identity evidence: ഏത് തരത്തിലുള്ള actor ആണ് വിളിക്കുന്നത്, അത് എന്ത് തെളിയിക്കുന്നു? ഇതാണ് AI agent തിരിച്ചറിയൽ നൽകുന്നത്. ഒരു verified signature ഒരു request നെ ഒരു key യുമായും അതിന്റെ published operator identifier യുമായും ബന്ധിപ്പിക്കുന്നു. automated clients നുള്ള ഇത്തരത്തിലുള്ള cryptographic authentication standardize ചെയ്യാൻ IETF Web Bot Auth working group charter ചെയ്തിട്ടുണ്ട്, അതിന്റെ scope end user നെയല്ല, agent നെയാണു authenticate ചെയ്യുന്നത്.
Credentials: ഈ call നു ഉത്തരവാദി ഏത് account ആണ്? ഇത് നിങ്ങൾ പുറപ്പെടുവിക്കുകയും കൈകാര്യം ചെയ്യുകയും ചെയ്യുന്ന നിങ്ങളുടെ API key, token അല്ലെങ്കിൽ session ആണ്.
Authorization: ഈ caller ന് ഇത് ചെയ്യാൻ അനുവാദമുണ്ടോ? ഇത് നിങ്ങളുടെ permission model ആണ്.

ഒരു verified agent സ്വയം authorized agent ആകുന്നില്ല. ഒരു valid signature ഒരു person agent ന് authority നൽ‍കിയെന്ന് തെളിയിക്കുന്നില്ല, അത് ആവശ്യപ്പെട്ട action സുരക്ഷിതമാണെന്ന് കൂടിയല്ല. Proof of Actor ആദ്യ ചോദ്യം സംബന്ധിച്ച് വിശ്വസനീയമായ context നൽകുന്നു, രണ്ടാമത്തെയും മൂന്നാമത്തെയും അവ അവകാശപ്പെട്ടിടത്ത് തന്നെ വിടുന്നു: നിങ്ങളുടെ application ൽ. agent authorization നെക്കുറിച്ചും, evidence എന്ത് സ്ഥാപിക്കാനാകും എന്ത് സ്ഥാപിക്കാനാവില്ല എന്നതും Detection & Limitations ൽ കൂടുതൽ വായിക്കുക.

Unknown ഒരു feature ആണ്, failure അല്ല

Request signing ഐച്ഛികമാണ്, unsigned client തനിക്ക് ഇഷ്ടമുള്ള വിധത്തിൽ തന്നെ സ്വയം വിവരിക്കാം. ഓരോ request നെയും Human അല്ലെങ്കിൽ Agent ആക്കാൻ നിർബന്ധിക്കുന്ന ഒരു system ചില സമയങ്ങളിൽ ആത്മവിശ്വാസത്തോടെ തെറ്റും, അത് സംഭവിക്കുമ്പോൾ നിങ്ങൾക്ക് അറിയാനാകില്ല.

evidence ഒരു നിർണ്ണയം പിന്തുണയ്ക്കാത്തപ്പോൾ Proof of Actor Unknown റിപ്പോർട്ട് ചെയ്യുന്നു. Unknown ഒരിക്കലും Human ആയി മാറ്റപ്പെടുന്നില്ല, default ആയി malicious ആയും കണക്കാക്കുന്നില്ല. നിങ്ങളുടെ policy ഓരോ route നും Unknown എന്താണ് അർത്ഥമാക്കുന്നത് എന്ന് നിർവ്വചിക്കുന്നു: public reads ന് allow ചെയ്യുക, account changes ന് നിലവിലുള്ള checks നിലനിർത്തുക, stakes ഉയർന്നിടത്ത് review ക്കായി queue ചെയ്യുക. Unknown ദൃശ്യമായി നിലനിർത്തുന്നതാണ് നിങ്ങളുടെ മറ്റു classifications വിശ്വസനീയമാക്കുന്നത്. handling unknown traffic എന്ന guide അത് എങ്ങനെ രൂപകൽപ്പന ചെയ്യാമെന്ന് കാണിക്കുന്നു.

നിങ്ങളുടെ stack ൽ AI agent തിരിച്ചറിയൽ എവിടെയാണ് പറ്റുന്നത്

Proof of Actor നിങ്ങളുടെ നിലവിലുള്ള gateway, authentication, rate limiting എന്നിവയ്ക്കൊപ്പം ഇരിക്കുന്നു. അത് ഇവയിൽ ഒന്നിനെയും മാറ്റിസ്ഥാപിക്കുന്നില്ല. സാധാരണ placements ഇതാണ്:

Server-side middleware route handlers ന്റെ മുൻപിൽ, അതുവഴി നിങ്ങളുടെ business logic പ്രവർത്തിക്കുന്നതിന് മുമ്പ് ഓരോ request നും വിലയിരുത്തപ്പെടുന്നു.
At the edge, അതുവഴി requests നിങ്ങളുടെ origin ലേക്ക് എത്തുന്നതിനുമുമ്പ് signals വിലയിരുത്തപ്പെടുന്നു.
Generic HTTP integration, അതുവഴി ഏത് stack നും request context അയയ്ക്കാനും basis സഹിതം ഒരു result സ്വീകരിക്കാനും കഴിയും.

onboarding സമയത്ത് ഓരോ founding team നും കൈകോർത്തുള്ള integrations നൽകുന്നു, അതിനാൽ പാത നിങ്ങളുടെ architecture ന് ഒത്തിരിക്കും, മറിച്ചല്ല. developer hub ഇന്ന് ലഭ്യമായ integration paths കാണിക്കുന്നു. നിങ്ങൾ agents നുവേണ്ടി tools പ്രവർത്തിപ്പിക്കുന്നുവെങ്കിൽ, MCP Servers use case tool calls നുള്ള പ്രത്യേക patterns ഉൾക്കൊള്ളുന്നു.

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

Proof of Actor ഇൻസ്റ്റാൾ ചെയ്താൽ നിങ്ങളുടെ API പ്രതികരിക്കുന്ന രീതി മാറില്ല. നിങ്ങളുടെ team നു അറിയാവുന്ന outcomes നോട് അവ താരതമ്യം ചെയ്യാനും, agents യഥാർത്ഥത്തിൽ എവിടേക്ക് പോകുന്നു എന്ന് കാണാനും, ഓരോ route ലെയും unknown rate അളക്കാനും, തെറ്റായി തോന്നുന്ന ഏതെങ്കിലും classification പരിശോധിക്കാനും result കൾ രേഖപ്പെടുത്തപ്പെടുന്നു. അതിനുശേഷം മാത്രമാണ് evidence പിന്തുണയ്ക്കുന്നിടത്ത്, route by route ആയി ഒരു policy enable ചെയ്യുന്നത്.

ഇതാണ് നിങ്ങൾ AI agent തിരിച്ചറിയൽ customers നെ അപ്രതീക്ഷിതമായി ആശ്ചര്യപ്പെടുത്തുകയോ അവർ ആശ്രയിക്കുന്ന integrations തകരുകയോ ചെയ്യാതെ rollout ചെയ്യുന്നത്. rolling out actor-aware policies safely എന്ന guide ഈ ക്രമം ഘട്ടംഘട്ടമായി വിശദീകരിക്കുന്നു.

founding developer program ൽ ചേരുക

Proof of Actor ചെറിയ ഒരു founding development teams കൂട്ടത്തോടെ private beta യിലാണ്. തിരഞ്ഞെടുത്ത teams ന് onboarding സമയത്ത് agreed usage limits നുള്ളിൽ up to 12 months free access, ഞങ്ങളുടെ engineers നിൽ നിന്നുള്ള നേരിട്ടുള്ള integration support, കൂടാതെ ഞങ്ങൾ തുടർന്ന് എന്ത് നിർമ്മിക്കുന്നു എന്നതിൽ യഥാർത്ഥ സ്വാധീനം എന്നിവ ലഭിക്കും.

നിങ്ങൾ ഒരു API പ്രവർത്തിപ്പിക്കുന്നുവെങ്കിൽ അതിനെ യഥാർത്ഥത്തിൽ ആരാണ് വിളിക്കുന്നത് എന്ന് അറിയാൻ ആഗ്രഹിക്കുന്നുവെങ്കിൽ, early access ന് അപേക്ഷിക്കുക. നിങ്ങളുടെ API, നിങ്ങൾക്ക് ഏറ്റവും പ്രധാനമായിരിക്കുന്ന routes, actor context ഉണ്ടെങ്കിൽ നിങ്ങൾ വ്യത്യസ്തമായി എടുക്കുന്ന തീരുമാനങ്ങൾ എന്നിവയെക്കുറിച്ച് ഞങ്ങളോട് പറയുക. Proof of Actor എങ്ങനെ പറ്റുന്നുവെന്ന് ഞങ്ങൾ നിങ്ങളോട് പറയും.

Sources

RFC 9421: HTTP Message Signatures, IETF, February 2024.
Web Bot Auth (webbotauth) working group charter, IETF.

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

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 agent തിരിച്ചറിയൽ API key authentication നിൽ നിന്ന് എങ്ങനെ വ്യത്യസ്തമാണ്?

ഒരു API key നിങ്ങൾക്ക് ഏത് account ആണ് request അയച്ചതെന്ന് പറയുന്നു. AI agent തിരിച്ചറിയൽ requestയ്ക്ക് പിന്നിൽ ഏത് തരത്തിലുള്ള actor ആണെന്നും ആ നിഗമനത്തെ എന്ത് തെളിവാണ് പിന്തുണയ്ക്കുന്നതെന്നും പറയുന്നു. നിങ്ങള്‍ക്ക് രണ്ടും വേണം, അവ വ്യത്യസ്ത ചോദ്യങ്ങൾക്ക് ഉത്തരം നൽകുന്നു.

എന്റെ API വിളിക്കുന്ന ഓരോ AI agent നെയും Proof of Actor തിരിച്ചറിയാനാകുമോ?

Proof of Actor താൻ കാണുന്ന ഓരോ request നെയും Human, Human + AI, Agent അല്ലെങ്കിൽ Unknown ആയി വർഗ്ഗീകരിക്കുകയും ഓരോ ഫലത്തിന്റെയും basis വ്യക്തമാക്കുകയും ചെയ്യുന്നു. തെളിവ് മതിയായ ശക്തിയില്ലെങ്കിൽ, ഫലം അനുമാനം അല്ലാതെ Unknown ആയിരിക്കും.

ഒരു agent നെ തിരിച്ചറിയുന്നത് അതിന് പ്രവർത്തിക്കാൻ അനുമതി ഉണ്ടെന്നർത്ഥമാണോ?

അല്ല. തിരിച്ചറിയലും authorization ഉം വേറിട്ട കാര്യങ്ങളാണ്. Proof of Actor നിങ്ങളുടെ application ന് കോളറിനെക്കുറിച്ചുള്ള context നൽകുന്നു, അതിന് ആ കോളർ എന്ത് ചെയ്യാം എന്ന് നിങ്ങളുടെ സ്വന്തം authorization rules തീരുമാനിക്കുന്നു.

Proof of Actor എന്റെ API യിലേക്കുള്ള requestകൾ തടയുമോ?

നിങ്ങൾ അത് വേണമെന്ന് തീരുമാനിച്ചില്ലെങ്കിൽ അല്ല. ഓരോ integration ഉം observation mode ലാണ് തുടങ്ങുന്നത്, നിങ്ങളുടെ team എഴുതുകയും enable ചെയ്യുകയും ചെയ്യുന്ന policies വഴിയാണ് enforcement നടക്കുന്നത്.

എനിക്ക് access എങ്ങനെ ലഭിക്കും?

Proof of Actor private beta യിലാണ്. Early access ന് അപേക്ഷിക്കുക, തിരഞ്ഞെടുത്ത founding developer teams ന് agreed usage limits നുള്ളിൽ up to 12 months free ലഭിക്കാം.

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

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

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

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