एंटरप्राइज में एजेंटिक सुरक्षाएडवांस्डपाठ 1557 मिनट का पाठ

एजेंट्स के लिए रनटाइम सिक्योरिटी: पॉलिसीज़ और गेटवे

प्रॉम्प्ट में लिखे नियमों को बातों में उलझाकर तोड़ा जा सकता है। लेकिन एजेंट और उसके टूल्स के बीच गेटवे द्वारा लागू किए गए नियमों को नहीं तोड़ा जा सकता। इस लेयर को कैसे बनाया जाए, यहाँ बताया गया है।

✦ ट्यूटर से पूछें🧪 लैब · 40 min📝 पाठ का टेस्ट
पाठ वीडियो में

60 सेकंड में

एजेंट्स के लिए रनटाइम सिक्योरिटी: पॉलिसीज़ और गेटवे

प्रॉम्प्ट में लिखे नियमों को बातों में उलझाकर तोड़ा जा सकता है। लेकिन एजेंट और उसके टूल्स के बीच गेटवे द्वारा लागू किए गए नियमों को नहीं तोड़ा जा सकता। इस लेयर को कैसे बनाया जाए…

1/4
आसान शब्दों में
गेट पर खड़ा सिक्योरिटी गार्ड अंदर-बाहर आने-जाने वाले हर व्यक्ति को चेक करता है, भले ही वे कुछ भी कहें। भले ही कोई अंदर बैठे गार्ड के दोस्त को अपनी मीठी बातों में फंसा ले, गार्ड फिर भी लिस्ट चेक करता है। वह गार्ड ही एक गेटवे है।
मॉडल तय करता है कि वह क्या करना चाहता है। लेकिन मॉडल के बाहर किसी चीज़ को यह तय करना चाहिए कि उसे क्या करने की अनुमति है। एक गेटवे (या पॉलिसी प्रॉक्सी) एजेंट्स और उनके टूल्स के बीच, और एजेंट्स और मॉडल प्रोवाइडर्स के बीच बैठता है। हर टूल कॉल और हर रिस्पॉन्स इसी से होकर गुज़रता है।

एक गेटवे क्या कर सकता है

फ़ंक्शनउदाहरण
टूल्स और आर्ग्युमेंट्स को allow-list करनायह एजेंट search_tickets और add_comment को कॉल कर सकता है; add_comment सिर्फ़ उन्हीं टिकट्स पर जो उसकी टीम को असाइन किए गए हैं
पहचान (identity) जोड़नाहर कॉल में वेरिफ़ाइड एजेंट और यूज़र की पहचान जोड़ता है, ताकि टूल्स मॉडल के दावों पर भरोसा न करें
आउटपुट्स पर डेटा लॉस प्रिवेंशन (DLP)जवाबों और बाहर जाने वाली कॉल्स में कार्ड नंबर, आधार जैसे नंबर, कीज़ और पासवर्ड को ब्लॉक या मास्क करता है
रेट और बजट लिमिट्सप्रति घंटे ज़्यादा से ज़्यादा 20 रिफ़ंड प्रस्तावित किए जा सकते हैं; प्रति टास्क लागत की एक तय सीमा
मंज़ूरी (अप्रूवल्स)ज़्यादा जोखिम वाली कॉल्स को रोकता है और उन्हें पूरी जानकारी के साथ किसी इंसान के पास भेजता है
विसंगति का पता लगाना (एनोमली डिटेक्शन)पहली बार इस्तेमाल होने वाले टूल्स, नए डेस्टिनेशन्स, अचानक उछाल और लूप्स पर अलर्ट भेजता है
किल स्विचएक ऐसी सेटिंग जो किसी एजेंट, टूल या सभी चीज़ों के लिए कॉल्स को तुरंत रोक देती है
लॉगिंगनिगरानी और घटनाओं से निपटने के लिए हर कॉल का एक जैसा रिकॉर्ड

पॉलिसी ऐज़ कोड

पॉलिसी ऐज़ कोड का मतलब है किसी कंसोल में सेटिंग्स क्लिक करने के बजाय, नियमों को ऐसी फ़ाइलों में लिखना जिनका सॉफ़्टवेयर की तरह वर्ज़न रखा जाए, रिव्यू किया जाए और टेस्ट किया जाए। आप देख सकते हैं कि किसने और क्यों कोई नियम बदला, लाइव होने से पहले उसे टेस्ट कर सकते हैं और वापस पुरानी स्थिति में ला सकते हैं। कुछ टीमें सामान्य पॉलिसी इंजन का इस्तेमाल करती हैं; शुरुआत के लिए एक छोटा, अच्छी तरह से टेस्ट किया गया फ़ंक्शन भी ठीक रहता है।
A simple policy check (Python)python
from dataclasses import dataclass

@dataclass
class ToolCall:
    agent: str
    user: str
    tool: str
    args: dict

POLICY = {
    "support-agent": {
        "allowed_tools": {"search_kb", "get_order", "draft_reply"},
        "needs_approval": {"issue_refund"},
    },
}

def decide(call: ToolCall) -> str:
    rules = POLICY.get(call.agent)
    if rules is None:
        return "deny: unknown agent"          # default deny
    if call.tool in rules["needs_approval"]:
        return "hold: human approval"
    if call.tool not in rules["allowed_tools"]:
        return "deny: tool not allowed"
    if call.tool == "get_order" and call.args.get("customer_id") != call.user:
        return "deny: not this user's order"  # identity from runtime, not model
    return "allow"
  • डिफ़ॉल्ट डिनाई (Default deny): अनजान एजेंट्स और अनजान टूल्स को मना कर दिया जाता है।
  • रनटाइम से पहचान: call.user प्लैटफ़ॉर्म द्वारा सेट किया जाता है, मॉडल के टेक्स्ट से कभी नहीं लिया जाता।
  • सिर्फ़ टूल के नाम ही नहीं, आर्ग्युमेंट्स भी चेक किए जाते हैं: अगर अनुमति प्राप्त टूल गलत टार्गेट के साथ है, तो भी उसे रोक दिया जाता है।

आउटपुट चेक और DLP

DLP चेक सिस्टम से बाहर जाने वाली चीज़ों (जैसे जवाब, ईमेल, URLs, टूल आर्ग्युमेंट्स) में कार्ड नंबर, पहचान संख्या, API keys और इंटरनल होस्टनेम जैसे पैटर्न ढूँढते हैं। वे कई अनजाने लीक्स को पकड़ लेते हैं। लेकिन वे ऐसे डेटा को छोड़ सकते हैं जिसे नए शब्दों में लिखा गया हो, टुकड़ों में बाँटा गया हो या एनकोड किया गया हो, इसलिए DLP को सिर्फ़ एक सुरक्षा परत मानें, पूरी दीवार नहीं।
प्रॉम्प्ट पर भरोसा करना
  • सिस्टम प्रॉम्प्ट में "बिना मंज़ूरी के रिफ़ंड टूल को कभी कॉल न करें"
  • "कार्ड नंबर ज़ाहिर न करें"
  • "सिर्फ़ मौजूदा यूज़र के ऑर्डर्स देखें"
गेटवे पर लागू किया गया
  • रिफ़ंड कॉल्स को तब तक रोक कर रखा जाता है जब तक कोई इंसान मंज़ूरी न दे दे
  • बाहर जाने वाले टेक्स्ट को स्कैन किया जाता है और कार्ड जैसे दिखने वाले नंबरों को मास्क कर दिया जाता है
  • ऑर्डर टूल किसी भी ऐसे कस्टमर ID को खारिज कर देता है जो वेरिफ़ाइड यूज़र से मेल नहीं खाता

किल स्विच

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

और देखें और पढ़ें

OWASP GenAI Security ProjectOWASP · reading

लैब

एक टेस्ट किया हुआ पॉलिसी फ़ंक्शन जो allow-list से बाहर की टूल कॉल्स को ब्लॉक करता है और जोखिम भरी कॉल्स को रोककर रखता है।

~40 min

समस्या

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

  1. decide को ऐसा बनाएँ कि वह अनजान एजेंट्स और allow-list में शामिल न होने वाले टूल्स को डिनाई कर दे।
  2. issue_refund को मंज़ूरी के लिए रोकें, और अगर रकम एजेंट की तय सीमा से ज़्यादा है, तो उसे तुरंत डिनाई कर दें।
  3. अनुमति प्राप्त लिस्ट में शामिल न होने वाले किसी भी डोमेन पर send_email को डिनाई करें।
  4. एक रेट लिमिट जोड़ें: एक रन में एक ही एजेंट द्वारा एक ही टूल पर 5 स्वीकृत कॉल्स के बाद, कॉल को डिनाई करें।
  5. अपने खुद के दो टेस्ट जोड़ें।

प्रैक्टिस लैब

कोड में बदलाव करें और इसे रन करें। Python आपके ब्राउज़र में चलता है — हमारे सर्वर पर कुछ नहीं भेजा जाता।

आउटपुट

कोई आउटपुट नहीं। वैल्यूज़ देखने के लिए print(...) जोड़ें।

आपका काम तब पूरा होगा जब

कठिन सवाल

उत्तर देखने से पहले ख़ुद जवाब देने की कोशिश करें। अगर आप इनके जवाब दे सकते हैं, तो आप पाठ समझ गए हैं।

Q1आपका ईमेल चेक "@" पर अलग करता है। आपको किन पेचीदा इनपुट्स को टेस्ट करना चाहिए?दिखाएं

एक से ज़्यादा @ वाले पते, बड़े अक्षरों वाले डोमेन्स, अतिरिक्त स्पेस, सबडोमेन्स (a@evil.example.com बनाम a@example.com), एक ही स्ट्रिंग में कई प्राप्तकर्ताओं की लिस्ट, और CC या BCC फ़ील्ड्स। उन्हें नॉर्मलाइज़ करें (छोटे अक्षर बनाएँ, स्पेस हटाएँ), आख़िरी @ के बाद वाला हिस्सा लें, सटीक डोमेन्स से तुलना करें, और सिर्फ़ "to" ही नहीं बल्कि हर प्राप्तकर्ता फ़ील्ड की जाँच करें।

Q2पॉलिसी रिफ़ंड को मंज़ूरी के लिए रोक कर रखती है। मंज़ूरी की रिक्वेस्ट में क्या दिखना चाहिए ताकि इंसान सही फ़ैसला ले सके?दिखाएं

कस्टमर, ऑर्डर, रकम, एजेंट द्वारा दिया गया कारण, वह स्रोत जिसकी वजह से यह हुआ (उदाहरण के लिए टिकट का टेक्स्ट), क्या इस कस्टमर को हाल ही में कोई रिफ़ंड मिला था, और इसमें असामान्य क्या है। यह भी बताएँ कि क्या इसे वापस पलटा जा सकता है। ऐसी रिक्वेस्ट जिसमें सिर्फ़ "रिफ़ंड मंज़ूर करें?" लिखा हो, उस पर बिना सोचे-समझे क्लिक होने का ख़तरा रहता है।

जारी रखने के लिए कृपया साइन इन करें।

अक्सर पूछे जाने वाले सवाल

क्या गेटवे से देरी होती है?

थोड़ी सी, जो आमतौर पर मॉडल के अपने रिस्पॉन्स टाइम की तुलना में बहुत कम होती है। सामान्य allow-list और आर्ग्युमेंट चेक्स तेज़ होते हैं। भारी चेक्स (जैसे बड़े आउटपुट्स को स्कैन करना) में ज़्यादा समय लगता है, इसलिए उन्हें वहीं लागू करें जहाँ जोखिम हो।

क्या गेटवे को रिक्वेस्ट्स को परखने के लिए किसी AI मॉडल का इस्तेमाल करना चाहिए?

मॉडल पर आधारित क्लासिफ़ायर असामान्य रिक्वेस्ट्स को फ़्लैग करने में मदद कर सकता है, लेकिन किसी भी अन्य मॉडल की तरह इसे भी धोखा दिया जा सकता है। कड़े नियमों (allow-lists, पहचान, लिमिट्स, अप्रूवल्स) को सीधे कोड में रखें, और AI चेक्स का इस्तेमाल सिर्फ़ एक अतिरिक्त संकेत के तौर पर करें, आख़िरी गेट के रूप में नहीं।

गेटवे कहाँ रहता है?

जहाँ से सारा ट्रैफ़िक गुज़रना ज़रूरी हो: टूल सर्वर्स के सामने एक प्रॉक्सी के रूप में, आपके MCP क्लाइंट या एजेंट प्लैटफ़ॉर्म में, या किसी नेटवर्क लेयर में। मायने यह रखता है कि एजेंट्स के पास टूल्स तक पहुँचने का कोई दूसरा रास्ता न हो।

हम नीतियों को कैसे टेस्ट करते हैं?

किसी भी अन्य कोड की तरह टेस्ट लिखें: वे कॉल्स जिन्हें अनुमति मिलनी चाहिए, वे कॉल्स जिन्हें रोका जाना चाहिए, और वे कॉल्स जिन्हें होल्ड पर रखा जाना चाहिए। हर पॉलिसी बदलाव पर उन्हें रन करें। जब भी कोई घटना आपको कुछ नया सिखाए, एक नया टेस्ट जोड़ें।

पाठ का टेस्ट

5 सवाल। पास होने और इस पाठ को पूरा करने के लिए 3 सही होने चाहिए (60%)।

टेस्ट देने और अपनी प्रोग्रेस सेव करने के लिए साइन इन करें