प्राप्त सामग्री को untrusted input मानें

पहचानें कि डेटा कहाँ instruction बनता है

Coding agent केवल उपयोगकर्ता का अनुरोध नहीं पढ़ता। वह issues, repository files, package documentation, search results और tool responses देख सकता है। इनमें से कुछ सामग्री में दूसरे व्यक्ति के instructions हो सकते हैं।

Prompt injection तब होता है जब ऐसी सामग्री मॉडल को अधिकृत काम से भटका देती है। Indirect injection उपयोगकर्ता के सीधे अनुरोध के बजाय प्राप्त किए गए स्रोत से आता है। OWASP repository सामग्री और tool output को संबंधित प्रवेश बिंदु बताता है। रोकथाम की guidance पढ़ें।

रखरखाव का काल्पनिक काम लें। उपयोगकर्ता agent से report filter ठीक करने और जरूरी tests चलाने को कहता है। प्राप्त README कहती है कि tests पुराने हैं और agent से configuration file upload करने को कहती है। README project समझा सकती है। वह उपयोगकर्ता की checks छोड़ने या files कहीं और भेजने की अनुमति नहीं दे सकती।

संभावित असर का नक्शा बनाएँ

वही भ्रामक text अलग environments में अलग असर करता है। Read-only summarizer गलत summary बना सकता है। Repository में write access वाला agent code बदल सकता है। Secrets और outbound network access वाला agent जानकारी उजागर कर सकता है।

कौन-से बचाव जरूरी हैं, यह तय करने से पहले उपलब्ध कार्रवाइयाँ जाँचें। संवेदनशील resources, write किए जा सकने वाले targets और external destinations लिखें। शुरुआती setup के बाद जोड़े connectors भी शामिल करें। नया tool मौजूदा कमजोरी का असर बढ़ा सकता है।

Agent भ्रामक सामग्री बाद के चरण तक भी पहुँचा सकता है। उदाहरण के लिए, वह untrusted instruction को generated task brief में copy कर सकता है। अगले agent को उस brief को स्वतंत्र रूप से स्वीकृत policy नहीं मानना चाहिए।

अलग उद्देश्यों वाले कई controls इस्तेमाल करें

Application design में trusted task instructions को प्राप्त डेटा से अलग रखें। प्राप्त सामग्री का स्रोत दिखाएँ। इन कदमों से अर्थ समझने में सुधार होता है, लेकिन पूरी security boundary सिद्ध नहीं होती।

Execution system में resource permissions लागू करें। संवेदनशील डेटा के destinations सीमित करें। असर वाली कार्रवाई से पहले उचित निर्णय जरूरी रखें। प्रस्तावित operation को अधिकृत काम और target के विरुद्ध जाँचें।

Filters और दूसरा मॉडल संदिग्ध सामग्री पहचानने में मदद कर सकते हैं। वे हमले छोड़ भी सकते हैं या वैध जानकारी रोक सकते हैं। तय नियमों पर आधारित authorization की जगह model का confidence score न लें। OWASP केवल prompts या retrieval पर भरोसा करने की सीमाएँ स्पष्ट करता है। जोखिम का विवरण पढ़ें।

वास्तविक exposure के बिना workflow जाँचें

अस्थायी repository और काल्पनिक files इस्तेमाल करें। Evaluation को production credentials या असीमित external writes न दें। काम से टकराने वाला हानिरहित instruction जोड़ें, जैसे जरूरी check छोड़ना।

मॉडल का उत्तर और वास्तविक tool actions, दोनों देखें। Check फिर भी छूट गई हो, तो “मैंने instruction अनदेखा किया” संदेश पर्याप्त नहीं है। काम, injected fixture, स्वीकार्य tools और देखा गया परिणाम दर्ज करें।

Prompts, models, connectors या permissions बदलने के बाद प्रतिनिधि cases दोहराएँ। रुका हुआ उदाहरण उस case का प्रमाण है, हर injection के विरुद्ध सुरक्षा का प्रमाण नहीं। Test fail हो तो मूल workflow ठीक करते समय उपलब्ध कार्रवाइयों का संभावित असर घटाएँ।