Your AI wants to nuke your database. Guardrails fix that.

Article original : blog.railway.com Lire en 🇫🇷 via Google Translate

Auteur: Railway
Thème: IA
Mots-clés: AI agents, database, guardrails, API tokens, infrastructure security
Ton: opinion

Résumé

Un agent IA a effacé une base de production hébergée sur Railway en utilisant un token API longue durée stocké localement sur la machine d'un utilisateur. L'API a fait son travail — authentification valide, mutation volumeDelete exécutée — exactement comme elle l'aurait fait pour un script CI. Railway profite de l'incident pour repenser son architecture autour du présupposé que les agents accèdent désormais à tout : suppressions différées par défaut, permissions de tokens granulaires, sauvegardes automatiques, et nouvelles "surfaces" pensées pour les agents. La leçon : tant qu'on construit les API comme si seuls des humains ou des CI les appelaient, on aura des incidents.

💡 Pourquoi ça compte

L'incident Railway est l'archétype de ce qui attend toutes les plateformes : les contrats d'API conçus pour humains et CI ne survivront pas aux agents. Cette fiche documente comment un acteur sérieux fait son examen de conscience public — un modèle utile pour qui travaille sur de l'infra ou des plateformes internes exposées à des agents.

Analyse approfondie

Si vous étiez sur X ou Hacker News ces derniers jours, vous avez probablement vu le post à propos d'un agent IA qui a effacé une base de production. C'est la nouvelle réalité dans laquelle nous vivons : nous donnons à nos agents IA le contrôle de tout. C'est un peu comme l'histoire de "Son of Anton" dans une certaine série TV, où l'IA part en vrille et efface tout le code. Sauf que cette fois, elle a pris les données avec.

Nous avions un client dont la base de données était hébergée sur Railway. Au cœur du post se trouvait cette commande :

curl -X POST https://backboard.railway.app/graphql/v2 \
  -H "Authorization: Bearer [token]" \
  -d '{"query":"mutation { volumeDelete(volumeId: \"3d2c42fb-...\") }"}'

La requête était authentifiée, et notre API l'a honorée de la même manière qu'elle l'aurait fait pour une commande CLI ou un pipeline CI. La différence, c'est qu'elle venait d'un agent IA. L'agent a trouvé un token Railway stocké localement sur la machine de l'utilisateur et s'en est servi pour appeler volumeDelete sur un volume de production. Nous avons depuis récupéré la base de données et le client est revenu en ligne avec toutes ses données.

L'ironie amère, c'est que nous avions déjà construit beaucoup de primitives pour ce genre de cas. L'agent les a simplement contournées en passant directement par l'endpoint legacy. Parlons de comment c'est arrivé, et de comment avancer rapidement et en sécurité avec les agents sur Railway.

Suppressions différées — désormais dans l'API Railway

Notre API a toujours fonctionné comme suit : on s'authentifie, on appelle une mutation, la mutation s'exécute. C'est le contrat sur lequel les pipelines CI et les scripts de déploiement se sont reposés, et c'est aussi le contrat que l'agent dans cette affaire a fini par utiliser. Il a trouvé un token longue durée sur disque, frappé l'endpoint GraphQL, et obtenu la même réponse qu'un job CI aurait obtenue.

Avec les suppressions différées, la mutation s'exécute, mais la ressource n'est pas immédiatement effacée — elle reste récupérable pendant plusieurs jours. C'est invisible pour les usages normaux (CI qui supprime une preview branch, par exemple), mais ça change tout en cas d'erreur d'agent.

Permissions granulaires sur les tokens

Avant, un token avait accès à tout dans le scope du projet. Désormais, on peut limiter un token à des actions spécifiques (lecture seule, déploiement, mais pas suppression). Si un agent doit lire les logs et redéployer, il n'a pas besoin de pouvoir tout effacer.

Sauvegardes empilées

Sauvegardes automatiques activées par défaut, snapshots avant les opérations destructrices, et politique de rétention pensée pour absorber les incidents agents.

Réessayer — en sécurité

L'idée centrale est que l'environnement par défaut doit être réversible. Si l'agent fait une erreur, l'opération doit pouvoir être annulée sans intervention manuelle compliquée.

Construire des surfaces pour les agents

Au-delà des correctifs, Railway repense l'API pour les agents : endpoints spécifiquement pensés pour les workflows agentiques, scopes de permissions clairs, et un modèle de "permission ladder" où l'agent demande explicitement les capacités dont il a besoin.

Où ça va

Le futur, ce sont des plateformes qui présupposent les agents. Pas seulement des API tolérantes aux agents, mais des API conçues pour que l'agent fasse son travail vite tout en gardant les humains dans la boucle pour les actions destructrices ou irréversibles.