Cloud Native Computing Foundation ने इस हफ़्ते Kubernetes पर LLM वर्कलोड्स को परिनियोजित करने वालों के लिए एक विशिष्ट, महत्वपूर्ण तर्क वाली guidance प्रकाशित की: K8s जो infrastructure primitives देता है (routing, network isolation, pod-level RBAC, secrets management) वे आवश्यक हैं लेकिन LLM security के लिए पर्याप्त नहीं। नीचे की observation यह है कि LLM एक stateless compute workload नहीं है। यह एक ऐसा सिस्टम है जो अविश्वसनीय input स्वीकार करता है और उसके साथ क्या करना है यह तय करता है, जिसमें शामिल है कि tools invoke करे या नहीं, संवेदनशील data उत्सर्जित करे या नहीं, या अपने prompt के अंदर दिखाई देने वाले निर्देशों का पालन करे या नहीं। यह threat model "इस microservice को containerize करो और isolate करो" से भिन्न है, और इसे application व prompt परत पर रहने वाले नियंत्रण चाहिए, cluster परत पर नहीं।
Kubernetes क्या नहीं कर सकता, इसकी CNCF की विशिष्ट सूची उपयोगी है। Kubernetes यह निर्धारित नहीं कर सकता कि एक prompt को मॉडल तक पहुँचने दिया जाए या नहीं, क्या एक response में संवेदनशील data है जिसे उपयोगकर्ता तक पहुँचने से पहले redact किया जाना चाहिए, या क्या मॉडल को किसी विशेष request के लिए किसी विशेष tool तक पहुँच होनी चाहिए। Infrastructure परत routing और pod isolation सँभालती है। Application परत को authentication, authorization, input validation, output filtering, tool-access निर्णय, और मॉडल ने वास्तव में क्या किया इसका audit logging सँभालना होता है। OWASP Top 10 for LLM Applications उन failure modes का सबसे अच्छा वर्तमान checklist है जिन्हें application-स्तर के नियंत्रणों को सम्बोधित करना होता है: prompt injection, संवेदनशील जानकारी का प्रकटीकरण, supply chain हमले, data और model poisoning, improper output handling, excessive agency, system prompt leakage, vector और embedding कमज़ोरियाँ, misinformation, और unbounded consumption। यदि आपके LLM परिनियोजन में इन दस items में से प्रत्येक के लिए स्पष्ट नियंत्रण नहीं हैं, तो यह तथ्य कि यह एक सुरक्षित Kubernetes cluster पर चलता है, इसे सुरक्षित नहीं बनाता।
यह 2026 के उस बड़े pattern में फ़िट होता है जो इस हफ़्ते यहाँ कवर की गई पीसेज़ में से गुज़रा: agent और LLM वर्कलोड्स के लिए governance परत एक प्रथम-श्रेणी श्रेणी बन रही है, मॉडल परत से अलग और infrastructure परत से अलग। AWS Agent Registry इसका enterprise-catalog-और-audit संस्करण भेजता है; CNCF Kubernetes-आधारित LLM infrastructure चलाने वाले किसी के लिए open-standards संस्करण प्रकाशित कर रहा है। Kubernetes AI Conformance कार्यक्रम 2026 में बाद में Sovereign AI standards शामिल करने के लिए विस्तारित हो रहा है, जो सीधे UK Sovereign AI Fund और इंडस्ट्री में व्यापक sovereignty pattern से जुड़ता है। विनियमित या self-hosted परिवेशों में LLMs परिनियोजित करना चाहने वाले निर्माताओं के लिए, open-source K8s-plus-AI-conformance पथ एक वास्तविक विकल्प है जो आपको hyperscaler lock-in से बचने देता है और साथ ही वास्तविक सुरक्षा-संरचना देता है। Hyperscaler-प्रतिबद्ध उद्यमों के लिए, Bedrock AgentCore के साथ AWS Agent Registry प्रबंधित संस्करण है। दोनों stacks उसी enterprise procurement dollars के लिए प्रतिस्पर्धा करेंगे।
Kubernetes पर LLM वर्कलोड्स चलाने वाली टीमों के लिए, तीन क़दम आते हैं। पहला, अपने वर्तमान परिनियोजन का OWASP Top 10 for LLM Applications के विरुद्ध audit करिए; यदि आपके पास दसों items में से प्रत्येक के लिए नामित नियंत्रण नहीं हैं, तो उनसे शुरू करिए जो input validation, output filtering, और tool-access authorization को कवर करते हैं, क्योंकि वे सबसे बड़ी attack surface बन्द करते हैं। दूसरा, अपनी आंतरिक documentation में infrastructure security posture को application-layer security posture से अलग करिए; एक compliance audit जो कहता है "हमारा K8s cluster CIS-benchmarked है" वह "हमारा LLM परिनियोजन production-safe है" जैसी बात नहीं है, और दोनों अलग-अलग skill sets वाली अलग टीमों के अधीन आते हैं। तीसरा, 2026 के शेष में CNCF AI Conformance कार्यक्रम पर नज़र रखिए; इस वर्ष बाद में आने वाले Sovereign AI standards सम्भवतः विनियमित-उद्योग LLM परिनियोजनों के लिए de-facto reference architecture बन जाएँगे, और उस spec पर जल्दी होना बाद में पकड़ने से अधिक मूल्यवान है। Hyperscaler-प्रबंधित stacks वाली टीमों के लिए, वही सिद्धांत भिन्न उत्पाद नामों के साथ लागू होते हैं: Bedrock, Vertex AI, और Azure AI Foundry सभी के पास समकक्ष application-स्तर नियंत्रण-सतहें हैं जिन्हें configure करना होता है, माना नहीं जा सकता।