ഏജന്റ് ആക്സസ് നയങ്ങൾ

നിങ്ങൾ നിയന്ത്രിക്കുന്ന policies ഉപയോഗിച്ച് AI agents-നെ route ചെയ്യുക

നിങ്ങളുടെ application ആളുകളെ, AI-assisted ഉപയോക്താക്കളെ, autonomous agents-നെ ഓരോ route-ലും എങ്ങനെ പരിഗണിക്കണമെന്ന് തീരുമാനിക്കുക. Proof of Actor തെളിവ് നൽകുന്നു; അന്തിമ തീരുമാനം നിങ്ങളുടെ policies എടുത്തോളും.

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

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

എല്ലാവർക്കും ഒരേ policy ഇനി മതിയാകില്ല

മിക്ക applications-ും ഒരു single kind of user ചുറ്റിപ്പറ്റിയാണ് രൂപകൽപ്പന ചെയ്തത്: account-ൽ sign in ചെയ്ത ശേഷം interface-ിലൂടെ click ചെയ്യുന്ന ഒരു വ്യക്തി. Access control ആ അനുമാനത്തെ പിന്തുടർന്നു. session valid ആണെങ്കിൽ request കടന്നുപോകും. അത് automated പോലെ തോന്നിയാൽ CAPTCHA അല്ലെങ്കിൽ block പ്രത്യക്ഷപ്പെടും.

ആ model തകരുകയാണ്. ഇന്ന് അതേ application ആളുകൾക്ക്, AI assistants-ുമായി പ്രവർത്തിക്കുന്ന ആളുകൾക്ക്, ആരുടെയോ behalf-ൽ പ്രവർത്തിക്കുന്ന autonomous agents-ക്ക് സേവനം നൽകുന്നു. ചില agents customers-ന്റെ സ്വന്തം integrations ആണ്. ചിലത് documentation എടുത്തുകൊണ്ടിരിക്കുന്ന AI assistants ആണ്. ചിലത് crawlers ആണ്. ചിലത് നിങ്ങളുടെ product ദുരുപയോഗം ചെയ്യാൻ ശ്രമിക്കുന്നു. ഒരൊറ്റ yes-or-no rule അവരെല്ലാം നന്നായി കൈകാര്യം ചെയ്യില്ല.

AI agent routing and access policies ആ single rule-നെ deliberate decisions-ന്റെ ഒരു set ആയി മാറ്റുന്നു: ഏത് actors-ക്ക് ഏത് experience ലഭിക്കും, ഏത് routes-ൽ, ഏത് conditions-ൽ. Proof of Actor ആ തീരുമാനങ്ങൾ എടുക്കാൻ നിങ്ങളുടെ application-ക്ക് തെളിവ് നൽകുന്നു, തീരുമാനങ്ങൾ തന്നെ നിങ്ങളുടെ കൈയിൽ തന്നെ വിടുന്നു. ഈ സമീപനത്തിന് പിന്നിലുള്ള design principles അറിയാൻ designing app policies for humans and AI agents വായിക്കുക, കൂടാതെ policies യഥാർത്ഥ product workflows-ിലേക്കെങ്ങനെ ചേരുന്നു എന്ന് SaaS apps use case-ൽ കാണുക.

നല്ല ഒരു agent policy എങ്ങനെയിരിക്കും

പ്രയോജനകരമായ policy വ്യക്തമാണ്. അതിൽ ഒരു route അല്ലെങ്കിൽ workflow, actor class, ആവശ്യമായ evidence-ന്റെ ശക്തി, response എന്നിവ പറയപ്പെടുന്നു. ഉദാഹരണത്തിന്:

Read-only catalog routes: verified agents-നെ allow ചെയ്യുക, structured response നൽകുക; standard rate limit-ോടെ declared agents-നെ allow ചെയ്യുക.
Account-changing actions: എല്ലാവർക്കും നിങ്ങളുടെ നിലവിലുള്ള re-authentication തുടരുക; actor Unknown ആയപ്പോൾ, action high impact ആണെങ്കിൽ review ചേർക്കുക.
Support submissions: disclose ചെയ്ത AI-assisted content accept ചെയ്യുക, routing-ിനായി അത് label ചെയ്യുക.
Signup: നിലവിലുള്ള checks നിലനിർത്തുക; inferred actor result-ൽ മാത്രം ആശ്രയിച്ച് ഒരിക്കലും തീരുമാനിക്കരുത്.

ഇവയിൽ ഓരോന്നും എല്ലാ agents-നെയും abuse ആയി കാണാതെയും, എല്ലാ agents-നെയും blind ആയി വിശ്വസിക്കാതെയും actor-നോട് പ്രതികരിക്കുന്നു. Agent-aware access-ന്റെ മുഴുവൻ ഉദ്ദേശം ഈ balance തന്നെയാണ്, കൂടാതെ designing app policies for humans and AI agents എന്ന blog post route by route കൂടുതൽ ഉദാഹരണങ്ങൾ അവതരിപ്പിക്കുന്നു.

അഞ്ചു പ്രതികരണങ്ങൾ

Proof of Actor-ന്റെ Route capability നിങ്ങളുടെ policies തിരഞ്ഞെടുക്കാൻ കഴിയുന്ന അഞ്ചു പ്രതികരണങ്ങളെ അടിസ്ഥാനമാക്കിയതാണ്.

Allow

Request സാധാരണ പോലെ തുടരാൻ അനുവദിക്കുക. പൊതുവായ അല്ലെങ്കിൽ low-risk routes-ലെ മിക്ക traffic-ും, agent traffic ഉൾപ്പെടെ, simply allow ചെയ്യേണ്ടതാണ്.

Adapt

Actor-ക്ക് അനുയോജ്യമായി experience മാറ്റുക. മനുഷ്യർക്ക് ഉള്ള interface-ിന് പകരം verified agent-ന് structured API response അല്ലെങ്കിൽ page-ന്റെ Markdown version നൽകുക. serving AI agents structured content എന്ന guide ഈ pattern വിശദീകരിക്കുന്നു.

Challenge

കൂടുതൽ ശക്തമായ ഒന്നാണ് ആവശ്യപ്പെടുക: പുതിയ login, അധിക credential, account owner-ിൽ നിന്ന് ഒരു confirmation. ഒരു തെറ്റായ തീരുമാനത്തിന്റെ ചെലവ് ഉയർന്ന routes-ൽ challenges ഉപയോഗിക്കുക.

Review

Action-നെ നേരിട്ട് completion-ിലേക്ക് അയയ്ക്കാതെ ഒരു queue-യിലേക്ക് കൊണ്ടുപോകുക, അല്ലെങ്കിൽ ഒരു human പരിശോധിക്കാൻ flag ചെയ്യുക. blocking legitimate users-നെ ബാധിക്കുമെങ്കിലും unattended completion വളരെ അപകടകരമായിടത്ത് review ഉപകാരപ്രദമാണ്.

Limit

Actor-നും route-നും അനുയോജ്യമായി rate അല്ലെങ്കിൽ volume limit പ്രയോഗിക്കുക, ώστε automated callers മനുഷ്യർക്കായി രൂപകൽപ്പന ചെയ്ത workflow-നെ അതിക്രമിക്കാതിരിക്കും.

robots.txt ഒരു access policy അല്ലാത്തത് എന്തുകൊണ്ട്

പല teams തുടങ്ങുന്നത് robots.txt-നോടെയാണ്, crawlers-നുള്ള ആദ്യ signal ആയി അത് ബുദ്ധിയുള്ളതുമാണ്. പക്ഷേ അത് agents-നുള്ള access policy അല്ല. Crawler operators വ്യത്യസ്ത user agents-ക്കായി വ്യത്യസ്ത behaviour രേഖപ്പെടുത്തുന്നു: Anthropic അതിന്റെ bots robots.txt directives അനുസരിക്കുന്നുവെന്ന് പറയുന്നു (Anthropic crawler documentation), അതേസമയം OpenAI പറയുന്നത് ChatGPT-User-ന്, ഉപയോക്താവ് ChatGPT-യോട് ഒരു ചോദ്യം ചോദിക്കുമ്പോൾ പ്രവർത്തിക്കുന്നതിനാൽ, request ഉപയോക്താവ് ആരംഭിക്കുന്നതിനാൽ robots.txt rules ബാധകമായിരിക്കണമെന്നില്ല എന്നാണ് (OpenAI crawler documentation). Robots.txt APIs, MCP tools, അല്ലെങ്കിൽ signed-in workflows എന്നിവയെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല.

Access policy request കൈകാര്യം ചെയ്യുന്ന സ്ഥലത്ത് തന്നെയായിരിക്കണം പ്രവർത്തിക്കുക, RFC 9421 പ്രകാരം പരിശോധിച്ച signature പോലുള്ള evidence വായിക്കണം, route അനുസരിച്ച് ഒരു response തിരഞ്ഞെടുക്കണം. MCP servers-ക്കായി, MCP authorization specification clients HTTP വഴി access tokens എങ്ങനെ നേടുന്നു എന്ന് നിർവചിക്കുന്നു; actor policies അതിനുമുകളിൽ context ചേർക്കുന്നു, അവ അതിനെ പകരം വയ്ക്കുന്നില്ല.

Proof of Actor നിങ്ങളുടെ policies-ലേക്ക് നൽകുന്നത് എന്താണ്

നിങ്ങളുടെ integration വിലയിരുത്തുന്ന ഓരോ request-ഉം policy വായിക്കാൻ കഴിയുന്ന നാല് ഭാഗങ്ങളുള്ള actor result സൃഷ്ടിക്കുന്നു:

Class: Human, Human + AI, Agent അല്ലെങ്കിൽ Unknown.
Basis: verified, declared, inferred അല്ലെങ്കിൽ unknown, അതിനാൽ നിങ്ങളുടെ policy validated signature-നെ self-declared client name-ിൽ നിന്ന് വ്യത്യസ്തമായി കൈകാര്യം ചെയ്യാൻ കഴിയും.
Evidence summary: ഫലത്തിന്റെ ആധാരം എന്താണെന്ന് വായിക്കാൻ എളുപ്പമുള്ള വിവരണം, logging-നും review-നും ഉപകാരപ്പെടുന്നത്.
Context: ഏത് integration-നും ഏത് route-നും അത് സൃഷ്ടിച്ചു എന്നത്.

Basis വ്യക്തമായതിനാൽ, നിങ്ങളുടെ policies വളരെ കൃത്യമായി പ്രവർത്തിക്കാം. "Allow agents" എന്നത് "read routes-ൽ verified agents-നെ allow ചെയ്യുക, declared agents-നെ rate-limit ചെയ്യുക, ബാക്കി എല്ലാറ്റിനും Unknown fallback പ്രയോഗിക്കുക" ആയി മാറുന്നു. Request മുതൽ decision വരെ ഉള്ള മുഴുവൻ flow How It Works-ൽ വിവരിച്ചിരിക്കുന്നു.

Fallbacks policy-യുടെ ഭാഗമാണ്

Evidence ഇല്ലാതിരിക്കുമ്പോൾ policy എങ്ങനെ പ്രവർത്തിക്കുന്നു എന്നതിനെക്കാൾ അതിന്റെ ഗുണമേന്മ മികച്ചതല്ല. Proof of Actor ആ സാഹചര്യങ്ങളെ മറച്ചുവെയ്ക്കാതെ വ്യക്തമായി അവതരിപ്പിക്കുന്നു.

Unknown: evidence ഒരു determination-നെ പിന്തുണച്ചില്ല. ഓരോ route-ലും Unknown എന്താണ് അർത്ഥമാക്കുന്നത് എന്ന് നിങ്ങളുടെ policy പറയുന്നു. അത് ഒരിക്കലും Human-ലേക്ക് convert ചെയ്യപ്പെടുന്നില്ല, default ആയി malicious എന്നും കണക്കാക്കുന്നില്ല.
Timeout: result സമയത്ത് എത്തിയില്ല. നിങ്ങളുടെ integration ആ route-ിനായി നിങ്ങൾ തിരഞ്ഞെടുത്ത fallback പ്രയോഗിക്കുന്നു.
Missing signals: ഒരു collector പ്രവർത്തിച്ചില്ല അല്ലെങ്കിൽ ഒരു header ഇല്ലായിരുന്നു. Result അത് പ്രതിഫലിപ്പിക്കുന്നു, അതനുസരിച്ച് നിങ്ങളുടെ policy കൈകാര്യം ചെയ്യുന്നു.

ഓരോ route-ക്കും നിങ്ങൾ fail open or fail closed തിരഞ്ഞെടുക്കുന്നു. Fail open എന്നത് Proof of Actor ഇല്ലാത്തപ്പോലെ request മുന്നോട്ട് പോകുന്നു എന്നർത്ഥം; fail closed എന്നത് നിങ്ങളുടെ നിലവിലുള്ള കൂടുതൽ ശക്തമായ check പ്രയോഗിക്കുന്നു എന്നർത്ഥം. Low-risk routes സാധാരണയായി fail open ചെയ്യും. Sensitive actions സാധാരണയായി fail closed ചെയ്യും. ഇത് നിങ്ങൾ risk tier അനുസരിച്ച് സജ്ജമാക്കുന്നു, ആഗോളമായി അല്ല.

Identity, credentials, authorization എന്നിവ വേറിട്ടുതന്നെ നിലനിർത്തുക

Agent access policies മൂന്ന് വ്യത്യസ്ത layers-ന്റെ മുകളിൽ നിലകൊള്ളുന്നു, അവയെ വേർതിരിച്ച് നിലനിർത്തുന്നത് ഏറ്റവും നാശകരമായ പിഴവുകൾ ഒഴിവാക്കുന്നു.

Identity evidence വിളിക്കുന്ന actor-ന്റെ തരം എന്താണെന്നും അതിന് എന്താണ് തെളിവെന്നുമാണ് ഉത്തരമിടുന്നത്. Proof of Actor ഇത് നൽകുന്നു.
Credentials ഏത് account ഉത്തരവാദിയാണെന്ന ചോദ്യത്തിന് മറുപടി നൽകുന്നു. നിങ്ങളുടെ session, token അല്ലെങ്കിൽ API key ഇത് നൽകുന്നു.
Authorization ഈ caller ഈ action ചെയ്യാൻ അനുവദനീയമാണോ എന്ന ചോദ്യത്തിന് മറുപടി നൽകുന്നു. നിങ്ങളുടെ permission model ഇത് നൽകുന്നു.

ഒരു verified agent identity ഉണ്ടെന്ന alone കൊണ്ട് agent authorized ആണ് എന്നോ, ഒരു person authority അതിന് delegate ചെയ്‌തിട്ടുണ്ട് എന്നോ, അതിന്റെ action safe ആണെന്നോ അർത്ഥമാക്കുന്നില്ല. Actor results routing-നും context ചേർക്കുന്നതിനും ഉപയോഗിക്കുക. Permission നൽകാൻ നിങ്ങളുടെ authorization model ഉപയോഗിക്കുക. Detection & Limitations എന്ന page ഓരോ തരത്തിലുള്ള evidence-നും എന്ത് സ്ഥാപിക്കാനാകുമെന്ന് കൃത്യമായി വിശദീകരിക്കുന്നു.

ഒന്നും തകരാതെ roll out ചെയ്യുക

Agent access policies അവതരിപ്പിക്കാൻ ഏറ്റവും സുരക്ഷിതമായ മാർഗം ഘട്ടങ്ങളായി മുന്നേറുക എന്നതാണ്.

Observe. observation mode-ൽ Proof of Actor ഇൻസ്റ്റാൾ ചെയ്യുക. നിങ്ങളുടെ users-ന് ഒന്നും മാറുന്നില്ല; results രേഖപ്പെടുത്തപ്പെടുന്നു.
Understand. ഏത് actors ഏത് routes ഉപയോഗിക്കുന്നു, ഓരോന്നിലുമുള്ള unknown rate എത്രയാണ്, നിങ്ങൾക്ക് ഇതിനകം അറിയുന്നതുമായി പൊരുത്തപ്പെടാത്ത results ഏതൊക്കെയാണെന്ന് അവലോകനം ചെയ്യുക.
Preview. Policy-യെ preview-ൽ പ്രവർത്തിപ്പിച്ച്, enforce ചെയ്യാതെ അത് എന്ത് ചെയ്തേനേ എന്ന് log ചെയ്യുക.
Enforce narrowly. evidence വ്യക്തമായി പിന്തുണയ്ക്കുന്ന ഒരു route-ൽ policy enable ചെയ്യുക. ഫലങ്ങൾ ശ്രദ്ധിക്കുക.
Expand. confidence ഉയരുന്നതിനനുസരിച്ച് കൂടുതൽ routes-ലേക്ക് വ്യാപിപ്പിക്കുക.

rolling out actor-aware policies safely എന്ന guide ഓരോ ഘട്ടവും വിശദീകരിക്കുന്നു, കൂടാതെ protecting sensitive actions without blocking agents ഉയർന്ന അപകടമുള്ള routes കൈകാര്യം ചെയ്യുന്നു.

നിങ്ങളുടെ ടീം നേടുന്നത് എന്ത്

Proof of Actor-ോടെ, നിങ്ങളുടെ team-ന് ഒരു integration-ിൽ മൂന്ന് capabilities ലഭിക്കുന്നു. Detect actor signals ശേഖരിക്കുകയും verified assertions-നെ inferences-ൽ നിന്ന് വേർതിരിക്കുകയും ചെയ്യുന്നു. Understand actor analytics, trends, ഓരോ result-ിന്റെയും പിന്നിലെ evidence എന്നിവ കാണിക്കുന്നു, Unknown ദൃശ്യമാക്കി നിലനിർത്തുന്നു. Route ഈ page-ൽ വിവരിച്ചിരിക്കുന്ന policies എഴുതാനും നിങ്ങൾ തിരഞ്ഞെടുക്കുന്ന സ്ഥലത്ത് അവ പ്രയോഗിക്കാനും അനുവദിക്കുന്നു. private beta കാലത്ത്, routing policies ഓരോ founding team-നുമായി ചേർന്ന് രൂപകൽപ്പന ചെയ്യപ്പെടുകയും നിങ്ങളുടെ സ്വന്തം application code-ൽ പ്രവർത്തിക്കുകയും ചെയ്യുന്നു, അതിനാൽ നിങ്ങൾക്ക് പൂർണ്ണ നിയന്ത്രണം നിലനിൽക്കുന്നു.

ഒഴിവാക്കേണ്ട സാധാരണ policy പിഴവുകൾ

ആദ്യമായി agent access രൂപകൽപ്പന ചെയ്യുന്ന teams പലപ്പോഴും കുറച്ച് പിഴവുകൾ ആവർത്തിക്കുന്നു. അവ ഒഴിവാക്കുന്നത് ആഴ്ചകളോളം പുനർനിർമ്മാണം बचിക്കുന്നു.

By default ഓരോ agent-നെയും block ചെയ്യുന്നത്. നിയമാനുസൃത agents പിന്നീട് നിങ്ങൾക്കൊപ്പമല്ലാതെ വഴികൾ കണ്ടെത്തും, പലപ്പോഴും ആളുകൾക്കായി നിങ്ങൾ നിർമ്മിച്ച interface scrape ചെയ്യുന്നു, അത് structured path-നേക്കാൾ സംരക്ഷിക്കാൻ ബുദ്ധിമുട്ടാണ്.
Declared name-നെ വിശ്വസിക്കുന്നത്. സ്വയം പേര് പറയുന്ന client ഒരു claim ഉന്നയിച്ചിട്ടുണ്ട്, തെളിവ് നൽകിയിട്ടില്ല. നിങ്ങൾ unverified caller-ന് നൽകുന്ന treatment തന്നെയാണ് നൽകേണ്ടത്.
എല്ലായിടത്തും ഒരേ fallback ഉപയോഗിക്കുന്നത്. പൊതുവായ pricing page-ിലെ Unknown-നും password change-യിലെ Unknown-നും വ്യത്യസ്ത സാഹചര്യങ്ങളാണ്. ഓരോ route-ക്കും സ്വന്തം ഉത്തരമാവശ്യമാണ്.
Inference-ൽ നിന്ന് ആളുകളെക്കുറിച്ച് തീരുമാനിക്കുന്നത്. Actor results routing-ിനുള്ള context ആണ്, വ്യക്തിയെക്കുറിച്ചുള്ള verdict അല്ല. Consequential decisions നിങ്ങളുടെ സ്വന്തം controls-ലും review-ലും തന്നെ വയ്ക്കുക.
Observation ഒഴിവാക്കുന്നത്. ഒന്നാം ദിവസം തന്നെ enforce ചെയ്‌താൽ false positives നിങ്ങൾ customer complaints വഴി കണ്ടെത്തും. ആദ്യം observe ചെയ്യുക, പിന്നെ evidence വ്യക്തമായിടത്ത് enforce ചെയ്യുക.

ഓരോ enforcement ഘട്ടത്തിനും മുമ്പ് നിങ്ങളുടെ security, product, support leads-ുമായി ഒരു ചെറിയ policy review നടത്തുന്നത് ഇവയിൽ അധികവും നേരത്തേ പിടികൂടാൻ സഹായിക്കും.

Founding developer program-ോടെ ആരംഭിക്കുക

Proof of Actor private beta-യിലാണു. തിരഞ്ഞെടുത്ത founding development teams-ന് agreed usage limits-ക്കുള്ളിൽ 12 months വരെ free access ലഭിക്കാം, കൂടാതെ നിങ്ങൾ ആദ്യ policies രൂപകൽപ്പന ചെയ്യുമ്പോൾ ഞങ്ങളുടെ engineers-ന്റെ direct support ലഭിക്കും.

നിങ്ങളുടെ application AI agents-നെ എങ്ങനെ പരിഗണിക്കണം എന്ന് നിങ്ങൾ തീരുമാനിക്കുന്നുണ്ടെങ്കിൽ, early access അപേക്ഷിക്കുക. ഏത് routes ആണ് ഏറ്റവും പ്രധാനപ്പെട്ടത്, ഏത് decisions ആണ് നിങ്ങൾ എടുക്കാൻ ആഗ്രഹിക്കുന്നത് എന്നതും ഞങ്ങളോട് പറയുക, നിങ്ങൾക്ക് അനുയോജ്യമായ policies നിർമ്മിക്കാൻ ഞങ്ങൾ സഹായിക്കും. ഇത് APIs-ലും MCP servers-ലും എങ്ങനെ ബാധകമാകുന്നു എന്നും നിങ്ങൾക്ക് കാണാം.

Sources

Does Anthropic crawl data from the web, and how can site owners block the crawler?, Anthropic.
Overview of OpenAI crawlers, OpenAI.
RFC 9421: HTTP Message Signatures, IETF, February 2024.
MCP authorization, modelcontextprotocol.io.

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

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 access policy എന്താണ്?

ഒരു request ചെയ്യുന്ന actor-ന്റെ തരത്തെ അടിസ്ഥാനമാക്കി നിങ്ങളുടെ application പ്രയോഗിക്കുന്ന rule ആണിത്, ഉദാഹരണത്തിന് read-only routes-ൽ verified agents-നെ allow ചെയ്യുക അല്ലെങ്കിൽ high-impact actions-ൽ കൂടുതൽ ശക്തമായ credential ആവശ്യപ്പെടുക. Proof of Actor actor result നൽകുന്നു; പ്രതികരണം തീരുമാനിക്കുന്നത് നിങ്ങളുടെ policy ആണ്.

Proof of Actor policies സ്വയമേവ enforce ചെയ്യുമോ?

ഇല്ല. ഓരോ integration-വും observation mode-ൽ ആരംഭിക്കുന്നു, നിങ്ങൾക്ക് ആ workflow-യ്ക്ക് യോജിക്കുന്നതായി ഉറപ്പായപ്പോൾ നിങ്ങളുടെ team ഓരോ route-ലും policies enable ചെയ്യുന്നു.

actor Unknown ആണെങ്കിൽ അല്ലെങ്കിൽ check timeout ആണെങ്കിൽ എന്താണ് സംഭവിക്കുന്നത്?

ഓരോ route-ക്കും നിങ്ങൾ വ്യക്തമായ fallback നിർവചിക്കുന്നു, ഉദാഹരണത്തിന് public reads allow ചെയ്യുക, account changes-ൽ existing checks നിലനിർത്തുക. Unknown, timeout എന്നിവ ഒരിക്കലും Human-ലേക്ക് default ആവില്ല.

എല്ലാ AI agents-നെയും block ചെയ്യണോ?

സാധാരണയായി വേണ്ട. പല agents-ും നിയമാനുസൃത പങ്കാളികളാണ്. Policies അവയ്ക്ക് structured path നൽകാനും, പ്രധാന്യമുള്ളിടത്ത് limit ചെയ്യാനും, sensitive actions-ൽ കൂടുതൽ ശക്തമായ checks reserve ചെയ്യാനും നിങ്ങളെ സഹായിക്കുന്നു.

Policies ആളുകളെക്കുറിച്ച് തീരുമാനങ്ങൾ എടുക്കാമോ?

തൊഴിൽ, credit, അല്ലെങ്കിൽ essential services-ിലേക്കുള്ള access പോലുള്ള വ്യക്തികളെ സംബന്ധിച്ച ഗൗരവമായ തീരുമാനങ്ങൾക്ക് Proof of Actor results ഏക ആധാരമായി ഉപയോഗിക്കരുത്. നിങ്ങളുടെ സ്വന്തം controls-നൊപ്പം routing, context എന്നിവയ്ക്കായി അവ ഉപയോഗിക്കുക.

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

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

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

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