GitHub MCP के दुरुपयोग से MCP के जरिए private repository तक पहुंच

 (invariantlabs.ai)
3 पॉइंट द्वारा GN⁺ 2025-05-28 | 2 टिप्पणियां | WhatsApp पर शेयर करें
  • व्यापक रूप से इस्तेमाल किए जाने वाले GitHub MCP integration में एक गंभीर vulnerability मिली है, जिसके जरिए हमलावर एक malicious GitHub Issue के माध्यम से उपयोगकर्ता के agent को manipulate कर private repository का डेटा leak कर सकते हैं
  • this vulnerability को Toxic Agent Flow नाम के एक नए प्रकार के रूप में पहचाना गया है, जिसमें agent malicious prompt के कारण अनचाहा डेटा public repository में उजागर कर देता है
  • यह vulnerability टूल की अपनी खामी नहीं, बल्कि architecture की सीमा से पैदा होती है, और साधारण user-confirmation policy जैसी व्यावहारिक उपयोग आदतें जोखिम को और बढ़ाती हैं
  • प्रभावी बचाव के लिए granular permission control और continuous security monitoring जैसे व्यवस्थित agent protection उपाय अपनाना जरूरी है
  • केवल model alignment से काम नहीं चलेगा, इसलिए MCP और पूरे agent environment में system-level security measures महत्वपूर्ण हैं

अवलोकन

Invariant ने व्यापक रूप से इस्तेमाल किए जाने वाले GitHub MCP integration (14,000 stars) में एक बेहद गंभीर vulnerability खोजी है। यह vulnerability हमलावर को malicious GitHub Issue बनाकर उपयोगकर्ता के agent को manipulate करने और private repository का डेटा बाहर leak करने में सक्षम बनाती है

यह समस्या Invariant के automated Toxic Agent Flow detection scanner द्वारा पहली बार पकड़ा गया मामला है। ऐसे scenario में agent को अनचाहा व्यवहार करने के लिए प्रेरित किया जाता है, जिससे data leak या malicious code execution जैसी क्षति हो सकती है

हाल के समय में industry में coding agents और IDE का बड़े पैमाने पर adoption हो रहा है, इसलिए ऐसे हमलों के प्रति जागरूकता बढ़ाना इस समय बेहद महत्वपूर्ण है

attack scenario

  • हमले की तैयारी

    • मान लें कि उपयोगकर्ता ने Claude Desktop जैसे MCP client को GitHub MCP server से जोड़ा हुआ है
    • <user>/public-repo: public repository, जहाँ कोई भी Issue बना सकता है
    • <user>/private-repo: private repository, जिसमें कंपनी का internal data आदि रखा है
    • हमलावर public repository में malicious Issue बनाता है, जिसमें prompt injection शामिल है
    • जब उपयोगकर्ता “public-repo के issue list दिखाओ” जैसे सामान्य अनुरोध करता है, तो agent public repository के Issue लाते समय injection के संपर्क में आ जाता है

  • हमले का प्रवाह

    • जैसे ही agent malicious Issue पढ़ता है, वह private repository का डेटा context में लाता है और उसे public repository में PR के रूप में बना देता है, जिससे वह किसी के लिए भी accessible हो जाता है
    • इस प्रक्रिया को Toxic Agent Flow कहा गया है, और Invariant के security analyzer से इसे वास्तविक environment में अपने-आप detect किया जा सकता है

हमले का प्रदर्शन

  • उदाहरण के तौर पर public repository (ukend0464/pacman) और private repositories के साथ हमले को पुन: निर्मित किया गया
  • हमलावर public repository में malicious Issue बनाता है, और जब agent उस repository के issue list को fetch करता है, तो prompt injection चल पड़ता है
  • जब उपयोगकर्ता Claude 4 Opus से support request करता है, तो Claude GitHub MCP integration के जरिए injection को execute करता है
    • Claude Desktop डिफ़ॉल्ट रूप से tool use पर confirmation मांगता है, लेकिन कई उपयोगकर्ता "Always Allow" policy पर काम करते हैं और अनजाने में इसे स्वीकार कर लेते हैं
  • agent private repository का डेटा निकालकर public PR के रूप में उजागर कर देता है
  • प्रयोग में private project name, relocation plan, salary जैसी sensitive जानकारी तक leak हुई

Toxic Agent Flows की पहचान

  • यह vulnerability तब भी हो सकती है जब मौजूदा MCP tool खुद compromise न हुआ हो, क्योंकि external platform (GitHub) से आया untrusted data इसका कारण बनता है
  • बड़े agent systems में ऐसे जोखिमों का analysis और mitigation हाथ से करना बहुत जटिल है, इसलिए Invariant ने automated detection method विकसित किया है ताकि proactive threat analysis संभव हो सके

प्रभाव का दायरा और प्रतिक्रिया उपाय

  • यह vulnerability किसी एक खास agent/client तक सीमित नहीं है, बल्कि MCP server इस्तेमाल करने वाले सभी agents को प्रभावित करती है
  • यह GitHub MCP server code की bug नहीं, बल्कि design-level issue है, इसलिए GitHub server patch से इसका समाधान संभव नहीं है
  • दो मुख्य प्रतिक्रिया रणनीतियाँ प्रस्तावित की गई हैं

1. granular permission control

  • MCP integration environment में agent को केवल उन्हीं repositories तक पहुँच दी जानी चाहिए जिनकी उसे वास्तव में जरूरत है; इसके लिए least privilege principle लागू करना जरूरी है
  • पारंपरिक token-based authorization अकेले usability के लिहाज से सीमित है
  • Invariant Guardrails जैसी dynamic runtime security layer workflow context के अनुसार access control को मजबूत बना सकती है
    • उदाहरण policy: प्रति session केवल एक repository की access की अनुमति देकर cross-repository data leak रोका जाए
    • policy definition का उदाहरण: 
      raise Violation("You can access only one repo per session.") if:
    (call_before: ToolCall) -> (call_after: ToolCall)
    call_before.function.name in (...set of repo actions)
    call_after.function.name in (...set of repo actions)
    call_before.function.arguments["repo"] != call_after.function.arguments["repo"] or
    call_before.function.arguments["owner"] != call_after.function.arguments["owner"]
    • Guardrails Playground आदि में policy experiments किए जा सकते हैं

2. continuous security monitoring

  • preventive measures के अलावा, agent और MCP system के बीच interaction को real time में scan करने वाले मजबूत monitoring tools की जरूरत है
  • उदाहरण: Invariant MCP-scan को अपनाकर monitoring और anomaly detection किया जा सकता है
  • नवीनतम proxy mode का उपयोग करके, मौजूदा infrastructure बदले बिना केवल MCP traffic को proxy के जरिए reroute कर real-time diagnosis किया जा सकता है
  • comprehensive monitoring के माध्यम से vulnerability detection, intrusion attempt logging, और malicious flow को शुरुआती चरण में रोका जा सकता है

केवल model alignment पर्याप्त क्यों नहीं है

  • नवीनतम large language models (जैसे Claude 4 Opus) भी साधारण prompt injection attack के सामने आसानी से exposed हो जाते हैं
  • केवल बुनियादी alignment training से वास्तविक deployment environment में मौजूद विविध और context-dependent हमलों को पूरी तरह नहीं रोका जा सकता
  • इसलिए system level पर context-aware detection और security framework को model layer से अलग बनाना अनिवार्य है

निष्कर्ष

  • Invariant ने GitHub MCP server में malicious GitHub Issue के जरिए agent को कब्जे में लेकर private repository को leak कराने वाली गंभीर vulnerability को प्रमाणित किया है
  • यह vulnerability Invariant की automated detection system द्वारा खोजे गए प्रमुख मामलों में से एक है, और MCP सहित विभिन्न environments में ऐसे हमले लगातार सामने आ रहे हैं
  • MCP-scan और Guardrails जैसे dedicated security scanners के जरिए MCP/agent systems को सुरक्षित रूप से लागू और संचालित करना अहम है

संदर्भ और संपर्क

  • अतिरिक्त security implementation या consulting की जरूरत होने पर earlyaccess@invariantlabs.ai पर संपर्क किया जा सकता है

लेखक:
Marco Milanta
Luca Beurer-Kellner

संबंधित पढ़ाई

2 टिप्पणियां

 
crawler 2025-05-28

बात बड़ी लगती है, लेकिन असल में यह सिर्फ prompt injection + MCP के इस्तेमाल कर सकने वाले अधिकार बहुत ज़्यादा होने से पैदा हुई समस्या है।
इसलिए यह ऐसा लगता है जैसे बाहरी रूप से MCP permissions को नियंत्रित कर सकने वाले टूल का प्रचार किया जा रहा हो।
अगर बाहर से आने वाले prompts और केवल अंदर से दिए जाने वाले prompts के लिए MCP जिन permissions का इस्तेमाल कर सकता है, उन्हें अलग रखा जाए तो अच्छा होगा।
 
GN⁺ 2025-05-28
Hacker News राय

  • मुझे लगता है कि यह हमला पूरी तरह समझा नहीं गया है। अगर आप Claude को access token देते हैं, तो चाहे आप उसे किसी भी उपयोग के लिए निर्देश दें, उसे इस तरह प्रेरित किया जा सकता है कि वह उस token की permissions के भीतर कुछ भी कर सके। अगर आप किसी LLM को credentials देते हैं, तो मानकर चलना चाहिए कि उन credentials की सारी permissions LLM इस्तेमाल कर सकता है। अगर tool-use calls को auto-allow किया गया हो, तो खास तौर पर सावधान रहना चाहिए। लेकिन GitHub में finely scoped access tokens होते हैं, इसलिए अगर केवल किसी खास repository तक access दिया जाए, तो LLM के दुरुपयोग की सीमा सीमित रहती है। यह हमला तभी संभव है जब LLM के पास पूरे account का access हो, और Claude को इतने जोखिमभरे credentials देना ही असली समस्या है

    • इस विषय का अहम हिस्सा यह है कि, ज़्यादातर prompt injection हमलों की तरह, LLM को ऐसे माहौल में रखा जाता है जहाँ उसे हमलावर-नियंत्रित data, sensitive information, और data exfiltration capability जैसे कम से कम तीन में से दो चीज़ों तक एक साथ access मिल जाता है। agent design का बुनियादी सिद्धांत यह होना चाहिए कि एक समय में अधिकतम दो ही अनुमति हों, और सिस्टम को इसी नियम पर डिजाइन करना चाहिए ताकि security issues रोके जा सकें। उदाहरण के लिए, जैसे ही आप किसी अविश्वसनीय व्यक्ति द्वारा बनाई गई issue देखते हैं, LLM का context पहले ही attacker द्वारा बनाए गए data से दूषित हो चुका होता है। उसके बाद अगर उसे sensitive information तक access दिया जाए, तो internet connection जैसी capabilities बंद कर देनी चाहिए। इस मॉडल का पालन करें तो repository-per-token के बिना भी सुरक्षित रहा जा सकता है। दुर्भाग्य से MCP में इसे सुनिश्चित करने के लिए कोई tool नहीं है

    • token permissions के बहुत व्यापक सेट होने की समस्या है, लेकिन साथ ही developers भी हर repository के लिए अलग token खुला नहीं रखना चाहते। इसलिए वे token को बहुत व्यापक permissions दे देते हैं और LLM पर बिना शर्त भरोसा कर लेते हैं। यह सावधानी समझदारी भरी है, लेकिन व्यवहार में ecosystem के कई खिलाड़ी ऐसा नहीं करते। इस report का महत्व इसी में है कि यह सिखाती है कि अगर LLM के पास permissions और untrusted data दोनों हों, तो कुछ भी hijack किया जा सकता है। समाधान यह है कि token के उपयोग-क्षेत्र को dynamically सीमित किया जाए। हम इस सूची में इसी तरीके पर शोध कर रहे हैं

    • यह Railway जैसी services में होने वाली समस्या है। Railway कभी-कभी एक ही project deploy करने के लिए पूरे GitHub repository access की मांग करता है, जबकि Netlify इस बात का सम्मान करता है कि आप केवल चुनी हुई repositories को permission दें। GitHub को ऐसे apps की approval ही रोक देनी चाहिए जो access scope का सम्मान नहीं करते

    • हर नई technology के आने पर यही चीज़ बार-बार होती है। जैसे लोग यह भ्रम पाल लेते हैं कि बुनियादी security principles को नए context में नज़रअंदाज़ किया जा सकता है। सच यह है कि चाहे कोई भी 'चमकदार' नई technology इस्तेमाल करें, basic security principles को कभी नज़रअंदाज़ नहीं करना चाहिए। crypto की दुनिया में भी पुराने fraud और financial crimes फिर से दोहराए गए, क्योंकि लोगों ने यह सोचकर पुराने सबक भुला दिए कि technology अलग है

    • अगर chatbot users के साथ interact करता है, तो यह मानकर चलना चाहिए कि chatbot अपनी अनुमति-सीमा के भीतर कुछ भी कर सकता है। chatbot बस API के ऊपर एक convenience layer है, अपने आप में कोई security mechanism नहीं

  • अगर MCP और agent security में रुचि है, तो इस पर हमारे कई materials हैं। पूरे attack scenario का Claude execution trace(लिंक), MCP connections के लिए security scanner(लिंक), MCP tool poisoning attacks(ब्लॉग), WhatsApp MCP exploit case(ब्लॉग), agents के लिए security layer Guardrails(ब्लॉग), और AI agents की security व utility का संयुक्त मूल्यांकन करने वाला AgentDojo(ब्लॉग) देख सकते हैं

  • मुझे संदेह है कि इसे सच में 'exploit' कहना चाहिए या नहीं। अगर आप agent को ऐसा token देते हैं जिससे वह private repositories तक पहुंच सकता है, तो वह पहुंच पाएगा ही। MCP बस एक API server है। जिसे API के जरिए expose नहीं करना चाहते, उसे permission भी नहीं देनी चाहिए

    • बहुतों की तरह मैंने भी लेख पढ़ने से पहले comments देख लिए। असली article पढ़ने पर पता चलता है कि GitHub पर एक malicious issue डाली जाती है, और उसी issue में ऐसा prompt होता है जो LLM को data exfiltration के लिए उकसाता है। जब repository owner agent को trigger करता है, तो agent इस malicious prompt के अनुसार काम करने लगता है

    • यह इंसानी गलती (या अति-आत्मविश्वास) का फायदा उठाने वाला एक असली exploit है। समस्या यह है कि लोग hype में आकर निजी, संवेदनशील, पूरे GitHub access वाले tokens बेझिझक LLM को दे देते हैं

    • यह विषय महत्वपूर्ण है इसलिए थोड़ा चुभते हुए कहना चाहता हूँ कि AI tool execution के जोखिम को सभी को सही तरह समझना चाहिए। agents अभी अपने मौजूदा attention(context) के आधार पर tools चलाते हैं, और यह attention tool execution results या prompts से आसानी से प्रभावित हो जाती है। लेकिन comments में बस यही दोहराया जा रहा है कि “token दिया इसलिए हुआ।” ऊपर से, समस्या को ठीक से समझाने के बाद भी बार-बार “user ने permission दी थी” कहकर मुद्दे को धुंधला किया जा रहा है, जो निराशाजनक है। यह 'confused deputy' समस्या पर एक क्लासिक गलत तर्क है। और लोग 'user responsibility' की बात करते हैं, जबकि असल समस्या यह भी है कि MCP में post-access control या logging जैसी चीज़ें नहीं हैं। मैं तो तभी सहज महसूस करूंगा जब logging अनिवार्य हो। साथ ही, security research को नज़रअंदाज़ करके उसे “common sense” कहकर खारिज करना भी सही नहीं। security की बात करना हमेशा उपयोगी है। किसी vulnerability के कमजोर होने का मतलब यह नहीं कि उस पर चर्चा न की जाए। इसे 'SQL injection' जैसा भी कहा जा सकता है। और यह न समझना कि सिस्टम को परोक्ष रूप से दूषित किया जा सकता है—जैसे public issue के जरिए malicious code पहुँचाना—खतरनाक है। आखिर में, लोगों को रक्षात्मक रवैये के बजाय नए विचारों के लिए खुला होना चाहिए, लेकिन ऐसा नहीं दिख रहा

  • security के नज़रिए से, जब LLM किसी अविश्वसनीय source के text को देखता है, तो यह मानना चाहिए कि वह source LLM के output generation को अपनी इच्छा के मुताबिक नियंत्रित कर सकता है। अगर उसका नतीजा tool call तक जाता है, तो अब वह untrusted source भी उस tool का उपयोग कर सकता है। इस बारे में पढ़ते हुए मुझे लगा कि invariant labs की Guardrails docs में marketing का पहलू भी है। यह सोचना ही डरावना है कि security के लिहाज़ से structure इतना जटिल है कि ऐसे guardrail products की ज़रूरत पड़ती है। काश AI कंपनियाँ शुरुआत से security-first design करतीं, तो शायद ऐसे products की ज़रूरत ही न पड़ती

    • सिर्फ input separation ठीक से कर देने पर यह आसान समस्या है। prompt में <github_pr_comment> जैसे tags लगाकर mark कर दें, उसे हमेशा read-only data की तरह इस्तेमाल करें, और साफ लिखें कि इसे कभी command की तरह interpret न किया जाए। यह attack दरअसल structure की दृष्टि से थोड़ा जटिल है। पुराने chatbot prompt injection issues की याद दिलाता है। अब MCP भी issue बन रहा है

    • सोचता हूँ कि क्या कुछ text को untrusted(impure) data के रूप में mark करके LLM को इस तरह train किया जा सकता है कि वह उस हिस्से के command-जैसे अर्थ को नज़रअंदाज़ करे

    • वास्तव में AI कंपनियाँ security design को ध्यान में रखती हैं। लेकिन यह 'exploit' केवल तब संभव है जब security को disable किया गया हो(और वह भी मोटी चेतावनी के साथ)। उदाहरण के लिए Claude Desktop डिफ़ॉल्ट रूप से हर tool call के लिए सीधी approval मांगता है। लेकिन बहुत से users “always allow” सेट कर देते हैं और हर action को monitor नहीं करते

    • इस तरह के software vulnerability patterns परंपरागत रूप से बार-बार आते रहे हैं, और नई technologies में भी इन्हें देखना एक साथ दिलचस्प और बेतुका लगता है। “user input लो, उसे कमज़ोर तरीके से सुरक्षित environment में command की तरह interpret करो और execute कर दो” — यह pattern बार-बार लौटता है। SQL injection, XSS, PHP include वगैरह में जो कहानी देखी थी, वही अब LLM में दोहराई जा रही है

  • मुझे नहीं लगता कि MCP अपने आप में revolutionary है या hacking के लिए खास तौर पर अधिक vulnerable है(हालाँकि MCP पर मेरी अलग राय है)। यह prompt injection techniques की marketing wrapping जैसा लगता है। जब मैं agent systems design करता हूँ, तो हमेशा एक सिद्धांत अपनाता हूँ: “जिस चीज़ तक agent की पहुँच है, वह agent तक पहुँच रखने वाले किसी भी व्यक्ति की पहुँच में समझी जानी चाहिए।” मैं access control LLM पर नहीं छोड़ता, और साफ रखता हूँ कि agent जो काम करता है उसकी security responsibility हमेशा request करने वाले principal की होती है। इस पूरे लेख में, शुरुआत से अंत तक, असली सवाल यह है कि agent को वास्तव में किन resources तक access दिया जाए। अगर उसे email data access दिया जाए, और prompt injection वाला email LLM को security token चुराकर भेजने के लिए उकसा दे, तो वही वास्तव में गंभीर जोखिम है

    • MCP की बात जोड़ना वैसा ही लगता है जैसे 10 साल पहले “इसे blockchain पर डाल दिया” कहना ट्रेंड था। “क्योंकि LLM approval और action का agent है, इसलिए least privilege principle को बहुत सख्ती से लागू करना चाहिए” — यह बात अनुभवी लोगों के लिए बहुत सामान्य है, लेकिन शायद हर नई पीढ़ी को ये basics फिर से सीखने पड़ते हैं

  • असली attack case और agent की प्रतिक्रिया यहाँ देखी जा सकती है। इसमें थोड़ा हास्यास्पद पहलू यह है कि agent ने attack को पूरी तरह सफल कर दिया

  • मैंने भी एक हफ्ते पहले Google's Jules coding agent आज़माया था, और GitHub OAuth permission request ने account के अंदर सभी repositories और permissions पर व्यापक access मांगा। यह design शायद developer convenience के कारण है, और GitHub OAuth auth flow भी इसकी वजह है। ideally repository-level restricted permissions देना और बाद में अतिरिक्त permissions मांगना आसान होना चाहिए। लेकिन हकीकत में लोगों को केवल चुनी हुई repositories के लिए अलग GitHub account बनाना पड़ता है(उदाहरण account)। यह बेहद झंझटभरा है। GitHub की official docs भी ऐसे machine users अलग से बनाने की सलाह देती हैं, लेकिन default repository scoping ज्यादा आसान होना चाहिए। अगर किसी को बेहतर तरीका पता हो तो ज़रूर बताना चाहिए

    • GitHub settings page पर Jules की permissions को specific repositories तक सीमित किया जा सकता है

  • मुझे इस लेख का दावा बहुत बढ़ा-चढ़ाकर किया हुआ लगता है। यह कहना कि एक simple issue से data exfiltration हो गया, जबकि असलियत में user को पहले कई security-wise जोखिमभरे कदम खुद उठाने पड़ते थे। यानी MCP server सेट करना, public/private repo दोनों तक पहुँच वाले credentials देना, LLM को उस server तक पहुँच और repository issues पढ़ने की अनुमति देना, फिर malicious issue को पढ़ना, और बाहरी जगह result publish करने की क्षमता देना — तब जाकर यह संभव हुआ। नतीजा बुरा है, लेकिन इसे “किसी तीसरे पक्ष द्वारा किया गया सक्रिय security exploit” कहना सही नहीं लगता। यह ज़्यादा उस स्थिति का परिणाम है जहाँ user ने खुद untrusted data पढ़वाया और परिणाम untrusted जगह भेजने की छूट दी। फिर भी GitHub MCP की कुछ जिम्मेदारी बनती है। public/private repositories के बीच cross-handling को न रोकना एक समस्या है

    • मूल बात यह है कि “issues का सारांश बना दीजिए” जैसे साधारण निर्देश से भी malicious issue में छिपे निर्देश लागू हो सकते हैं, इसे नज़रअंदाज़ नहीं करना चाहिए

    • MCP का marketing angle भी महत्वपूर्ण है। protocol खुद में ऐसे trustworthy environments या users के लिए अलग-थलग होना चाहिए जिनकी पहुँच नियंत्रित हो। MCP servers के लिए scoping या authentication का कोई standard तरीका न होना समस्या है। मुझे GitHub MCP से ज्यादा हमारी industry की overall usage/implementation practices में बुनियादी समस्या लगती है। व्यवहार में custom MCP servers चलाते समय लोग AI के अलावा अतिरिक्त information(ID, JWT आदि) भी पास करते हैं ताकि security gating हो सके

    • मौजूदा AI hype की वजह से, सच तो यह है कि बहुत लोग ऐसे खतरनाक configurations और flows बिना सोचे-समझे अपना रहे हैं। आप कह सकते हैं “ऐसी चीज़ें इस्तेमाल ही नहीं करनी चाहिए,” लेकिन यही वजह है कि guardrails ज़रूरी हैं। लोग अक्सर जोखिमभरे फैसले लेते हैं

    • public/private repositories को mix न करने की बात करें तो, व्यवहार में यह पूरी तरह अलग tool calls हैं। MCP server के दृष्टिकोण से उस interaction का पता लगाने का कोई तरीका नहीं है

  • अभी यह चर्चा उस HN thread में चल रही है, यह मैंने अभी देखा

    • वहाँ भी पहले ही कहा जा चुका है कि security risk बिल्कुल स्पष्ट है। यानी अगर आप किसी system को private data तक access देते हैं और बाहरी users को arbitrary input text डालने की अनुमति भी देते हैं, तो आप परोक्ष रूप से बाहरी users को private data तक पहुँच का रास्ता दे रहे हैं। standard security practices अपनाकर इसे आसानी से रोका जा सकता है

    • वर्तमान comments अब यहाँ स्थानांतरित होकर एकत्रित हो रहे हैं

  • MCP सिर्फ एक protocol है, और A2A जैसे समान मामले या और भी primitive approaches बहुत हैं। आप LLM से GitHub API docs पढ़वाकर token के साथ API इस्तेमाल करने को भी कह सकते हैं। अभी सभी LLMs में यह स्तर नहीं आया है, लेकिन जल्द आ जाएगा। tool registration mechanism को पूरी तरह secure करना व्यवहार में लगभग असंभव है। data exfiltration की अंतिम जिम्मेदारी आखिरकार LLM पर ही आती है। developers LLM से productivity gains चाहते हैं, इसलिए या तो safety की गारंटी देनी होगी, या फिर हालात ऐसे हो सकते हैं कि हर laptop में security firewall जोड़नी पड़े। सबसे परेशान करने वाली बात यह है कि भविष्य में शायद “बुरा व्यवहार करने वाले LLM को पकड़ने वाला LLM” बनाम “security firewall का दुरुपयोग करने वाला LLM” जैसा टकराव भी देखने को मिले