Laisse tes agents requêter la base,
en lecture seule tant que tu n'en décides pas autrement
AgentsRoom gère tes connexions MySQL, PostgreSQL et MongoDB et donne à tes agents IA de code un moyen d'y lancer des requêtes. Lecture seule par défaut, une instruction à la fois, avec le mot de passe hors de portée.
Un agent qui peut lire les vraies lignes arrête de deviner tes données. Un agent qui ne peut pas les écrire arrête d'être un risque à surveiller ligne par ligne.
Comment AgentsRoom atteint une base dans un sous-réseau privé et répond à une requête en lecture seule venue d'un agent IA.
Un agent IA de code qui ne voit pas tes données écrit du code contre le schéma qu'il a imaginé. Il invente une colonne, suppose qu'un enum a trois valeurs alors qu'il en a sept, et explique un bug avec une théorie au lieu d'une ligne. Lui donner une connexion à la base règle ça, et c'est aussi le moyen le plus rapide de transformer un agent utile en incident. AgentsRoom est construit autour de cette tension.
Tu enregistres tes connexions dans l'app comme dans n'importe quel client de base de données : moteur, hôte, port, utilisateur, base, et TLS quand le serveur l'attend. Si la base n'est pas joignable depuis l'internet ouvert, la connexion passe par un tunnel SSH ou une session de redirection de port AWS SSM, en réutilisant les connexions SSH et SSM déjà enregistrées dans AgentsRoom. C'est comme ça qu'une base posée dans un sous-réseau privé devient quelque chose que tu peux interroger sans l'ouvrir au monde.
Chaque connexion démarre en lecture seule. Un SELECT s'exécute. Une instruction qui modifierait les données, non, tant que tu n'as pas rendu cette connexion précise accessible en écriture et confirmé l'opération. Une seule instruction est acceptée par appel, donc rien ne se cache derrière un point-virgule, et les résultats sont plafonnés pour qu'une requête large ne noie ni un agent ni une fenêtre. Une connexion peut aussi être marquée comme production, ce qui rend la confirmation plus difficile à donner par accident.
Lire n'est pas tout le travail. Une connexion enregistrée sur une machine apparaît sur tes autres machines : tu configures une base une fois, pas une fois par ordinateur. Et une base s'exporte dans un fichier, se restaure depuis un fichier, ou se copie directement sur un autre serveur, à travers les mêmes tunnels : les opérations pour lesquelles tu quittais l'application.
Un client de base de données pensé pour qu'un agent soit aux commandes
MySQL, PostgreSQL et MongoDB, joignables en réseau privé, avec les garde-fous actifs par défaut.
Connexions MySQL, PostgreSQL et MongoDB
Enregistre une connexion par base : hôte, port, utilisateur, la base à ouvrir et TLS quand le serveur l'exige. Ta base locale, celle de staging et le réplica de production vivent dans la même liste, prêtes à être choisies plutôt que retapées.
Atteindre une base privée
Une base dans un sous-réseau privé n'est pas un cas particulier. Fais passer la connexion par un tunnel SSH ou une session de redirection de port AWS SSM et AgentsRoom l'ouvre pour toi, en réutilisant les connexions SSH et SSM déjà enregistrées dans l'app.
Lecture seule par défaut
Une nouvelle connexion peut lire, et rien d'autre. Les requêtes renvoient des lignes, les instructions qui changeraient les données sont refusées. Personne n'a à penser à activer le mode sûr, parce que le mode sûr est le point de départ de chaque connexion.
Deux verrous avant une écriture
Écrire demande deux gestes délibérés, pas un. La connexion doit être rendue accessible en écriture, et l'opération elle-même doit être confirmée explicitement. Un seul clic distrait ne peut pas enchaîner sur un UPDATE sans clause WHERE.
Une instruction par appel
Chaque appel porte exactement une instruction. Tout ce qui est empilé derrière un point-virgule est refusé plutôt qu'exécuté, donc une lecture qui ressemble à une lecture ne peut pas faire passer une seconde instruction avec elle. Les résultats sont plafonnés en plus de ça.
La production est signalée
Marque une connexion comme production et la confirmation devient plus exigeante. La base qui compte cesse de ressembler exactement à la copie locale, autant pour toi en fin de journée longue que pour un agent qui déroule une liste de tâches.
Vos connexions, sur chaque machine
Une connexion enregistrée au bureau est là sur le portable : nom, hôte, port, utilisateur, base par défaut et le tunnel qu'elle emprunte. Seul le mot de passe reste sur place, chiffré sur la machine où vous l'avez saisi, si bien que chaque machine vous le demande une fois.
Exporter, importer, copier
Sortez une base dans un fichier .sql, rejouez un fichier dans une base, ou copiez une base directement sur une autre. La cible est sauvegardée avant d'être écrasée, et la remplacer complètement est une décision distincte, confirmée à part.
Les agents requêtent la base, ils ne détiennent jamais le mot de passe
Tes identifiants de base de données sont stockés par AgentsRoom, pas distribués. Un agent demande à exécuter une requête sur une connexion qu'il connaît par son nom, l'app ouvre la connexion, exécute l'instruction et renvoie les lignes. Le mot de passe ne fait jamais partie de ce que l'agent reçoit, jamais partie de la requête qu'il écrit, et jamais partie de la conversation qu'il conserve.
La règle de lecture seule est la seconde moitié de tout ça, et pour un agent ce n'est pas un défaut dont il pourrait se sortir par la parole. L'outil avec lequel un agent interroge refuse tout ce qui n'est pas une lecture, quoi qu'autorise cette connexion. Rendre une connexion inscriptible débloque les écritures pour toi, dans la console, où chacune demande une confirmation explicite, volontairement plus difficile à donner quand la connexion est marquée production. Le pire résultat d'un agent qui lance une mauvaise requête reste une réponse fausse, pas une table perdue.
La règle d'une seule instruction ferme la faille classique. Un appel qui porte une instruction ne peut pas être prolongé par un point-virgule et une seconde, donc une requête qui paraît inoffensive à la relecture ne peut pas faire autre chose à l'exécution. Combinée aux résultats plafonnés, une erreur reste une erreur au lieu de devenir un export.
Trois moteurs, et on nomme ceux qui manquent
MySQL et MariaDB, PostgreSQL, et MongoDB. Chacun a son propre driver plutôt qu'une couche de traduction, parce qu'ils diffèrent vraiment : une session PostgreSQL est liée à une seule base, MongoDB prend une requête et pas du SQL, et chaque export s'appuie sur les outils livrés avec ce moteur. Les trois joignent un serveur en direct, ou via un tunnel SSH ou une session de redirection de port AWS SSM quand il n'est pas exposé sur l'internet ouvert.
SQL Server, Oracle, SQLite, Redis et les autres ne sont pas supportés. Tu mérites de le savoir avant le téléchargement plutôt qu'après. Le prochain moteur est décidé par ce que les gens demandent : si le tien manque, dis lequel sur le backlog public et il sera compté.
Demander ton moteur de base de donnéesDéplacer une base, pas seulement la lire
Exporte une base vers un fichier. Importe un fichier dans une base. Ou copie une base directement sur une autre, y compris à travers le tunnel SSH ou la session AWS SSM que tu as déjà enregistrée. Chaque moteur s'appuie sur ses propres outils officiels, écrits en flux sur le disque : une base de plusieurs gigaoctets devient une barre de progression, pas un plantage.
Ces outils sont livrés avec la base de données, pas avec AgentsRoom : mysqldump et mysql, pg_dump et psql, mongodump et mongorestore. Quand ils manquent, l'app dit exactement lesquels et te laisse pointer le dossier qui les contient, comme doit le faire un client de base de données : lancée depuis le Dock ou le menu Démarrer, une app ne voit qu'un PATH nu et prétendrait sinon qu'ils sont absents sur une machine qui les a.
C'est sur la copie qu'un mauvais clic coûte une journée : elle est construite autour de ça, pas autour du cas idéal.
- Une connexion en lecture seule refuse l'import d'emblée, avant que quoi que ce soit ne soit ouvert.
- La cible est sauvegardée dans un fichier que tu choisis avant la première instruction appliquée.
- La confirmation nomme la connexion et la base, et le dit plus fort quand la connexion est marquée production.
- Supprimer et recréer la base cible est une option à part, et sur une connexion production tu dois retaper le nom de la base.
D'une base privée à une réponse
Enregistre la connexion, route-la, puis requête-la ou laisse un agent le faire.
Enregistre la connexion
Ajoute la base : hôte, port, utilisateur, le nom de la base, et TLS si le serveur l'attend. Donne-lui un nom que tu reconnaîtras plus tard, et marque-la comme production si c'en est une.
Route-la si elle est privée
Si la base n'est pas joignable directement, fais pointer la connexion vers un tunnel SSH ou une session de redirection de port AWS SSM construite à partir des connexions déjà enregistrées dans AgentsRoom. Une base dans un sous-réseau privé devient joignable sans être exposée publiquement.
Requête-la, ou laisse un agent la requêter
Lance ton instruction depuis l'app, ou laisse un agent en lancer une via MCP. Lecture seule tant que tu n'y touches pas, une instruction par appel, des résultats plafonnés, et une confirmation explicite entre chaque écriture et tes données.
Quand un agent a besoin des vraies lignes
Les moments où lire les données de production est le chemin le plus court vers le correctif.
Déboguer sur de vraies données
Le bug n'apparaît que pour une poignée de comptes. Laisse l'agent lire ces lignes et il trouve la valeur qui casse la logique, au lieu de proposer trois théories sur ce à quoi les données pourraient ressembler.
Une base qui n'est pas publique
La base vit dans un sous-réseau privé, sans point d'entrée public. Fais passer la connexion par un tunnel SSH ou une session AWS SSM construite sur tes connexions enregistrées, et requête-la sans ouvrir un port sur l'internet.
Laisse l'agent vérifier, pas deviner
Avant d'écrire une migration ou une requête, un agent peut regarder ce qui est réellement stocké. Il lit, il rapporte, et il n'obtient jamais au passage la possibilité de changer quoi que ce soit.
La production, sans le risque d'écriture
Lire la production est souvent nécessaire, y écrire ne l'est presque jamais au milieu d'une tâche. Marque la connexion comme production, garde-la en lecture seule, et la différence entre enquêter et casser cesse de dépendre de l'attention de qui que ce soit.
Rafraîchir la préproduction avec de vraies données
Le bug ne se reproduit que sur de vraies lignes. Copie la base sur ton serveur de préproduction, à travers le tunnel déjà enregistré, avec un dump de ce qui s'y trouvait pris avant.
Tu ouvres le portable, tout est là
Tes connexions suivent ton compte : mêmes hôtes, mêmes tunnels, mêmes indicateurs lecture seule et production. Chaque machine demande le mot de passe une fois, parce que c'est la partie qui ne quitte jamais la machine où il a été saisi.
Comment mes agents requêtent-ils la base ?
Via AgentsRoom MCP, avec quatre outils. db_list renvoie tes connexions enregistrées et leurs métadonnées, db_schema parcourt les schémas, les tables et les colonnes sans une ligne de SQL, db_query exécute une instruction et renvoie les lignes, et db_connection_new propose une base que tu n'as pas encore enregistrée. AgentsRoom ouvre la connexion, y compris le tunnel SSH ou la session AWS SSM placée devant quand il y en a une. Ce qui repart vers l'agent, c'est un jeu de résultats, jamais un identifiant.
db_query est en lecture seule quoi qu'autorise la connexion. Rendre une connexion inscriptible débloque les écritures pour toi, dans la console, où chacune est confirmée explicitement et où une connexion marquée production le dit haut et fort. Ça ne les débloque pas pour un agent : la règle de lecture seule de db_query vit dans l'application desktop et non dans le process MCP, donc elle tient même si on convainc l'agent de demander autre chose. Tu n'as pas besoin d'un mot de passe pour lancer un DROP, et c'est pour ça que le garde-fou porte sur l'instruction et pas seulement sur l'identifiant.
La même limite s'applique à l'enregistrement d'une base. db_connection_new ouvre le formulaire de création pré-rempli avec l'hôte, l'utilisateur et la connexion SSH ou AWS SSM par laquelle la base doit être jointe, et c'est toi qui relis, qui tapes le mot de passe et qui enregistres. Rien n'est stocké tant que tu ne l'as pas fait. L'agent obtient ce qu'il lui faut pour raisonner sur tes données, et aucune des façons dont cet accès tourne d'habitude à l'incident ne lui est accessible.
Découvrir AgentsRoom MCPFAQ
Quelles bases de données sont supportées ?
MySQL et MariaDB, PostgreSQL, et MongoDB. Chacun a son propre driver, et chacun est joignable en direct ou via un tunnel SSH ou une session de redirection de port AWS SSM. SQL Server, Oracle, SQLite et les autres ne sont pas supportés aujourd'hui. Si tu as besoin de l'un d'eux, demande-le sur le backlog public : la liste grandit avec ce que les gens demandent réellement.
Un agent IA peut-il écrire dans ma base ?
Non. L'outil MCP avec lequel un agent interroge, db_query, est en lecture seule quoi qu'autorise la connexion : un SELECT, un SHOW ou un EXPLAIN passent, un find ou un aggregate MongoDB aussi, et tout ce qui modifierait des données est refusé. Rendre une connexion inscriptible débloque les écritures pour toi, dans la console, où chacune est confirmée explicitement, pas pour un agent. Le garde-fou porte sur l'instruction et non sur le mot de passe, parce qu'un mot de passe n'est pas ce qu'il faut pour lancer un DROP.
Comment atteindre une base dans un sous-réseau privé ?
Fais passer la connexion par un tunnel SSH ou une session de redirection de port AWS SSM, construite à partir des connexions SSH et SSM que tu as déjà enregistrées dans AgentsRoom. L'app ouvre le tunnel ou la session et y branche la base, donc la base reste injoignable depuis l'internet public.
Mes agents voient-ils le mot de passe de la base ?
Non. Les agents requêtent via MCP en nommant une connexion. AgentsRoom détient les identifiants et exécute l'instruction lui-même, donc le mot de passe n'est jamais renvoyé à l'agent, jamais écrit dans la requête et jamais présent dans la conversation.
Un agent peut-il lancer plusieurs instructions d'un coup ?
Non. Un appel porte exactement une instruction. Tout ce qui est empilé derrière un point-virgule est refusé plutôt qu'exécuté, ce qui supprime la plus vieille façon de cacher une écriture dans quelque chose qui ressemble à une lecture.
Qu'est-ce que ça change de marquer une connexion comme production ?
Ça durcit la confirmation exigée avant une écriture. La base qui compte cesse de se comporter comme la copie locale, ce que tu veux en fin de journée longue et ce que tu veux encore plus d'un agent qui déroule une liste de tâches.
Que se passe-t-il avec une requête qui renvoie beaucoup de lignes ?
Les résultats sont plafonnés. Une requête qui renverrait une table énorme revient tronquée au lieu de noyer la fenêtre ou le contexte de l'agent, donc un SELECT large reste un désagrément plutôt qu'un export de tes données.
Un agent peut-il ajouter une connexion à une base de données ?
Il peut en proposer une, jamais en enregistrer une. db_connection_new ouvre le formulaire de création pré-rempli avec l'hôte, le port, l'utilisateur et la connexion SSH ou AWS SSM par laquelle la base doit être jointe, et c'est toi qui relis, qui tapes le mot de passe et qui enregistres. Rien n'est stocké tant que tu ne l'as pas fait, et l'agent ne fournit jamais d'identifiant.
Comment un agent découvre-t-il mon schéma ?
Avec db_schema, qui explore une connexion enregistrée sans le moindre SQL. Appelé sans argument, il liste les schémas ; avec une base, il liste les tables et les vues ; avec une table, il renvoie les colonnes, leurs types, leur nullabilité, leurs clés et leurs valeurs par défaut. C'est moins coûteux et plus sûr que de faire requêter information_schema à un agent à la main.
Mes connexions aux bases sont-elles synchronisées entre mes machines ?
La connexion oui, le mot de passe non. Le nom, l'hôte, le port, l'utilisateur, la base par défaut, la portée, les indicateurs lecture seule et production ainsi que le tunnel SSH ou SSM emprunté suivent votre compte : une connexion enregistrée sur une machine apparaît sur les autres au lieu d'être ressaisie. Le mot de passe, lui, reste chiffré dans le trousseau de la machine où vous l'avez tapé et ne nous est jamais transmis, et c'est pourquoi une connexion arrivée d'une autre machine est signalée comme attendant son mot de passe avant de pouvoir être ouverte.
Puis-je exporter une base et l'importer ailleurs ?
Oui. Tu peux exporter une base vers un fichier, réimporter ce fichier dans une base, ou copier une base directement sur une autre, y compris à travers les tunnels SSH ou SSM déjà enregistrés. Chaque moteur s'appuie sur ses propres outils officiels (mysqldump et mysql, pg_dump et psql, mongodump et mongorestore), livrés avec la base de données et non avec AgentsRoom : s'ils sont introuvables, l'app te demande de pointer le dossier qui les contient. Une copie ne tourne qu'entre deux connexions du même moteur, puisqu'un dump ne se restaure que dans le moteur qui l'a produit. L'import est refusé sur une connexion en lecture seule, la cible est sauvegardée dans un fichier que tu choisis avant la moindre écriture, et remplacer la cible est une option à part dont la confirmation nomme la base.
Tu pourrais aussi aimer
RDS via AWS SSM
Atteins une instance Amazon RDS sans endpoint public, depuis ta propre machine, via aws ssm start-session et le document AWS-StartPortForwardingSessionToRemoteHost. Pas de bastion à maintenir, pas de VPN, pas de règle SSH entrante. AgentsRoom ouvre la session sur un port loopback et y branche son client de base de données. MySQL, PostgreSQL et MongoDB, donc RDS MySQL, RDS PostgreSQL, Aurora et DocumentDB.
Connexions SSH
Enregistre tes connexions SSH, ouvre un terminal SSH intégré et lance Claude Code, Codex ou Antigravity CLI directement sur ton serveur distant ou ton VPS. Authentification par clé ou mot de passe, profils de connexion par projet, sans client SSH séparé.
Gestionnaire de secrets
Range tes clés d'API, tes tokens et tes mots de passe dans le trousseau de ton système, référence-les avec {{secret:NAME}} dans tes commandes de dev et les environnements de tes agents, et laisse AgentsRoom les résoudre au lancement. Les agents voient les noms, jamais les valeurs, et rien n'est jamais synchronisé vers un serveur.
Terminaux de dev
Gestionnaire de terminaux et lanceur de process par projet. Démarre backend, frontend et workers en un clic, en local ou sur un serveur distant.
AgentsRoom MCP
Le serveur MCP qui laisse tes agents piloter AgentsRoom lui-même : projets, terminaux, backlog et connexions, avec les garde-fous qui vont avec.
Donne à tes agents les données, pas les clés
Télécharge AgentsRoom, enregistre tes connexions MySQL, PostgreSQL et MongoDB, atteins-les via un tunnel SSH ou une session AWS SSM, et laisse tes agents les interroger en lecture seule.
App companion : suivez vos agents en déplacement
Utilisez Claude, Codex, Antigravity CLI ou un autre fournisseur IA.
Remontez bugs et demandes directement dans votre backlog public.