परिभाषा
actor result का प्रमाण आधार उसके पीछे मौजूद evidence के प्रकार का वर्णन करता है। Proof of Actor चार मानों का उपयोग करता है:
- verified: एक cryptographic या अन्यथा जांची जा सकने वाली assertion सफल रही।
- declared: actor या application ने यह बताया।
- inferred: निष्कर्ष व्यवहारिक या संदर्भगत signals से निकाला गया।
- unknown: निर्धारण के लिए पर्याप्त evidence नहीं था।
हर result में एक class (Human, Human + AI, Agent या Unknown, जैसा कि application traffic के लिए हमारी taxonomy में वर्णित है) और एक basis दोनों होते हैं। "Agent, verified" और "Agent, inferred" अलग results हैं और उन्हें अलग तरह से संभालना चाहिए।
basis क्यों महत्वपूर्ण है
basis के बिना classification यह छिपा देती है कि वह कितना भार सह सकती है। एक dashboard जो signed request के लिए "Agent" और request timing के आधार पर अनुमान के लिए भी "Agent" दिखाता है, टीमों को दोनों पर एक ही policy लागू करने के लिए प्रेरित करता है। खासकर security-sensitive applications में, inference को कभी भी cryptographic verification जैसा नहीं दिखना चाहिए।
class को basis से अलग रखने से policies evidence की मजबूती के अनुरूप बनती हैं:
- एक read-only route किसी भी Agent result को allow कर सकता है।
- अधिक impact वाले route पर केवल verified agents को known operators माना जा सकता है और बाकी सभी से अधिक मजबूत credentials मांगे जा सकते हैं।
चार मान विस्तार से
Verified
कुछ जांचा गया और सफल रहा। सबसे स्पष्ट उदाहरण एक HTTP message signature (RFC 9421) है जो agent के operator द्वारा प्रकाशित key के विरुद्ध मान्य होती है। Verified evidence विशिष्ट check को साबित करता है, उससे अधिक कुछ नहीं: एक valid signature दिखाता है कि request पर किस key ने sign किया, यह नहीं कि action authorized है।
Declared
किसी ने ऐसा कहा। एक client जो स्वयं को agent बताता है, एक MCP client name, या आपकी अपनी application के भीतर AI-assistance disclosure declaration हैं। ये उपयोगी हैं, अक्सर ईमानदार होते हैं, और कभी-कभी गलत भी। User-agent spoofing गलत declaration का क्लासिक उदाहरण है। User-Agent header डिज़ाइन के अनुसार self-reported होता है।
Inferred
System ने signals से तर्क निकाला: browser session में interaction patterns, request timing, missing browser context, protocol details। Inferences गलत भी हो सकती हैं, इसलिए उन्हें हमेशा inferences के रूप में label किया जाता है और इसलिए लोगों से जुड़े consequential decisions कभी भी केवल उन पर आधारित नहीं होने चाहिए।
Unknown
Evidence किसी determination का समर्थन नहीं कर सका। यह Unknown classification के साथ जुड़ता है और आपकी policy में एक स्पष्ट fallback से map होना चाहिए। AI traffic classify करते समय Unknown क्यों एक valid result है पर हमारी post यह समझाती है कि ऐसा क्यों है।
Basis बनाम confidence scores
कई systems evidence को एक ही number में संकुचित कर देती हैं। एक score यह छिपा देता है कि वह cryptographic check से आया था या heuristic से, और एक uncalibrated percentage ऐसी precision का संकेत देता है जो मौजूद नहीं है। नामित bases का एक छोटा set समझने में आसान, audit करने में आसान, और दुरुपयोग करना अधिक कठिन होता है।
सामान्य गलतफहमियां
"Declared का मतलब अविश्वसनीय है।" Declarations अक्सर सही होती हैं और कुछ प्रश्नों, जैसे AI-assistance disclosure, के लिए यही एकमात्र उपलब्ध evidence होती हैं। बस उन्हें verification की तरह नहीं माना जाना चाहिए।
"Verified का मतलब सुरक्षित है।" Verification signer की पहचान के बारे में है, intent या permission के बारे में नहीं।
Proof of Actor में evidence basis
हर Proof of Actor result अपना basis और evidence का human-readable summary बताता है। Policies आपकी application में चलती हैं और class तथा basis का साथ में उपयोग कर सकती हैं। Detection & Limitations देखें या early access के लिए आवेदन करें।
स्रोत
- RFC 9421: HTTP Message Signatures: verified evidence का सबसे स्पष्ट source
- RFC 9110: HTTP Semantics, User-Agent: एक self-reported, declared identifier