Lass deine Agenten die Datenbank abfragen,
schreibgeschützt, bis du etwas anderes sagst
AgentsRoom verwaltet deine MySQL- und MariaDB-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 MySQL- und MariaDB-Verbindungen in der App wie in jedem SQL-Client: 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.
Ein SQL-Client, der davon ausgeht, dass ein Agent am Steuer sitzt
MySQL und MariaDB, erreichbar in privaten Netzen, mit standardmäßig aktiven Leitplanken.
MySQL- und MariaDB-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.
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.
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 zweite Hälfte davon ist die Schreibschutz-Regel, und für einen Agenten ist sie keine Voreinstellung, aus der er sich herausreden könnte. Das Werkzeug, mit dem ein Agent abfragt, lehnt alles außer einem Lesevorgang ab, egal was diese Verbindung erlaubt. Eine Verbindung schreibbar zu machen, schaltet Schreibvorgänge für dich frei, in der SQL-Konsole, wo jeder einzelne eine ausdrückliche Bestätigung verlangt, die bei einer als Produktion markierten Verbindung bewusst schwerer zu geben ist. Das Schlimmste, was aus einer schlechten Abfrage eines Agenten folgt, bleibt 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. Zusammen mit begrenzten Ergebnismengen bleibt ein Fehler ein Fehler, statt zu einem Export zu werden.
Heute MySQL und MariaDB, und sonst nichts
Der Datenbank-Client in AgentsRoom spricht das MySQL Wire Protocol, und MariaDB ist dazu kompatibel, beide werden also schon jetzt unterstützt: direkt, oder über einen SSH-Tunnel oder eine AWS SSM Port-Forwarding-Session, wenn der Server aus dem offenen Internet nicht erreichbar ist.
PostgreSQL, MongoDB, SQL Server, SQLite und die anderen werden nicht unterstützt. 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 anfragenVon 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.
Sie routen, 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.
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 er bekommt dabei nie die Fähigkeit, 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.
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.
db_query ist schreibgeschützt, egal was die Verbindung erlaubt. Eine Verbindung schreibbar zu machen, schaltet Schreibvorgänge für dich frei, in der SQL-Konsole, wo jeder einzelne ausdrücklich bestätigt wird und wo eine als Produktion markierte Verbindung das auch deutlich sagt. Für einen Agenten schaltet es nichts frei: Die Schreibschutz-Regel für db_query sitzt in der Desktop-App statt im MCP-Prozess, sie hält also selbst dann, wenn man den Agenten dazu überredet, etwas anderes zu verlangen. Für ein DROP braucht es kein Passwort, und genau deshalb sitzt die Leitplanke am Statement und nicht nur an den Zugangsdaten.
Dieselbe Grenze gilt für das Anlegen einer Datenbank. db_connection_new ö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. 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.
AgentsRoom MCP entdeckenFAQ
Welche Datenbanken werden unterstützt?
MySQL und MariaDB, und nur die. Der Client spricht das MySQL Wire Protocol und MariaDB ist dazu kompatibel, beide funktionieren also, direkt oder über einen SSH-Tunnel oder eine AWS SSM Port-Forwarding-Session. PostgreSQL, MongoDB, SQL Server, SQLite und der Rest werden heute nicht unterstützt. Brauchst du eine davon, frag sie im öffentlichen Backlog an: Die Liste wächst mit dem, was tatsächlich nachgefragt wird.
Kann ein KI-Agent in meine Datenbank schreiben?
Nein. Das MCP-Werkzeug, mit dem ein Agent abfragt, db_query, ist schreibgeschützt, egal was die Verbindung erlaubt: SELECT, SHOW, DESCRIBE, EXPLAIN und WITH gehen durch, alles, was Daten verändern würde, wird abgelehnt. Eine Verbindung schreibbar zu machen, schaltet Schreibvorgänge für dich in der SQL-Konsole frei, wo jeder einzelne ausdrücklich bestätigt wird, nicht für einen Agenten. Die Leitplanke sitzt am Statement und nicht am Passwort, denn für ein DROP braucht es kein Passwort.
Wie erreiche ich eine Datenbank in einem privaten Subnetz?
Leite die Verbindung über einen SSH-Tunnel oder eine AWS SSM Port-Forwarding-Session, gebaut aus den SSH- und SSM-Verbindungen, die du in AgentsRoom schon gespeichert hast. Die App öffnet den Tunnel oder die Session und verbindet die Datenbank darüber, die Datenbank bleibt also aus dem öffentlichen Internet unerreichbar.
Sehen meine Agenten das Datenbank-Passwort?
Nein. Agenten fragen über MCP ab, indem sie eine Verbindung benennen. AgentsRoom hält die Zugangsdaten und führt das Statement selbst aus, das Passwort wird also nie an den Agenten zurückgegeben, nie in die Abfrage geschrieben und ist nie Teil der Konversation.
Kann ein Agent mehrere Statements auf einmal ausführen?
Nein. Ein Aufruf trägt genau ein Statement. Alles, was hinter einem Semikolon gestapelt ist, wird abgelehnt statt ausgeführt, und damit fällt der älteste Weg weg, einen Schreibvorgang in etwas zu verstecken, das wie ein Lesevorgang aussieht.
Was ändert es, eine Verbindung als Produktion zu markieren?
Es verschärft die Bestätigung, die vor einem Schreibvorgang nötig ist. Die Datenbank, auf die es ankommt, verhält sich nicht mehr wie die lokale Kopie, und genau das willst du am Ende eines langen Tages, und noch mehr von einem Agenten, der eine Aufgabenliste abarbeitet.
Was passiert bei einer Abfrage, die sehr viele Zeilen zurückgibt?
Ergebnismengen sind begrenzt. Eine Abfrage, die eine riesige Tabelle zurückgeben würde, kommt gekürzt zurück, statt das Fenster oder den Kontext des Agenten zu überschwemmen, ein breites SELECT bleibt also eine Unannehmlichkeit statt eines Exports deiner Daten.
Kann ein Agent eine Datenbankverbindung hinzufügen?
Er kann eine vorschlagen, niemals eine speichern. db_connection_new öffnet das Anlageformular, vorausgefüllt mit Host, Port, Benutzer und der SSH- oder AWS SSM Verbindung, über die die Datenbank erreicht werden soll, und du prüfst es, tippst das Passwort und speicherst. Vorher wird nichts abgelegt, und der Agent liefert nie Zugangsdaten.
Wie lernt ein Agent mein Schema kennen?
Mit db_schema, das eine gespeicherte Verbindung ganz ohne SQL erkundet. Ohne Argument aufgerufen listet es die Schemas auf, mit einer Datenbank die Tabellen und Views, mit einer Tabelle liefert es die Spalten, ihre Typen, ob sie NULL zulassen, ihre Schlüssel und ihre Standardwerte. Das ist günstiger und sicherer, als einen Agenten information_schema von Hand abfragen zu lassen.
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 SQL-Client darüber. Nur MySQL und MariaDB, also RDS MySQL und Aurora MySQL-kompatibel.
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- und MariaDB-Verbindungen, erreiche sie über einen SSH-Tunnel oder eine AWS SSM Session und lass deine Agenten sie schreibgeschützt abfragen.
Companion-App: Agenten auch unterwegs im Blick behalten
Nutzen Sie Claude, Codex, Antigravity CLI oder einen anderen AI-Anbieter.
Bugs und Wünsche direkt in dein öffentliches Backlog schicken.
Ein Blick auf AgentsRoom in Aktion.