AgentCorruption: AgentCore मेटाडेटा और IAM जोखिम

अक्टूबर 2026 की Zenity जांच के अनुसार, मॉडल से प्रभावित टूल AgentCore रनटाइम के मेटाडेटा तक पहुंच सकते थे और पुराने डिफ़ॉल्ट रोल की अनुमतियां पहुंच का दायरा बढ़ाती थीं। AWS अपने रनटाइम के रोल क्रेडेंशियल तक पहुंच को अपेक्षित व्यवहार मानता है और न्यूनतम विशेषाधिकार की सलाह देता है। Zenity की जांच में कोई CVE पहचान संख्या नहीं दी गई है और ग्राहकों पर हमले का प्रमाण नहीं है।^{[1], [4]}

💡 आसान भाषा में (ELI5)

कल्पना करें कि कार्यशाला में काम करने वाले एजेंट को उसके निर्धारित कामों के लिए एक प्रवेश-पत्र मिला है। Zenity के अनुसार, मॉडल के निर्देशों से प्रभावित टूल अंदर के काउंटर से यह पत्र मांग सकता था; पत्र की पुरानी अनुमतियां जरूरत से अधिक कमरे खोलती थीं। AWS कहता है कि कार्यशाला के भीतर एजेंट को अपने ही रोल के क्रेडेंशियल मिलना अपेक्षित है। व्यावहारिक बचाव यह है कि हर पत्र से खुलने वाले दरवाजे सीमित करें और नियंत्रित करें कि कौन-से टूल अंदरूनी अनुरोध भेज सकते हैं।^{[1], [4]}

इस पेज के मुख्य शब्द

AgentCorruption: Amazon Bedrock AgentCore के विरुद्ध नियंत्रित शोध-श्रृंखला के लिए Zenity Labs का नाम। Zenity ने कोई CVE पहचान संख्या नहीं दी है और उसकी जांच ग्राहकों पर हमले का प्रमाण नहीं देती।^{[1], [7]}
MMDS और निष्पादन-रोल क्रेडेंशियल: AWS दस्तावेज़ बताते हैं कि AgentCore microVM के भीतर चल रहा कोड MMDS से उस रनटाइम के निष्पादन-रोल के अस्थायी क्रेडेंशियल पा सकता है। सेवा इसे अपेक्षित व्यवहार मानती है; क्रेडेंशियल किन कार्रवाइयों की अनुमति देते हैं, यह रोल की अनुमतियों पर निर्भर है।^{[4], [5]}
अनुमतियों का प्रभाव-क्षेत्र: निष्पादन-रोल तय करता है कि एजेंट कोड किन AWS कार्रवाइयों और संसाधनों तक पहुंच सकता है। Zenity ने उसी खाते और क्षेत्र में ऐतिहासिक रूप से व्यापक डिफ़ॉल्ट अनुमतियां बताईं। AWS न्यूनतम विशेषाधिकार की सलाह देता है; अनुमति संबंधित कार्रवाई पर लागू पहचान और संसाधन नीतियों से तय होती है। AWS स्पष्ट करता है कि खातों के बीच पहुंच के लिए रोल और लक्ष्य संसाधन, दोनों पर अनुमति चाहिए।^{[3], [1], [6]}
CWE-918 — संपादकीय वर्गीकरण: यह पृष्ठ एजेंट टूल से आंतरिक मेटाडेटा सेवा को भेजे गए सर्वर-साइड अनुरोध के लिए CWE-918 को संपादकीय वर्गीकरण के रूप में उपयोग करता है। AWS ने यह CWE निर्धारित नहीं किया; मेटाडेटा तक पहुंच दस्तावेज़ित व्यवहार है।^{[8], [4], [1]}

फ्रेमवर्क मैपिंग

MITRE CWE के लिए FlawOpen की वैचारिक मैपिंग; किसी विक्रेता या CVE रिकॉर्ड ने इस शोध प्रदर्शन को यह कमजोरी ID नहीं दी है। CWE-918

हमले का चरण-दर-चरण प्रवाह

चरण 1

सार्वजनिक एजेंट के पास आउटबाउंड टूल है

Zenity ने सार्वजनिक रूप से पहुंच योग्य AgentCore एजेंट का परीक्षण किया, जिसमें बाहर अनुरोध भेजने वाला टूल था। इस परिस्थिति के लिए पहुंच योग्य एजेंट और मॉडल से प्रभावित हो सकने वाला टूल-पथ जरूरी है; यह हर तैनाती पर लागू नहीं होती।^{[2], [1]}

चरण 2

मॉडल का प्रभाव मेटाडेटा तक पहुंचता है

Zenity के अनुसार, उसके परीक्षण एजेंट को स्थानीय मेटाडेटा सेवा से अनुरोध करने के लिए प्रेरित किया जा सकता था। AWS microVM के भीतर कोड द्वारा MMDS क्रेडेंशियल तक पहुंच को दस्तावेज़ित करता है। सुरक्षा का प्रश्न मॉडल से टूल तक भरोसे की राह और उन क्रेडेंशियल की शक्ति है, न कि रनटाइम के अपने क्रेडेंशियल का मौजूद होना।^{[2], [1], [4]}

चरण 3

जवाब एजेंट के रोल के क्रेडेंशियल देता है

AWS के अनुसार MMDS कॉन्फ़िगर किए गए निष्पादन-रोल के अस्थायी क्रेडेंशियल देता है। ये क्रेडेंशियल अपने-आप हर संसाधन की पहुंच नहीं देते; लागू IAM और संसाधन नीतियां अनुमत कार्रवाइयां तय करती हैं। AWS खातों के बीच पहुंच के लिए रोल और लक्ष्य संसाधन, दोनों पर स्पष्ट अनुमति की बात करता है।^{[4], [6], [1]}

चरण 4

पुरानी अनुमतियों ने प्रभाव बढ़ाया

Zenity ने बताया कि उस समय का डिफ़ॉल्ट रोल उसी खाते और क्षेत्र के दूसरे AgentCore संसाधनों पर कार्रवाइयों की अनुमति देता था, जिनमें रनटाइम आह्वान, सत्र/इवेंट पहुंच, मेमोरी संचालन और सीक्रेट तक पहुंच शामिल थी। Zenity के अनुसार, AWS ने 29 सितंबर 2026 तक इस डिफ़ॉल्ट रोल को काफी सीमित कर दिया। इससे यह साबित नहीं होता कि ग्राहक-प्रबंधित रोल अपने-आप बदले।^{[3], [1], [6]}

चरण 5

मौजूदा नियंत्रण अलग-अलग सीमाओं की रक्षा करते हैं

Zenity कहता है कि 14 फरवरी 2026 से नए एजेंट MMDSv2 का उपयोग कर रहे थे। AWS के मौजूदा दस्तावेज़ों के अनुसार 30 जून 2026 से रनटाइम आह्वान के लिए MMDSv2 सक्षम होना जरूरी है। AWS अब भी बताता है कि microVM के भीतर का कोड रोल क्रेडेंशियल तक पहुंच सकता है; इसलिए MMDSv2 न्यूनतम-विशेषाधिकार IAM या मॉडल से प्रभावित टूल के नियंत्रण का विकल्प नहीं है। यह अलगाव स्रोतों पर आधारित रक्षात्मक निष्कर्ष है।^{[5], [4], [1]}

साक्ष्य और मौजूदा दायरा

सीमा	साक्ष्य	रक्षात्मक कदम
मेटाडेटा पहुंच	Zenity ने अपने परीक्षण में पहुंच की सूचना दी; AWS microVM के अंदर के कोड को MMDS क्रेडेंशियल मिलने की बात दस्तावेज़ित करता है।	एजेंट कोड और मॉडल से प्रभावित टूल को निष्पादन-रोल क्रेडेंशियल का उपयोगकर्ता मानें।
रोल अनुमतियां	Zenity ने पुराने व्यापक डिफ़ॉल्ट की सूचना दी। AWS कहता है कि खातों के बीच पहुंच के लिए रोल और लक्ष्य संसाधन, दोनों पर स्पष्ट अनुमति चाहिए; अन्य कार्रवाइयों पर उनकी लागू IAM और संसाधन नीतियां लागू होती हैं।	तैनात रोल और संसाधन नीतियां जांचें; हर कार्रवाई पर लागू नीति सत्यापित करें और प्रॉम्प्ट या सेवा के डिफ़ॉल्ट से अनुमति का दायरा न मानें।
डिफ़ॉल्ट रोल में बदलाव	Zenity ने कहा कि उसने 29 सितंबर 2026 को AWS द्वारा डिफ़ॉल्ट रोल सीमित किए जाने को देखा। जांच यह नहीं कहती कि ग्राहक-प्रबंधित रोल अपने-आप बदले; इसमें CVE पहचान संख्या नहीं है और ग्राहक पर हमले का प्रमाण नहीं है।	हर खाते और क्षेत्र में प्रभावी रोल जांचें; ग्राहक-प्रबंधित रोल बदले हुए हैं, ऐसा न मानें।
MMDSv2	Zenity नए एजेंटों में MMDSv2 के उपयोग की तारीख 14 फरवरी 2026 बताता है; AWS के मौजूदा दस्तावेज़ 30 जून 2026 से रनटाइम आह्वान के लिए इसे सक्षम करना जरूरी बताते हैं। AWS अब भी VM के अंदर से क्रेडेंशियल पहुंच दस्तावेज़ित करता है।	MMDSv2 सक्षम करें और रोल की कार्रवाइयों, संसाधनों तथा कॉलर को अलग से सीमित करें।

मूल कारण विश्लेषण (Root Cause)

दो सीमाओं का अलग-अलग आकलन करें: मॉडल से प्रभावित टूल रनटाइम के भीतर से अनुरोध कर सकते हैं, और निष्पादन-रोल उन अनुरोधों के अधिकार तय करता है। AWS रनटाइम के अपने क्रेडेंशियल तक पहुंच को अपेक्षित मानता है; Zenity द्वारा बताई गई दूसरे एजेंटों तक पहुंच पुराने रोल-दायरे पर निर्भर थी। MMDSv2 सक्षम करने से IAM सीमित नहीं होता, और रोल सीमित करने से मॉडल-निर्देशित अंदरूनी अनुरोध नहीं रुकते। टूल के आउटबाउंड ट्रैफ़िक और IAM अनुमति की अलग-अलग समीक्षा करें; केवल नेटवर्क आउटबाउंड सीमित करना यह साबित नहीं करता कि microVM के अंदर का कोड MMDS तक नहीं पहुंच सकता।^{[1], [3], [4], [5]}

सोर्स कोड: कमज़ोर बनाम सुरक्षित कार्यान्वयन

ये केवल उदाहरण के लिए IAM नीति कथन हैं; ये AWS की पुरानी नीति या बाद में हुए डिफ़ॉल्ट-रोल बदलाव नहीं हैं। AWS रनटाइम अनुमतियों को विशिष्ट संसाधन ARN तक सीमित करने और वाइल्डकार्ड से बचने की सलाह देता है। पहला कथन व्यापक संसाधन-पैटर्न दिखाता है; दूसरा, यदि आह्वान की अनुमति जरूरी हो, तो उसे एक स्वीकृत रनटाइम तक सीमित करता है। जरूरत न हो तो अनुमति हटाएं। वास्तविक तैनाती के लिए कार्रवाई/संसाधन समर्थन और संबंधित संसाधन नीतियां जांचें; यह पूरी तरह तैनाती योग्य नीति नहीं है।^{[3], [6], [5]}

कमज़ोर कार्यान्वयन

{
  "Effect": "Allow",
  "Action": "bedrock-agentcore:InvokeAgentRuntime",
  "Resource": "arn:aws:bedrock-agentcore:REGION:ACCOUNT:runtime/*"
}

सुरक्षित और सुदृढ़ फ़िक्स

{
  "Effect": "Allow",
  "Action": "bedrock-agentcore:InvokeAgentRuntime",
  "Resource": "arn:aws:bedrock-agentcore:REGION:ACCOUNT:runtime/APPROVED_RUNTIME_ID"
}

इंजीनियरिंग और सिस्टम सुरक्षा चेकलिस्ट

✓हर खाते और क्षेत्र में प्रत्येक रनटाइम निष्पादन-रोल की सूची बनाएं; प्रभावी अनुमतियों की तुलना वर्तमान AWS और ग्राहक-प्रबंधित नीतियों से करें।^{[6], [5]}
✓जब तक हर उपयोग की दस्तावेज़ित जरूरत न हो, अन्य रनटाइम आह्वान, बातचीत-पठन, सीक्रेट प्राप्ति, मेमोरी लेखन और इमेज पहुंच हटाएं।^{[3], [6]}
✓यदि एक रनटाइम को दूसरे को बुलाना जरूरी हो, तो पहचान और संसाधन नीतियों को स्वीकृत रनटाइम और endpoint तक सीमित करें; जांचें कि असंबंधित रनटाइम अस्वीकृत हों।^[6]
✓AWS की आवश्यकता के अनुसार MMDSv2 सक्षम करें, लेकिन microVM के अंदर कोड द्वारा रोल क्रेडेंशियल तक पहुंच को अलग अनुमति-सीमा मानें।^{[5], [4], [1]}
✓मॉडल से प्रभावित टूल के गंतव्यों को कार्यभार की जरूरत तक सीमित करें; इसे आउटबाउंड जोखिम में कमी मानें, VM के भीतर MMDS पहुंच न होने का प्रमाण नहीं।^[5]
✓सार्वजनिक एजेंटों को ऐसे रोल दें जिनके विशेषाधिकार उन्हें आह्वान करने वाले principal से अधिक न हों; IAM Access Analyzer और नकारात्मक अनुमति परीक्षणों से प्रभावी अनुमतियां जांचें।^{[5], [6]}

स्रोत

← AI Security Directory →