एजेंट एक्सेस नीतियाँ

आपके नियंत्रण वाली नीतियों के साथ AI agents को route करें

तय करें कि आपका application route by route लोगों, AI-assisted users और autonomous agents के साथ कैसे व्यवहार करता है। Proof of Actor evidence देता है; निर्णय आपकी policies लेती हैं।

Early Access प्राप्त करें यह कैसे काम करता है, देखें

द्वारा Toshendra Sharmaसंस्थापक और CEO, AgentCredia · Updated November 13, 2026

सबके लिए एक ही policy अब पर्याप्त नहीं है

अधिकांश applications एक ही तरह के user को ध्यान में रखकर बनाई गई थीं: एक व्यक्ति जो interface पर क्लिक करता है और account में signed in है। Access control इसी धारणा पर आधारित था। अगर session valid है, तो request आगे बढ़ जाती है। अगर वह automated लगती है, तो CAPTCHA या block दिख जाता है।

यह model टूट रहा है। आज वही application लोगों, AI assistants के साथ काम करने वाले लोगों और किसी और की ओर से काम करने वाले autonomous agents, सभी को service देती है। कुछ agents ग्राहकों के अपने integrations होते हैं। कुछ AI assistants documentation fetch करते हैं। कुछ crawlers होते हैं। कुछ आपके product का दुरुपयोग करने की कोशिश करते हैं। एक yes-or-no rule इन सभी के लिए अच्छा काम नहीं कर सकता।

AI agent routing और access policies उस एक rule को deliberate decisions के एक set से बदलते हैं: किस actor को कौन सा experience मिलेगा, किन routes पर, किन conditions के तहत। Proof of Actor आपके application को ये decisions लेने के लिए evidence देता है, और decisions को आपके हाथ में छोड़ देता है। इस approach के design principles के लिए designing app policies for humans and AI agents पढ़ें, और देखें कि policies वास्तविक 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 पर बिना जांच के भरोसा करके। यही 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 को सामान्य रूप से आगे बढ़ने दें। अधिकांश traffic, जिसमें public या low-risk routes पर अधिकांश agent traffic भी शामिल है, simply allow किया जाना चाहिए।

Adapt

Experience को actor के अनुरूप बदलें। Human-shaped interface के बजाय verified agent को structured API response या page का Markdown version दें। serving AI agents structured content guide इस pattern को कवर करता है।

Challenge

कुछ अधिक मजबूत मांगें: नया login, अतिरिक्त credential, account owner से confirmation। उन routes पर challenges का उपयोग करें जहां गलत decision की लागत अधिक है।

Review

Action को सीधे completion तक पहुंचाने के बजाय queue में जाने दें, या human review के लिए flag करें। Review तब उपयोगी है जब block करने से legitimate users को नुकसान होगा, लेकिन बिना निगरानी के completion बहुत जोखिमभरा है।

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 के लिए अलग behavior document करते हैं: 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 के handled होने वाली जगह पर चलना चाहिए, RFC 9421 के तहत जांचे गए signature जैसी evidence पढ़नी चाहिए, और हर route के लिए response चुनना चाहिए। MCP servers के लिए, MCP authorization specification यह परिभाषित करती है कि clients HTTP के माध्यम से access tokens कैसे प्राप्त करते हैं; actor policies इसके ऊपर context जोड़ती हैं, इसे replace नहीं करतीं।

Proof of Actor आपकी policies को कैसे feed करता है

आपका integration जिन हर request का मूल्यांकन करता है, वह एक actor result उत्पन्न करता है जिसमें चार हिस्से होते हैं, जिन्हें आपकी policy पढ़ सकती है:

Class: Human, Human + AI, Agent या Unknown.
Basis: verified, declared, inferred या unknown, ताकि आपकी policy एक validated signature और self-declared client name के साथ अलग व्यवहार कर सके.
Evidence summary: परिणाम किस आधार पर टिका है, इसका readable description, logging और review के लिए उपयोगी।
Context: किस integration और किस route ने इसे उत्पन्न किया।

क्योंकि basis explicit है, आपकी policies precise हो सकती हैं। "Allow agents" का मतलब बन जाता है "read routes पर verified agents को allow करें, declared agents को rate-limit करें, और बाकी सब पर Unknown fallback लागू करें." Request से decision तक की पूरी flow How It Works पर वर्णित है।

Fallbacks policy का हिस्सा हैं

Evidence गायब होने पर policy का व्यवहार जितना अच्छा होगा, policy उतनी ही अच्छी होगी। Proof of Actor उन मामलों को छुपाने के बजाय स्पष्ट बनाता है।

Unknown: evidence किसी determination का समर्थन नहीं कर सका। आपकी policy तय करती है कि हर route पर Unknown का क्या मतलब होगा। इसे कभी Human में convert नहीं किया जाता और default रूप से इसे malicious नहीं माना जाता।
Timeout: result समय पर नहीं आया। आपका integration उस route के लिए चुना गया fallback लागू करता है।
Missing signals: कोई collector नहीं चला या कोई header अनुपस्थित था। Result उसी को reflect करता है, और आपकी 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 होती हैं। आप इसे globally नहीं, बल्कि risk tier के हिसाब से सेट करते हैं।

Identity, credentials और authorization को अलग रखें

Agent access policies तीन अलग layers के ऊपर बैठती हैं, और उन्हें अलग रखना सबसे गंभीर गलतियों से बचाता है।

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 सुरक्षित है। Routing और context जोड़ने के लिए actor results का उपयोग करें। Permission देने के लिए अपने authorization model का उपयोग करें। Detection & Limitations page स्पष्ट करती है कि किस प्रकार की evidence क्या स्थापित कर सकती है।

कुछ भी तोड़े बिना rollout करें

Agent access policies को introduce करने का सबसे सुरक्षित तरीका staged है।

Observe. observation mode में Proof of Actor install करें। आपके users के लिए कुछ नहीं बदलता; results record होते हैं।
Understand. देखें कि कौन से actors कौन से routes का उपयोग करते हैं, हर एक पर Unknown rate कितना है, और कौन से results आपकी पहले से ज्ञात बातों से असहमत हैं।
Preview. Policy को preview में चलाएं, यह log करते हुए कि अगर enforce किया जाता तो वह क्या करती।
Enforce narrowly. Policy को एक ऐसे route पर सक्षम करें जहां evidence स्पष्ट रूप से इसका समर्थन करता हो। Outcomes देखें।
Expand. Confidence बढ़ने पर और routes तक विस्तार करें।

rolling out actor-aware policies safely guide हर stage को समझाती है, और protecting sensitive actions without blocking agents high-stakes routes को कवर करती है।

आपकी team को क्या मिलता है

Proof of Actor के साथ, आपकी team को तीन capabilities वाला एक integration मिलता है। Detect actor signals इकट्ठा करता है और verified assertions को inferences से अलग करता है। Understand actor analytics, trends और हर result के पीछे की evidence दिखाता है, जबकि Unknown visible रहता है। Route आपको इस page पर वर्णित policies लिखने और उन्हें अपनी पसंद की जगह पर लागू करने देता है। private beta के दौरान, routing policies हर founding team के साथ designed होती हैं और आपके अपने application code में चलती हैं, ताकि आपका पूरा control बना रहे।

बचने योग्य सामान्य policy गलतियां

जो teams पहली बार agent access design करती हैं, वे कुछ सामान्य गलतियां दोहराती हैं। उन्हें टालने से हफ्तों का rework बचता है।

डिफ़ॉल्ट रूप से हर agent को block करना। तब legitimate agents अक्सर आपको bypass कर देते हैं, अक्सर उस interface को scrape करके जो आपने लोगों के लिए बनाया था, और उसे protect करना structured path से अधिक कठिन होता है।
Declared name पर भरोसा करना। जो client केवल अपना नाम बताता है, उसने दावा किया है, प्रमाण नहीं दिया। उसे वही 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 step से पहले security, product और support leads के साथ एक short policy review इनमें से अधिकांश को जल्दी पकड़ लेता है।

Founding developer program से शुरुआत करें

Proof of Actor private beta में है। चुनी गई founding development teams को agreed usage limits के भीतर up to 12 months तक free access मिल सकता है, और अपनी पहली policies design करते समय हमारे engineers से direct support मिलता है।

अगर आप तय कर रहे हैं कि आपकी application AI agents के साथ कैसा व्यवहार करे, तो apply for 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 में शुरू करें: results को अपने logs के पास record करें और जब तक आप कोई policy न चुनें, कुछ न बदलें। Node.js integration guide पढ़ें

अक्सर पूछे जाने वाले प्रश्न

AI agent access policy क्या है?

यह आपकी application द्वारा request करने वाले actor के प्रकार के आधार पर लागू किया जाने वाला नियम है, जैसे read-only routes पर verified agents को allow करना या high-impact actions पर stronger credential मांगना। Proof of Actor actor result देता है; response आपकी policy तय करती है।

क्या Proof of Actor policies को अपने-आप enforce करता है?

नहीं। हर integration observation mode में शुरू होती है, और policies आपकी team द्वारा route by route तब सक्षम की जाती हैं जब आपको भरोसा हो कि वे उस workflow के लिए उपयुक्त हैं।

जब actor Unknown हो या check time out हो जाए तो क्या होता है?

आप हर route के लिए एक explicit fallback तय करते हैं, उदाहरण के लिए public reads को allow करना और account changes पर existing checks बनाए रखना। Unknown और timeouts कभी Human में default नहीं होते।

क्या मुझे सभी AI agents को block करना चाहिए?

आमतौर पर नहीं। कई agents वैध participants होते हैं। Policies आपको उनके लिए एक structured path देने, जहां ज़रूरत हो वहां उन्हें limit करने और sensitive actions के लिए stronger checks reserve करने देती हैं।

क्या policies लोगों के बारे में decisions ले सकती हैं?

Proof of Actor के results को रोजगार, credit या essential services तक पहुंच जैसे व्यक्तियों से जुड़े consequential decisions का sole basis नहीं होना चाहिए। Routing और context के लिए, अपने controls के साथ मिलाकर उनका उपयोग करें।

जानें कि आपका app कौन उपयोग कर रहा है।

founding developers के छोटे समूह के लिए private beta।

Early Access प्राप्त करें मूल्य निर्धारण देखें

क्या पहले बात करना पसंद करेंगे? founders से बात करें