तुलना

Proof of Actor विरुद्ध user agent allowlists: नाव हे claim आहे, proof नाही

User-Agent string वर आधारित allowlisting पटकन सेट अप होते आणि समजायला सोपे असते. ते फसवणेही सोपे असते, कारण header मध्ये client जे पाठवतो तेच असते. user agent allowlist प्रत्यक्षात तुम्हाला काय सांगते, network checks कुठे मदत करतात, आणि Proof of Actor declarations कशा verified evidence पासून वेगळ्या करतो हे येथे दिले आहे.

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

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

थोडक्यात उत्तर

User agent allowlist client च्या User-Agent header मध्ये जे नाव असते त्यावर विश्वास ठेवते, आणि कोणताही client कोणतेही नाव टाइप करू शकतो. Reverse DNS आणि published IP ranges काही operators साठी खरे evidence देतात, पण फक्त ज्यांनी ते publish केले आहे त्यांच्यासाठी. Proof of Actor header ला declaration मानते, agents त्यांच्या requests sign करतात तिथे signatures तपासते, आणि evidence कमी असेल तेव्हा Unknown report करते, त्यामुळे तुमचा code facts समोर ठेवून निर्णय घेतो.

User agent allowlist ही web वरील सर्वात जुनी patterns पैकी एक आहे. तुम्ही ज्यांच्यावर विश्वास ठेवता अशा crawler आणि client names ची यादी ठेवता. request आली आणि User-Agent header जुळला, तर तुम्ही तिला पुढे जाता देता, challenge वगळता, किंवा हलके page serve करता. सेट अप करण्यास काही मिनिटे लागतात आणि टीममधील प्रत्येकाला ती समजते.

हा pattern त्या काळी अधिक अर्थपूर्ण होता, जेव्हा मुख्य automated visitors काही search crawlers आणि काही monitoring tools इतकेच होते. आज, AI agents, assistants आणि automated clients वाढत्या संख्येने applications पर्यंत पोहोचतात, आणि त्यापैकी बरेच जण नाव जाहीर करतात. त्या नावांपैकी काही खरी असतात. काही कॉपी केलेली असतात. header तुम्हाला कोणते आहे ते सांगू शकत नाही.

Proof of Actor वेगळा दृष्टिकोन घेते. ते User-Agent string ला तेच मानते जे ती आहे, म्हणजे एक declaration, आणि stronger evidence अस्तित्वात असेल तेव्हा त्यासोबत ते report करते. हे पृष्ठ नावावर आधारित allowlisting च्या मर्यादा, network-level checks कुठे मदत करतात, आणि verified signatures व स्पष्ट Unknown class चित्र कसे बदलतात हे स्पष्ट करते.

थोडक्यात

	User agent allowlist	Proof of Actor
मुख्य evidence	User-Agent header मधील नाव	Signatures, declarations आणि signals, प्रत्येकी त्यांच्या basis सह label केलेले
client ते बनावट करू शकतो का?	हो, तीच string पाठवून	declared basis दावा केला जाऊ शकतो; verified basis साठी signing key आवश्यक आहे
Output	यादीत आहे किंवा नाही	Human, Human + AI, Agent किंवा Unknown, तसेच basis
अस्पष्ट traffic	allowlisted नसल्याप्रमाणे हाताळले जाते, किंवा default ने allow केले जाते	Unknown, तुमच्या निवडीनुसार प्रति route fallback सह
AI-सह मदत घेणारे लोक	अदृश्य; ते सामान्य browser वापरतात	घोषित किंवा observed झाल्यावर स्वतंत्र वर्ग, Human + AI
देखभाल	नावे बदलली की manual list updates	agent operators ने published केलेली keys; policies तुमच्या code मध्ये
install केल्यावर default	यादी जे allow करते ते	Observation; तुम्ही policy जोडत नाही तोपर्यंत काहीच बदलत नाही
कशात सर्वोत्तम	well-behaved, known clients चे स्वस्त routing	product आणि policy निर्णयांसाठी evidence-based actor context

पुढील भागात प्रत्येक ओळ समजावली आहे.

User-Agent नुसार allowlisting spoof का होऊ शकते

User-Agent header client सेट करतो. browser तो सेट करतो, script तो सेट करते, आणि agent framework तो सेट करते. HTTP मध्ये त्या value खरी आहे की नाही याची तपासणी नसते. तुमची allowlist एखाद्या string वर विश्वास ठेवत असेल, तर ती string कॉपी करणाऱ्याला तोच उपचार मिळतो.

याला user agent spoofing म्हणतात, आणि ते एका सोप्या कारणामुळे सामान्य आहे: त्याची किंमत काहीच नसते. challenge टाळू इच्छिणाऱ्या scraper ला तुम्ही विश्वास ठेवता त्या crawler चे नाव उधार घ्यावे लागते. गैरवर्तणूक करणारा client लोकप्रिय assistant असल्याचा दावा करू शकतो. एखादे वैध tool सुद्धा generic browser string पाठवू शकते, कारण library च्या default मुळे ते झाले.

याचा परिणाम असा की user agent allowlist चे दोन failure modes होतात:

False trust: अविश्वसनीय client trusted नावाचा दावा करतो आणि पास होतो.
False doubt: वैध client अनपेक्षित किंवा generic string पाठवतो आणि fail होतो.

केवळ header पाहून यापैकी कोणताही failure दिसत नाही. हीच मुख्य मर्यादा आहे, आणि list maintenance ने ती दूर होत नाही.

याचा अर्थ User-Agent strings दुर्लक्षित कराव्यात असा नाही. well-behaved crawlers आणि agents प्रामाणिकपणे स्वतःची घोषणा करतात, आणि हे नाव routing, analytics आणि debugging साठी उपयुक्त hint असते. client स्वतःला काय म्हणतो ते तुम्हाला कळते.

ही माहिती declaration म्हणून, इतर evidence सोबत तौलनिक पाहणे योग्य आहे, प्रवेश उघडणारी स्वतंत्र key म्हणून नाही. Proof of Actor ते अगदी तसेच नोंदवते.

Reverse DNS आणि IP list: अंशतः उपाय

अनेक teams network checks ने allowlist मजबूत करतात. ते मदत करतात, आणि नेमकेपणाने समजून घेण्यासारखे आहेत.

Reverse DNS verification

काही crawler operators एक verification process document करतात: request च्या IP address साठी hostname lookup करा, तो operator च्या domain चा आहे का ते तपासा, मग त्या hostname चे lookup करून तोच IP परत मिळतो का ते confirm करा. हा round trip यशस्वी झाला, तर request operator च्या infrastructure मधून आली याचे खरे evidence तुमच्याकडे असते.

याला practical मर्यादा आहेत. हे फक्त ज्यांनी ते document आणि support केले आहे अशा operators साठीच चालते. यात DNS lookups येतात, ज्यांना तुम्हाला cache करावे लागते. आणि हे तुम्हाला network बद्दल सांगते, त्या network वर कोणते product किंवा agent ने request केली याबद्दल नाही.

Published IP ranges

इतर operators त्यांच्या automated clients वापरतात त्या IP ranges publish करतात. request ला त्या ranges शी जुळवणे जलद असते आणि reverse DNS सारखेच evidence देते. IP ranges publish करण्यासाठी standard format वर IETF मध्ये चर्चा सुरू आहे, पण November 2026 पर्यंत ठरलेला standard नाही, आणि coverage हे प्रत्येक operator publish करतो की नाही यावर अवलंबून असते.

अधिक agents shared cloud infrastructure वर, proxies च्या मागे, किंवा user च्या स्वतःच्या device वर चालू लागल्यामुळे IP evidenceही कमकुवत होते. एका cloud address वर अनेक unrelated clients असू शकतात, आणि एखादा agent व्यक्तीच्या browser मधून काम करत असेल तर तो त्या व्यक्तीच्या network सारखा दिसतो.

Network checks एकत्र काय देतात

Reverse DNS आणि IP lists काही well-known operators साठी काही declarations अधिक मजबूत गोष्टीत बदलतात. ते agents आणि tools च्या long tail ला कव्हर करत नाहीत, आणि AI सोबत काम करणाऱ्या लोकांना अजिबात मदत करत नाहीत. ते अंशतः उपाय आहेत: वापरण्यासारखे, पण एकटे अपुरे.

Signatures विरुद्ध declarations

Evidence चे अधिक मजबूत रूप म्हणजे cryptographic signature. HTTP Message Signatures मध्ये, जे RFC 9421 मध्ये परिभाषित आहेत, client प्रत्येक request चे निवडक भाग private key ने sign करतो. verifier operator चा published public key fetch करतो आणि signature तपासतो. तो verify झाला तर request त्या key च्या holder ने sign केली होती, आणि signed भाग प्रवासात बदलले गेले नाहीत.

IETF Web Bot Auth working group automated clients कसे ही signatures वापरतात आणि त्या त्यांच्या keys कशा publish करतात हे standardize करत आहे. आमचा Web Bot Auth for product teams explainer सध्याची स्थिती समजावतो.

Proof of Actor valid signature ला Verified evidence म्हणून वापरते. User-Agent string, client hint किंवा request body मधील self-description हे Declared ठरते. Behavioral आणि contextual signals Inferred म्हणून गणले जातात, आणि तसे label केले जातात. प्रत्येक result मध्ये त्याचा basis कोणता आहे हे स्पष्टपणे नमूद केले जाते, त्यामुळे तुमची टीम दावा आणि check यांची गल्लत करत नाही. संपूर्ण व्याख्यांसाठी evidence basis entry पहा.

Verified evidence साठीही एक मर्यादा लागू होते. valid signature request कोणत्या key ने sign केली हे सिद्ध करते. agent ला तो जे मागत आहे ते करण्याची परवानगी आहे हे ते सिद्ध करत नाही. हा agent authorization चा प्रश्न आहे, आणि तो तुमच्या application मध्येच राहतो.

अंदाज न लावता Unknown हाताळणे

Allowlist प्रत्येक request ला दोनच गटांपैकी एका गटात टाकते: यादीत किंवा नाही. प्रत्यक्षात याचा अर्थ अस्पष्ट traffic ला तुमचा default काय आहे ते मिळते, आणि तो default सहसा संपूर्ण site साठी एकदाच ठरवला जातो.

Proof of Actor Unknown ला पहिल्या दर्जाचा result मानते. जेव्हा evidence विश्वसनीय निष्कर्षाला support करत नाही, तेव्हा ते अंदाज न लावता तसे सांगते. त्यानंतर तुमची policy प्रत्येक route वर Unknown चा अर्थ ठरवते:

public documentation किंवा marketing pages वर, ते allow करा.
search किंवा listing endpoints वर, तुमच्या नेहमीच्या rate limits सह allow करा.
account changes वर, तुमचे विद्यमान checks ठेवा.
high-impact actions वर, ते review कडे पाठवा किंवा अधिक मजबूत signal मागा.

handling Unknown traffic वरचा guide आणि unknown classification entry या patterns समजावतात. वेळोवेळी तुमचा Unknown rate track केल्याने तुमच्या traffic चा किती भाग अजूनही कमकुवत evidence वर अवलंबून आहे हेही समजते.

AI-सह मदत घेणाऱ्या लोकांचे काय?

सामान्य browser मध्ये AI assistant वापरणाऱ्या व्यक्तीबद्दल user agent allowlist काहीही सांगत नाही. त्यांचा User-Agent हा सामान्य browser string असतो. तरीही अनेक products अशा interaction ला ओळखू इच्छितात, उदाहरणार्थ AI-ने लिहिलेल्या submissions ला label करण्यासाठी किंवा AI-सह वापरकर्ते onboarding मधून कसे जातात हे समजण्यासाठी.

Supported integration मधून मदत घोषित केली गेली किंवा observed झाली तर Proof of Actor हे interactions Human + AI म्हणून report करते. ते फक्त writing style वरून अंदाज लावत नाही. अधिक माहितीसाठी AI-assisted interaction पहा.

Allowlist पासून evidence-based policies कडे जाणे

पहिल्या दिवशीच तुम्हाला allowlist काढून टाकण्याची गरज नाही. सुरक्षित मार्ग असा दिसतो:

Observation mode मध्ये install करा. Proof of Actor काहीही बदलत नाही. तुमची allowlist काम करत राहते.
Compare करा. प्रत्येक route साठी पाहा की कोणत्या allowlisted requests कडे verified evidence आहे, कोणत्या कडे फक्त declaration आहे, आणि कोणत्या Unknown मध्ये संपतात.
Policies preview करा. verified agents, declared agents आणि Unknown यांना वेगळ्या पद्धतीने हाताळणारी policy तयार करा, आणि प्रत्यक्ष traffic वर तिचा परिणाम preview करा.
Route by route enforce करा. spoofed नाव सर्वात महत्त्वाचे ठरेल अशा routes पासून सुरू करा.
Hint म्हणून allowlist ठेवा. नावे routing आणि analytics साठी उपयुक्त राहतात, आता त्यांच्या basis सह.

rolling out actor-aware policies safely वरचा guide प्रत्येक पायरी स्पष्ट करतो, आणि verified automated requests signed clients कसे बसतात ते सांगतो.

Allowlist कधी पुरेशी असते

कमी जोखमीच्या routing साठी, उदाहरणार्थ public content वर known crawler ला हलके page serve करणे, user agent allowlist बऱ्याच वेळा पुरेशी असते. spoofed नावाची किंमत कमी असते.

जेव्हा निर्णयाचे परिणाम होतात, जसे challenge वगळणे, अधिक समृद्ध data उघडणे, किंवा write allow करणे, तेव्हा तुम्हाला तपासता येईल असे evidence हवे असते. इथेच Proof of Actor बसते, तुम्ही आधीच चालवत असलेल्या network checks आणि edge controls सोबत काम करत.

सुरुवात करा

Proof of Actor private beta मध्ये आहे. निवडलेल्या founding developer teams ना ठरलेल्या usage limits मध्ये, automatic billing शिवाय, 12 months पर्यंत free access मिळू शकतो. early access साठी अर्ज करा आणि आज तुम्ही कोणते clients allowlist करता आणि कोणत्या routes ला अधिक चांगल्या evidence ने protect करायचे आहे ते सांगा.

विकसकांसाठी

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 वाचा

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

User agent allowlist निरुपयोगी आहे का?

नाही. well-behaved clients कडून आलेले ते एक उपयुक्त declaration आहे आणि known crawlers ला route करण्याचा स्वस्त मार्ग आहे. समस्या त्याला proof मानण्यात आहे. कोणताही client कोणतीही User-Agent string पाठवू शकतो, म्हणून allowlist एकटी कधीही sensitive actions उघडू नये.

Reverse DNS verification User-Agent spoofing दुरुस्त करते का?

ज्या operators ते document करतात त्यांच्यासाठी ते मदत करते. reverse lookup नंतर matching forward lookup केल्याने IP address operator च्या domain शी जोडला जातो. ते फक्त ज्यांनी त्याला support केले आहे त्यांच्यासाठी चालते, आणि shared cloud किंवा residential addresses वरून येणाऱ्या traffic बद्दल काहीच सांगत नाही.

Proof of Actor User-Agent header कसा हाताळते?

Declaration म्हणून. ते declared basis सह result मध्ये योगदान देते, verified basis कधीच नाही. Verified basis साठी HTTP Message Signature सारखे evidence हवे असते, जे published key विरुद्ध तपासले जाते.

Verified signature काय सिद्ध करते?

कोणत्या key ने request sign केली आणि signed parts बदलले नव्हते हे ते सिद्ध करते. agent ला तो action करण्याची परवानगी आहे हे ते सिद्ध करत नाही. Authorization तुमच्या application मध्येच राहते.

जे clients known agent असल्याचा दावा करतात पण verify होऊ शकत नाहीत त्यांचे काय होते?

Proof of Actor evidence जे समर्थित करते ते report करते, अनेकदा declared किंवा inferred result, किंवा Unknown. त्या route साठी तुमची policy claimed name वर विश्वास ठेवण्याऐवजी fallback निवडते.

Proof of Actor जोडल्याने माझे सध्याचे allowlist behavior बदलेल का?

नाही. ते observation mode मध्ये सुरू होते. काहीही बदलण्यापूर्वी प्रत्यक्ष traffic वर तुम्ही त्याचे परिणाम तुमच्या allowlist decisions शी तुलना करू शकता.

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

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

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

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