Laisser un agent IA déployer votre application, sans risque

Donner à un agent de codage un accès en écriture à la production semble imprudent jusqu’à ce qu’on regarde ce dont il a vraiment besoin au quotidien : vérifier qu’un déploiement est bien sorti, lire les 100 dernières lignes de log, redémarrer un processus bloqué, parfois définir une variable d’environnement. Presque tout ça est en lecture seule. La petite partie qui ne l’est pas devrait quand même exiger qu’un humain dise oui.

C’est exactement la forme que prend le serveur Model Context Protocol de Railyard, pas une rustine ajoutée après coup sur une API conçue pour autre chose.

Connecter un agent

Railyard fait tourner un serveur MCP à https://app.railyard.run/api/mcp, en streamable HTTP, authentifié avec les mêmes jetons API que la CLI et l’API REST utilisent déjà. Créez-en un sous Settings → Team → API tokens, et choisissez read si l’agent ne doit faire que consulter :

claude mcp add --transport http railyard https://app.railyard.run/api/mcp \
  --header "Authorization: Bearer rly_..."

Cursor, ou n’importe quel autre client MCP qui parle streamable HTTP et peut envoyer un en-tête Authorization, se connecte de la même façon — pointez-le vers l’URL, passez le jeton.

Ce que le jeton permet vraiment

La liste d’outils est volontairement courte : list_servers, list_apps, get_app et app_logs sont en lecture seule. deploy_app, restart_app et set_env demandent un jeton en écriture. C’est toute la surface pour le travail quotidien d’un agent — rien sur les serveurs, les domaines ou les bases de données n’est exposé ici; ça passe toujours par l’API REST ou la CLI, volontairement hors de portée de l’agent par défaut.

La limite de permission, c’est le jeton, pas une consigne dans le prompt. Un agent avec un jeton en lecture ne peut physiquement rien déployer, peu importe ce qu’on lui demande ou ce qu’il décide de lui-même — aucune instruction ne peut convaincre un jeton en lecture seule de faire une action en écriture.

La partie qui attend votre accord

Deux outils — unset_env et delete_app — sont marqués approval, même avec un jeton en écriture. Aucun des deux ne s’exécute quand l’agent les appelle. À la place, une demande apparaît sur la page Approvals de l’équipe, visible depuis le tableau de bord, et rien ne change tant qu’un admin de l’équipe n’a pas approuvé. Approuver exécute l’action et enregistre le résultat; rejeter l’abandonne simplement.

C’est là que se trouve la vraie limite : un agent peut déployer votre application, la redémarrer et ajuster son environnement tout seul, parce que ce sont des actions récupérables — un mauvais déploiement se retire, un redémarrage n’est qu’un redémarrage. Supprimer une variable ou une application ne se récupère pas de la même façon, donc ça attend une personne, à chaque fois, peu importe comment le jeton a été configuré.

Les déploiements qu’un agent lance passent toujours par les mêmes règles d’approbation et la même limite de fréquence que l’application a déjà — même chose qu’un déploiement lancé depuis le tableau de bord ou un git push : l’agent n’a pas un chemin plus rapide ou plus permissif que vous.

De bonnes habitudes, pas seulement de bons réglages par défaut

• Donnez à chaque agent son propre jeton avec une date d’expiration, et révoquez-le une fois la tâche terminée plutôt que de laisser traîner une longue durée de vie dans la configuration d’un agent.
• Par défaut, utilisez un jeton en lecture pour les agents qui répondent surtout à des questions (« pourquoi ce endpoint est-il lent? ») et ne donnez l’écriture que quand le travail de l’agent l’exige vraiment.
• Traitez la page Approvals comme une vraie étape de revue, pas un tampon automatique — elle existe parce que unset_env et delete_app sont les deux actions de cette liste qu’on ne défait pas facilement.

Référence complète des outils et des portées de jeton : MCP pour les agents IA.