MCP CALLER തിരിച്ചറിയൽ

നിങ്ങളുടെ MCP server-ലേക്ക് ആരാണ് വിളിക്കുന്നത് എന്ന് അറിയുക

നിങ്ങളുടെ MCP server, നിങ്ങൾ നിയന്ത്രിക്കാത്ത AI clients-ന് tools തുറന്നുകൊടുക്കുന്നു. ഓരോ call-ന്റെയും പിന്നിൽ എന്താണുള്ളത്, അതിനെ പിന്തുണയ്ക്കുന്ന തെളിവ് എന്താണ്, tool-പ്രതി policies നിങ്ങൾക്ക് എങ്ങനെ നിശ്ചയിക്കാം എന്നിവ Proof of Actor പറയുന്നു.

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

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

നിങ്ങളുടെ tools, നിങ്ങൾക്ക് കാണാനാകാത്ത callers-ന് തുറന്നിരിക്കുന്നു

ഒരു MCP server നിങ്ങളുടെ product-നെ AI clients-ക്ക് ഉപയോഗയോഗ്യമാക്കുന്നു. ഇത് tools, resources, prompts എന്നിവ തുറന്നുവെക്കുന്നു, assistants, agents എന്നിവക്ക് അവ കണ്ടെത്തുകയും വിളിക്കുകയും ചെയ്യാൻ കഴിയുന്നു, കൂടാതെ Model Context Protocol specification-ൽ വിവരിച്ചിരിക്കുന്നതുപോലെ hosts, clients, servers എന്നിവയ്ക്കിടയിലെ JSON-RPC 2.0 messages ഉപയോഗിക്കുന്നു. ടീമുകൾ അവ നിർമ്മിക്കുന്നത് അതിനാലാണ്: AI agents ഇതിനകം പ്രവർത്തിക്കുന്ന workflows-ലേക്ക് നിങ്ങളുടെ product-നെ അവർ കൊണ്ടുവരുന്നു.

അതേസമയം, നിങ്ങൾ നിർമ്മിക്കാത്തതും നേരിട്ട് നിരീക്ഷിക്കാനാകാത്തതുമായ clients-ിൽ നിന്ന് നിങ്ങളുടെ server calls സ്വീകരിക്കുന്നു എന്നതും അതിന്റെ അർത്ഥമാണ്. ഒരു single tool, ഒരു developer local ആയി test ചെയ്യുമ്പോഴും, signed-in വ്യക്തിക്ക് വേണ്ടി പ്രവർത്തിക്കുന്ന desktop assistant-ലൂടെയോ, രാത്രി മുഴുവൻ നീണ്ട task autonomously ഓടിക്കുന്ന autonomous agent-ലൂടെയോ, അല്ലെങ്കിൽ നിങ്ങളുടെ server-ലെ ദൗർബല്യങ്ങൾ പരിശോധിക്കുന്ന എന്തെങ്കിലുമോ വഴി invoke ചെയ്യപ്പെട്ടേക്കാം. Protocol, ഏത് tool വിളിക്കപ്പെട്ടു, ഏത് arguments ഉപയോഗിച്ചാണ് വിളിച്ചത് എന്നിവ നിങ്ങളോട് പറയുന്നു. പക്ഷേ call-ന്റെ പിന്നിൽ എന്ത് kind of actor ആണ് ഉള്ളത്, അതിനെ എത്ര വിശ്വസിക്കണം എന്നത് അത്, സ്വന്തം നിലയിൽ, പറയുന്നില്ല.

MCP server caller identification ആ വിടവ് പൂരിപ്പിക്കുന്നു. Proof of Actor ഓരോ tool call-ലും evidence-backed actor result ചേർക്കുന്നു, അതുവഴി your server-ന് ആരെന്ത് നേടുന്നു എന്ന് സംബന്ധിച്ച informed decisions എടുക്കാൻ കഴിയും. പ്രശ്നത്തിന്റെ കൂടുതൽ ആഴത്തിലുള്ള വീക്ഷണത്തിന് who is calling your MCP server വായിക്കുക, ടീമുകൾ ഇത് എങ്ങനെ പ്രയോഗിക്കുന്നു എന്നതിനായി MCP servers use case കാണുക.

Terms-നെക്കുറിച്ചുള്ള കുറിപ്പ്. "Caller identity" എന്നതിന് cloud infrastructure-ലും സുപരിചിതമായ ഒരു അർത്ഥമുണ്ട്. ഉദാഹരണത്തിന് AWS STS GetCallerIdentity ഓപ്പറേഷൻ വിളിക്കാൻ ഉപയോഗിക്കുന്ന IAM user അല്ലെങ്കിൽ role-നെക്കുറിച്ചുള്ള വിശദാംശങ്ങൾ തിരികെ നൽകുന്നു. അത് ഏത് cloud credential call നടത്തിയെന്ന് പറയുന്നു. ഈ പേജിലെ MCP server caller identification മറ്റൊരു ചോദ്യത്തിനാണ് മറുപടി നൽകുന്നത്: Human, Human + AI, Agent അല്ലെങ്കിൽ Unknown എന്നതിൽ ഏത് kind of actor ആണ് നിങ്ങളുടെ MCP server-ലേക്കുള്ള ഒരു tool call-ന്റെ പിന്നിലുള്ളത്, അതിനുള്ള തെളിവ് എന്താണ്.

MCP callers എന്തുകൊണ്ട് വ്യത്യസ്തരാണ്

MCP callers, browser visitors-ൽ നിന്നുമാത്രമല്ല, traditional API clients-ൽ നിന്നും policy-യ്ക്ക് പ്രധാന്യമുള്ള രീതികളിൽ വ്യത്യസ്തരാണ്.

അവ എല്ലായ്പ്പോഴും മിക്കവാറും automated ആണ്. ചോദ്യം "human ആണോ bot ആണോ?" എന്നതിലല്ല, മറിച്ച് "ഏത് agent, എങ്ങനെ പ്രവർത്തിക്കുന്നു, എന്ത് തെളിവോടെ?" എന്നതിലാണ്.
അവ പലപ്പോഴും ഒരു വ്യക്തിക്കായി പ്രവർത്തിക്കുന്നു. ഒരു assistant, user ആവശ്യപ്പെട്ടതിനാൽ നിങ്ങളുടെ tool വിളിച്ചിരിക്കാം, അല്ലെങ്കിൽ അത് സ്വതന്ത്രമായി പ്രവർത്തിച്ചിരിക്കാം. ആ കേസുകൾക്ക് വ്യത്യസ്ത treatment അർഹമാണ്.
അവ സ്വയം വിവരിക്കുന്നു. MCP lifecycle specification പ്രകാരം client, തന്റെ initialize request-ൽ പേര്, version എന്നിവയോടുകൂടിയ ഒരു clientInfo object അയക്കുന്നു. ആ declaration പ്രയോജനകരമായ context ആണ്, പക്ഷേ അത് തെളിവല്ല.
Tools-ന്റെ impact വളരെ വ്യത്യസ്തമാണ്. ഒരു search tool-ഉം records ഇല്ലാതാക്കുന്ന tool-ഉം ഒരേ policy പങ്കിടരുത്.

നല്ല MCP caller identification ഈ നാല് കാര്യങ്ങളെയും മാനിക്കണം.

Proof of Actor MCP callers-നെ എങ്ങനെ തിരിച്ചറിയുന്നു

നിങ്ങളുടെ server-ിൽ നിന്നുള്ള signals

ഓരോ call-ലും ലഭ്യമായ context നിങ്ങളുടെ MCP integration Proof of Actor-ന് നൽകുന്നു: client-ന്റെ declared details, transport, request context, client നൽകുന്ന ഏതെങ്കിലും cryptographic request signatures, ഉദാഹരണത്തിന് RFC 9421-ൽ നിർവചിച്ചിരിക്കുന്ന HTTP Message Signatures, കൂടാതെ വിളിക്കപ്പെടുന്ന tool. ഓരോ signal-നും അത് എവിടെ നിന്നാണ് വന്നതെന്ന് label ചെയ്യപ്പെടുന്നു.

basis-ോടുകൂടിയ classification

Proof of Actor നാല് classes-ിൽ ഒന്നിനെ തിരികെ നൽകുന്നു, Human, Human + AI, Agent അല്ലെങ്കിൽ Unknown, കൂടാതെ result-ന്റെ basis-ഉം നൽകുന്നു:

verified cryptographic check, ഉദാഹരണത്തിന് published key-നെതിരായ request signature, passed ആയപ്പോൾ;
declared client അല്ലെങ്കിൽ നിങ്ങളുടെ application അത് stated ചെയ്തപ്പോൾ, ഉദാഹരണത്തിന് session-ലുള്ള client name;
inferred result call patterns-ൽ ആശ്രയിക്കുമ്പോൾ;
unknown തെളിവ് ഒരു determination-നെ പിന്തുണയ്ക്കാത്തപ്പോൾ.

ഒരു declared client name ഒരിക്കലും verification ആയി അവതരിപ്പിക്കപ്പെടുന്നില്ല. തെളിവ് കുറവായാൽ, result Unknown ആയിരിക്കും, ആത്മവിശ്വാസമുള്ള ഒരു guess അല്ല, കൂടാതെ നിങ്ങളുടെ server-ന് അത് എന്തുമായാണ് പ്രവർത്തിക്കുന്നത് എന്ന് കൃത്യമായി അറിയാം.

നിങ്ങളുടെ tools ഉപയോഗിക്കാവുന്ന ഒരു result

Actor result tool call-നൊപ്പം എത്തുന്നു, നിങ്ങളുടെ server-ന്റെ logic-ന് തയ്യാറായി. observation mode-ൽ നിങ്ങൾ അത് രേഖപ്പെടുത്തുന്നു. നിങ്ങൾ തയ്യാറാകുമ്പോൾ, നിങ്ങളുടെ tool-level policies അതിനെ അടിസ്ഥാനമാക്കി പ്രവർത്തിക്കും.

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

Detect

ഓരോ tool call-ലും ലഭ്യമായ caller evidence പിടിച്ചെടുക്കുക, verified, declared, inferred evidence എന്നിവ വേറിട്ടുനിർത്തുക.

Understand

ഏത് clients ഏത് tools-നെ വിളിക്കുന്നു, എത്ര തവണ, എന്ത് തെളിവോടെ, അത് സമയത്തിനനുസരിച്ച് എങ്ങനെ മാറുന്നു എന്നിവ കാണുക. കൂടുതലും Unknown callers ആകർഷിക്കുന്ന tools, പെരുമാറ്റം മാറുന്ന clients, verifiable identity ഉള്ള calls-ന്റെ share എന്നിവ കണ്ടെത്തുക.

Route

ഓരോ tool-നും risk tier-നും policies എഴുതുക. സാധാരണ patterns:

Low-impact tools search അല്ലെങ്കിൽ read-only lookups പോലുള്ളവ: broad ആയി allow ചെയ്യുക, standard rate limit-ോടെ.
Moderate-impact tools drafts സൃഷ്ടിക്കുന്നതു പോലുള്ളവ: verified, declared callers-നെ allow ചെയ്യുക, Unknown-നെ rate-limit ചെയ്യുക.
High-impact tools data ഇല്ലാതാക്കൽ, settings മാറ്റൽ, അല്ലെങ്കിൽ user-ന്റെ behalf-ൽ messages അയയ്ക്കൽ പോലുള്ളവ: നിങ്ങളുടെ strongest authorization ആവശ്യപ്പെടുക, caller Unknown ആയിരിക്കുമ്പോഴോ സ്വതന്ത്രമായി പ്രവർത്തിക്കുമ്പോഴോ confirmation അല്ലെങ്കിൽ review ചേർക്കുക.

protecting sensitive actions without blocking agents എന്ന guide ഈ tiers എങ്ങനെ design ചെയ്യാം എന്ന് കാണിക്കുന്നു.

Identity evidence, credentials, authorization എന്നിവ വേറിട്ടതാണ്

MCP security ഏറ്റവും നല്ലത് മൂന്ന് ചോദ്യങ്ങൾ വേറിട്ടുനിൽക്കുമ്പോഴാണ്:

Identity evidence: ഏത് kind of client ആണ് വിളിക്കുന്നത്, അതിനെ എന്താണ് തെളിയിക്കുന്നത്? ഇത് Proof of Actor നൽകുന്നു.
Credentials: ഈ call ഏത് account അല്ലെങ്കിൽ token ഉപയോഗിച്ചാണ് നടത്തുന്നത്? ഇത് നിങ്ങളുടെ MCP server-ന്റെ authentication നൽകുന്നു. MCP authorization specification പ്രകാരം authorization optional ആണ്, HTTP-based transports-നായി അത് OAuth 2.1-ൽ അടിസ്ഥാനമാക്കുന്നു, MCP server ഒരു resource server ആയി access tokens validate ചെയ്യുന്നു.
Authorization: ഈ caller-ക്ക്, ഈ arguments-ോടെ, ഈ account-നായി, ഈ tool ഉപയോഗിക്കാൻ കഴിയുമോ? ഇത് നിങ്ങളുടെ permission model നൽകുന്നു.

Recognised client സ്വയം authorized ആയ client അല്ല. Valid signature, session-ന് പിന്നിലുള്ള വ്യക്തി ഈ specific action-നായി authority delegated ചെയ്തുവെന്ന് കാണിക്കുന്നില്ല. delegated authorityയും agent authorizationയും കുറിച്ച് കൂടുതൽ വായിക്കുക. ആദ്യ ചോദ്യത്തിന് കൂടുതൽ നല്ല context നൽകുന്നതിലൂടെ രണ്ടാം, മൂന്നാം ചോദ്യങ്ങളിലെ നിങ്ങളുടെ ഉത്തരങ്ങൾ കൂടുതൽ informed ആക്കാൻ Proof of Actor സഹായിക്കുന്നു.

Client name-നെ മാത്രം വിശ്വസിക്കരുതേ?

കാരണം ഏതൊരു client-നും ഏത് name-ും അയയ്ക്കാം. Declared name-നെ proof ആയി കാണുന്നത് imitation-നെ ക്ഷണിക്കുന്നു: hostile client-ന് popular assistant-ന്റെ name പകർത്തുന്നത് മതി. Proof of Actor name-നെ declared evidence ആയി രേഖപ്പെടുത്തുന്നു, ലഭ്യമായ കൂടുതൽ ശക്തമായ തെളിവുമായി അതിനെ സംയോജിപ്പിക്കുന്നു, കൂടാതെ basis നിങ്ങളോട് പറയുന്നു. തുടർന്ന് നിങ്ങളുടെ policy verified callers-ന്, വെറും declaration മാത്രമുള്ള callers-നെക്കാൾ കൂടുതൽ സ്വാതന്ത്ര്യം നൽകാനും, ഒന്നുമില്ലെങ്കിൽ നിങ്ങളുടെ Unknown fallback പ്രയോഗിക്കാനും കഴിയും.

Observation mode-ൽ ആരംഭിക്കുക

നിങ്ങളുടെ MCP server-ൽ Proof of Actor ഇൻസ്റ്റാൾ ചെയ്യുന്നതുകൊണ്ട് ഏതെങ്കിലും tool പ്രതികരിക്കുന്ന വിധം മാറുന്നില്ല. ആരാണ് നിങ്ങളുടെ tools വിളിക്കുന്നത്, തെളിവ് എത്ര ശക്തമാണ്, policies എവിടെയാണ് സഹായകരമാകുക എന്നിവ നിങ്ങൾക്ക് കാണാനാവാൻ results രേഖപ്പെടുത്തപ്പെടുന്നു. നിങ്ങൾ ആത്മവിശ്വാസമുള്ളപ്പോൾ, ഒരു high-impact tool-ൽ policy enable ചെയ്യുക, outcomes നിരീക്ഷിക്കുക, തുടർന്ന് വ്യാപിപ്പിക്കുക. How It Works മുഴുവൻ flow ഉൾക്കൊള്ളുന്നു, Detection & Limitations ഓരോ kind of evidence എന്താണ് establish ചെയ്യാൻ കഴിയുന്നത്, കഴിയാത്തത് എന്താണ് എന്നിവ വിശദീകരിക്കുന്നു.

MCP servers-ഉം APIs-ഉം പ്രവർത്തിപ്പിക്കുന്ന teams-നായി നിർമ്മിച്ചത്

Proof of Actor നിങ്ങളുടെ existing authentication, rate limiting, logging എന്നിവയ്‌ക്കൊപ്പം നിങ്ങളുടെ server-ന്റെ ഉള്ളിൽ സ്ഥിതിചെയ്യുന്നു. ഓരോ founding team-ത്തിനും integrations hands-on ആയി നൽകപ്പെടുന്നു, അതുവഴി setup നിങ്ങളുടെ transport, hosting, tool design എന്നിവയ്ക്ക് യോജിക്കുന്നു. MCP Servers and APIs use cases, നിങ്ങളുടെ tools-ലും നിങ്ങളുടെ API-യിലും ഒരേ approach എങ്ങനെ പ്രയോഗിക്കാമെന്ന് കാണിക്കുന്നു.

നിങ്ങൾ expose ചെയ്യുന്ന ഓരോ tool-നെയും കുറിച്ച് ചോദിക്കേണ്ട ചോദ്യങ്ങൾ

Tool-level policies എഴുതുന്നതിന് മുമ്പ്, നിങ്ങളുടെ MCP server expose ചെയ്യുന്ന ഓരോ tool-ഉം ഒരു ചെറിയ checklist ഉപയോഗിച്ച് പരിശോധിക്കുന്നത് സഹായകരമാണ്:

ഈ tool എന്താണ് മാറ്റാൻ കഴിയുന്നത്? Read-only tools-ഉം data മാറ്റുന്ന, messages അയക്കുന്ന, അല്ലെങ്കിൽ billing-നെ ബാധിക്കുന്ന tools-ഉം വ്യത്യസ്ത treatment അർഹിക്കുന്നു.
ഇത് ആര്ക്ക് വേണ്ടിയാണ്? ചില tools signed-in വ്യക്തിക്ക് വേണ്ടി പ്രവർത്തിക്കുന്ന assistants-നായി ഉള്ളതാണ്; മറ്റുള്ളവ autonomous workflows-നായി. പ്രതീക്ഷിക്കുന്ന caller ശരിയായ policy-യെ രൂപപ്പെടുത്തുന്നു.
ഒരു തെറ്റ് എത്ര ചെലവേറിയതാണ്? തെറ്റായ search result വിലകുറഞ്ഞതാണ്. തെറ്റായ deletion അങ്ങനെയല്ല. ഓരോ tool-നെയും risk tier-ലേക്ക് map ചെയ്യുക.
ഏത് evidence ആവശ്യമായിരിക്കണം? Declared client മതിയാകുമോ, അല്ലെങ്കിൽ tool-ന് verified identity plus നിങ്ങളുടെ strongest authorization ആവശ്യമുണ്ടോ എന്ന് തീരുമാനിക്കുക.
Unknown ആയാൽ എന്ത് സംഭവിക്കും? ഓരോ tool-നും explicit fallback തിരഞ്ഞെടുക്കുക: allow, rate-limit, user-നെ confirm ചെയ്യാൻ പറയുക, അല്ലെങ്കിൽ review-ലേക്ക് route ചെയ്യുക.
അത് പ്രവർത്തിക്കുന്നു എന്ന് നിങ്ങൾ എങ്ങനെ അറിയും? എന്തെങ്കിലും enforce ചെയ്യുന്നതിന് മുമ്പ് observation mode-ൽ നിങ്ങൾ ഏത് outcomes നിരീക്ഷിക്കുമെന്നത് തീരുമാനിക്കുക.

Tool-ഓരോന്നിനും ഈ ചോദ്യങ്ങൾക്ക് ഒരിക്കൽ വീതം മറുപടി നൽകുന്നത് caller identification-നെ വ്യക്തവും test ചെയ്യാവുന്നതുമായ rules-ആക്കി മാറ്റുന്നു, കൂടാതെ അത് integrate ചെയ്യുന്ന clients-ന് നിങ്ങളുടെ server-ന്റെ behaviour വിശദീകരിക്കാൻ എളുപ്പമാക്കുന്നു.

Founding developer program-ിൽ ചേരുക

Proof of Actor private beta-യിലാണുള്ളത്. തെരഞ്ഞെടുത്ത founding development teams-ന് സമ്മതിച്ച usage limits-ിനുള്ളിൽ up to 12 months free access ലഭിക്കാം, tool-level policies design ചെയ്യുമ്പോൾ ഞങ്ങളുടെ engineers-ിൽ നിന്ന് നേരിട്ടുള്ള support-ോടുകൂടി.

നിങ്ങൾ ഒരു MCP server പ്രവർത്തിപ്പിക്കുകയും അത് ആരാണ് വിളിക്കുന്നത് എന്ന് അറിയാൻ ആഗ്രഹിക്കുകയും ചെയ്യുന്നുവെങ്കിൽ, apply for early access. നിങ്ങളുടെ server, നിങ്ങൾ expose ചെയ്യുന്ന tools, നിങ്ങൾക്ക് ഏറ്റവും പ്രധാനപ്പെട്ട calls എന്നിവയെക്കുറിച്ച് ഞങ്ങളോട് പറയുക.

Sources

Model Context Protocol specification (2025-06-18), modelcontextprotocol.io.
MCP lifecycle: initialization and clientInfo, modelcontextprotocol.io.
MCP authorization, modelcontextprotocol.io.
RFC 9421: HTTP Message Signatures, IETF, February 2024.
AWS STS GetCallerIdentity API reference, Amazon Web Services.

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

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

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

ഒരു MCP server-ന് caller identification എന്തിന് വേണം?

MCP servers, ആളുകൾക്ക് വേണ്ടി പ്രവർത്തിക്കുന്നതോ സ്വതന്ത്രമായി പ്രവർത്തിക്കുന്നതോ ആയ AI clients-ന് tools തുറന്നുകൊടുക്കുന്നു. ഒരു tool call-ന്റെ പിന്നിൽ ഏത് തരത്തിലുള്ള caller ആണെന്ന് അറിയുന്നത്, കുറഞ്ഞ impact ഉള്ള tools സ്വതന്ത്രമായി അനുവദിക്കാനും ഉയർന്ന impact ഉള്ളവയ്ക്ക് കൂടുതൽ നിയന്ത്രണം ആവശ്യപ്പെടാനും സഹായിക്കുന്നു.

MCP session-ലുള്ള client name ഒരു verification ആണോ?

ഇല്ല. ഒരു client name client തന്നെ ചെയ്യുന്ന ഒരു declaration ആണ്. Proof of Actor അത് declared evidence ആയി രേഖപ്പെടുത്തുകയും, cryptographically verified identity-യിൽ നിന്ന് വേറിട്ട് നിലനിർത്തുകയും ചെയ്യുന്നു.

Caller identification, MCP authorization-നെ പകരം വയ്ക്കുമോ?

ഇല്ല. Caller identity evidence, ഉപയോഗിക്കുന്ന credential, caller ചെയ്യാൻ അനുവദിച്ചിരിക്കുന്ന കാര്യങ്ങൾ എന്നിവ വേറിട്ട ചോദ്യങ്ങളാണ്. Proof of Actor ആദ്യത്തേതിന് context ചേർക്കുന്നു, authorization നിങ്ങളുടെ server-ലേക്ക് വിട്ടുകൊടുക്കുന്നു.

Proof of Actor tool calls തടയുമോ?

നിങ്ങളുടെ policies അങ്ങനെ പറയുന്നു എങ്കിൽ മാത്രം. ഓരോ integration-ഉം observation mode-ലാണ് ആരംഭിക്കുന്നത്, നിങ്ങൾ തയ്യാറാകുമ്പോൾ tool-level policies enable ചെയ്യാം.

ഞാൻ ഇത് എങ്ങനെ പരീക്ഷിക്കാം?

early access-ന് അപേക്ഷിക്കുക. തെരഞ്ഞെടുത്ത founding developer teams-ന് സമ്മതിച്ച usage limits-ിനുള്ളിൽ up to 12 months free ലഭിക്കാം, hands-on integration support-ോടുകൂടി.

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

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

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

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