Lass deine Agenten die Datenbank abfragen,
schreibgeschützt, bis du etwas anderes sagst
AgentsRoom verwaltet deine MySQL-, PostgreSQL-, SQL Server-, MongoDB-, SQLite- und Google BigQuery-Verbindungen und gibt deinen KI-Coding-Agenten einen Weg, Abfragen dagegen auszuführen. Standardmäßig schreibgeschützt, ein Statement nach dem anderen, und das Passwort bleibt außer Reichweite.
Ein Agent, der die echten Zeilen lesen kann, hört auf, über deine Daten zu raten. Ein Agent, der sie nicht ändern kann, hört auf, ein Risiko zu sein, das du Zeile für Zeile überwachen musst.
Wie AgentsRoom eine Datenbank in einem privaten Subnetz erreicht und eine schreibgeschützte Abfrage eines KI-Agenten beantwortet.
Ein KI-Coding-Agent, der deine Daten nicht sehen kann, schreibt Code gegen das Schema, das er sich vorgestellt hat. Er erfindet eine Spalte, nimmt an, ein Enum habe drei Werte, wo es sieben hat, und erklärt einen Bug mit einer Theorie statt mit einer Zeile. Ihm eine Datenbankverbindung zu geben, behebt das, und es ist zugleich der schnellste Weg, aus einem hilfreichen Agenten einen Vorfall zu machen. AgentsRoom ist um genau diese Spannung herum gebaut.
Du speicherst deine Verbindungen in der App wie in jedem Datenbank-Client: Engine, Host, Port, Benutzer, Datenbank und TLS, wenn der Server es erwartet. Ist die Datenbank aus dem offenen Internet nicht erreichbar, wird die Verbindung über einen SSH-Tunnel oder eine AWS SSM Port-Forwarding-Session geleitet, und zwar über die SSH- und SSM-Verbindungen, die du in AgentsRoom schon gespeichert hast. So wird eine Datenbank in einem privaten Subnetz zu etwas, das du abfragen kannst, ohne sie der Welt zu öffnen.
Jede Verbindung startet schreibgeschützt. Ein SELECT läuft. Ein Statement, das Daten verändern würde, läuft nicht, solange du diese eine Verbindung nicht schreibbar gemacht und die Operation bestätigt hast. Pro Aufruf wird nur ein Statement akzeptiert, es versteckt sich also nichts hinter einem Semikolon, und Ergebnismengen sind begrenzt, damit eine breite Abfrage weder einen Agenten noch ein Fenster überschwemmt. Eine Verbindung lässt sich außerdem als Produktion markieren, was die Bestätigung schwerer aus Versehen zu geben macht.
Lesen ist nicht die ganze Arbeit. Eine auf einem Rechner gespeicherte Verbindung taucht auch auf deinen anderen auf, du richtest eine Datenbank also einmal ein statt einmal pro Computer. Und eine Datenbank lässt sich in eine Datei exportieren, aus einer Datei wiederherstellen oder direkt auf einen anderen Server kopieren, durch dieselben Tunnel: genau die Vorgänge, für die du die App bisher verlassen hast.
Ein Datenbank-Client, der davon ausgeht, dass ein Agent am Steuer sitzt
MySQL, PostgreSQL, SQL Server, MongoDB, SQLite und Google BigQuery, die Server-Engines erreichbar in privaten Netzen, mit standardmäßig aktiven Leitplanken.
MySQL-, PostgreSQL-, SQL Server- und MongoDB-Verbindungen
Speichere eine Verbindung pro Datenbank: Host, Port, Benutzer, die zu öffnende Datenbank und TLS, wenn der Server es verlangt. Deine lokale Datenbank, die von Staging und das Produktions-Replikat stehen alle in derselben Liste, bereit zum Auswählen statt zum Neutippen.
Eine private Datenbank erreichen
Eine Datenbank in einem privaten Subnetz ist kein Sonderfall. Leite die Verbindung über einen SSH-Tunnel oder eine AWS SSM Port-Forwarding-Session, und AgentsRoom öffnet sie für dich, wobei die SSH- und SSM-Verbindungen wiederverwendet werden, die du in der App schon gespeichert hast. Eine Google Cloud SQL-Instanz wird über ihren Verbindungsnamen durch den Cloud SQL Auth Proxy erreicht, mit deiner eigenen gcloud-Anmeldung und ohne gespeicherte Zugangsdaten.
Standardmäßig schreibgeschützt
Eine neue Verbindung kann lesen und sonst nichts. Abfragen liefern Zeilen, Statements, die Daten ändern würden, werden abgelehnt. Niemand muss daran denken, den sicheren Modus einzuschalten, denn im sicheren Modus startet jede Verbindung.
Zwei Schlösser vor einem Schreibvorgang
Schreiben verlangt zwei bewusste Handlungen, nicht eine. Die Verbindung muss schreibbar gemacht werden, und die Operation selbst muss ausdrücklich bestätigt werden. Ein einziger unachtsamer Klick kann sich nicht zu einem UPDATE ohne WHERE-Klausel auswachsen.
Ein Statement pro Aufruf
Jeder Aufruf trägt genau ein Statement. Alles, was hinter einem Semikolon gestapelt ist, wird abgelehnt statt ausgeführt, ein Lesevorgang, der wie ein Lesevorgang aussieht, kann also kein zweites Statement mitschmuggeln. Obendrauf sind Ergebnismengen begrenzt.
Produktion ist markiert
Markiere eine Verbindung als Produktion, und die Bestätigung wird strenger. Die Datenbank, auf die es ankommt, sieht nicht mehr exakt aus wie die lokale Kopie, weder für dich am Ende eines langen Tages noch für einen Agenten, der eine Aufgabenliste abarbeitet.
Deine Verbindungen, auf jedem Rechner
Eine auf dem Bürorechner gespeicherte Verbindung ist auch auf dem Laptop da: Name, Host, Port, Benutzer, Standarddatenbank und der Tunnel, über den sie läuft. Zurück bleibt einzig das Passwort, verschlüsselt auf dem Rechner, auf dem du es getippt hast, sodass jeder Rechner einmal danach fragt.
Exportieren, Importieren, Kopieren
Zieh eine Datenbank in eine .sql-Datei, spiel eine solche Datei in eine Datenbank ein, oder kopiere eine Datenbank direkt auf eine andere. Das Ziel wird gesichert, bevor es überschrieben wird, und es ganz zu ersetzen ist eine eigene, bestätigte Entscheidung.
Agenten fragen die Datenbank ab, das Passwort halten sie nie in der Hand
Deine Datenbank-Zugangsdaten werden von AgentsRoom gespeichert, nicht herausgegeben. Ein Agent bittet darum, eine Abfrage gegen eine Verbindung auszuführen, die er nur beim Namen kennt, die App öffnet die Verbindung, führt das Statement aus und gibt die Zeilen zurück. Das Passwort ist nie Teil dessen, was der Agent bekommt, nie Teil der Abfrage, die er schreibt, und nie Teil der Konversation, die er behält.
Die Schreibschutz-Regel ist die zweite Hälfte davon, und für einen Agenten ist sie nichts, aus dem er sich herausreden könnte. Das Werkzeug, mit dem ein Agent abfragt, lehnt alles außer einem Lesevorgang ab, es sei denn, zwei Dinge treffen zu: Die Verbindung ist schreibbar, und du hast „Agenten Schreibzugriff erlauben“ für diese Verbindung eingeschaltet. Die Option ist standardmäßig aus, und die Prüfung läuft in der Desktop-App statt im Prozess des Agenten. Deine eigenen Schreibvorgänge in der Konsole verlangen weiterhin eine ausdrückliche Bestätigung, die bewusst schwerer zu geben ist, wenn die Verbindung als Produktion markiert ist. Sobald eine Verbindung für Schreibvorgänge von Agenten geöffnet ist, laufen diese ohne diese Bestätigung, behalte die Option also einer Datenbank vor, die du dem Agenten anvertrauen würdest. Überall sonst bleibt das Schlimmste, was aus einer schlechten Abfrage folgt, eine falsche Antwort statt einer verlorenen Tabelle.
Die Ein-Statement-Regel schließt die klassische Lücke. Ein Aufruf, der ein Statement trägt, lässt sich nicht um ein Semikolon und ein zweites erweitern, eine Abfrage, die im Review harmlos wirkt, kann zur Ausführungszeit also nichts anderes tun. SQL Server braucht dieses Semikolon nicht, dort ist ein Lesevorgang deshalb ein SELECT oder ein WITH ohne jedes Schreib- oder Transaktionsschlüsselwort, und er läuft in einer Transaktion, die immer zurückgerollt wird. Zusammen mit begrenzten Ergebnismengen bleibt ein Fehler ein Fehler, statt zu einem Export zu werden.
Sechs Engines, und wir nennen die, die fehlen
MySQL und MariaDB, PostgreSQL, SQL Server (Azure SQL und Amazon RDS for SQL Server inklusive), MongoDB, SQLite und Google BigQuery. Jede hat ihren eigenen Treiber statt einer Übersetzungsschicht, denn sie unterscheiden sich wirklich: Eine PostgreSQL- oder SQL Server-Session hängt an einer einzigen Datenbank, MongoDB nimmt eine Abfrage entgegen und kein SQL, T-SQL braucht kein Semikolon zwischen zwei Statements, jeder Export läuft über die Werkzeuge, die mit der jeweiligen Engine mitkommen, SQLite ist einfach eine Datei auf deinem Computer, ohne Host, Benutzer oder Passwort, und eine BigQuery-Verbindung ist ein Google Cloud-Projekt mit einem Standard-Dataset, angemeldet mit deinem eigenen Google-Login (gcloud auth application-default login), ohne gespeicherten Schlüssel. Die vier Server-Engines erreichst du direkt, oder über einen SSH-Tunnel oder eine AWS SSM Port-Forwarding-Session, wenn sie nicht im offenen Internet stehen.
Oracle, Redis und die anderen werden nicht unterstützt. Auf SQL Server meldest du dich mit einem SQL-Login an (Windows-, Active Directory- und Entra ID-Authentifizierung werden nicht angeboten), und Export, Import oder Kopie gibt es nicht. Bei BigQuery rechnet Google jede Abfrage nach den gelesenen Bytes ab, deshalb hat jede Verbindung ein Kostenlimit pro Abfrage (standardmäßig 1 GiB, anpassbar): Eine Abfrage darüber wird abgelehnt statt abgerechnet. Eine Tabelle zu öffnen ist kostenlos und schreibgeschützt, deine Agenten nutzen dieselben Tools db_list, db_schema und db_query mit denselben Leitplanken und sehen, wie viele Bytes jede Abfrage gelesen hat, und auch dort gibt es weder Export noch Import oder Kopie. Das solltest du vor dem Download erfahren und nicht danach. Welche Engine als Nächstes kommt, entscheidet die Nachfrage: Fehlt deine, nenne sie im öffentlichen Backlog, und sie wird mitgezählt.
Deine Datenbank-Engine anfragenEine Datenbank bewegen, nicht nur lesen
Exportiere eine Datenbank in eine Datei. Importiere eine Datei in eine Datenbank. Oder kopiere eine Datenbank direkt auf eine andere, auch durch den SSH-Tunnel oder die AWS SSM Session, die du schon gespeichert hast. Jede Engine läuft über ihre eigenen offiziellen Werkzeuge und schreibt im Stream auf die Platte, eine Datenbank von mehreren Gigabyte wird damit zu einem Fortschrittsbalken statt zu einem Absturz.
Diese Werkzeuge kommen mit der Datenbank mit, nicht mit AgentsRoom: mysqldump und mysql, pg_dump und psql, mongodump und mongorestore. SQL Server hat kein Gegenstück, das eine ganze Datenbank streamt, seine Verbindungen haben deshalb weder Export noch Import noch Kopie. Fehlen die Werkzeuge, sagt die App genau, welche, und lässt dich den Ordner angeben, in dem sie liegen, so wie ein Datenbank-Client das tun sollte: aus dem Dock oder dem Startmenü gestartet, sieht eine App nur einen minimalen PATH und würde sie sonst auf einem Rechner als fehlend melden, auf dem sie längst liegen.
Beim Kopieren kostet ein falscher Klick einen ganzen Tag, deshalb ist es genau darum herum gebaut und nicht um den Idealfall.
- Eine schreibgeschützte Verbindung lehnt den Import rundweg ab, bevor überhaupt etwas geöffnet wird.
- Das Ziel wird in eine Datei deiner Wahl gesichert, bevor auch nur ein Statement angewendet wird.
- Die Bestätigung nennt die Verbindung und die Datenbank beim Namen und wird deutlicher, wenn die Verbindung als Produktion markiert ist.
- Das Ziel zu löschen und neu anzulegen ist eine eigene Option, und auf einer Produktionsverbindung musst du den Namen der Datenbank eintippen.
Von einer privaten Datenbank zu einer Antwort
Verbindung speichern, routen, dann selbst abfragen oder einen Agenten abfragen lassen.
Die Verbindung speichern
Füge die Datenbank hinzu: Host, Port, Benutzer, Datenbankname und TLS, wenn der Server es erwartet. Gib ihr einen Namen, den du später wiedererkennst, und markiere sie als Produktion, wenn sie das ist.
Route sie, wenn sie privat ist
Ist die Datenbank nicht direkt erreichbar, richte die Verbindung auf einen SSH-Tunnel oder eine AWS SSM Port-Forwarding-Session, gebaut aus den Verbindungen, die in AgentsRoom schon gespeichert sind. Eine Datenbank in einem privaten Subnetz wird erreichbar, ohne sie öffentlich freizulegen. Wähle in Google Cloud stattdessen die Cloud SQL-Instanz: AgentsRoom startet den Cloud SQL Auth Proxy für dich.
Selbst abfragen oder einen Agenten abfragen lassen
Führe dein Statement aus der App aus, oder lass einen Agenten eines über MCP ausführen. Schreibgeschützt, bis du es änderst, ein Statement pro Aufruf, begrenzte Ergebnismengen, und eine ausdrückliche Bestätigung zwischen jedem Schreibvorgang und deinen Daten.
Wenn ein Agent die echten Zeilen braucht
Die Momente, in denen das Lesen von Produktionsdaten der kürzeste Weg zum Fix ist.
Gegen echte Daten debuggen
Der Bug zeigt sich nur bei einer Handvoll Konten. Lass den Agenten diese Zeilen lesen, und er findet den Wert, der die Logik bricht, statt drei Theorien darüber vorzuschlagen, wie die Daten aussehen könnten.
Eine Datenbank, die nicht öffentlich ist
Die Datenbank liegt in einem privaten Subnetz ohne öffentlichen Endpunkt. Leite die Verbindung über einen SSH-Tunnel oder eine AWS SSM Session, gebaut auf deinen gespeicherten Verbindungen, und frage sie ab, ohne einen Port ins Internet zu öffnen.
Lass den Agenten nachsehen, nicht raten
Bevor er eine Migration oder eine Abfrage schreibt, kann ein Agent nachsehen, was tatsächlich gespeichert ist. Er liest, er berichtet, und solange du diese Verbindung nicht für Schreibvorgänge von Agenten geöffnet hast, hat er dabei keine Möglichkeit, etwas zu ändern.
Produktion, ohne Schreibrisiko
Produktion zu lesen ist oft nötig, mitten in einer Aufgabe darauf zu schreiben fast nie. Markiere die Verbindung als Produktion, halte sie schreibgeschützt, und der Unterschied zwischen Untersuchen und Kaputtmachen hängt nicht mehr davon ab, dass jemand aufpasst.
Staging mit echten Daten auffrischen
Der Bug lässt sich nur mit echten Zeilen reproduzieren. Kopiere die Datenbank auf deinen Staging-Server, durch den Tunnel, den du schon gespeichert hast, und was dort vorher lag, wird zuerst in eine Datei gesichert.
Laptop aufklappen, alles ist da
Deine Verbindungen folgen deinem Konto: dieselben Hosts, dieselben Tunnel, dieselben Kennzeichen für schreibgeschützt und Produktion. Mit synchronisierten Passwörtern folgen auch die Passwörter, Ende-zu-Ende-verschlüsselt, sodass nichts neu getippt wird; ohne sie fragt jeder Rechner einmal nach dem Passwort.
Wie fragen meine Agenten die Datenbank ab?
Über AgentsRoom MCP, mit vier Werkzeugen. db_list liefert deine gespeicherten Verbindungen und ihre Metadaten, db_schema geht Schemas, Tabellen und Spalten durch, ohne eine Zeile SQL, db_query führt ein Statement aus und gibt die Zeilen zurück, und db_connection_new schlägt eine Datenbank vor, die du noch nicht gespeichert hast. AgentsRoom öffnet die Verbindung, samt SSH-Tunnel oder AWS SSM Session davor, wenn es einen gibt. Was zum Agenten zurückwandert, ist eine Ergebnismenge, niemals Zugangsdaten.
Agenten können nur schreiben, wenn du „Agenten Schreibzugriff erlauben“ für eine Verbindung einschaltest, die zugleich schreibbar ist. Diese Opt-in-Einstellung ist standardmäßig aus und wird mit der Verbindung über dein ganzes Konto synchronisiert. Sobald sie aktiv ist, werden Schreibvorgänge sofort ausgeführt, nutze sie also nur, wenn du dem Agenten diese Datenbank anvertraust. Die Desktop-App prüft die Berechtigung in ihrem Hauptprozess, und db_query nimmt weiterhin nur ein Statement pro Aufruf an.
Das Registrieren einer Datenbank kann auch komplett die Aufgabe des Agenten sein. db_connection_new hält den geprüften Weg: Es öffnet das Anlageformular, vorausgefüllt mit Host, Benutzer und der SSH- oder AWS SSM Verbindung, über die sie erreicht werden soll, und du prüfst es, tippst das Passwort und speicherst; vorher wird nichts abgelegt. Sofern du "Agenten können Verbindungen verwalten" nicht ausschaltest (Einstellungen, standardmäßig an), schreibt db_connection_save die Verbindung direkt, und auch dann reist das Passwort nie durch die Konversation: Es wird aus einem Secret deines Tresors kopiert, das der Agent nur benennt. Der Agent bekommt, was er braucht, um über deine Daten nachzudenken, und keiner der Wege, auf denen dieser Zugriff sonst zu einem Vorfall wird, steht ihm offen.
Auch jede Abfrage eines Agenten ist sichtbar. Aufrufe von db_query und db_schema landen im Tab Aktivität des rechten Panels, mit dem SQL und den ersten zurückgegebenen Zeilen, in einem eigenen Protokoll pro Datenbank; der Avatar des Agenten erscheint auf dem Button Datenbanken und, mit dem Badge Agent bei der Arbeit, in deiner Liste Datenbanken. Du kannst es auch auf deinem Handy verfolgen, in der Agentenkarte der mobilen App. Dieses Protokoll wird nur zwischen deinem Computer und deinem Handy übertragen, Ende-zu-Ende-verschlüsselt und mit maskierten Zugangsdaten: Kein Ergebnis wird auf einem Server gespeichert.
AgentsRoom MCP entdeckenDerselbe Tab Aktivität, der deine Aufrufe von db_query und db_schema auflistet, hier auf einem gespeicherten SSH-Server gefilmt : Ein Agent führt drei Befehle aus, jeder landet mit seiner Ausgabe, seinem Exit-Code und seiner Dauer, dann öffnet sich das Protokoll dieser Verbindung in voller Größe. Das Protokoll bleibt auf deinem Computer.
Welche Datenbanken werden unterstützt?
Kann ein KI-Agent in meine Datenbank schreiben?
Wie erreiche ich eine Datenbank in einem privaten Subnetz?
Sehen meine Agenten das Datenbank-Passwort?
Kann ein Agent mehrere Statements auf einmal ausführen?
Was ändert es, eine Verbindung als Produktion zu markieren?
Was passiert bei einer Abfrage, die sehr viele Zeilen zurückgibt?
Kann ein Agent eine Datenbankverbindung hinzufügen?
Wie lernt ein Agent mein Schema kennen?
Werden meine Datenbankverbindungen zwischen meinen Rechnern synchronisiert?
Kann ich eine Datenbank exportieren und woanders importieren?
Wie ist das Konto geschützt, das meine Verbindungen enthält?
Screenshots
Echte Aufnahmen der App, ergänzt, wenn sich diese Funktion weiterentwickelt.
Verbinden Sie Google BigQuery mit Ihrem eigenen Google-Login 
Begrenzen Sie, was eine BigQuery-Abfrage pro Verbindung abrechnen darf 
Direkte TLS-Verbindungen überprüfen das Serverzertifikat, mit einer Opt-in-Option für selbstsignierte Server
Das könnte dir auch gefallen
RDS über AWS SSM
Erreiche eine Amazon RDS Instanz ohne öffentlichen Endpunkt von deiner eigenen Maschine aus, über aws ssm start-session und das Dokument AWS-StartPortForwardingSessionToRemoteHost. Kein Bastion-Host, kein VPN, keine eingehende SSH-Regel. AgentsRoom öffnet die Session auf einem Loopback-Port und verbindet den Datenbank-Client darüber. MySQL, PostgreSQL, SQL Server und MongoDB, also RDS MySQL, RDS PostgreSQL, RDS for SQL Server, Aurora und DocumentDB.
Cloud SQL Auth Proxy
Erreiche eine Cloud SQL for MySQL oder PostgreSQL Instanz von deiner eigenen Maschine aus, auch über die private IP, ohne Bastion-VM. AgentsRoom startet den Cloud SQL Auth Proxy auf einem Loopback-Port mit deinen gcloud Application Default Credentials, unterstützt IAM-Datenbankauthentifizierung und lässt KI-Agenten die Instanz schreibgeschützt abfragen.
SSH-Verbindungen
Speichere deine SSH-Verbindungen, öffne ein integriertes Terminal über SSH und starte Claude Code, Codex oder Antigravity CLI direkt auf deinem Remote-Server oder VPS. Authentifizierung per SSH-Schlüssel oder Passwort, Verbindungsprofile pro Projekt, kein separater SSH-Client nötig.
Secret Manager
Speichere API-Keys, Tokens und Passwörter im Schlüsselbund deines Betriebssystems, referenziere sie als {{secret:NAME}} in Dev-Befehlen und Agenten-Umgebungen, und lass AgentsRoom sie beim Start auflösen. Agenten sehen die Namen, nie die Werte, und nichts wird je auf einen Server synchronisiert.
Dev-Terminals
Terminal-Manager und Prozess-Launcher pro Projekt. Starte Backend, Frontend und Worker mit einem Klick, lokal oder auf einem Remote-Server.
AgentsRoom MCP
Der MCP-Server, mit dem deine Agenten AgentsRoom selbst steuern: Projekte, Terminals, Backlog und Verbindungen, samt der Leitplanken, die dazugehören.
Gib deinen Agenten die Daten, nicht die Schlüssel
Lade AgentsRoom herunter, speichere deine MySQL-, PostgreSQL-, SQL Server-, MongoDB-, SQLite- und Google BigQuery-Verbindungen, erreiche die Server-Verbindungen über einen SSH-Tunnel oder eine AWS SSM Session und lass deine Agenten sie abfragen, schreibgeschützt, solange du keine Verbindung für ihre Schreibvorgänge freigibst.
Companion-App: Agenten auch unterwegs im Blick behalten
Nutze Claude, Codex, Antigravity CLI oder einen anderen KI-Anbieter.
Bugs und Wünsche direkt in dein öffentliches Backlog schicken.
Agenten, die du wie eine Unterhaltung liest
Jeder Agent hat eine Rolle, ein Gesicht und einen Verlauf, den du wie in einer Messaging-App liest.
