तुलना

Proof of Actor बनाम user agent allowlists: एक नाम दावा है, proof नहीं

User-Agent string के आधार पर allowlisting जल्दी सेट हो जाती है और समझना आसान है। इसे धोखा देना भी आसान है, क्योंकि header वही होता है जो client भेजना चुनता है। यहां बताया गया है कि user agent allowlist वास्तव में क्या बताती है, network checks कहां मदद करते हैं, और Proof of Actor declarations को verified evidence से कैसे अलग करता है.

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

द्वारा 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 में से एक है। आप trusted crawler और client names की एक सूची रखते हैं। जब कोई request matching User-Agent header के साथ आती है, तो आप उसे आगे जाने देते हैं, challenge छोड़ देते हैं, या उसे हल्का page serve करते हैं। इसे set up करने में कुछ मिनट लगते हैं और team का हर व्यक्ति इसे समझता है.

यह pattern तब अधिक समझ में आता था जब मुख्य automated visitors कुछ search crawlers और कुछ monitoring tools तक सीमित थे। आज, AI agents, assistants और automated clients बढ़ती संख्या में applications तक पहुंचते हैं, और उनमें से कई अपना नाम बताते हैं। उन नामों में से कुछ असली होते हैं। कुछ copied होते हैं। Header यह नहीं बता सकता कि कौन सा है.

Proof of Actor अलग approach लेता है। यह User-Agent string को उसी रूप में देखता है जैसा वह है, एक declaration, और जब वह evidence मौजूद होता है तो उसे stronger evidence के साथ रिपोर्ट करता है। यह page नाम के आधार पर allowlisting की सीमाएं, network-level checks कहां मदद करते हैं, और verified signatures तथा एक स्पष्ट Unknown class तस्वीर को कैसे बदलते हैं, यह समझाती है.

संक्षिप्त संस्करण

	User agent allowlist	Proof of Actor
मुख्य evidence	User-Agent header में एक नाम	Signatures, declarations और signals, प्रत्येक अपने basis के साथ labeled
क्या client इसे नकली बना सकता है?	हां, वही string भेजकर	एक declared basis का दावा किया जा सकता है; verified basis के लिए signing key चाहिए
Output	सूची में या नहीं	Human, Human + AI, Agent या Unknown, साथ में एक basis
अस्पष्ट traffic	Non-allowlisted माना जाता है, या default से अनुमति मिलती है	Unknown, route के हिसाब से आपके चुने हुए fallback के साथ
AI-assisted लोग	अदृश्य; वे ordinary browsers का उपयोग करते हैं	एक अलग class, Human + AI, जब declared या observed हो
रखरखाव	Names बदलने पर manual list updates	Agent operators द्वारा published keys; आपके code में policies
Install पर default	सूची जो अनुमति दे	Observation; जब तक आप policy न जोड़ें, कुछ नहीं बदलता
सबसे अच्छा किसके लिए	अच्छी तरह व्यवहार करने वाले, ज्ञात clients की सस्ती routing	product और policy decisions के लिए evidence-based actor context

बाकी page हर row को समझाती है.

User-Agent के आधार पर allowlisting spoofable क्यों है

User-Agent header client द्वारा set किया जाता है। एक browser इसे set करता है, एक script इसे set करती है, और एक agent framework इसे set करता है। HTTP में ऐसा कुछ नहीं है जो यह जांचे कि value सच है। अगर आपकी allowlist किसी string पर भरोसा करती है, तो उस string की नकल करने वाला कोई भी व्यक्ति वही treatment पाता है.

इसे user agent spoofing कहा जाता है, और यह एक साधारण कारण से आम है: इसकी लागत शून्य है। एक scraper जो challenge से बचना चाहता है, उसे केवल उस crawler का नाम borrow करना होता है जिस पर आप भरोसा करते हैं। एक गलत व्यवहार करने वाला client किसी popular assistant होने का दावा कर सकता है। एक legitimate tool भी generic browser string भेज सकता है क्योंकि किसी library default ने ऐसा किया.

इसका परिणाम यह है कि user agent allowlist के दो failure modes होते हैं:

False trust: एक untrusted client trusted नाम का दावा करता है और पास हो जाता है।
False doubt: एक legitimate client unexpected या generic string भेजता है और fail हो जाता है।

इनमें से कोई भी failure केवल header से दिखाई नहीं देता। यही मुख्य limitation है, और list maintenance की कोई भी मात्रा इसे हटाती नहीं है.

इसका मतलब यह नहीं कि आपको User-Agent strings को नजरअंदाज करना चाहिए। अच्छे व्यवहार वाले crawlers और agents ईमानदारी से खुद को बताते हैं, और नाम routing, analytics और debugging के लिए एक उपयोगी संकेत है। यह बताता है कि client खुद को क्या कहता है.

इस जानकारी के लिए सही जगह declaration के रूप में है, अन्य evidence के साथ weighed, न कि ऐसे key के रूप में जो अकेले access खोल दे। Proof of Actor इसे ठीक उसी तरह record करता है.

Reverse DNS और IP lists: आंशिक उपाय

कई teams allowlist को network checks के साथ मजबूत करती हैं। वे मदद करते हैं, और उन्हें ठीक से समझना worth है.

Reverse DNS verification

कुछ crawler operators एक verification process document करते हैं: request के IP address के लिए hostname lookup करें, जांचें कि वह operator के domain से संबंधित है, फिर उस hostname को lookup करें और confirm करें कि वह उसी IP पर resolve होता है। जब यह round trip सफल होता है, तो आपके पास वास्तविक evidence होता है कि request operator की infrastructure से आई थी.

Limitations व्यावहारिक हैं। यह केवल उन्हीं operators के लिए काम करता है जो इसे document और support करते हैं। इसमें DNS lookups जुड़ते हैं जिन्हें cache करना पड़ता है। और यह network के बारे में बताता है, यह नहीं कि उस network पर कौन सा product या agent request कर रहा था.

Published IP ranges

अन्य operators वे IP ranges publish करते हैं जिनका उपयोग उनके automated clients करते हैं। किसी request को उन ranges के against match करना तेज़ है और reverse DNS जैसी evidence देता है। IETF में इन ranges को publish करने के लिए standard format पर ongoing discussion है, लेकिन November 2026 तक कोई settled standard नहीं है, और coverage इस बात पर निर्भर करती है कि प्रत्येक operator publish करना चुनता है या नहीं.

IP evidence तब भी कमजोर होता है जब अधिक agents shared cloud infrastructure पर, proxies के पीछे, या किसी user के अपने device से चलें। एक cloud address कई unrelated clients host कर सकता है, और किसी person's browser से acting agent उस person's network जैसा दिखता है.

Network checks मिलकर क्या देते हैं

Reverse DNS और IP lists कुछ declarations को well-known operators के subset के लिए कुछ stronger में बदल देते हैं। वे agents और tools की long tail को cover नहीं करते, और लोगों के AI के साथ काम करने पर बिल्कुल मदद नहीं करते। वे आंशिक उपाय हैं: उपयोगी हैं, लेकिन अपने आप में पर्याप्त नहीं.

Signatures बनाम declarations

Evidence का stronger रूप cryptographic signature है। HTTP Message Signatures के साथ, जो RFC 9421 में defined है, client हर request के चुने गए parts को private key से sign करता है। Verifier operator की published public key fetch करता है और signature जांचता है। अगर यह verify हो जाता है, तो request उसी key के holder द्वारा sign की गई थी, और signed parts रास्ते में बदले नहीं गए थे.

IETF का Web Bot Auth working group यह standardize कर रहा है कि automated clients इन signatures का उपयोग कैसे करें और अपनी keys कैसे publish करें। Product teams के लिए हमारा Web Bot Auth explainer current status को कवर करता है.

Proof of Actor एक valid signature को Verified evidence के रूप में उपयोग करता है। User-Agent string, client hint या request body में self-description Declared माना जाता है। Behavioral और contextual signals Inferred माने जाते हैं, और उसी तरह labeled होते हैं। हर result यह बताता है कि वह किस basis पर टिका है, ताकि आपकी team कभी claim को check से न मिला दे। Full definitions के लिए evidence basis entry देखें.

एक limit verified evidence पर भी लागू होती है। एक valid signature यह साबित करता है कि request पर किस key ने sign किया। यह साबित नहीं करता कि agent वही करने के लिए authorized है जो वह करने को कह रहा है। यह agent authorization का सवाल है, और यह आपकी application में ही रहता है.

अनुमान लगाने के बजाय Unknown को संभालना

एक allowlist हर request को दो buckets में डालती है: सूची में या नहीं। व्यवहार में इसका मतलब है कि अस्पष्ट traffic को आपका default मिलता है, और default आमतौर पर पूरे site के लिए एक बार चुना जाता है.

Proof of Actor Unknown को एक first-class result मानता है। जब evidence विश्वसनीय determination का समर्थन नहीं करता, तो यह अनुमान लगाने के बजाय ऐसा कहता है। तब आपकी policies तय करती हैं कि हर route पर Unknown का क्या मतलब है:

Public documentation या marketing pages पर, इसे allow करें।
Search या listing endpoints पर, इसे अपनी सामान्य rate limits के साथ allow करें।
Account changes पर, अपनी मौजूदा checks रखें।
High-impact actions पर, इसे review में भेजें या stronger signal मांगें।

handling Unknown traffic पर guide और unknown classification entry इन patterns को समझाती हैं। समय के साथ अपने Unknown rate को track करना भी आपको बताता है कि आपके traffic का कितना हिस्सा अभी भी कमजोर evidence पर निर्भर है.

AI-assisted लोग क्या?

User agent allowlist का उस व्यक्ति के बारे में कुछ नहीं कहना जो ordinary browser के अंदर AI assistant का उपयोग करता है। उनका User-Agent एक normal browser string होता है। फिर भी कई products उस interaction को पहचानना चाहते हैं, उदाहरण के लिए AI-drafted submissions को label करने या समझने के लिए कि AI-assisted users onboarding से कैसे गुजरते हैं.

Proof of Actor इन interactions को Human + AI के रूप में report करता है जब सहायता declared होती है या supported integration के माध्यम से observed होती है। यह केवल writing style से अनुमान नहीं लगाता। अधिक जानकारी के लिए AI-assisted interaction पढ़ें.

Allowlist से evidence-based policies की ओर बढ़ना

Day one पर आपको अपनी allowlist हटाने की आवश्यकता नहीं है। एक सुरक्षित path इस तरह दिखता है:

Observation mode में install करें। Proof of Actor कुछ नहीं बदलता। आपकी allowlist काम करती रहती है।
Compare करें। हर route के लिए देखें कि कौन से allowlisted requests verified evidence लाते हैं, कौन से केवल declaration लाते हैं, और कौन से Unknown पर समाप्त होते हैं।
Policies preview करें। ऐसी policy draft करें जो verified agents, declared agents और Unknown को अलग तरह से treat करे, और real traffic पर उसका effect preview करें।
Route दर route enforce करें। उन routes से शुरू करें जहां spoofed name सबसे अधिक मायने रखेगा।
Allowlist को एक hint की तरह रखें। Names routing और analytics के लिए उपयोगी बने रहते हैं, अब उनके basis के साथ visible.

rolling out actor-aware policies safely पर guide हर step को कवर करती है, और verified automated requests बताता है कि signed clients कैसे fit होते हैं.

Allowlist कब पर्याप्त है

Low-stakes routing के लिए, जैसे public content पर किसी ज्ञात crawler को हल्का page देना, user agent allowlist अक्सर ठीक है। Spoofed name की लागत कम होती है.

जब निर्णय के consequences हों, जैसे challenge छोड़ना, richer data expose करना, या write की अनुमति देना, तब आपको ऐसा evidence चाहिए जिसे आप check कर सकें। वहीं Proof of Actor फिट बैठता है, network checks और edge controls के साथ जो आप पहले से चला रहे हैं.

शुरुआत करें

Proof of Actor private beta में है। चुनी गई founding developer teams को agreed usage limits के भीतर 12 months तक का free access मिल सकता है, बिना automatic billing के। 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 के पास record करें और जब तक आप कोई policy न चुनें, कुछ न बदलें। Node.js integration guide पढ़ें

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

क्या user agent allowlist बेकार है?

नहीं। यह अच्छे व्यवहार वाले clients से आने वाला एक उपयोगी declaration है और ज्ञात crawlers को route करने का एक सस्ता तरीका है। समस्या इसे proof मानने में है। कोई भी client कोई भी User-Agent string भेज सकता है, इसलिए allowlist अकेले sensitive actions को कभी unlock नहीं करनी चाहिए.

क्या reverse DNS verification User-Agent spoofing को ठीक कर देती है?

यह उन operators के लिए मदद करती है जो इसे document करते हैं। Request के IP address पर reverse lookup, फिर matching forward lookup, IP address को operator के domain से जोड़ता है। यह केवल उन्हीं operators के लिए काम करता है जो इसे support करते हैं, और shared cloud या residential addresses से आने वाले traffic के बारे में कुछ नहीं बताता.

Proof of Actor User-Agent header को कैसे देखता है?

एक declaration के रूप में। यह declared basis के साथ result में योगदान देता है, verified basis के रूप में कभी नहीं। Verified basis के लिए ऐसा evidence चाहिए जैसे published key के खिलाफ checked HTTP Message Signature.

एक verified signature क्या साबित करता है?

यह साबित करता है कि request पर किस key ने sign किया और signed parts बदले नहीं गए। यह साबित नहीं करता कि agent को action करने की अनुमति है। Authorization आपकी application में ही रहती है.

जब clients खुद को एक ज्ञात agent बताते हैं लेकिन verify नहीं हो पाते, तो क्या होता है?

Proof of Actor वही report करता है जिसे evidence support करता है, अक्सर declared या inferred result, या Unknown। आपकी policy उस route के लिए fallback चुनती है, दावे किए गए नाम पर भरोसा करने के बजाय.

क्या Proof of Actor जोड़ने से मेरा मौजूदा allowlist behavior बदल जाएगा?

नहीं। यह observation mode में शुरू होता है। आप किसी बदलाव से पहले real traffic पर इसके results की तुलना अपने allowlist decisions से कर सकते हैं.

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

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

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

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