એજન્ટ ઍક્સેસ નીતિઓ

તમે નિયંત્રિત કરો એવી નીતિઓ સાથે AI એજન્ટ્સને રૂટ કરો

તમારું application લોકો, AI ની મદદથી કામ કરતા users અને autonomous agents ને route by route કેવી રીતે treats કરે છે તે નક્કી કરો. Proof of Actor evidence આપે છે; તમારી policies નિર્ણય લે છે.

પ્રારંભિક ઍક્સેસ મેળવો તે કેવી રીતે કાર્ય કરે છે તે અન્વેષણ કરો

દ્વારા Toshendra Sharmaસ્થાપક અને CEO, AgentCredia · Updated November 13, 2026

સૌ માટે એક જ policy હવે પૂરતી નથી

મોટાભાગની applications એક જ પ્રકારના user ને ધ્યાનમાં રાખીને બનાવવામાં આવી હતી: account માં sign in થયેલો, interface પર click કરતો વ્યક્તિ. Access control પણ એ જ ધારણાને અનુસરી રહ્યું હતું. Session valid હોય તો request પસાર થઈ જાય. જો તે automated લાગે તો CAPTCHA અથવા block દેખાય.

આ model તૂટે છે. આજે એ જ application લોકો, AI assistants સાથે કામ કરતા લોકો, અને કોઈના વતી કામ કરતા autonomous agents ને સેવા આપે છે. કેટલાક agents customer's own integrations છે. કેટલાક AI assistants documentation fetch કરે છે. કેટલાક crawlers છે. થોડાક તમારા product નો દુરુપયોગ કરવાનો પ્રયાસ કરે છે. એક જ yes-or-no rule આ બધાને સારી રીતે સંભાળી શકતો નથી.

AI agent routing અને access policies એ એક જ rule ને deliberate decisions ના સમૂહથી બદલે છે: કયા actors ને કયો અનુભવ મળશે, કયા routes પર, કઈ શરતો હેઠળ. Proof of Actor તમારા application ને આ decisions લેવા માટે evidence આપે છે, અને decisions પોતાને તમારી હાથમાં રાખે છે. આ approach પાછળના design principles માટે designing app policies for humans and AI agents વાંચો, અને policies real product workflows સાથે કેવી રીતે map થાય છે તે માટે SaaS apps use case જુઓ.

સારી agent policy કેવી દેખાય

ઉપયોગી policy ચોક્કસ હોય છે. તે route અથવા workflow, actor class, જરૂરી evidence ની strength, અને response નું નામ આપે છે. ઉદાહરણ તરીકે:

Read-only catalog routes: verified agents ને allow કરો અને structured response આપો; declared agents ને standard rate limit સાથે allow કરો.
Account-changing actions: સૌ માટે existing re-authentication યથાવત રાખો; જ્યારે actor Unknown હોય અને action high impact હોય ત્યારે review ઉમેરો.
Support submissions: disclosed AI-assisted content સ્વીકારો અને routing માટે તેને label કરો.
Signup: existing checks યથાવત રાખો; inferred actor result પરથી ક્યારેય એકલા નિર્ણય ન કરો.

આ દરેક response actor ને ધ્યાનમાં રાખે છે, દરેક agent ને abuse માનીને નહીં અને દરેક agent પર blind trust રાખીને નહીં. એજ agent-aware access નો મૂળ સંતુલન છે, અને designing app policies for humans and AI agents પરનો blog post વધુ ઉદાહરણો route by route સમજાવે છે.

પાંચ responses

Proof of Actor ની Route capability પાંચ responses પર આધારિત છે, જેમાંથી તમારી policies પસંદ કરી શકે છે.

Allow

Request ને સામાન્ય રીતે આગળ વધવા દો. જાહેર અથવા ઓછા જોખમવાળા routes પરનો મોટાભાગનો traffic, જેમાં મોટાભાગનો agent traffic પણ શામેલ છે, simply allow થવો જોઈએ.

Adapt

Actor ને અનુરૂપ અનુભવ બદલો. માનવ-આકારના interface ને બદલે verified agent માટે structured API response અથવા page નું Markdown version આપો. serving AI agents structured content માર્ગદર્શિકા આ pattern કવર કરે છે.

Challenge

કંઈક વધુ મજબૂત માંગો: તાજું login, વધારાનું credential, account owner તરફથી confirmation. જ્યાં ખોટા નિર્ણયની કિંમત ઊંચી હોય એવા routes પર challenges ઉપયોગ કરો.

Review

Action ને straight to completion ના બદલે queue માં મોકલો, અથવા તેને માનવી દ્વારા તપાસવા માટે flag કરો. જ્યાં blocking legitimate users ને નુકસાન પહોંચાડી શકે પરંતુ unattended completion બહુ જોખમી હોય ત્યાં review ઉપયોગી છે.

Limit

Actor અને route મુજબ tuned rate અથવા volume limit લાગુ કરો, જેથી automated callers લોકો માટે બનાવેલા workflow ને overwhelm ન કરી શકે.

robots.txt access policy નથી

ઘણી teams robots.txt થી શરૂઆત કરે છે, અને crawlers માટે તે એક સમજદાર first signal છે. એ agents માટે access policy નથી. Crawler operators અલગ user agents માટે અલગ વર્તણૂક દસ્તાવેજ કરે છે: Anthropic કહે છે કે તેના bots robots.txt directives માન્ય રાખે છે (Anthropic crawler documentation), જ્યારે OpenAI નોંધે છે કે ChatGPT-User માટે, જે ત્યારે કાર્ય કરે છે જ્યારે user ChatGPT ને પ્રશ્ન પૂછે છે, robots.txt rules લાગુ ન પણ પડે કારણ કે action user દ્વારા શરૂ કરવામાં આવે છે (OpenAI crawler documentation). Robots.txt APIs, MCP tools અથવા signed-in workflows વિશે પણ કંઈ કહેતું નથી.

Access policy એ request જ્યાં handle થાય છે ત્યાં ચલાવવી પડે, RFC 9421 હેઠળ checked થયેલી signature જેવા evidence વાંચવા પડે, અને દરેક route માટે response પસંદ કરવો પડે. MCP servers માટે, MCP authorization specification નિર્ધારિત કરે છે કે clients HTTP પર access tokens કેવી રીતે મેળવે; actor policies તેના ઉપર context ઉમેરે છે, તેને બદલે નથી.

Proof of Actor તમારી policies ને કેવી રીતે feed કરે છે

તમારી integration જે request evaluate કરે છે તે દરેક request ચાર ભાગો સાથે actor result આપે છે, જેને તમારી policy વાંચી શકે:

Class: Human, Human + AI, Agent અથવા Unknown.
Basis: verified, declared, inferred અથવા unknown, જેથી તમારી policy validated signature ને self-declared client name થી જુદી રીતે treat કરી શકે.
Evidence summary: result કયા આધાર પર છે તેનું વાંચી શકાય એવું વર્ણન, logging અને review માટે ઉપયોગી.
Context: કઈ integration અને કયો route તેના ઉત્પન્ન થવામાં સામેલ હતો.

Basis explicit હોવાથી તમારી policies ચોક્કસ બની શકે છે. "Allow agents" નો અર્થ બને છે "read routes પર verified agents ને allow કરો, declared agents ને rate-limit કરો, બાકી બધું Unknown fallback પર મૂકો." Request થી decision સુધીનો સંપૂર્ણ flow How It Works પર વર્ણવ્યો છે.

Fallbacks policy નો ભાગ છે

Policy એટલી જ સારી છે જેટલી તે evidence ના અભાવમાં વર્તે છે. Proof of Actor એ કેસોને છુપાવવાને બદલે explicit બનાવે છે.

Unknown: evidence એ determination માટે પૂરતો આધાર આપ્યો નથી. તમારી policy કહે છે કે દરેક route પર Unknown નો અર્થ શું છે. તેને ક્યારેય Human માં ફેરવવામાં આવતું નથી અને default તરીકે malicious પણ માનવામાં આવતું નથી.
Timeout: result સમયસર આવ્યો નથી. તમારી integration એ route માટે તમે પસંદ કરેલો fallback લાગુ કરે છે.
Missing signals: collector ચાલ્યો નહોતો અથવા header ગેરહાજર હતું. Result એ દર્શાવે છે, અને તમારી policy તે અનુસાર વર્તે છે.

દરેક route માટે તમે fail open or fail closed કરવું છે કે નહીં તે પસંદ કરો. Fail open એટલે request એવું જ આગળ વધે જેમ કે Proof of Actor ન હોય; fail closed એટલે તમારો existing stronger check લાગુ પડે. Low-risk routes સામાન્ય રીતે fail open હોય છે. Sensitive actions સામાન્ય રીતે fail closed હોય છે. તમે આને global રીતે નહીં, risk tier પ્રમાણે સેટ કરો છો.

Identity, credentials અને authorization ને અલગ રાખો

Agent access policies ત્રણ અલગ સ્તરોની ઉપર બેઠી છે, અને તેમને અલગ રાખવાથી સૌથી નુકસાનકારક ભૂલો ટળે છે.

Identity evidence જવાબ આપે છે કે કયો actor call કરી રહ્યો છે અને તેનો પુરાવો શું છે. Proof of Actor આ પૂરુ પાડે છે.
Credentials જવાબ આપે છે કે કયા account માટે જવાબદારી છે. તમારું session, token અથવા API key આ પૂરુ પાડે છે.
Authorization જવાબ આપે છે કે આ caller ને આ action કરવા માટે પરવાનગી છે કે નહીં. તમારું permission model આ પૂરુ પાડે છે.

Verified agent identity નો અર્થ એ નથી કે agent authorized છે, કોઈ વ્યક્તિએ તેને authority સોંપી છે, અથવા તેની action safe છે. Actor results નો ઉપયોગ routing અને context ઉમેરવા માટે કરો. Permission આપવા માટે તમારા authorization model નો ઉપયોગ કરો. Detection & Limitations પાનું સ્પષ્ટ કરે છે કે evidence નો દરેક પ્રકાર શું સ્થાપિત કરી શકે છે.

કંઈક તૂટ્યા વગર rollout કરો

Agent access policies રજૂ કરવાની સૌથી સલામત રીત stages માં છે.

Observe. observation mode માં Proof of Actor ઇન્સ્ટોલ કરો. તમારા users માટે કંઈ બદલાતું નથી; results record થાય છે.
Understand. કયા actors કયા routes વાપરે છે, દરેક પર unknown rate શું છે, અને તમારા જાણ્યા મુજબ કંઈ વિરુદ્ધ આવતા results છે કે નહીં તે સમીક્ષો.
Preview. policy ને preview માં ચલાવો, enforce કર્યા વિના તે શું કરત તેની logging કરો.
Enforce narrowly. જ્યાં evidence સ્પષ્ટ રીતે સમર્થન આપે તેવા એક route પર policy enable કરો. Outcomes જુઓ.
Expand. confidence વધે તેમ વધુ routes સુધી વિસ્તારો.

rolling out actor-aware policies safely માર્ગદર્શિકા દરેક stage સમજાવે છે, અને protecting sensitive actions without blocking agents high-stakes routes કવર કરે છે.

તમારી ટીમને શું મળે છે

Proof of Actor સાથે તમારી team ને એક integration અને ત્રણ capabilities મળે છે. Detect actor signals gather કરે છે અને verified assertions ને inferences થી અલગ કરે છે. Understand actor analytics, trends અને દરેક result પાછળનું evidence બતાવે છે, Unknown ને visible રાખીને. Route તમને આ પેજ પર વર્ણવેલી policies લખવા અને જ્યાં તમે ઇચ્છો ત્યાં લાગુ કરવાની મંજૂરી આપે છે. private beta દરમિયાન, routing policies દરેક founding team સાથે રચાય છે અને તમારા પોતાના application code માં ચાલે છે, જેથી તમારું સંપૂર્ણ control જળવાય.

ટાળવા જેવી સામાન્ય policy ભૂલો

પ્રથમ વખત agent access ડિઝાઇન કરતી teams થોડા જ સામાન્ય ભુલો વારંવાર કરે છે. તેમને ટાળવાથી અઠવાડિયાંનું rework બચી શકે છે.

ડિફૉલ્ટ પ્રમાણે દરેક agent ને block કરવો. પછી legitimate agents ઘણી વાર તમારી આસપાસ route કરે છે, ઘણી વખત તમે લોકો માટે બનાવેલા interface ને scrape કરીને, જે structured path કરતાં protect કરવું વધુ મુશ્કેલ છે.
Declared નામ પર ભરોસો કરવો. માત્ર પોતાનું નામ આપનાર client એ claim કર્યો છે, પુરાવો આપ્યો નથી. તેને તેવો જ treatment આપો જે તમે unverified caller ને આપશો.
દરેક જગ્યાએ એક જ fallback વાપરવો. public pricing page પર Unknown અને password change પર Unknown બે અલગ પરિસ્થિતિઓ છે. દરેક route ને તેનો પોતાનો જવાબ જોઈએ.
Inference પરથી લોકો વિશે નિર્ણય કરવો. Actor results routing માટે context છે, વ્યક્તિ વિશેનો verdict નથી. Consequential decisions તમારા પોતાના controls અને review પાસે જ રાખો.
Observation છોડવી. Day one પર enforcement કરવાથી 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 અંદર up to 12 months સુધીનું free access, અને તેમની પહેલી policies ડિઝાઇન કરતી વખતે અમારા engineers નો direct support મળી શકે છે.

જો તમે નક્કી કરી રહ્યા છો કે તમારું application AI agents સાથે કેવી રીતે વર્તે, તો early access માટે apply કરો. કયા routes સૌથી મહત્વના છે અને તમે કયા નિર્ણયો લેવા માગો છો તે અમને જણાવો, અને અમે તમારી સાથે fit થતી 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: પરિણામ પાછળના signals, જેથી તમારી team કારણ જોઈ શકે.

observation mode માં શરૂ કરો: પરિણામોને તમારા logsની બાજુમાં નોંધો અને તમે policy પસંદ કરો ત્યાં સુધી કંઈ બદલશો નહીં. Node.js integration guide વાંચો

વારંવાર પૂછાતા પ્રશ્નો

AI agent access policy શું છે?

આ એ નિયમ છે જે તમારું application request કરનાર actor ના પ્રકારના આધારે લાગુ કરે છે, જેમ કે read-only routes પર verified agents ને allow કરવું અથવા high-impact actions માટે વધુ મજબૂત credential માંગવું. Proof of Actor actor result આપે છે; તમારી policy પ્રતિભાવ નક્કી કરે છે.

શું Proof of Actor policies ને આપમેળે enforce કરે છે?

ના. દરેક integration observation mode માં શરૂ થાય છે, અને policies તમારી ટીમ દ્વારા route by route enable કરવામાં આવે છે, જ્યારે તમને ખાતરી થાય કે તે workflow માટે યોગ્ય છે.

જ્યારે actor Unknown હોય અથવા check time out થાય ત્યારે શું થાય છે?

તમે દરેક route માટે explicit fallback નક્કી કરો છો, ઉદાહરણ તરીકે public reads allow કરવી અને account changes માટે existing checks યથાવત રાખવા. Unknown અને timeouts ક્યારેય Human તરીકે default થતા નથી.

શું મને બધા AI agents block કરવાં જોઈએ?

સામાન્ય રીતે નહીં. ઘણા agents legitimate participants હોય છે. Policies તમને તેમને structured path આપવા, જ્યાં મહત્વ હોય ત્યાં limit કરવા અને sensitive actions માટે stronger checks reserve કરવા દે છે.

શું policies લોકો વિશે નિર્ણયો લઈ શકે છે?

Proof of Actor ના results વ્યક્તિઓ વિશેના consequential decisions, જેમ કે employment, credit અથવા essential services માટે access, માટે એકમાત્ર આધાર હોવા જોઈએ નહીં. તેને routing અને context માટે, તમારી પોતાની controls સાથે સાથે ઉપયોગ કરો.

તમારા app નો ઉપયોગ કોણ કરે છે તે જાણો.

Founding developers ના નાના સમૂહ માટે private beta.

પ્રારંભિક ઍક્સેસ મેળવો કિંમત જુઓ

પહેલાં વાત કરવી પસંદ કરો છો? સ્થાપકો સાથે વાત કરો