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 et MariaDB 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 MySQL et MariaDB dans l'app comme tu le ferais dans n'importe quel client SQL : 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 que tu as 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 requêter sans l'ouvrir au monde entier.
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.
Un client SQL qui part du principe qu'un agent est aux commandes
MySQL et MariaDB, joignables dans des réseaux privés, avec les garde-fous actifs par défaut.
Connexions MySQL et MariaDB
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.
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 l'histoire, et pour un agent ce n'est pas un réglage par défaut dont il pourrait se sortir en discutant. L'outil avec lequel un agent requête refuse tout ce qui n'est pas une lecture, quoi qu'autorise cette connexion. Rendre une connexion accessible en écriture débloque les écritures pour toi, dans la console SQL, où chacune demande une confirmation explicite, volontairement plus difficile à donner quand la connexion est marquée comme production. Le pire résultat d'un agent qui lance une mauvaise requête reste une mauvaise réponse plutôt qu'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.
MySQL et MariaDB aujourd'hui, et rien d'autre
Le client de base de données d'AgentsRoom parle le protocole réseau de MySQL, et MariaDB est compatible avec lui, donc les deux sont supportés dès maintenant : en direct, ou via un tunnel SSH ou une session de redirection de port AWS SSM quand le serveur n'est pas joignable depuis l'internet ouvert.
PostgreSQL, MongoDB, SQL Server, SQLite 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'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.
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 accessible en écriture débloque les écritures pour toi, dans la console SQL, où chacune est confirmée explicitement et où une connexion marquée comme production le dit à voix haute. Ça ne les débloque pas pour un agent : la règle de lecture seule de db_query vit dans l'app desktop plutôt que dans le processus MCP, donc elle tient même si on convainc l'agent de demander autre chose. Il ne faut pas de 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, et rien d'autre. Le client parle le protocole réseau de MySQL et MariaDB est compatible avec lui, donc les deux marchent, en direct ou via un tunnel SSH ou une session de redirection de port AWS SSM. PostgreSQL, MongoDB, SQL Server, 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 réclament vraiment.
Un agent IA peut-il écrire dans ma base ?
Non. L'outil MCP avec lequel un agent requête, db_query, est en lecture seule quoi qu'autorise la connexion : SELECT, SHOW, DESCRIBE, EXPLAIN et WITH passent, tout ce qui modifierait les données est refusé. Rendre une connexion accessible en écriture débloque les écritures pour toi dans la console SQL, où chacune est confirmée explicitement, pas pour un agent. Le garde-fou porte sur l'instruction plutôt que sur le mot de passe, parce que ce n'est pas un mot de passe 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.
Tu pourrais aussi aimer
RDS via AWS SSM
Atteins une instance Amazon RDS sans endpoint public, depuis ta machine, via aws ssm start-session et le document AWS-StartPortForwardingSessionToRemoteHost. Pas de bastion à maintenir, pas de VPN, aucune règle SSH entrante. AgentsRoom ouvre la session sur un port loopback et y branche son client SQL. MySQL et MariaDB uniquement, donc RDS MySQL et Aurora compatible MySQL.
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 et MariaDB, atteins-les via un tunnel SSH ou une session AWS SSM, et laisse tes agents les requêter 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.
Aperçu d'AgentsRoom en action.