चैट बॉट के लिए गार्ड्स लागू करने का उदाहरण

काटो गार्ड्स के साथ एआई एप्लिकेशन्स को सुरक्षित करना (नमूना कॉन्फ़िगरेशन)

सारांश

यह गाइड आपको कस्टम एआई एप्लिकेशन को काटो एआई सुरक्षा गार्ड्स का उपयोग करके सुरक्षित करने की प्रक्रिया का कुल मिलाकर मार्गदर्शन करता है। यह एक तीन-चरणीय प्रवाह के रूप में संरचित है, प्रत्येक पिछले के आधार पर बनाया गया है, जिससे आप सटीकता से देख सकते हैं कि प्रत्येक चरण में क्या परिवर्तन होते हैं और क्यों।

इस गाइड में पूरे समय इस्तेमाल किया गया एप्लिकेशन ट्रैवलबोट है — एक सरल एआई-संचालित यात्रा सहायक चैटबॉट। हालांकि उदाहरण विशिष्ट है, अवधारणाएँ और चरण किसी भी कस्टम एआई एप्लिकेशन पर लागू होते हैं जिसे आप बनाते हैं और सुरक्षित करना चाहते हैं।

गाइड में तीन चरण शामिल हैं:

• चरण 1 प्रारंभिक स्थिति स्थापित करता है: एक कार्यशील एआई एप्लिकेशन जो एक एलएलएम के साथ सीधे संचार करता है, बिना कोई सुरक्षा नियंत्रण के। यह चरण आपको प्रारंभिक बिंदु और इससे उत्पन्न होने वाले खतरों को समझने में मदद करता है।
• चरण 2 गार्ड को प्रस्तुत करता है: एक काटो प्रॉक्सी गार्ड तैयार किया जाता है और एप्लिकेशन और एलएलएम के बीच डाला जाता है। गार्ड के माध्यम से ट्रैफिक पुनर्निर्देशित किया जाता है, जो सभी इंटरैक्शन को लॉग करना शुरू कर देता है। अभी तक कोई नीति नियम कॉन्फ़िगर नहीं किए गए हैं — इस चरण का उद्देश्य केवल यह सत्यापित करना है कि गार्ड के संचालन में प्रवाह अभी भी काम कर रहा है।
• चरण 3 प्रवर्तन को सक्रिय करता है: इंटरैक्शन नीति नियम कॉन्फ़िगर और प्रकाशित किए जाते हैं, गार्ड को जेलब्रेक प्रयासों को रोकने और स्वास्थ्य-संबंधी सामग्री की निगरानी करने का निर्देश देते हुए। एप्लिकेशन अब पूरी तरह से सुरक्षित है।
  गाइड के अंत तक, आपके पास यह स्पष्ट चित्र होगा कि एक कस्टम एआई एप्लिकेशन को काटो गार्ड्स के साथ कैसे सुरक्षित किया जा सकता है — एक पूरी तरह से खुले कनेक्शन से सक्रिय रूप से लागू और निगरानी किए गए एआई वर्कफ़्लो तक।

स्टेज 1 — प्रारंभिक स्थिति: आपका एआई ऐप गार्ड के बिना

यह चरण क्या कवर करता है

किसी भी सुरक्षा नियंत्रणों को पेश करने से पहले, यह समझना महत्वपूर्ण है कि एप्लिकेशन अपने आप कैसे काम करता है। यह चरण आपको आधारभूत सेटअप के माध्यम से मार्गदर्शन करता है — एक कार्यशील एआई-संचालित चैट अनुप्रयोग जो सीधे एक बड़े भाषा मॉडल (एलएलएम) के साथ संचार करता है। इसे 'पहले' चित्र की तरह समझें: ऐप कार्यात्मक है, लेकिन उपयोगकर्ता और मॉडल के बीच कुछ भी नहीं है।

ऐप कैसे काम करता है

एप्लिकेशन एक साधारण यात्रा सहायक चैटबॉट है जिसे ट्रैवलबोट कहा जाता है। यह तीन घटकों से मिलकर बनता है जो साथ मिलकर काम करते हैं:

1। फ्रंटएंड यह वही है जो उपयोगकर्ता देखता और इंटरैक्ट करता है — एक ब्राउज़र में चैट इंटरफेस जहां वे सवाल टाइप कर सकते हैं और जवाब प्राप्त कर सकते हैं।

2। बैकएंड
यह वह इंजन है जो पर्दे के पीछे काम कर रहा है। यह उपयोगकर्ता का संदेश प्राप्त करता है, बातचीत का इतिहास ट्रैक करता है, और संदेश को एएलएम को भेजता है। यह त्रुटियों को भी संभालता है और मॉडल की प्रतिक्रिया उपयोगकर्ता को वापस भेजता है। बैकएंड फ्लास्क, एक हल्के वेब फ्रेमवर्क के साथ बनाया गया है।

3। एलएलएम कनेक्शन
यह वह जगह है जहां बुद्धिमत्ता जीवित रहती है। बैकएंड उपयोगकर्ता का संदेश (बातचीत इतिहास के साथ) एक बड़े भाषा मॉडल को भेजता है, जो एक प्रतिक्रिया उत्पन्न करता है। इस चरण में, बैकएंड एलएलएम के साथ सीधे संवाद करता है — इसके बीच कुछ भी नहीं है।

प्रवाह इस प्रकार दिखता है:

उपयोगकर्ता (ब्राउज़र) → बैकएंड (फ्लास्क) → एलएलएम → प्रतिक्रिया उपयोगकर्ता को वापस

भाषा और फ्रेमवर्क पर एक नोट

इस गाइड का नमूना एप्लिकेशन पायथन के साथ बनाया गया है, जिसमें फ्लास्क नामक हल्के वेब फ्रेमवर्क का उपयोग किया गया है। पायथन एआई एप्लिकेशन विकास के लिए एक लोकप्रिय विकल्प है, लेकिन यह अकेला नहीं है। वही अवधारणाएँ और प्रवाह लागू होते हैं चाहे आपका एप्लिकेशन नोड.जेएस, जावा, गो, या किसी अन्य भाषा में बनाया गया हो। कॉन्फ़िगरेशन मूल्य, अनुरोध संरचना, और गार्ड एकीकरण सभी एक ही तर्क का पालन करते हैं — केवल सिंटैक्स बदलता है।

कॉन्फ़िगरेशन फ़ाइल

बैकएंड और एलएलएम के बीच का कनेक्शन config.py नामक फ़ाइल द्वारा नियंत्रित किया जाता है। यह फ़ाइल तीन महत्वपूर्ण मूल्य रखती है:

OPENAI_API_KEY = "sk-proj-xK92mLqP3nVwTz8YdR5eN1uJbF7cQm4HsAo6WpGi0XvCl"
BASE_URL = "https://bedrock-mantle.eu-north-1.api.aws/v1"
MODEL_ID = "amazon.nova-pro-v1:0"

• OPENAI_API_KEY — यह वह प्रमाणपत्र है जो LLM प्रदाता को साबित करता है कि आपका आवेदन अनुरोध करने के लिए अधिकृत है।
• BASE_URL — यह पता है जिस पर बैकएंड अनुरोध भेजता है। अभी यह सीधे एलएलएम प्रदाता की ओर इशारा करता है।
• MODEL_ID — यह एलएलएम प्रदाता को बताता है कि प्रतिक्रियाएँ उत्पन्न करते समय किस विशिष्ट मॉडल का उपयोग करना है।

इस चरण में ऐप को चलाने के लिए, आप (या आपके डेवलपर) इन तीन मूल्यों को आपके एलएलएम प्रदाता द्वारा प्रदान किए गए प्रमाणपत्रों के साथ भरेंगे।

ऐप आपके संदेश के साथ क्या करता है

जब कोई उपयोगकर्ता संदेश भेजता है, तो यह कदम-दर-कदम होता है:

1. उपयोगकर्ता चैट इंटरफेस में एक संदेश टाइप करता है और भेजना दबाता है।
2. ब्राउज़र संदेश को फ्लास्क बैकएंड पर भेजता है, जिसमें उस बातचीत को पहचानने वाले सत्र आईडी भी शामिल होता है।
3. बैकएंड संदेश को बातचीत के इतिहास में जोड़ता है और सब कुछ एलएलएम को अग्रेषित करता है, एक सिस्टम निर्दे instructionsation पूर्वकर्ता लगाकर मॉडल को ट्रैवलबॉट के रूप में व्यवहार करने के लिए कहता है।
4. एलएलएम पूरी बातचीत को प्रोसेस करता है और एक उत्तर उत्पन्न करता है।
5. उत्तर को बैकएंड को वापस भेजा जाता है, बातचीत के इतिहास में जोड़ा जाता है, और उपयोगकर्ता के ब्राउज़र को लौटाया जाता है।
6. उपयोगकर्ता प्रतिक्रिया को चैट इंटरफेस में देखता है।

अब तक जो नहीं हो रहा है

इस चरण में, एप्लिकेशन पूरी तरह से कार्यात्मक है लेकिन पूरी तरह से असुरक्षित है। इसका मतलब है:

• उपयोगकर्ता जो मॉडल को भेजता है उसका कोई निरीक्षण नहीं है।
• उपकरण कॉल और जवाबों की कोई जांच नहीं होती है।
• कोई नीति प्रवर्तन नहीं है — कोई भी संदेश, जिसमें दुर्भावनापूर्ण संदेश शामिल हैं, एलएलएम तक पहुँचता है।
• एप्लिकेशन का उपयोग कैसे किया जा रहा है उसमें कोई दृश्यता नहीं है।

उपयोगकर्ता, उदाहरण के लिए, मॉडल को उसकी निर्दे instructionsations को अनदेखा करने के लिए प्रेरित कर सकता है, संवेदनशील जानकारी निकाल सकता है, या एप्लिकेशन का उपयोग ऐसे तरीकों से कर सकता है जो आपकी संस्था की नीतियों का उल्लंघन करते हैं — और यह सब न तो पता चल पाता और न ही रोका जाता।

अगला चरण ठीक इसी अंतर को संबोधित करता है।

सारांश

स्टेज 2 — गार्ड को प्रस्तुत करना

यह चरण क्या कवर करता है

स्टेज 1 में, हमने एक कार्यशील एआई एप्लिकेशन स्थापित किया जो सीधे एलएलएम के साथ संचार करता है। एप्लिकेशन काम करता है, लेकिन उपयोगकर्ता और मॉडल के बीच कुछ भी नहीं खड़ा है। इस चरण में, हम एक काटो एआई सुरक्षा गार्ड पेश करते हैं — वह प्रवर्तन परत जो आपके एप्लिकेशन और एलएलएम के बीच बैठती है, ट्रैफ़िक का वास्तविक समय में निरीक्षण करती है इससे पहले कि यह मॉडल तक पहुंचे और प्रतिक्रिया उपयोगकर्ता को वापस की जाए।

इस चरण के अंत तक, सभी LLM ट्रैफ़िक, उपयोगकर्ता संदेश, उपकरण परिभाषाएं, उपकरण उपयोग आदि Cato के माध्यम से जाते हैं। उपयोगकर्ता अनुभव समान रहता है — लेकिन अब प्रत्येक इंटरैक्शन की जांच की जाती है और उसे नियंत्रित किया जा सकता है।

प्रवाह का अद्यतन इस प्रकार दिखता है:

{ऊंचाई="" चौड़ाई=""}

गार्ड क्या है?

एक गार्ड एआई सुरक्षा के लिए प्रवर्तन बिंदु है। इस उदाहरण में, जिसमें हम प्रॉक्सी मोड का उपयोग कर रहे हैं, यह एक मध्यस्थ के रूप में कार्य करता है — आपके एप्लिकेशन और LLM के बीच बैठकर — और आपके द्वारा परिभाषित नीतियों के खिलाफ हर प्रॉम्प्ट और प्रतिक्रिया का मूल्यांकन करता है। उन नीतियों के आधार पर, गार्ड किसी इंटरैक्शन की अनुमति दे सकता है, उसे अवरुद्ध कर सकता है, या लॉग कर सकता है।

तीन प्रकार के गार्ड होते हैं। इस गाइड के लिए, हम एक प्रॉक्सी गार्ड का उपयोग कर रहे हैं। प्रॉक्सी मोड में, गार्ड पूरी तरह से ट्रैफिक पथ में इनलाइन बैठता है। आपका एप्लिकेशन सीधे एलएलएम की बजाय गार्ड की एंडपॉइंट पर अनुरोध भेजता है, और गार्ड निरीक्षण के बाद उन्हें अग्रेषित करता है। आपके एप्लिकेशन की लॉजिक में कोई बदलाव जरूरी नहीं है — केवल गंतव्य पते में बदलाव होता है।

चरण 1 — काटो प्रबंधन एप्लिकेशन में गार्ड बनाएँ

पहला कदम काटो प्रबंधन एप्लिकेशन में गार्ड को एक तार्किक इकाई के रूप में बनाना है। यह यूआई में किया जाता है — इस समय किसी कोड की आवश्यकता नहीं है।

1. नेविगेशन मेनू से एआई सुरक्षा > गार्ड्स चुनें, फिर नया क्लिक करें।
2. एक वर्णनात्मक गार्ड नाम दर्ज करें। हमारे उदाहरण में, हम E2E नमूना उपयोग केस का उपयोग करते हैं।
3. गार्ड प्रकार चुनें के तहत, प्रॉक्सी चुनें।
4. एआई सेवा चुनें के तहत, ड्रॉपडाउन से कस्टम एंडपॉइंट चुनें। यह विकल्प किसी भी ओपनएआई-संगत एंडपॉइंट के साथ काम करता है, जिसे हमारा एप्लिकेशन उपयोग करता है।
5. एंडपॉइंट यूआरएल फ़ील्ड में, अपने एलएलएम प्रदाता का यूआरएल दर्ज करें। हमारे उदाहरण में, यह https://bedrock-mantle.eu-north-1.api.aws/v1 है। यह वही यूआरएल है जो पहले config.py में BASE_URL के रूप में सेट किया गया था — आप अब इस पते को गार्ड को सौंप रहे हैं, सीधे अपने एप्लिकेशन में इसका उपयोग करने के बजाय।
   नोट: URL में पथ शामिल होना चाहिए, और /v1 को सम्मिलित करना चाहिए।
6. गार्ड सेटिंग्स को कॉन्फ़िगर करें के तहत गार्ड के होस्ट को काटो का क्लाउड पर सेट छोड़ दें। इसका मतलब है कि गार्ड का प्रबंधन और होस्टिंग काटो द्वारा की जाती है — आपको कोई अतिरिक्त इंफ्रास्ट्रक्चर तैनात या बनाए रखने की जरूरत नहीं है।
7. सेव करें पर क्लिक करें।

अभी क्या हुआ? आपने एक गार्ड बना लिया है जो जानता है कि आपका एलएलएम कहाँ रहता है। अब काटो आपके एप्लिकेशन और उस एलएलएम के बीच सभी ट्रैफ़िक के लिए मध्यस्थ के रूप में काम करेगा। गार्ड के पास अभी तक कोई नीति नियम नहीं हैं — हम उन्हें चरण 3 में जोड़ देंगे। फिलहाल, हम केवल कनेक्शन को स्थापित कर रहे हैं और यह सत्यापित कर रहे हैं कि प्रवाह अभी भी काम करता है।

चरण 2 — गार्ड का कनेक्शन विवरण पुनः प्राप्त करें

एक बार गार्ड सहेजे जाने के बाद, उसे गार्ड्स पेज से खोलें और गार्ड के डॉक्स पेज पर जाकर नेविगेट करें, जो आपके एप्लिकेशन को आवश्यक सभी कनेक्शन विवरण प्रदान करता है ताकि वह गार्ड से कनेक्ट हो सके बिना एलएलएम से सीधे जुड़ने की।

आप यहां दो प्रमुख जानकारी के टुकड़े पाएंगे:

• गार्ड एंडपॉइंट (आपका नया BASE_URL) - यह पता है जहाँ अब आपका एप्लिकेशन अनुरोध भेजेगा: https://api.aisec.catonetworks.com/fw/v1/proxy/openai

  • यह आपके कॉन्फ़िगरेशन में एलएलएम के एंडपॉइंट यूआरएल की जगह लेता है। इस बिंदु से, आपका एप्लिकेशन काटो से बात करता है, और काटो आपके नाम पर एलएलएम से बात करता है।

• गार्ड एपीआई कुंजी (आपकी नई OPENAI_API_KEY)

  • डॉक्स पेज एक गार्ड एपीआई कुंजी भी प्रदान करता है — वह प्रमाणपत्र जिसे आपका एप्लिकेशन गार्ड के साथ प्रमाणित करने के लिए उपयोग करता है। यह आपकी कॉन्फ़िगरेशन में पहले मौजूद एलएलएम एपीआई कुंजी की जगह लेता है। यह इस प्रकार दिखाई देता है: cato-1234-abcde

नोट: काटो दो गार्ड एपीआई कुंजियाँ प्रदान करता है। आपको केवल एक की जरूरत है अनुरोध करने के लिए। दूसरी कुंजी अस्तित्व में है ताकि आप प्रमाणपत्रों को सुरक्षित रूप से घुमा सकें — आप अपने एप्लिकेशन को नई कुंजी का उपयोग करने के लिए अपडेट कर सकते हैं जबकि पुरानी अभी भी सक्रिय है, किसी भी डाउनटाइम से बचते हुए।

एलएलएम एपीआई कुंजी

पहले, एलएलएम एपीआई कुंजी आपके एप्लिकेशन की कॉन्फ़िगरेशन में रहती थी। गार्ड के स्थान पर होने के साथ, वह कुंजी अनुरोध शीर्षलेखों में चली जाती है जो आपका एप्लिकेशन गार्ड को भेजता है — विशेष रूप से x-cato-provider-api-key नामक शीर्षलेख में। गार्ड इसका उपयोग आपके एप्लिकेशन के नाम पर एलएलएम के साथ प्रमाणित करने के लिए करता है।

यह वास्तव में एक सुरक्षा सुधार है: एलएलएम एपीआई कुंजी अब किसी कॉन्फ़िगरेशन फ़ाइल में हार्डकोड नहीं है, और गार्ड उस प्रमाणपत्र के लिए नियंत्रित पास-थ्रू के रूप में कार्य करता है।

चरण 3 — आवेदन कॉन्फ़िगरेशन अपडेट करें

अब जब गार्ड बनाया गया है और आपके पास इसका कनेक्शन विवरण है, यह एप्लिकेशन को अपडेट करने का समय है। स्टेज 1 और स्टेज 2 को स्पष्ट रूप से अलग रखने के लिए, हम मूल को ओवरराइट करने के बजाय कॉन्फ़िगरेशन फ़ाइलों का एक नया सेट बनाते हैं। इस तरह, दोनों चरण संदर्भ के लिए अक्षुण्ण रहते हैं।

नई कॉन्फ़िगरेशन फ़ाइल, config_stage2.py, अद्यतन कनेक्शन विवरण को दर्शाती है:

# चरण 2 कॉन्फ़िगरेशन — काटो प्रॉक्सी गार्ड के माध्यम से रूटिंग

गार्ड_एपीआई_कुंजी = "cato-xxxxx-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
BASE_URL = "https://api.aisec.catonetworks.com/fw/v1/proxy/openai"
MODEL_ID = "amazon.nova-pro-v1:0"
LLM_PROVIDER_API_KEY = "[SECRET_1]" # आपका एलएलएम प्रदाता एपीआई कुंजी — गार्ड को प्रेषित की जाती है, एलएलएम को नहीं

SYSTEM_PROMPT = (
"आप ट्रैवलबोट हैं, एक दोस्ताना और ज्ञानवान यात्रा सहायक। "
"उपयोगकर्ताओं को गंतव्य खोजने, यात्रा कार्यक्रम बनाने, होटल की सिफारिश करने, और व्यावहारिक यात्रा सुझाव साझा करने में मदद करें। प्रतिक्रिया संक्षेप और उत्साही बनाए रखें। "
"यदि कोई प्रश्न यात्रा से संबंधित नहीं है, तो कृपा पूर्वक वार्तालाप को मोड़ दें।"
)

MAX_TOKENS = 1024

स्टेज 1 से प्रमुख अंतर:

चरण 4 — ग्राहक कोड अपडेट करें

ग्राहक कोड को भी एक संबंधित चरण 2 संस्करण मिलता है — bedrock_client_stage2.py। लॉजिक बड़े पैमाने पर चरण 1 के समान है, जिसमें दो जोड़ हैं:

1. गार्ड एपीआई की का उपयोग गार्ड के साथ प्रमाणित करने के लिए किया जाता है (अनुमति शीर्षलेख में)।
2. एलएलएम एपीआई की को एक अतिरिक्त शीर्षलेख (x-cato-provider-api-key) के रूप में पारित किया जाता है ताकि गार्ड इसे एलएलएम पर अग्रेषित कर सके।
3. सत्र आईडी अतिरिक्त शीर्षलेख (x-cato-session-id) के रूप में पारित किया जाता है ताकि गार्ड एक ही वार्तालाप से अनुरोध को समूहबद्ध कर सके — यह सीधे एप्लिकेशन लॉजिक में पहले से मौजूद session_id को मैप करता है।

# बेडरॉक_क्लाइंट_स्टेज2.py

openai से OpenAI आयात करें
config_stage2 से GUARD_API_KEY, BASE_URL, MODEL_ID, LLM_PROVIDER_API_KEY, SYSTEM_PROMPT, MAX_TOKENS आयात करें


class BedrockClient:
    def __init__(self):
        self._client = कोई नहीं

    def _get_client(self) -> OpenAI:
        if self._client कोई नहीं है:
            self._client = OpenAI(
                api_key=GUARD_API_KEY,
                base_url=BASE_URL,
                default_headers={
                    "x-cato-provider-api-key": LLM_PROVIDER_API_KEY,
                }
            )
        वापसी self._client

    def invoke(self, messages: list[dict], session_id: str = "") -> str:
        सभी संदेश = [{"भूमिका": "सिस्टम", "सामग्री": SYSTEM_PROMPT}] + messages

        प्रतिक्रिया = self._get_client().chat.completions.create(
            मॉडल=MODEL_ID,
            संदेश=सभी संदेश,
            अधिकतम_टोकन=MAX_TOKENS,
            अतिरिक्त_हेडर्स={
                "x-cato-session-id": session_id,
            }
        )

        वापसी प्रतिक्रिया.चुनाव[0].संदेश.सामग्री

प्रवाह का सत्यापन

जैसे ही अद्यतन कॉन्फ़िगरेशन और क्लाइंट फ़ाइलें सेट की जाती हैं, अनुप्रयोग को उपयोगकर्ता के दृष्टिकोण से चरण 1 में जैसे ही कार्य करना चाहिए। TravelBot यात्रा प्रश्नों का समान रूप से उत्तर देता है — लेकिन अब हर बातचीत गार्ड के माध्यम से हो रही है।

इस बिंदु पर गार्ड के पास कोई नीति नियम कॉन्फ़िगर नहीं किए गए हैं, इसलिए यह किसी भी ट्रैफ़िक को अवरुद्ध या संशोधित नहीं कर रहा है। हालाँकि, यह हर बातचीत को लॉग कर रहा है। आप Cato प्रबंधन अनुप्रयोग में गार्ड खोलकर और गार्ड लॉगिंग पृष्ठ की समीक्षा करके इसे सत्यापित कर सकते हैं, जहाँ आप देखेंगे कि उपयोग के अनुसार सत्र दिखाई दे रहे हैं।

यह पुष्टि करता है कि एकीकरण सही ढंग से काम कर रहा है और गार्ड ट्रैफ़िक प्राप्त कर रहा है।

चरण 1 से चरण 2 तक के परिवर्तन का सारांश

चरण 3 — नीति नियमों को कॉन्फ़िगर करना

यह चरण क्या कवर करता है

चरण 2 में, हमने गार्ड को पेश किया और सत्यापित किया कि ट्रैफ़िक सही ढंग से उसके माध्यम से गुजर रहा है। गार्ड सक्रिय है, लेकिन यह अभी तक कोई नियम लागू नहीं कर रहा है — यह बिना किसी कार्रवाई के ट्रैफ़िक का निरीक्षण कर रहा है। इस चरण में, हम गार्ड इंटरैक्शन नीति को कॉन्फ़िगर करते हैं: नियमों का सेट जो गार्ड को बताता है कि जब वह विशिष्ट प्रकार की सामग्री का पता लगाता है तो क्या करना है।

इस चरण के अंत तक, गार्ड लाइव ट्रैफ़िक के खिलाफ दो नियमों को सक्रिय रूप से लागू करेगा:

• किसी भी बातचीत को अवरोध और गुमनाम करें जिसमें PII या पासवर्ड जैसी जानकारी शामिल है
• निगरानी करें किसी भी बातचीत जिसमें चिकित्सा सलाह या स्वास्थ्य-संबंधित डेटा शामिल है

नोट: हम अनुशंसा करते हैं कि आप पहले अपने नियमों को उनकी निगरानी में सेट करके उनका परीक्षण करें और उन्हें ब्लॉक करने के लिए ले जाएं जब आप इसे मान्य करें कि पहचान आपके अपेक्षानुसार काम कर रही हैं।

गार्ड इंटरैक्शन नीति क्या है?

गार्ड इंटरैक्शन नीति आपके एआई सुरक्षा गार्डों के लिए नियम आधार है। इसे एआई ट्रैफ़िक के लिए फ़ायरवॉल के रूप में सोचें — नेटवर्क पैकेट का निरीक्षण करने के बजाय, यह एआई इंटरैक्शन की सामग्री का निरीक्षण करता है और जब कोई मिलान पाया जाता है तो आपकी परिभाषित कार्रवाई लागू करता है।

नीति में प्रत्येक नियम निर्दिष्ट करता है:

• किस गार्ड पर नियम लागू होता है
• क्या देखें — एक इंजन प्रोफ़ाइल द्वारा परिभाषित, जो कि पहचान श्रेणी है (उदाहरण के लिए, जेलब्रेक प्रयास, पीआईआई, या चिकित्सा डेटा)
• क्या करें जब कोई मिलान पाया जाता है — अवरुद्ध करें, निगरानी करें, गुमनाम करें और अवरुद्ध करें, या गुमनाम करें और निगरानी करें
• निरीक्षण के लिए ट्रैफ़िक की किस दिशा — उपयोगकर्ता से आने वाले संदेश, सहायक से प्रतिक्रियाएँ, उपकरण इनपुट, या उपकरण आउटपुट

ध्यान देने योग्य एक महत्वपूर्ण व्यवहार: गार्ड इंटरैक्शन नीति के नियमों का मूल्यांकन उनके नियम आधार में स्थिति की परवाह किए बिना किया जाता है। उदाहरण के लिए, यदि एक नियम निगरानी कहता है और दूसरा अवरोधन कहता है, तो अवरोधन कार्रवाई लागू होती है। उदाहरण के लिए, यदि एक नियम कहता है कि मॉनिटर और दूसरा कहता है ब्लॉक, तो ब्लॉक क्रिया लागू होती है।

स्टेप 1 — नियम 1 बनाएँ: जेलब्रेक प्रयास अवरुद्ध करें

पहला नियम जो हम बनाते हैं, वह जेलब्रेक प्रयासों को लक्षित करता है — उपयोगकर्ताओं द्वारा मॉडल को अपनी निर्देशों को अनदेखा करने या इसकी सुरक्षा को बाइपास करने के लिए किए गए जानबूझकर प्रयास। TravelBot जैसी ग्राहक-सामना करने वाली एप्लिकेशन के लिए, यह एक सार्थक जोखिम है: एक उपयोगकर्ता मॉडल को इसकी परिभाषित भूमिका के बाहर व्यवहार करने के लिए मजबूर कर सकता है या ऐसी जानकारी का खुलासा कर सकता है जिसे उसे नहीं करना चाहिए।

प्रारंभ करने के लिए, गार्ड्स नीति पृष्ठ पर जाएं। आप AI सुरक्षा > गार्ड इंटरैक्शन नीति का चयन करके मुख्य नेविगेशन मेनू से या गार्ड के अवलोकन पृष्ठ से नीति प्रबंधन पर क्लिक करके सीधे ऐसा कर सकते हैं।

गार्ड्स नीति पृष्ठ से, नया खोलने के लिए नियम संपादक खोलें, फिर निम्नलिखित को कॉन्फ़िगर करें:

सामान्य

• नाम: कुछ ट्रैफ़िक अवरोध करें
• विवरण: यह हमारे यात्रा बॉट से जेलब्रेक ट्रैफ़िक को ब्लॉक करता है
• सक्षम टॉगल चालू छोड़ें

गार्ड्स

• E2E नमूना उपयोग मामला चुनें — यह नियम को हमारे विशिष्ट गार्ड तक सीमित करता है और खाते में किसी अन्य गार्ड को प्रभावित नहीं करता है

इंजन प्रोफ़ाइल

• संवेदनशील पहचानकर्ता का चयन करें — यह वह पहचान श्रेणी है जो प्रॉम्प्ट इंजेक्शन प्रयासों, जेलब्रेक पैटर्न, और मॉडल से रहस्य या प्रमाण-पत्र निकालने के प्रयासों की पहचान करती है

कार्रवाई

• एनोनिमाइज & ब्लॉक चुनें — जब गार्ड को मैच मिलता है, तो यह बातचीत में मौजूद किसी भी संवेदनशील डेटा को गुमनाम कर देगा और प्रॉम्प्ट को पूरी तरह से LLM तक पहुंचने से रोक देगा

दिशा

• उपयोगकर्ता और उपकरण इनपुट की जाँच करें — नियम उपयोगकर्ता से आने वाली सामग्री पर लागू होता है और किसी भी उपकरण इनपुट से होता है। उपयोगकर्ता से प्रतिक्रियाएं और उपकरण आउटपुट इस नियम के लिए स्कोप में नहीं हैं।

बचत पर क्लिक करें। नियम को अप्रकाशित संशोधन में सहेजा गया है और फिर भी लाइव ट्रैफ़िक को प्रभावित नहीं करेगा।

स्टेप 2 — नियम 2 बनाएँ: चिकित्सा सामग्री की निगरानी करें

दूसरा नियम एक अलग दृष्टिकोण अपनाता है। ट्रैफ़िक को अवरुद्ध करने के बजाय, यह समीक्षा के लिए उन्हें चिह्नित करते हुए बातचीत को आगे बढ़ने की अनुमति देता है। यह सामग्री के लिए उपयुक्त है जो जरूरी नहीं कि दुर्भावनापूर्ण हो लेकिन यह दृश्यता के योग्य हो सकता है — इस मामले में, चिकित्सा सलाह או स्वास्थ्य-संबंधित डेटा में शामिल बातचीत।

TravelBot के लिए, एक उपयोगकर्ता जो चिकित्सा यात्रा सलाह माँग रहा है (जैसे टीकाकरण आवश्यकताएँ या गंतव्य के लिए स्वास्थ्य सावधानियाँ) स्वाभाविक रूप से हानिकारक नहीं है, लेकिन यह वही सामग्री है जिसे आपका संगठन अनुपालन या गुणवत्ता के उद्देश्यों के लिए ट्रैक करना चाहता है।

गार्ड्स नीति पृष्ठ से, फिर से नया पर क्लिक करें और निम्नलिखित को कॉन्फ़िगर करें:

• सामान्य विन्यास
  • नाम: संभावित हानिकारक डेटा की निगरानी करें
  • विवरण: यह संचार के माध्यम से जाने की अनुमति देता है, लेकिन बातचीत की निगरानी करता है
    सक्षम टॉगल चालू छोड़ें

गार्ड्स

• E2E नमूना उपयोग मामला चुनें

इंजन प्रोफ़ाइल

• स्वास्थ्य डेटा एक्सपोजर का चयन करें — यह ऐसी बातचीत का पता लगाता है जिसमें चिकित्सा मार्गदर्शन, स्वास्थ्य डेटा, या नैदानिक ​​जानकारी शामिल है

कार्रवाई

• अनुकूलित करें और निगरानी करें का चयन करें — बातचीत को LLM तक अनुमति है और प्रतिक्रिया सामान्य रूप से उपयोगकर्ता को वापस कर दी जाती है। किसी भी व्यक्तिगत जानकारी को व्यक्तिगत विवरणों की रक्षा के लिए गुमनाम किया जाता है। स्वीकृति के लिए बातचीत Cato में लॉग की जाती है।

दिशा

• सभी चार दिशाओं की जांच करें: उपयोगकर्ता, सहायक, उपकरण इनपुट, और उपकरण आउटपुट— यह नियम सभी दिशाओं में ट्रैफ़िक की निगरानी करता है, जिससे आपको बातचीत के दोनों पक्षों में पूरी दृश्यता मिल जाती है

बचत पर क्लिक करें।

स्टेप 3 — नीति प्रकाशित करें

दोनों नियमों को सहेजने के बाद, गार्ड्स नीति पृष्ठ एक अप्रकाशित संशोधन स्थिति और शीर्ष दाईं ओर एक प्रकाशित करें (2) बटन दिखाएगा, यह दर्शाता है कि दो नियम लाइव जाने के लिए तैयार हैं।

महत्वपूर्ण: जब तक आप प्रकाशित नहीं करते, सक्रिय नीति अपरिवर्तित रहती है। आपके नियम ड्राफ्ट स्थिति में मौजूद होते हैं और लाइव ट्रैफ़िक के खिलाफ लागू नहीं होते हैं। यह आपको आपके परिवर्तनों की समीक्षा करने का अवसर देता है इससे पहले कि वे प्रभावी हों।

जब आप तैयार हों, तो प्रकाशित करें (2) पर क्लिक करें। दोनों नियम तुरंत सक्रिय हो जाते हैं और गार्ड सभी आने वाले ट्रैफ़िक पर उन्हें लागू करने लगते हैं।

{ऊंचाई="" चौड़ाई=""}

गार्ड अब क्या कर रहा है

दोनों नियमों को प्रकाशित करके, प्रत्येक बातचीत जो E2E नमूना उपयोग मामला गार्ड के माध्यम से जाती है अब नीति के खिलाफ मूल्यांकन की जाती है। यह व्यवहार में कैसा दिखता है:

एक उपयोगकर्ता TravelBot को एक संदेश भेजता है। मॉडल तक पहुँचने से पहले, गार्ड इसे दोनों नियमों के खिलाफ जांचता है:

• यदि संदेश में कोई जेलब्रेक पैटर्न या रहस्य निकालने का प्रयास शामिल है, तो गार्ड इसे गुमनाम करता है और अवरुद्ध करता है। LLM कभी भी संदेश नहीं देखता है, और उपयोगकर्ता को एक अवरुद्ध प्रतिक्रिया प्राप्त होती है।
• यदि संदेश में चिकित्सा सलाह या स्वास्थ्य-संबंधित सामग्री शामिल है, तो गार्ड इसे अनुमति देता है लेकिन समीक्षा के लिए बातचीत लॉग करता है।
• यदि संदेश किसी भी नियम से मेल नहीं खाता है, तो यह मॉडल तक अप्रभावित पहुँच से गुजरता है।

उपयोगकर्ता से प्रतिक्रियाएं, उपकरण इनपुट और उपकरण आउटपुट के लिए भी यही मूल्यांकन लागू होता है, प्रत्येक नियम के लिए कॉन्फ़िगर की गई दिशाओं के आधार पर।

सत्यापित कर रहे हैं कि नियम सक्रिय हैं

यह पुष्टि करने के लिए कि नियम सक्रिय हैं और आपके गार्ड पर लागू होते हैं, गार्ड के अवलोकन पृष्ठ पर नेविगेट करें। सक्रिय नियमों के तहत, अब आपको दोनों नियम सूचीबद्ध दिखाई देने चाहिए। जैसे जैसे ट्रैफ़िक गार्ड के माध्यम से प्रवाहित होती है और पहचान होती है, इंटरैक्शन ओवर टाइम चार्ट और उल्लंघन ब्रेकडाउन पैनल आबादी शुरू कर देंगे।

आप व्यक्तिगत सत्रों की समीक्षा करने के लिए भी गार्ड लॉगिंग पर जा सकते हैं, देख सकते हैं कि कौनसे नियम फायर हुए, और फ़्लैग की गई बातचीत के विवरण का निरीक्षण करें — बशर्ते आपके पास संवेदनशील सामग्री देखने की आवश्यक अनुमतियाँ हैं।

सारांश

इन दो नियमों को स्थान पर रखकर, एप्लिकेशन में अब सक्रिय सुरक्षा प्रवर्तन है। दुर्भावनापूर्ण प्रॉम्प्ट प्रयास को मॉडल तक पहुँचने से पहले अवरुद्ध कर दिया जाता है, और संवेदनशील स्वास्थ्य-संबंधी बातचीत आपकी सुरक्षा टीम को दिखाई देती है — बिना एप्लिकेशन कोड में कोई बदलाव किए या वैध बातचीत के लिए अंतिम उपयोगकर्ता अनुभव पर कोई प्रभाव डाले।

यह Cato AI सुरक्षा गार्डों के साथ एक कस्टम एआई एप्लिकेशन को सुरक्षित करने के लिए एंड-टू-एंड गाइड को पूरा करता है।