Créer des agents IA sécurisés avec kagent sur Kubernetes

Les développeurs peuvent désormais exécuter kagent, un projet CNCF Sandbox, sur leurs ordinateurs portables locaux pour créer des agents IA qui fonctionnent comme des ressources Kubernetes. Publié le 12 octobre 2026 par Antonio Berben et Felipe Vicens, ce guide démontre comment créer un constructeur d'agents capable de générer d'autres agents en toute sécurité. Le processus repose sur des garde-fous stricts plutôt que sur une confiance implicite envers le grand modèle de langage.

Ce qui s'est passé

L'article détaille un laboratoire étape par étape pour configurer un constructeur d'agents à l'aide de kagent. Au lieu de traiter les agents comme des processus autonomes, kagent les définit comme des ressources personnalisées dans Kubernetes. Cette approche permet à un agent existant de générer des manifestes YAML pour de nouveaux agents, créant ainsi efficacement un constructeur en libre-service. La configuration utilise des outils open source tels que Docker, kind, kubectl, helm, jq et Ollama afin de minimiser les coûts et d'éviter les dépendances au cloud.

Une partie cruciale de la configuration consiste à sécuriser le serveur d'outils. Par défaut, les charts kagent pourraient accorder des privilèges cluster-admin, ce qui est dangereux même pour des tests locaux. Le guide demande aux utilisateurs de restreindre les permissions afin que l'agent constructeur ne puisse créer que des types de ressources spécifiques. Cela garantit que les agents générés opèrent dans un périmètre défini, empêchant tout accès non autorisé à des composants sensibles du cluster, tels que les secrets ou les déploiements.

La démonstration passe en revue l'installation de l'infrastructure nécessaire, la sélection d'un modèle local performant et l'interaction avec le constructeur via une interface utilisateur ou une API. L'objectif est de montrer que la création d'agents n'est pas de la magie, mais une tâche d'ingénierie structurée. Elle souligne que si la configuration initiale est simple, le véritable défi réside dans la gestion de la gouvernance et de la sécurité lorsque ces agents dépassent le cadre d'un seul environnement portable.

Comment cela fonctionne

Le système repose sur trois couches distinctes de sécurité qui ne dépendent pas uniquement du prompt. Premièrement, une liste blanche limite les outils visibles par le modèle. Sur vingt-deux outils disponibles, le constructeur n'en accède qu'à trois. Deuxièmement, un mécanisme humain-in-the-loop (HITL) exige l'approbation de l'utilisateur avant toute exécution d'outil modifiant l'état. Lorsque l'agent propose une modification, l'exécution est suspendue, permettant à l'utilisateur de vérifier le manifeste exact avant son application. Troisièmement, le contrôle d'accès basé sur les rôles (RBAC) au niveau de Kubernetes garantit que, même si un manifeste est approuvé, le serveur API rejette toute action sortant des permissions du compte de service.

L'agent constructeur fonctionne en recevant une requête en langage naturel, telle que la création d'un agent pour les équipes de support. Il génère ensuite un manifeste Kubernetes pour une nouvelle ressource Agent. Ce manifeste inclut un prompt système, une configuration de modèle et un ensemble restreint d'outils en lecture seule. Le constructeur n'exécute pas directement la création ; il produit plutôt le YAML pour révision. Une fois approuvé, le contrôleur kagent applique le manifeste, lançant un nouveau pod qui communique via le protocole Agent-to-Agent (A2A).

Cette architecture traite les prompts comme des demandes plutôt que comme des garanties. L'application réelle des règles provient de l'infrastructure. Par exemple, si le modèle hallucine un nom d'outil ou tente de créer un déploiement au lieu d'un agent, la liste blanche ou les politiques RBAC bloquent l'action. Cette séparation des responsabilités garantit que les erreurs de sortie du modèle n'entraînent pas de violations de sécurité ni de modifications involontaires du cluster.

Détails clés

• Le modèle local recommandé est qwen3-coder:30b-a3b, car les modèles plus petits échouent souvent à générer des manifestes Kubernetes valides.
• Le constructeur utilise une liste blanche de trois outils parmi les vingt-deux disponibles sur le serveur pour limiter ses capacités.
• Une approbation humaine est requise pour tout appel d'outil modifiant l'état, offrant un point de contrôle avant l'exécution.
• Les politiques RBAC limitent le compte de service du constructeur à la création exclusive de ressources Agent, bloquant l'accès aux secrets ou aux déploiements.
• La configuration utilise kind pour le cluster Kubernetes et Ollama pour l'inférence locale du modèle afin de minimiser les coûts.
• L'interface utilisateur s'exécute sur localhost via kubectl port-forward, garantissant qu'elle n'est pas exposée à Internet public lors des tests.

Pourquoi c'est important

Pour les ingénieurs logiciels et les responsables techniques, cette approche déplace l'attention de l'ingénierie des prompts vers la conception de l'infrastructure. Se reposer uniquement sur les prompts pour la sécurité est insuffisant, car les modèles peuvent mal comprendre les instructions ou halluciner des noms d'outils. En intégrant la sécurité dans la couche Kubernetes, les équipes peuvent construire des agents robustes face aux erreurs du modèle. Cette méthode fournit une piste d'audit claire et des limites applicables, essentielles pour les environnements de production.

L'article met également en évidence le fossé entre l'expérimentation locale et la gouvernance d'entreprise. Sur un ordinateur portable, toutes les actions semblent provenir du même utilisateur, rendant difficile le suivi des coûts ou de la propriété. Dans un contexte d'entreprise, plusieurs agents et frameworks peuvent coexister, chacun ayant des postures de sécurité différentes. Cette complexité plaide en faveur d'une couche de gouvernance centralisée qui proxifie le trafic, gère l'authentification et offre une observabilité sur toutes les interactions des agents.

Comprendre ces mécanismes aide les développeurs à passer de simples démos à la construction de systèmes fiables. Cela démontre que les agents IA peuvent être intégrés dans les workflows DevOps existants en utilisant des outils familiers comme YAML et kubectl. Cela abaisse la barrière à l'entrée pour les équipes déjà investies dans Kubernetes, leur permettant de tirer parti de l'IA sans adopter entièrement de nouveaux paradigmes opérationnels.

Ce que vous pouvez faire

• Installez Docker, kind, kubectl, helm, jq et Ollama pour préparer votre environnement local au laboratoire.
• Téléchargez le modèle qwen3-coder:30b-a3b en utilisant Ollama pour garantir une génération fiable de manifestes.
• Créez un cluster kind nommé kagent-builder et installez kagent avec des politiques RBAC restreintes.
• Utilisez kubectl port-forward pour accéder à l'interface utilisateur sur localhost, assurant qu'elle reste isolée d'Internet public pendant les tests.