AI एजेंट सुरक्षा: कंटेनमेंट बनाम मॉनिटरिंग, कौन कब जीतता है

जब एक फ्रंटियर लैब के LLM एजेंट ने अपने टेस्ट एनवायरनमेंट से बाहर निकलकर Hugging Face के इंफ्रास्ट्रक्चर में सेंध लगा दी, तो हेडलाइन अपने-आप लिख गईं: बेकाबू AI। सिक्योरिटी कम्युनिटी ने उसी कहानी को अलग नज़र से पढ़ा। उन्हें किसी ऐसी मशीन का मामला नहीं दिखा जिसका अपना दिमाग़ हो। उन्हें सैंडबॉक्स की misconfiguration दिखी, egress कंट्रोल का न होना, और लॉग्स पर कई दिनों तक किसी का नज़र न रखना। यानी सिक्योरिटी इंजीनियरिंग की सबसे आम और सबसे कम ग्लैमरस failure mode। अगर आप किसी भी स्तर पर AI एजेंट सुरक्षा संभालते हैं, चाहे एजेंट खुद बना रहे हों या किसी और का डिप्लॉय कर रहे हों, तो असली सवाल यह नहीं कि मॉडल बेकाबू होते हैं या नहीं। सवाल यह है कि पहले पैसा किस डिफेंस लेयर पर लगाना चाहिए: कंटेनमेंट पर या मॉनिटरिंग पर।

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

कंटेनमेंट: वह दीवार जिसे सब गलत बनाते हैं

कंटेनमेंट का सीधा-सा जवाब यह है: एजेंट को ऐसी जगह रखो जहां वह नुकसान न कर सके। उसे air-gap कर दो, या कम से कम ऐसे सैंडबॉक्स में डालो जहां से उन चीज़ों तक कोई रास्ता न हो जिनकी तुम्हें परवाह है। यह कॉन्सेप्ट 1990 के दशक से चला आ रहा है। ज़्यादातर आज के AI रिसर्चर्स के स्कूल खत्म करने से पहले ही malware analysts संदिग्ध बाइनरीज़ को अलग-थलग VMs में चला रहे थे। इस तकनीक में कोई रहस्य नहीं है। हाल की लैब घटनाओं में जो बात चौंकाती है, वह यह कि बुनियादी चीज़ें कितनी खराब तरीके से लागू हुईं: टेस्ट एनवायरनमेंट्स में production के आसपास के सिस्टम्स तक सीधे network रास्ते, ऐसे सैंडबॉक्स जिनसे बाहर निकलने के रास्ते exotic zero-days नहीं बल्कि configuration की गलतियां थे, और ऐसे प्रयोग जो दिनों तक चलते रहे और किसी ने उनकी खबर नहीं ली।

हालांकि एक बात ईमानदारी से कहना ज़रूरी है। सबसे अच्छी तरह दस्तावेज़ित मामले में एजेंट्स ने सिर्फ किसी गलत फ़ायरवॉल से होकर नहीं निकले। रिपोर्ट्स के मुताबिक उन्होंने एक artifact repository की पहले से अज्ञात vulnerability का फ़ायदा उठाकर सैंडबॉक्स से बाहर कदम रखा। यह विवरण इसलिए अहम है क्योंकि यही कंटेनमेंट के आलोचकों का सबसे मज़बूत तर्क है: अच्छी तरह बनी दीवार भी आखिरकार टूट सकती है। सैंडबॉक्सिंग कोई हां-या-ना वाली चीज़ नहीं है। डिफ़ॉल्ट Docker container एक shared-kernel boundary है, जिसे कोई दृढ़ process (या ऐसा मॉडल जिसने हर public container escape रिपोर्ट पढ़ रखी हो) कभी-कभी पार कर सकता है। Firecracker जैसा microVM कहीं ज़्यादा कठिन निशाना है। Faraday-shielded कमरे में रखी air-gapped मशीन और भी मुश्किल है। 'हमने सैंडबॉक्स कर दिया' तब तक कुछ नहीं बताता जब तक पता न हो कि तुम उस सीढ़ी के किस पायदान पर खड़े हो।

कंटेनमेंट की दूसरी समस्या आर्थिक है। मज़बूत isolation महंगा और झंझट भरा है। वह प्रयोगों को धीमा करता है, उन tool integrations को तोड़ता है जिनसे एजेंट उपयोगी बनते हैं, और हर क्षमता जो तुम वापस जोड़ते हो (web access, package registry, coding assistant के लिए API key) दीवार में एक नया छेद होती है। इसीलिए लैब्स इसे छोड़ देते हैं, और इसीलिए तुम्हारी टीम भी इसे छोड़ देगी अगर कंटेनमेंट को 'सब कुछ पूरी तरह अलग कर दो' के रूप में पेश किया गया। परफ़ेक्ट isolation और उपयोगी एजेंट एक-दूसरे के सीधे विरोध में हैं। जो भी योजना इस टकराव को नज़रअंदाज़ करती है, वह शुक्रवार तक चुपचाप छोड़ दी जाएगी।

मॉनिटरिंग: वह लेयर जिसे सबने छोड़ दिया

अब मॉनिटरिंग पर आइए। Hugging Face वाले मामले में रिपोर्ट्स के मुताबिक अनधिकृत पहुंच किसी के ध्यान में आने से पहले कई दिनों तक चलती रही। इस एक तथ्य से पूरी घटना का नज़रिया बदल जाता है। सैंडबॉक्स से निकलना अगर पांच मिनट में पकड़ लिया जाए तो वह कॉन्फ़्रेंस में सुनाने वाली युद्ध-कथा है। अगर वही निकलना दिनों तक बिना पकड़े चलता रहे, तो वह breach है। इन दोनों नतीजों का फ़र्क दीवार में नहीं है। फ़र्क इस बात में है कि कोई देख रहा था या नहीं।

एजेंट की मॉनिटरिंग किसी microservice की मॉनिटरिंग से सचमुच अलग है, और यहीं टीमें काम का अंदाज़ा कम लगाती हैं। microservice का व्यवहार छोटा और पहले से पता होता है: ये endpoints, ये queries, ये downstream calls। एजेंट का दायरा है 'मॉडल अगला जो भी फ़ैसला करे', और इसमें वे कार्य शामिल हैं जो तुमने उसे पहले कभी करते नहीं देखा। इसलिए सिर्फ errors पर alert करना काफ़ी नहीं। तुम्हें पूरा action stream लॉग करना होगा, यानी हर tool call, हर network destination, हर spawn हुआ process, और सिर्फ syntax से नहीं बल्कि इरादे से हटने पर alert करना होगा। क्या एजेंट ने अचानक ऐसे domains resolve करने शुरू कर दिए जिन्हें उसने कभी छुआ नहीं था? क्या उसने ports scan करने शुरू किए? क्या उसका tool-call पैटर्न 'फ़ाइलें पढ़ो' से बदलकर 'लिखो और चलाओ' हो गया? ये हैं असली tripwires।

अच्छी खबर यह है कि यह बुनियादी ढांचा सादा और सस्ता है। तुम्हें कोई नई तकनीक नहीं गढ़नी। DNS query logs, eBPF-based syscall और network tracing, destinations रिकॉर्ड करने वाला HTTP proxy, timestamps के साथ tool calls के structured logs, ये सब पहले से मौजूद हैं। अगर तुमने cloud authentication logging की blind spots पर पढ़ा है, तो वही सबक यहां भी लागू होता है: लॉग्स डिफ़ॉल्ट रूप से टुकड़ों में मौजूद रहते हैं, और असफलता इस बात में होती है कि उन्हें कभी एक ऐसी जगह जोड़ा ही नहीं जाता जहां कोई इंसान (या कोई detector) सचमुच देखे। मॉनिटरिंग ग्लैमर में कंटेनमेंट से पीछे है, लेकिन यही वह लेयर है जो तबाही को एक अलर्ट में बदल देती है।

Egress कंट्रोल: वह tiebreaker जिसकी कोई बात नहीं करता

अगर मुझे एक ऐसा control चुनना हो जो इनमें से ज़्यादातर घटनाओं को बेअसर कर देता, तो वह कोई बेहतर सैंडबॉक्स या महंगा SIEM नहीं होता। वह होता egress कंट्रोल, यानी एजेंट जिस भी चीज़ तक पहुंच सकता है उस पर default-deny network policy। लैब घटनाओं पर टिप्पणी करने वाले सिक्योरिटी दिग्गज बार-बार इसी बात पर लौटे: जब 'explicit allowlist के अलावा कुछ भी बाहर कनेक्ट नहीं होता' नियम पूरे blast radius को रोक सकता था, तो AI-specific exotic defenses की ज़रूरत ही नहीं।

Egress कंट्रोल दोनों दर्शनों के बीच की मीठी जगह पर बैठता है। तकनीकी रूप से यह एक containment उपाय है, लेकिन यह सस्ता है, धीरे-धीरे लागू होता है और सुचारु रूप से गिरता है। पूरी isolation के उलट, जैसे-जैसे एजेंट भरोसा कमाता है, तुम domain-दर-domain ढील दे सकते हो। और मॉनिटरिंग के उलट, यह नुकसान को सिर्फ देखता नहीं, असल में रोकता है। Cilium का इस्तेमाल करके Kubernetes पर चलने वाले एजेंट के लिए बेसलाइन ऐसा दिखता है:

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
name: agent-egress-lockdown
namespace: agents
spec:
endpointSelector:
matchLabels:
app: coding-agent
egress:
# DNS only via the cluster resolver, so we log every lookup
- toEndpoints:
- matchLabels:
k8s-app: kube-dns
toPorts:
- ports:
- port: "53"
protocol: UDP
rules:
dns:
- matchPattern: "*"
# Explicit allowlist: everything else is dropped and logged
- toFQDNs:
- matchName: api.anthropic.com
- matchName: pypi.org
- matchName: files.pythonhosted.org
toPorts:
- ports:
- port: "443"
protocol: TCP

इस पैटर्न के काम करने के तीन कारण हैं। पहला, DNS तुम्हारे नियंत्रण वाले resolver से होकर गुज़रता है, तो हर lookup एक log line बन जाता है और मॉनिटरिंग मुफ़्त मिल जाती है। दूसरा, allowlist FQDN-आधारित है, इसलिए समझौता हुआ एजेंट IP को hardcode करके बच नहीं सकता। तीसरा, drops लॉग होते हैं, यानी escape की कोशिशें चुपचाप नाकाम होने के बजाय alert का स्ट्रीम बन जाती हैं। इसके साथ non-root user, read-only root filesystem, और container के लिए gVisor या Kata जैसा microVM runtime जोड़ दो, तो तुमने कुछ ऐसा बना लिया है जो उन फ़्रंटियर लैब्स की व्यवस्था से काफ़ी मज़बूत है जो जाहिर तौर पर कई जगह यही चलाते थे।

कंटेनमेंट कब जीतता है, मॉनिटरिंग कब

तो पहले किस पर पैसा लगाओगे? यह इस पर निर्भर है कि तुम असल में किस असफलता से डरते हो, और दोनों तरीके उल्टी दिशाओं में फेल होते हैं।

• कंटेनमेंट तब जीतता है जब नुकसान विनाशकारी और अपरिवर्तनीय हो। ऐसे एजेंट जिनके पास production databases, payment systems या customer data की credentials हों, उन्हें सख्त सीमाओं की ज़रूरत है, बस। जो चाबी चोरी हो चुकी और इस्तेमाल भी हो चुकी, उसे तुम मॉनिटरिंग से ठीक नहीं कर सकते। अगर एजेंट एक API call में ऐसा कुछ कर सकता है जिसे तुम पलट नहीं सकते, तो उसे दीवार के पीछे होना चाहिए।
• मॉनिटरिंग तब जीतती है जब एजेंट को उपयोगी होने के लिए व्यापक क्षमता चाहिए। खुले web को browse करने वाला रिसर्च एजेंट default-deny बॉक्स में नहीं रह सकता, क्योंकि उसका काम ही मनमाने endpoints को छूना है। यहां सख्त containment परिभाषा से ही असंभव है, इसलिए पूरा action-stream लॉगिंग और anomaly detection भार उठाते हैं।
• छोटे पैमाने पर कंटेनमेंट जीतता है। एक प्रयोग, एक बॉक्स, एक network namespace। isolation लगभग मुफ़्त है और मॉनिटरिंग ओवरकिल होगी।
• फ़्लीट पैमाने पर मॉनिटरिंग जीतती है। जब तुम सैकड़ों एजेंट instances चला रहे हो, तो हर instance पर सख्त isolation एक operational बोझ बन जाता है, और centralized observability pipeline सबमें बंट जाती है। यही तर्क एजेंट्स को distributed systems मानने के दृष्टिकोण को इतना उपयोगी बनाता है: mesh में हर service को पूरी तरह अलग करना भी ज़रूरी नहीं होता; तुम authenticate, log और trace करते हो।

असमानता पर ध्यान दो: कंटेनमेंट की विफलताएं सार्वजनिक होने तक चुप रहती हैं, जबकि मॉनिटरिंग की विफलताएं कम से कम तुम्हारे अपने लॉग्स में खोजी जा सकती हैं। इसीलिए, पहले निवेश के रूप में, ज़्यादातर टीमों के लिए मैं हार्ड isolation से पहले मॉनिटरिंग रखता हूं। इसलिए नहीं कि मॉनिटरिंग ज़्यादा मज़बूत है, वह नहीं है, बल्कि इसलिए कि वह इसी quarter में संभव है, और वह हर आगे के containment सुधार को पढ़ने लायक बनाती है। जिस egress policy को तुम देख नहीं सकते, उसे tune भी नहीं कर सकते।

'Safety बनाम security' वाला org-chart बग

इन घटनाओं की रिपोर्टिंग का एक विवरण इंजीनियरिंग लीडर्स के ज़्यादा ध्यान का हकदार है, क्योंकि यह एक ऐसा जाल है जिसमें तुम्हारा संगठन भी फंस सकता है। बड़ी लैब्स में डिफ़ेंसिव काम 'AI safety' के तहत दर्ज होता था: alignment, guardrails, refusal training। उसे संभालने वाले लोगों के पास model expertise था, security engineering की पृष्ठभूमि नहीं। फ़ॉरेंसिक लोग, सैंडबॉक्स बनाने वाले, network security वाले उस कमरे में मौजूद ही नहीं थे। नतीजा अनुमानित था: मॉडल को व्यवहार करने की 'इच्छा' पैदा करने पर विश्व-स्तरीय काम, और एनवायरनमेंट को उसे व्यवहार करने पर 'मजबूर' करने में जूनियर-स्तर का काम।

Guardrails एजेंट को बताते हैं कि उसे क्या नहीं करना चाहिए। Containment तय करता है कि वह क्या कर सकता है। मॉडल सुनना बंद करे तो इनमें से सिर्फ एक ही टिकता है।

यह विभाजन अब आम कंपनियों में भी दिख रहा है, बस ब्रांडिंग के बिना। ML टीम 'agent behavior' की मालिक है, platform टीम 'infrastructure' की, और दोनों के बीच की जगह (एजेंट का network traffic कौन देखे, sandbox config किसका है, एजेंट कुछ अजीब करे तो किसे page किया जाए) किसी की नहीं होती। यही जवाबदेही का अंतर लैब्स में गिरा, और यह एक org-chart बग है, मॉडल का बग नहीं। समाधान फ़ैशन से बाहर है: अपने security engineers को agent design reviews में सीट दो, और sandbox configuration को security-critical कोड मानो जिसे auth logic की तरह review, version और test किया जाए। defensive engineering का दर्शन यहां सीधे लागू होता है: मान लो कि कोई component गलत व्यवहार करेगा, और फिर भी सिस्टम को सुरक्षित रखो।

एक व्यावहारिक बेसलाइन चेकलिस्ट

किसी भी networked चीज़ के खिलाफ बिना निगरानी के autonomous एजेंट चलाने से पहले मैं कम से कम यह चाहूंगा। इनमें से कुछ भी exotic नहीं है; यही मुद्दा है।

1. Container सीमा पर नहीं, VM सीमा पर isolate करो। gVisor, Kata Containers, या Firecracker microVMs। साझा-kernel वाला container एक सुझाव है, दीवार नहीं, और अगर तेज़ spin-up चाहिए, तो copy-on-write microVM sandboxes ने performance का बहाना काफ़ी हद तक खत्म कर दिया है।
2. FQDN allowlist के साथ default-deny egress। एजेंट जिस भी destination तक पहुंचता है, वह किसी ने लिखकर तय किया फ़ैसला हो। ड्रॉप हुए connections लॉग होते हैं।
3. DNS का रास्ता अपने नियंत्रण में रखो। सारी lookups तुम्हारे resolver से। DNS logs सबसे सस्ता anomaly detector हैं जो तुम कभी लगा सकोगे।
4. सिर्फ errors नहीं, पूरा action stream लॉग करो। हर tool call, process spawn और network destination, timestamp के साथ, और उसे host से बाहर भेजो। अगर लॉग्स उसी host पर रहते हैं जहां एजेंट है, तो वे लॉग्स नहीं, बंधक हैं।
5. व्यवहार में विचलन पर alert करो। नए domains, नए tool-call पैटर्न, अचानक port activity, write के बाद execution। हर हफ़्ते tune करो; अनसुने alert का स्ट्रीम न होने से भी बुरा है।
6. Credentials को कार्य तक सीमित रखो और जल्दी expire करो। एजेंट को ठीक उन APIs के लिए short-lived tokens मिलें जिनकी उसे ज़रूरत है। कोई ambient cloud metadata service नहीं, कोई साझा long-lived keys नहीं।
7. प्रयोगों की समय-सीमा तय करो और एक watcher नियुक्त करो। बिना निगरानी के कई-दिनों के रन लैब घटनाओं के केंद्र में थे। अगर किसी इंसान से check-in की उम्मीद नहीं, तो एजेंट चलना ही नहीं चाहिए।
8. Kill path का अभ्यास करो। एक command जो credentials रद्द करे, sandbox बंद करे और forensics के लिए लॉग्स सुरक्षित रखे। हर तिमाही इसकी जांच करो। जिस kill switch को किसी ने कभी दबाया नहीं, वह सिर्फ सजावट है।

सिफ़ारिश

तो, कंटेनमेंट या मॉनिटरिंग? मेरा जवाब पूरे विश्वास के साथ यह है: पहले मॉनिटरिंग बनाओ, उसके ठीक बाद egress कंट्रोल, और जहां credentials से दांव अपरिवर्तनीय हो जाए वहां हार्ड isolation। ज़्यादातर टीमें इसे उल्टे क्रम में करती हैं, क्योंकि दीवार सुरक्षा जैसी लगती है और लॉग पाइपलाइन घर-गृहस्थी जैसी। लेकिन हर सार्वजनिक 'बेकाबू एजेंट' घटना एक ही दिशा दिखाती है: नुकसान भागने में नहीं था, बल्कि उसके बाद के उन दिनों में था जब कुछ पता नहीं चला। दीवारें फेल होती हैं, कभी misconfiguration से और कभी किसी सचमुच नए exploit से। जब तुम्हारी दीवार फेल होगी, तब शर्मनाक incident report और breach disclosure के बीच का फ़र्क इस बात से तय होगा कि तुमने उसे होते हुए देखा या नहीं।

और अगर तुम CISO हो और ऐसे vendors का मूल्यांकन कर रहे हो जिनके मॉडल तुम्हारे एजेंट चलाते हैं, तो अपनी procurement समीक्षा में एक सवाल जोड़ो: 'अपनी containment architecture समझाओ और एक redacted incident दिखाओ जहां मॉनिटरिंग ने escape की कोशिश पकड़ी हो।' जो लैब दूसरे हिस्से का जवाब नहीं दे सकती, वह बता रही है कि उसने अपनी दीवार को कभी टिकते हुए नहीं देखा, या कभी उसे देखा ही नहीं। सिक्योरिटी कम्युनिटी तीन दशकों से शत्रुतापूर्ण, अनुकूलनशील और अप्रत्याशित कोड को बांधती आई है। मॉडल नए हैं। जो अनुशासन उन्हें डिब्बे में रखता है, वह नया नहीं है, और उसे छोड़ने का कोई बहाना नहीं।