AGENT प्रवेश धोरणे

तुम्ही नियंत्रित करता अशा धोरणांसह AI agents राऊट करा

तुमचे application लोकांशी, AI-assisted users शी आणि autonomous agents शी route by route कसे वागेल हे ठरवा. Proof of Actor evidence देते; अंतिम निर्णय तुमची धोरणे घेतात.

लवकर प्रवेश मिळवा ते कसे कार्य करते ते अन्वेषित करा

लेखक Toshendra Sharmaसंस्थापक आणि CEO, AgentCredia · Updated November 13, 2026

सर्वांसाठी एकच policy आता पुरेशी नाही

बहुतेक applications एका प्रकारच्या user भोवती डिझाइन केले होते: account मध्ये signed in असलेली आणि interface मधून क्लिक करणारी व्यक्ती. Access control या गृहितावर आधारले होते. Session वैध असेल तर request पुढे जाते. ती automated दिसली तर CAPTCHA किंवा block दिसतो.

ते model आता तुटत आहे. आज तेच application लोकांनाही, AI assistants सोबत काम करणाऱ्या लोकांनाही, आणि एखाद्याच्या वतीने काम करणाऱ्या autonomous agents ना देखील सेवा देते. काही agents ग्राहकांच्या स्वतःच्या integrations असतात. काही AI assistants documentation आणतात. काही crawlers असतात. काही तुमचे product abuse करण्याचा प्रयत्न करतात. एकच yes-or-no rule या सर्वांसाठी योग्य ठरू शकत नाही.

AI agent routing आणि access policies त्या एकमेव नियमाऐवजी deliberate decisions चा संच देतात: कोणत्या actors ना कोणता अनुभव, कोणत्या routes वर, कोणत्या अटींवर. Proof of Actor तुमच्या application ला हे निर्णय घेण्यासाठी evidence देते, आणि निर्णय तुमच्याकडेच ठेवते. या दृष्टिकोनामागील 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 strength, आणि response यांची नावे देते. उदाहरणार्थ:

Read-only catalog routes: verified agents ना allow करा आणि structured response द्या; declared agents ना standard rate limit सह allow करा.
Account-changing actions: सर्वांसाठी तुमची विद्यमान re-authentication ठेवा; actor Unknown असेल आणि action high impact असेल तेव्हा review जोडा.
Support submissions: disclosed AI-assisted content स्वीकारा आणि routing साठी label करा.
Signup: विद्यमान checks ठेवा; inferred actor result वरून कधीही एकट्याने निर्णय घेऊ नका.

या प्रत्येक ठिकाणी agent ला abuse समजून न घेता आणि प्रत्येक agent वर आंधळेपणाने विश्वास न ठेवता response दिला जातो. हाच agent-aware access चा संपूर्ण उद्देश आहे, आणि designing app policies for humans and AI agents हा blog post route by route आणखी उदाहरणे उलगडतो.

पाच response

Proof of Actor ची Route capability तुमची policy कोणत्या पाच response मधून निवडू शकते याभोवती बांधलेली आहे.

Allow

request नेहमीप्रमाणे पुढे जाऊ द्या. बहुतेक traffic, public किंवा low-risk routes वरील बहुतेक agent traffic सहित, फक्त allow केले पाहिजे.

Adapt

actor ला योग्य असा अनुभव बदला. मानवासारख्या interface ऐवजी verified agent साठी structured API response किंवा पानाची Markdown version द्या. serving AI agents structured content या guide मध्ये हा pattern समाविष्ट आहे.

Challenge

अधिक मजबूत काहीतरी मागा: नवीन login, अतिरिक्त credential, account owner कडून confirmation. ज्या routes वर चुकीच्या निर्णयाची किंमत जास्त आहे तिथे challenges वापरा.

Review

action पूर्ण करण्याऐवजी queue मध्ये जाऊ द्या, किंवा human कडून तपासणीसाठी flag करा. जिथे block केल्याने legitimate users चे नुकसान होईल पण unattended completion खूप धोकादायक आहे, तिथे review उपयुक्त आहे.

Limit

actor आणि route नुसार rate किंवा volume limit लावा, जेणेकरून people साठी तयार केलेला workflow automated callers मुळे भरून जाणार नाही.

robots.txt ही access policy नाही

अनेक टीम्स robots.txt पासून सुरुवात करतात, आणि crawlers साठी ते एक वाजवी पहिला signal आहे. पण ते agents साठी access policy नाही. Crawler operators वेगवेगळ्या user agents साठी वेगळे behavior दस्तऐवजीकृत करतात: Anthropic सांगते की त्यांचे bots robots.txt directives पाळतात (Anthropic crawler documentation), तर OpenAI नोंदवते की ChatGPT-User साठी, जेव्हा user ChatGPT ला प्रश्न विचारतो तेव्हा कृती user ने सुरू केल्यामुळे 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: result कशावर आधारलेला आहे याचे वाचता येण्यासारखे वर्णन, logging आणि review साठी उपयुक्त.
Context: कोणत्या integration ने आणि कोणत्या route ने तो result तयार केला.

Basis स्पष्ट असल्यामुळे तुमच्या policies अचूक असू शकतात. "Allow agents" हे "read routes वर verified agents ना allow करा, declared agents ना rate-limit करा, उरलेल्या सर्वांसाठी Unknown fallback वापरा" असे होते. Request पासून निर्णयापर्यंतचा पूर्ण flow How It Works वर वर्णन केला आहे.

Fallbacks policy चा भाग आहेत

Evidence नसताना तुमची policy कशी वागते यावरच तिची गुणवत्ता ठरते. Proof of Actor ही प्रकरणे लपवण्याऐवजी स्पष्ट करते.

Unknown: evidence ने निर्धारणाला आधार दिला नाही. प्रत्येक route वर Unknown चा अर्थ काय हे तुमची policy ठरवते. ते कधीही 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 म्हणजे तुमचा विद्यमान अधिक मजबूत check लागू होतो. Low-risk routes साधारणपणे fail open असतात. Sensitive actions साधारणपणे fail closed असतात. तुम्ही हे प्रति risk tier ठरवता, जागतिक पातळीवर नाही.

Identity, credentials आणि authorization वेगळे ठेवा

Agent access policies तीन स्वतंत्र थरांवर बसतात, आणि त्यांना वेगळे ठेवणे सर्वात नुकसानकारक चुका टाळते.

Identity evidence कोणत्या प्रकारचा actor कॉल करीत आहे आणि ते काय सिद्ध करते हे सांगते. हे Proof of Actor देते.
Credentials कोणते account जबाबदार आहे हे सांगतात. तुमचे session, token किंवा API key हे देते.
Authorization हा caller ही action करू शकतो का ते सांगते. तुमचा permission model हे देतो.

Verified agent identity म्हणजे agent authorized आहे, एखाद्या व्यक्तीने त्याला authority दिली आहे, किंवा त्याची action सुरक्षित आहे असे होत नाही. Actor results चा वापर routing आणि context देण्यासाठी करा. Permission देण्यासाठी तुमचा authorization model वापरा. Detection & Limitations पानात कोणत्या प्रकारचे evidence नेमके काय सिद्ध करू शकते हे स्पष्ट केले आहे.

काहीही मोडू न देता rollout करा

Agent access policies आणण्याचा सर्वात सुरक्षित मार्ग टप्प्याटप्प्याने आहे.

Observe. observation mode मध्ये Proof of Actor install करा. तुमच्या users साठी काहीही बदलत नाही; results नोंदवले जातात.
Understand. कोणते actors कोणते routes वापरतात, प्रत्येकावर unknown rate किती आहे, आणि तुम्हाला आधीच माहीत असलेल्या गोष्टींशी विरोध करणारे result आहेत का ते पाहा.
Preview. Policy preview मध्ये चालवा, enforce न करता ती काय करेल ते log करा.
Enforce narrowly. Evidence स्पष्टपणे समर्थन देत असलेल्या एका route वर policy सक्षम करा. Outcomes पहा.
Expand. Confidence वाढत गेल्यावर अधिक routes वर विस्तार करा.

rolling out actor-aware policies safely हा guide प्रत्येक टप्पा समजावतो, आणि protecting sensitive actions without blocking agents उच्च-जोखमीच्या routes कव्हर करतो.

तुमच्या टीमला काय मिळते

Proof of Actor सह तुमच्या टीमला तीन capabilities असलेली एक integration मिळते. Detect actor signals गोळा करते आणि verified assertions व inferences वेगळे करते. Understand actor analytics, trends आणि प्रत्येक result मागचे evidence दाखवते, Unknown दृश्यमान ठेवून. Route तुम्हाला या पानावर वर्णन केलेल्या policies लिहू देते आणि निवडलेल्या ठिकाणी लागू करू देते. private beta दरम्यान, routing policies प्रत्येक founding team सोबत तयार केल्या जातात आणि तुमच्या स्वतःच्या application code मध्ये चालतात, त्यामुळे तुमचे पूर्ण नियंत्रण राहते.

टाळाव्यात अशा सामान्य policy चुका

पहिल्यांदाच agent access डिझाइन करणाऱ्या टीम्स काही ठराविक चुका वारंवार करतात. त्या टाळल्याने अनेक आठवड्यांचे rework वाचते.

डिफॉल्टने प्रत्येक agent block करणे. Legitimate agents मग तुमच्या मार्गाभोवती वळसा घालतात, अनेकदा तुम्ही लोकांसाठी तयार केलेले interface scrape करून, जे structured path पेक्षा जपणे कठीण असते.
Declared name वर विश्वास ठेवणे. फक्त स्वतःचे नाव सांगणाऱ्या client ने दावा केला आहे, पुरावा दिलेला नाही. त्याला unverified caller प्रमाणेच वागणूक द्या.
सर्वत्र एकच fallback वापरणे. Public 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 शी कसे वागावे हे ठरवत असाल, तर 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 च्या शेजारी नोंदवा आणि तुम्ही policy निवडेपर्यंत काहीही बदलू नका. Node.js integration guide वाचा

वारंवार विचारले जाणारे प्रश्न

AI agent प्रवेश धोरण म्हणजे काय?

हे असे नियम आहे जे तुमचे application request करणाऱ्या actor च्या प्रकारावर आधारित लागू करते, उदाहरणार्थ read-only routes वर verified agents ना allow करणे किंवा high-impact actions साठी अधिक मजबूत credential मागणे. Proof of Actor actor result देते; response तुमची policy ठरवते.

Proof of Actor आपोआप policies enforce करते का?

नाही. प्रत्येक integration observation mode मध्ये सुरू होते, आणि तुमची टीम route by route policies सक्षम करते, जेव्हा त्या त्या workflow ला योग्य आहेत याची खात्री होते.

जेव्हा actor Unknown असतो किंवा check timeout होतो तेव्हा काय होते?

प्रत्येक route साठी तुम्ही स्पष्ट fallback ठरवता, उदाहरणार्थ public reads allow करा आणि account changes वर विद्यमान checks तशाच ठेवा. Unknown आणि timeouts कधीही Human वर default होत नाहीत.

मी सगळे AI agents block करावे का?

साधारणपणे नाही. अनेक agents वैध सहभागी असतात. Policies तुम्हाला त्यांच्यासाठी structured path देतात, जिथे गरज आहे तिथे limit करतात आणि sensitive actions साठी अधिक मजबूत checks राखून ठेवतात.

Policies लोकांबद्दल निर्णय घेऊ शकतात का?

Proof of Actor चे results employment, credit किंवा essential services access यांसारख्या व्यक्तींवरील consequential decisions साठी एकमेव आधार नसावेत. त्यांचा वापर routing आणि context साठी करा, तुमच्या own controls सोबत.

तुमचे app कोण वापरत आहे ते जाणून घ्या.

founding developers च्या छोट्या गटासाठी private beta.

लवकर प्रवेश मिळवा किमती पहा

आधी बोलणे पसंत आहे? founders शी बोला