La Cloud Native Computing Foundation a publié cette semaine un guide avec un argument spécifique pis important pour quiconque déploie des charges LLM sur Kubernetes : les primitives d'infrastructure que K8s fournit (routage, isolation réseau, RBAC au niveau pod, gestion de secrets) sont nécessaires mais pas suffisantes pour la sécurité LLM. L'observation de fond, c'est qu'un LLM, c'est pas une charge de calcul sans état. C'est un système qui accepte de l'entrée non fiable pis décide quoi faire avec, incluant s'il doit invoquer des outils, émettre des données sensibles, ou suivre des instructions qui apparaissent à l'intérieur de son prompt. Ce modèle de menace, c'est pas le même que « conteneurise ce microservice pis isole-le », pis ça demande des contrôles qui vivent à la couche application pis prompt, pas à la couche cluster.
La liste spécifique de la CNCF sur ce que Kubernetes peut pas faire est utile. Kubernetes peut pas déterminer si un prompt devrait être laissé passer jusqu'au modèle, si une réponse contient des données sensibles qui devraient être caviardées avant d'atteindre un utilisateur, ou si le modèle devrait avoir accès à un outil particulier pour une requête particulière. La couche d'infrastructure gère le routage pis l'isolation de pods. La couche application doit gérer l'authentification, l'autorisation, la validation d'entrée, le filtrage de sortie, les décisions d'accès aux outils, pis la journalisation d'audit de ce que le modèle a vraiment fait. Le OWASP Top 10 pour applications LLM, c'est la meilleure liste de contrôle actuelle des modes de défaillance auxquels les contrôles au niveau application doivent s'adresser : injection de prompt, divulgation d'information sensible, attaques de chaîne d'approvisionnement, empoisonnement de données pis de modèles, manipulation impropre de sortie, agence excessive, fuite de prompt système, faiblesses de vecteurs pis d'embeddings, désinformation, pis consommation non bornée. Si ton déploiement LLM a pas de contrôles explicites pour chacun de ces items, le fait qu'il roule sur un cluster Kubernetes sécurisé le rend pas sécurisé.
Ça correspond au patron plus large de 2026 qui traverse les pièces couvertes ici toute la semaine : la couche de gouvernance pour les charges agent pis LLM devient une catégorie de première classe, séparée de la couche modèle pis séparée de la couche infrastructure. Agent Registry d'AWS livre la version catalogue-pis-audit en entreprise de ça ; la CNCF publie la version en standards ouverts pour quiconque opère une infrastructure LLM basée sur Kubernetes. Le programme Kubernetes AI Conformance s'étend plus tard en 2026 pour inclure des standards Sovereign AI, ce qui se rattache directement au Sovereign AI Fund britannique pis au patron de souveraineté plus large à travers l'industrie. Pour les constructeurs qui veulent déployer des LLM dans des environnements régulés ou auto-hébergés, le chemin open-source K8s-plus-AI-conformance est une vraie option qui te laisse contourner le verrouillage des hyperscalers tout en obtenant une vraie structure de sécurité. Pour les entreprises engagées sur un hyperscaler, Agent Registry d'AWS avec Bedrock AgentCore, c'est la version gérée. Les deux piles vont concurrencer sur les mêmes dollars d'approvisionnement entreprise.
Pour les équipes qui roulent des charges LLM sur Kubernetes, trois gestes suivent. Premièrement, audite ton déploiement actuel contre le OWASP Top 10 pour applications LLM ; si t'as pas des contrôles nommés pour chacun des dix items, commence par ceux qui couvrent la validation d'entrée, le filtrage de sortie, pis l'autorisation d'accès aux outils, parce que ceux-là ferment la plus grande surface d'attaque. Deuxièmement, sépare la posture de sécurité d'infrastructure de la posture de sécurité au niveau application dans ta documentation interne ; un audit de conformité qui dit « notre cluster K8s est CIS-benchmarké », c'est pas la même chose que « notre déploiement LLM est sûr en production », pis les deux appartiennent à des équipes différentes avec des compétences différentes. Troisièmement, surveille le programme CNCF AI Conformance pour le reste de 2026 ; les standards Sovereign AI qui viennent plus tard cette année vont probablement devenir l'architecture de référence de facto pour les déploiements LLM en industrie régulée, pis être en avance sur cette spec vaut plus que rattraper après qu'elle sort. Pour les équipes sur des piles gérées par hyperscalers, les mêmes principes s'appliquent avec des noms de produits différents : Bedrock, Vertex AI, pis Azure AI Foundry ont toutes des surfaces équivalentes de contrôle au niveau application qui doivent être configurées, pas présumées.