AI एजेंटों के बीच सुरक्षित संदेश: पहचान, अनुमति और रीप्ले से बचाव
प्रमाणित एजेंट पहचान, टेनेंट संदर्भ, सीमित अधिकार, रीप्ले सुरक्षा और ऑडिट से SaaS एजेंट संदेश सुरक्षित करें।
इस मार्गदर्शिका में
AI एजेंटों के बीच संचार सुरक्षित कैसे करें?
एक ही उत्पाद के भीतर चलने पर भी हर एजेंट-से-एजेंट संदेश को अविश्वसनीय API अनुरोध मानें। भेजने वाली सेवा की पहचान प्रमाणित करें, हस्तांतरण को अधिकृत करें, सत्यापित उपयोगकर्ता और टेनेंट संदर्भ से जोड़ें, संदेश की जाँच करें और पुराने या दोहराए गए निर्देशों से दोहरी कार्रवाई रोकें। “मैं बिलिंग एजेंट हूँ” कहने वाला संदेश केवल पाठ है; पहचान विश्वसनीय रनटाइम या क्रिप्टोग्राफिक क्रेडेंशियल से आनी चाहिए। OWASP असुरक्षित एजेंट-से-एजेंट संचार को अलग एजेंटिक जोखिम मानता है।
हर एजेंट को सत्यापन योग्य सेवा पहचान दें
हर एजेंट सेवा को उसकी तैनाती और वातावरण से जुड़ी अलग पहचान दें। कम समय के क्रेडेंशियल या स्वीकृत वर्कलोड पहचान तंत्र से सेवा-से-सेवा ट्रैफिक प्रमाणित करें और जारीकर्ता, ऑडियंस, अवधि तथा लक्षित प्राप्तकर्ता जाँचें। साझा एडमिन कुंजी प्रॉम्प्ट में न भेजें और सभी एजेंटों को एक व्यापक सेवा टोकन न दें; साझा क्रेडेंशियल से कार्रवाई का स्रोत पता लगाना और पहुँच रद्द करना कठिन होता है।
केवल भेजने वाले को नहीं, हस्तांतरण को अधिकृत करें
तय करें कि कौन-सा एजेंट किस टेनेंट के लिए, किसकी ओर से और किन शर्तों पर कौन-सा काम माँग सकता है। विश्वसनीय ऑर्केस्ट्रेशन कोड से सीमित प्रतिनिधि स्कोप और काम-विशिष्ट दावे दें। प्राप्तकर्ता एजेंट या सेवा को स्वयं नीति और लक्षित संसाधन जाँचना चाहिए; प्रमाणीकरण बताता है अनुरोध किसने भेजा, यह नहीं कि अनुरोध की अनुमति है।
संदेश को उपयोगकर्ता, टेनेंट, काम और प्राप्तकर्ता से बाँधें
सत्यापित संदर्भ को हस्ताक्षरित आवरण या विश्वसनीय संदेश मेटाडेटा में रखें जिसे मॉडल बदल न सके। एक अलग काम या सहसंबंध ID, लक्षित प्राप्तकर्ता, समाप्ति समय और न्यूनतम अधिकार का प्रतिनिधित्व जोड़ें। संदेश का टेनेंट या उपयोगकर्ता प्रमाणित सेवा या मूल काम से मेल न खाए तो उसे अस्वीकार करें। बातचीत के शब्दों या पिछले चरण से पहचान का अनुमान न लगाएँ।
| भेजने वाला → प्राप्तकर्ता | सत्यापित पहचान | स्वीकृत काम/स्कोप | टेनेंट और काम का संदर्भ | रीप्ले और ऑडिट नियंत्रण |
|---|---|---|---|---|
संदेश में छेड़छाड़, रीप्ले और टेनेंट डेटा लीक कैसे रोकें?
सख्त संदेश स्कीमा अपनाएँ और हर फ़ील्ड जाँचें
संदेश स्कीमा का संस्करण रखें और प्राप्तकर्ता पर जरूरी फ़ील्ड, डेटा प्रकार, आकार, मानों की सीमा और आपसी नियम जाँचें। खुले पाठ, टूल आउटपुट और खोजी गई सामग्री को डेटा मानें, चलाए जाने वाले निर्देश नहीं। जहाँ अप्रत्याशित फ़ील्ड अधिकार बदल सकते हैं वहाँ उन्हें अस्वीकार करें। किसी एजेंट को दूसरे एजेंट का सिस्टम प्रॉम्प्ट या सुरक्षा नीति बनाने न दें।
रीप्ले और दोहरी साइड इफेक्ट वाली कार्रवाई रोकें
कम समय की वैधता और संदेश या ऑपरेशन की अनूठी पहचान रखें। प्राप्तकर्ता आवश्यक इडेम्पोटेंसी अवधि तक निपटाए गए पहचानकर्ता दर्ज करे और दोहराए गए भुगतान, संदेश, निर्यात या बदलाव को तब तक अस्वीकार करे जब तक स्पष्ट रीट्राई नीति न हो। हस्ताक्षर या संदेश प्रमाणीकरण को पेलोड, भेजने वाले, प्राप्तकर्ता, ऑडियंस और समाप्ति से बाँधें, ताकि वैध संदेश दूसरे संदर्भ में कॉपी न हो।
क्यू और स्टोरेज में टेनेंट सीमाएँ बनाए रखें
संदेश क्यू, वर्कफ़्लो अवस्था, कैश और विफल संदेश रिकॉर्ड को टेनेंट तथा अनुमति के अनुसार अलग या सख्ती से सीमित रखें। बैकग्राउंड वर्कर विश्वसनीय रिकॉर्ड से प्राधिकरण फिर लोड करे; क्यू में संदेश होने को अनुमति न मानें। ट्रेस में संवेदनशील संदेश-भाग कम रखें और अवधि तय करें—ऑब्ज़र्वेबिलिटी को दूसरा खुला ग्राहक-डेटा भंडार न बनने दें।
टीमें मल्टी-एजेंट हस्तांतरण की निगरानी कैसे करें?
निर्णय और अनुमति का शुरू से अंत तक ट्रेस रखें
हर हस्तांतरण को काम ID से जोड़ें और प्रमाणित भेजने वाला, प्राप्तकर्ता सेवा, टेनेंट संदर्भ, माँगी गई क्षमता, प्राधिकरण निर्णय, नीति संस्करण, समय और परिणाम दर्ज करें। जिम्मेदारी की कड़ी समझने लायक जानकारी रखें, पर प्रॉम्प्ट और उत्तर का पूरा पाठ कम से कम रखें। सभी एजेंटों को एक अस्पष्ट कर्ता मानने के बजाय विश्वास सीमा में बदलाव ट्रेस में दिखाएँ।
नकली, पुराने और दूसरे टेनेंट के संदेशों की जाँच करें
अज्ञात भेजने वाले, गलत ऑडियंस, समाप्त क्रेडेंशियल, बदले पेलोड, दोहराए ऑपरेशन ID, टेनेंट बेमेल, बहुत व्यापक अनुमति, अनपेक्षित स्कीमा फ़ील्ड और प्रभावित डाउनस्ट्रीम एजेंट के परीक्षण करें। अस्वीकृति और सुरक्षित पुनर्प्राप्ति दोनों जाँचें: गलत संदेश से साइड इफेक्ट न हो, और अनुपलब्ध एजेंट के कारण दूसरा एजेंट आवश्यक अनुमति को दरकिनार न करे।
पूरी प्रक्रिया बंद किए बिना एक एजेंट की पहुँच रद्द करें
पहचान, प्रतिनिधि स्कोप और टूल अधिकार अलग-अलग रद्द किए जा सकें। घटना में प्रभावित एजेंट के नए काम रोकें, लंबित काम रद्द या अलग रखें, उजागर क्रेडेंशियल बदलें और डाउनस्ट्रीम कार्रवाइयों का ट्रेस देखें। अप्रभावित वर्कफ़्लो चलने देने से पहले उनका निर्भरता पथ और अधिकार जाँचें; साझा सीक्रेट और असीमित प्रतिनिधित्व रोकथाम कठिन बनाते हैं।
मल्टी-एजेंट संचार सुरक्षा के आम सवाल
क्या एक ही ऐप में एजेंट अपने आप भरोसेमंद होते हैं?
नहीं। सॉफ़्टवेयर सीमा, क्यू या मॉडल भूमिका भेजने वाले की पहचान और अधिकार साबित नहीं करते। प्राप्तकर्ता सीमा पर हर हस्तांतरण प्रमाणित और अधिकृत करें।
क्या सभी एजेंट एक सेवा खाता साझा कर सकते हैं?
व्यापक साझा क्रेडेंशियल से बचें। अलग-अलग कम अवधि की पहचान और सीमित प्रतिनिधि अनुमति दें, ताकि कार्रवाई का स्रोत पता चले और पहुँच स्वतंत्र रूप से रद्द हो सके।
एक ही एजेंट संदेश को दो बार चलने से क्या रोकता है?
अनूठी ऑपरेशन ID, तय समाप्ति और प्राप्तकर्ता-साइड इडेम्पोटेंसी या रीप्ले जाँच रखें। खासकर तब स्पष्ट रीट्राई नीति अपनाएँ जब टाइमआउट से पहले पहला प्रयास पूरा हुआ हो सकता है।
क्या पूरा एजेंट वार्तालाप ऑडिट के लिए रखना चाहिए?
आमतौर पर डिफ़ॉल्ट रूप से नहीं। पहचान, प्रतिनिधि अनुमति, नीति निर्णय और परिणाम दर्ज करें; फिर केवल उचित उद्देश्य के लिए जरूरी सामग्री सीमित पहुँच और स्पष्ट अवधि के साथ रखें।
संबंधित व्यावहारिक मार्गदर्शिकाएँ
संबंधित मुद्दों की मार्गदर्शिकाएँ
स्रोत और प्रकाशन रिकॉर्ड
मसौदा 27 सितंबर 2026 को तैयार; इंजीनियरिंग, सुरक्षा और संपादकीय समीक्षा लंबित · स्रोत जाँचे गए .