Gérer l'infrastructure avec des agents IA via MCP

Opfield dispose d'un serveur MCP à côté de son API REST. N'importe quel client MCP, qu'il s'agisse d'un agent de code dans votre éditeur ou d'une application de chat, peut s'y connecter et travailler avec les mêmes ressources qu'une personne voit dans l'interface : routes, conteneurs, bases de données gérées, Pages, alertes et nœuds. Cet article explique comment cet accès reste sûr et à quoi ressemble une session type.

Les mêmes règles que pour une personne

Les agents n'ont pas de modèle de droits à part. Un client MCP se connecte à https://<your-opfield>/api/mcp et s'authentifie en OAuth au nom d'un utilisateur. Sur l'écran de consentement, l'utilisateur choisit les scopes accordés au client, et ceux-ci ne dépassent jamais ses propres droits. Un accès limité à des dossiers, des nœuds ou des ressources précises fonctionne de la même façon : un agent qui a accès au dossier d'une application ne voit que ce dossier. L'agent peut appeler get_my_access pour savoir ce qui lui a été accordé et où il peut créer des ressources.

Les agents peuvent faire presque tout ce qu'une personne fait avec les ressources. Quelques actions restent volontairement réservées au navigateur : l'usurpation d'identité, le consentement OAuth, la création de jetons d'API ou d'autorisations, ainsi que la connexion et les sessions de l'utilisateur lui-même. Un agent ne peut pas s'accorder plus de droits.

Le point d'accès MCP n'accepte que les jetons OAuth émis pour lui ; les jetons de l'API REST n'y fonctionnent pas. L'utilisateur doit aussi disposer du droit MCP : c'est donc un administrateur qui décide qui peut connecter des agents.

Tout est dans le journal d'audit

Chaque action d'un agent passe par les mêmes contrôles qu'un clic dans l'interface et s'inscrit dans le même journal d'audit, avec l'utilisateur et le jeton d'origine. Pour savoir ce qu'un agent a changé pendant la nuit, il suffit d'ouvrir le journal d'audit.

Des garde-fous contre les erreurs

Les droits définissent ce qu'un agent peut faire. Mais certaines erreurs arrivent dans le cadre de ces droits, alors Opfield ajoute des garde-fous :

• Garde-fou de console. Les agents peuvent exécuter des commandes en root dans la console d'un nœud, ce qui leur permet de le réparer. Docker, containerd et Podman y sont masqués, et une commande Docker est refusée avec le nom de l'outil Opfield à utiliser. C'est un garde-fou contre les erreurs, pas une frontière de sécurité : il évite qu'un agent modifie un conteneur géré dans le dos d'Opfield.
• Pas de SSH vers les nœuds. Les agents ne peuvent pas exécuter de commandes en SSH sur des hôtes qui sont des nœuds Opfield. Ils passent par la console du nœud, qui a son garde-fou.
• Les changements hors d'Opfield sont visibles. Si un conteneur géré est malgré tout arrêté, modifié ou supprimé à la main, l'alerte intégrée « Container changed outside Opfield » se déclenche.
• Des nouvelles tentatives sans risque. Les opérations de création acceptent une clé d'idempotence : un agent qui réessaie après un délai dépassé ne crée pas de doublon.

Des outils Docker plutôt qu'un shell

L'essentiel du travail d'un agent sur les charges de travail passe par des outils dédiés plutôt que par des commandes shell : lister les conteneurs de tous les nœuds Docker, lire les logs et les métriques, redémarrer, mettre à jour une image, modifier la configuration, gérer les déploiements avec slots et retour arrière, les projets Compose, les volumes, les réseaux et les sources Git avec leurs builds. Comme ce sont des opérations Opfield, les routes, les Secure Links et la disponibilité restent cohérents après un changement, et chaque étape est auditée.

Les agents peuvent aussi lire la documentation et les skills d'Opfield via MCP avant de modifier quoi que ce soit.

Exemple : un service en panne

Un utilisateur écrit à un agent : « L'API de facturation renvoie des 502 depuis ce matin. Trouve pourquoi et corrige. » Une session type :

1. find_resource trouve la route et le conteneur derrière elle ; get_route montre l'upstream.
2. get_docker_container montre que le conteneur redémarre en boucle et que sa source Git a déployé un nouveau build à 07:40.
3. get_docker_container_logs montre que le processus s'arrête au démarrage : une nouvelle variable d'environnement obligatoire manque.
4. L'agent le signale et propose deux options : revenir au build précédent ou ajouter la variable.
5. L'utilisateur choisit le retour arrière. L'agent appelle manage_docker_source avec rollback, puis vérifie à nouveau les logs et la route : le conteneur tourne et la route répond 200. Le retour arrière figure dans le journal d'audit au nom de l'utilisateur.

Personne n'a eu besoin d'un accès shell au serveur, et l'agent n'a rien fait en dehors des droits de l'utilisateur.

Pour commencer

Ajoutez le serveur MCP dans votre client avec l'adresse de votre Opfield, connectez-vous et choisissez les scopes. Commencez par des scopes en lecture seule, regardez dans le journal d'audit ce que fait l'agent, et élargissez l'accès à mesure que la confiance s'installe. Si vous préférez ne pas configurer de client, l'assistant intégré à Opfield utilise les mêmes outils et les mêmes règles.