Pozwól swoim agentom odpytywać bazę,
tylko do odczytu, dopóki nie zdecydujesz inaczej
AgentsRoom zarządza Twoimi połączeniami MySQL, PostgreSQL, SQL Server, MongoDB, SQLite i Google BigQuery i daje agentom AI do kodowania sposób na uruchamianie na nich zapytań. Domyślnie tylko do odczytu, po jednym poleceniu naraz, z hasłem trzymanym poza ich zasięgiem.
Agent, który widzi prawdziwe wiersze, przestaje zgadywać, co jest w Twoich danych. Agent, który nie może w nich pisać, przestaje być ryzykiem pilnowanym linijka po linijce.
Jak AgentsRoom sięga po bazę danych w prywatnej podsieci i odpowiada na zapytanie agenta AI w trybie tylko do odczytu.
Agent AI do kodowania, który nie widzi Twoich danych, pisze kod pod schemat, który sobie wyobraził. Wymyśla kolumnę, zakłada, że enum ma trzy wartości, choć ma ich siedem, i tłumaczy błąd teorią zamiast wierszem. Danie mu połączenia z bazą to naprawia, a jednocześnie jest najszybszą drogą do zamiany pomocnego agenta w incydent. AgentsRoom jest zbudowany wokół tego napięcia.
Zapisujesz swoje połączenia w aplikacji tak, jak zrobiłbyś to w dowolnym kliencie bazy danych: silnik, host, port, użytkownik, baza i TLS, gdy serwer tego oczekuje. Jeśli baza nie jest osiągalna z otwartego internetu, połączenie jest kierowane przez tunel SSH albo sesję przekierowania portów AWS SSM, na bazie połączeń SSH i SSM zapisanych już w AgentsRoom. W ten sposób baza siedząca w prywatnej podsieci staje się czymś, co możesz odpytywać, nie otwierając jej na świat.
Każde połączenie startuje w trybie tylko do odczytu. SELECT się wykona. Polecenie, które zmieniłoby dane, nie, dopóki nie uczynisz tego konkretnego połączenia zapisywalnym i nie potwierdzisz operacji. Na jedno wywołanie przyjmowane jest wyłącznie jedno polecenie, więc nic dodatkowego nie schowa się za średnikiem, a zbiory wyników są ograniczane, żeby szerokie zapytanie nie zalało agenta ani okna. Połączenie można też oznaczyć jako produkcyjne, co utrudnia przypadkowe potwierdzenie.
Czytanie to nie cała robota. Połączenie zapisane na jednej maszynie pojawia się na pozostałych, więc bazę konfigurujesz raz, a nie raz na komputer. A samą bazę można wyeksportować do pliku, odtworzyć z pliku albo skopiować wprost na inny serwer, przez te same tunele: czyli zrobić dokładnie to, po co dotąd trzeba było wychodzić z aplikacji.
Klient bazy danych, który zakłada, że steruje nim agent
MySQL, PostgreSQL, SQL Server, MongoDB, SQLite i Google BigQuery, silniki serwerowe osiągalne w sieciach prywatnych, z zabezpieczeniami włączonymi domyślnie.
Połączenia MySQL, PostgreSQL, SQL Server i MongoDB
Zapisz połączenie dla każdej bazy: host, port, użytkownik, baza do otwarcia i TLS, gdy serwer tego wymaga. Twoja baza lokalna, ta ze stagingu i replika produkcyjna żyją na tej samej liście, gotowe do wybrania zamiast przepisywania.
Sięgnij po prywatną bazę
Baza w prywatnej podsieci to nie jest przypadek szczególny. Skieruj połączenie przez tunel SSH albo sesję przekierowania portów AWS SSM, a AgentsRoom otworzy je za Ciebie, wykorzystując połączenia SSH i SSM zapisane już w aplikacji. Instancja Google Cloud SQL jest dostępna przez nazwę połączenia, za pośrednictwem Cloud SQL Auth Proxy, z użyciem Twojego własnego logowania gcloud i bez zapisywania czegokolwiek.
Domyślnie tylko do odczytu
Nowe połączenie potrafi czytać i nic więcej. Zapytania zwracają wiersze, polecenia, które zmieniłyby dane, są odrzucane. Nikt nie musi pamiętać o włączeniu trybu bezpiecznego, bo tryb bezpieczny to punkt startowy każdego połączenia.
Dwa zamki przed zapisem
Zapis wymaga dwóch świadomych ruchów, nie jednego. Połączenie musi zostać uczynione zapisywalnym, a sama operacja musi zostać wyraźnie potwierdzona. Jedno nieuważne kliknięcie nie przerodzi się w UPDATE bez klauzuli WHERE.
Jedno polecenie na wywołanie
Każde wywołanie niesie dokładnie jedno polecenie. Cokolwiek doklejone za średnikiem jest odrzucane, a nie wykonywane, więc odczyt, który wygląda na odczyt, nie przemyci ze sobą drugiego polecenia. Do tego dochodzą ograniczone zbiory wyników.
Produkcja jest oznaczona
Oznacz połączenie jako produkcyjne, a potwierdzenie stanie się trudniejsze. Baza, na której naprawdę zależy, przestaje wyglądać dokładnie tak jak lokalna kopia, zarówno dla Ciebie pod koniec długiego dnia, jak i dla agenta przerabiającego listę zadań.
Twoje połączenia na każdej maszynie
Połączenie zapisane na maszynie w biurze jest też na laptopie: nazwa, host, port, użytkownik, domyślna baza i tunel, przez który biegnie. Na miejscu zostaje wyłącznie hasło, zaszyfrowane na tej maszynie, na której zostało wpisane, więc każda maszyna pyta o nie raz.
Eksport, import, kopiowanie
Zrzuć bazę do pliku .sql, wgraj taki plik do bazy albo skopiuj jedną bazę wprost na drugą. Baza docelowa zostaje zabezpieczona, zanim ktokolwiek ją nadpisze, a zastąpienie jej w całości to osobna decyzja, potwierdzana oddzielnie.
Agenci odpytują bazę, nigdy nie trzymają hasła
Dane logowania do Twojej bazy AgentsRoom przechowuje, a nie rozdaje. Agent prosi o uruchomienie zapytania na połączeniu, które zna po nazwie, aplikacja otwiera połączenie, wykonuje polecenie i zwraca wiersze. Hasło nigdy nie jest częścią tego, co agent dostaje, nigdy nie jest częścią zapytania, które pisze, ani rozmowy, którą prowadzi.
Reguła tylko do odczytu to druga połowa tej układanki, a agent nie ma jak się z niej wygadać. Narzędzie, którym agent odpytuje bazę, odrzuca wszystko poza odczytem, chyba że spełnione są dwa warunki: połączenie jest zapisywalne i włączyłeś dla niego „Zezwól agentom na zapis”. Opcja jest domyślnie wyłączona, a sprawdzenie odbywa się w aplikacji desktopowej, a nie w procesie agenta. Twoje własne zapisy w konsoli nadal wymagają wyraźnego potwierdzenia, celowo trudniejszego do wydania, gdy połączenie jest oznaczone jako produkcyjne. Gdy połączenie jest już otwarte na zapisy agentów, są one wykonywane bez tego potwierdzenia, więc zostaw tę opcję dla bazy, którą powierzyłbyś agentowi. Wszędzie indziej najgorszym skutkiem złego zapytania pozostaje zła odpowiedź, a nie utracona tabela.
Zasada jednego polecenia zamyka klasyczną lukę. Wywołania niosącego jedno polecenie nie da się rozszerzyć średnikiem i drugim poleceniem, więc zapytanie, które w przeglądzie czyta się jako nieszkodliwe, nie zrobi czegoś innego w chwili wykonania. SQL Server nie potrzebuje tego średnika, więc tam odczyt to SELECT albo WITH bez żadnego słowa kluczowego zapisu czy transakcji, a uruchamia się on wewnątrz transakcji, która zawsze jest wycofywana. W połączeniu z ograniczonymi zbiorami wyników pomyłka zostaje pomyłką, zamiast stać się eksportem danych.
Sześć silników, i mówimy wprost, których brakuje
MySQL i MariaDB, PostgreSQL, SQL Server (w tym Azure SQL i Amazon RDS for SQL Server), MongoDB, SQLite oraz Google BigQuery. Każdy ma własny sterownik zamiast warstwy tłumaczącej, bo naprawdę się od siebie różnią: sesja PostgreSQL albo SQL Server jest związana z jedną bazą, MongoDB przyjmuje zapytanie, a nie SQL, T-SQL nie potrzebuje średnika między dwoma poleceniami, każdy eksport opiera się na narzędziach dostarczanych razem z danym silnikiem, SQLite to po prostu plik na Twoim komputerze, bez hosta, użytkownika i hasła, a połączenie BigQuery to projekt Google Cloud z domyślnym zbiorem danych, do którego logujesz się własnym kontem Google (gcloud auth application-default login), bez zapisywania żadnego klucza. Cztery silniki serwerowe są osiągalne bezpośrednio albo przez tunel SSH lub sesję przekierowania portów AWS SSM, gdy nie są wystawione na otwarty internet.
Oracle, Redis i pozostałe nie są obsługiwane. Do SQL Server logujesz się loginem SQL (uwierzytelnianie Windows, Active Directory i Entra ID nie jest dostępne) i nie ma tam eksportu, importu ani kopiowania. W BigQuery Google nalicza opłatę za każde zapytanie według liczby odczytanych bajtów, dlatego każde połączenie ma limit kosztów na zapytanie (domyślnie 1 GiB, z możliwością zmiany): zapytanie powyżej tego limitu zostaje odrzucone, zamiast trafić na rachunek. Otwarcie tabeli jest bezpłatne i tylko do odczytu, Twoi agenci używają tych samych narzędzi db_list, db_schema i db_query z tymi samymi zabezpieczeniami i widzą, ile bajtów odczytało każde zapytanie, a eksportu, importu ani kopiowania również tam nie ma. Masz prawo wiedzieć o tym przed pobraniem, a nie po nim. O tym, który silnik będzie następny, decyduje to, o co proszą ludzie, więc jeśli brakuje Twojego, napisz który na publicznym backlogu, a zostanie policzony.
Poproś o swój silnik bazy danychPrzenieś bazę, nie tylko ją czytaj
Wyeksportuj bazę do pliku. Zaimportuj plik do bazy. Albo skopiuj jedną bazę wprost na drugą, również przez zapisany wcześniej tunel SSH lub sesję AWS SSM. Każdy silnik korzysta z własnych oficjalnych narzędzi, zapisujących strumieniowo na dysk, więc baza ważąca kilka gigabajtów to pasek postępu, a nie awaria.
Te narzędzia przychodzą z bazą danych, a nie z AgentsRoom: mysqldump i mysql, pg_dump i psql, mongodump i mongorestore. SQL Server nie ma odpowiednika, który strumieniuje całą bazę, więc jego połączenia nie mają eksportu, importu ani kopiowania. Kiedy brakuje tych narzędzi, aplikacja mówi wprost, których, i pozwala wskazać katalog, w którym leżą, tak jak powinien to robić klient bazy danych: uruchomiona z Docka albo z menu Start aplikacja widzi tylko minimalny PATH i inaczej uznałaby, że ich brakuje na maszynie, która je ma.
To przy kopiowaniu jedno złe kliknięcie kosztuje cały dzień, więc zbudowano je wokół tego, a nie wokół wariantu idealnego.
- Połączenie tylko do odczytu odrzuca import od razu, zanim cokolwiek zostanie otwarte.
- Baza docelowa trafia do pliku wybranego przez Ciebie, zanim zostanie zastosowane pierwsze polecenie.
- Potwierdzenie wymienia z nazwy połączenie i bazę, a mówi głośniej, gdy połączenie jest oznaczone jako produkcyjne.
- Usunięcie bazy docelowej i utworzenie jej od nowa to osobna opcja, a na połączeniu produkcyjnym musisz wpisać nazwę bazy.
Od prywatnej bazy do odpowiedzi
Zapisz połączenie, skieruj je, a potem odpytuj sam albo pozwól agentowi.
Zapisz połączenie
Dodaj bazę: host, port, użytkownik, nazwa bazy i TLS, jeśli serwer tego oczekuje. Nadaj jej nazwę, którą później rozpoznasz, i oznacz jako produkcyjną, jeśli tym właśnie jest.
Skieruj je, jeśli baza jest prywatna
Jeśli baza nie jest osiągalna bezpośrednio, wskaż połączeniu tunel SSH albo sesję przekierowania portów AWS SSM zbudowaną z połączeń zapisanych już w AgentsRoom. Baza w prywatnej podsieci staje się osiągalna bez wystawiania jej publicznie. W Google Cloud wybierz zamiast tego instancję Cloud SQL: AgentsRoom uruchomi dla Ciebie Cloud SQL Auth Proxy.
Odpytaj ją sam albo pozwól agentowi
Uruchom polecenie z poziomu aplikacji albo pozwól agentowi uruchomić je przez MCP. Tylko do odczytu, dopóki tego nie zmienisz, jedno polecenie na wywołanie, ograniczone zbiory wyników i wyraźne potwierdzenie stojące między każdym zapisem a Twoimi danymi.
Kiedy agent potrzebuje prawdziwych wierszy
Momenty, w których odczyt danych produkcyjnych to najkrótsza droga do poprawki.
Debugowanie na prawdziwych danych
Błąd pokazuje się tylko dla garstki kont. Pozwól agentowi przeczytać te wiersze, a znajdzie wartość, która łamie logikę, zamiast proponować trzy teorie o tym, jak te dane mogą wyglądać.
Baza, która nie jest publiczna
Baza żyje w prywatnej podsieci bez publicznego endpointu. Skieruj połączenie przez tunel SSH albo sesję AWS SSM zbudowaną na Twoich zapisanych połączeniach i odpytuj ją, nie otwierając portu do internetu.
Niech agent sprawdzi, a nie zgaduje
Zanim napisze migrację albo zapytanie, agent może zobaczyć, co jest naprawdę zapisane. Czyta, raportuje i dopóki nie otworzysz tego połączenia na zapisy agentów, nie ma przy tym żadnej możliwości zmiany czegokolwiek.
Produkcja bez ryzyka zapisu
Czytanie produkcji często jest konieczne, pisanie do niej w środku zadania prawie nigdy. Oznacz połączenie jako produkcyjne, zostaw je tylko do odczytu, a różnica między badaniem a psuciem przestanie zależeć od czyjejś uwagi.
Odśwież staging prawdziwymi danymi
Błąd odtwarza się wyłącznie na prawdziwych wierszach. Skopiuj bazę na swój serwer stagingowy przez zapisany wcześniej tunel, a to, co tam było, trafi najpierw do pliku.
Otwierasz laptopa, wszystko jest na miejscu
Twoje połączenia idą za Twoim kontem: te same hosty, te same tunele, te same oznaczenia tylko do odczytu i produkcyjne. Gdy włączysz synchronizowane hasła, one też idą za Tobą, zaszyfrowane end-to-end, więc nic nie trzeba wpisywać od nowa; bez nich każda maszyna pyta o hasło raz.
Jak moi agenci odpytują bazę danych?
Przez AgentsRoom MCP, za pomocą czterech narzędzi. db_list zwraca Twoje zapisane połączenia i ich metadane, db_schema przechodzi po schematach, tabelach i kolumnach bez linijki SQL, db_query uruchamia jedno polecenie i zwraca wiersze, a db_connection_new proponuje bazę, której jeszcze nie zapisałeś. AgentsRoom otwiera połączenie, razem z tunelem SSH albo sesją AWS SSM przed nim, jeśli taka istnieje. Do agenta wraca zbiór wyników, nigdy dane logowania.
Agenci mogą zapisywać tylko wtedy, gdy włączysz „Zezwól agentom na zapis” w połączeniu, które jest też zapisywalne. Tę opcję włączasz świadomie: domyślnie jest wyłączona i synchronizuje się razem z połączeniem na całym Twoim koncie. Po włączeniu zapisy są wykonywane natychmiast, więc używaj jej tylko wtedy, gdy ufasz agentowi na tyle, by powierzyć mu tę bazę. Aplikacja desktopowa sprawdza to uprawnienie w swoim procesie głównym, a db_query nadal przyjmuje tylko jedno polecenie na wywołanie.
Rejestrowanie bazy danych może być też w całości zadaniem agenta. db_connection_new zachowuje ścieżkę z przeglądem: otwiera formularz tworzenia wypełniony wstępnie hostem, użytkownikiem oraz połączeniem SSH albo AWS SSM, przez które należy po nią sięgnąć, a Ty go sprawdzasz, wpisujesz hasło i zapisujesz, i nic nie zostaje zapisane, dopóki tego nie zrobisz. Chyba że wyłączysz „Agenci mogą zarządzać połączeniami” (Ustawienia, domyślnie włączone), db_connection_save zapisuje połączenie od razu, a hasło nadal nie przechodzi przez rozmowę: jest kopiowane z sekretu sejfu, którego agent wskazuje tylko nazwę. Agent dostaje to, czego potrzebuje, żeby wnioskować o Twoich danych, a żaden ze sposobów, w jakie taki dostęp zwykle zamienia się w incydent, nie jest dla niego dostępny.
Każde zapytanie agenta też jest widoczne. Wywołania db_query i db_schema trafiają do karty Aktywność w prawym panelu, razem z SQL i pierwszymi zwróconymi wierszami, w osobnym dzienniku dla każdej bazy; awatar agenta widać na przycisku Bazy danych oraz, z plakietką Agent przy pracy, na Twojej liście Bazy danych. Możesz to też śledzić na telefonie, w karcie agenta w aplikacji mobilnej. Ten dziennik jest przesyłany tylko między Twoim komputerem a Twoim telefonem, szyfrowany end-to-end, z zamaskowanymi sekretami: żaden wynik nie jest zapisywany na żadnym serwerze.
Poznaj AgentsRoom MCPTa sama karta Aktywność, w której lądują Twoje wywołania db_query i db_schema, nagrana tutaj na zapisanym serwerze SSH: agent uruchamia trzy komendy, każda trafia tam razem z wynikiem, kodem wyjścia i czasem trwania, potem dziennik tego połączenia otwiera się w całości. Dziennik zostaje na Twoim komputerze.
Które bazy danych są obsługiwane?
Czy agent AI może pisać do mojej bazy danych?
Jak dostać się do bazy w prywatnej podsieci?
Czy moi agenci widzą hasło do bazy danych?
Czy agent może uruchomić kilka poleceń naraz?
Co zmienia oznaczenie połączenia jako produkcyjne?
Co się dzieje z zapytaniem, które zwraca mnóstwo wierszy?
Czy agent może dodać połączenie z bazą danych?
Skąd agent poznaje mój schemat?
Czy moje połączenia z bazami danych synchronizują się między maszynami?
Czy mogę zrzucić bazę danych i zaimportować ją gdzie indziej?
Jak chronione jest konto, które przechowuje moje połączenia?
Zrzuty ekranu
Prawdziwe zrzuty z aplikacji, dodawane w miarę rozwoju tej funkcji.
Połącz Google BigQuery za pomocą własnego logowania Google 
Ogranicz, ile jedno zapytanie BigQuery może naliczyć, na połączenie 
Bezpośrednie połączenia TLS weryfikują certyfikat serwera, z możliwością wyboru dla serwerów z własnym podpisem
Może Cię też zainteresować
RDS przez AWS SSM
Sięgnij po instancję Amazon RDS bez publicznego endpointu, z własnej maszyny, przez aws ssm start-session i dokument AWS-StartPortForwardingSessionToRemoteHost. Bez bastionu do utrzymania, bez VPN, bez reguły przychodzącej dla SSH. AgentsRoom otwiera sesję na porcie loopback i przez nią podłącza swojego klienta bazy danych. MySQL, PostgreSQL, SQL Server i MongoDB, czyli RDS MySQL, RDS PostgreSQL, RDS for SQL Server, Aurora i DocumentDB.
Cloud SQL Auth Proxy
Sięgnij po instancję Cloud SQL for MySQL lub PostgreSQL z własnej maszyny, także przez prywatny adres IP, bez maszyny bastionowej. AgentsRoom uruchamia Cloud SQL Auth Proxy na porcie loopback z Twoimi gcloud Application Default Credentials, obsługuje uwierzytelnianie bazy danych przez IAM i pozwala agentom AI odpytywać ją tylko do odczytu.
Połączenia SSH
Zapisuj swoje połączenia SSH, otwieraj wbudowany terminal po SSH i uruchamiaj Claude Code, Codex lub Antigravity CLI bezpośrednio na zdalnym serwerze czy VPS. Uwierzytelnianie kluczem SSH lub hasłem, profile połączeń per projekt, bez osobnego klienta SSH.
Menedżer sekretów
Przechowuj klucze API, tokeny i hasła w pęku kluczy swojego systemu, odwołuj się do nich przez {{secret:NAME}} w komendach dev i środowiskach agentów, a AgentsRoom rozwiąże je przy starcie. Agenci widzą nazwy, nigdy wartości, i nic nie jest synchronizowane z serwerem.
Dev Terminals
Menedżer terminali per projekt i launcher procesów. Uruchamiaj backend, frontend i workery jednym kliknięciem, lokalnie lub na zdalnym serwerze.
AgentsRoom MCP
Serwer MCP, dzięki któremu Twoi agenci sterują samym AgentsRoom: projekty, terminale, backlog i połączenia, razem z zabezpieczeniami, które do tego należą.
Daj swoim agentom dane, a nie klucze
Pobierz AgentsRoom, zapisz swoje połączenia MySQL, PostgreSQL, SQL Server, MongoDB, SQLite i Google BigQuery, sięgnij po te serwerowe przez tunel SSH albo sesję AWS SSM i pozwól agentom odpytywać je tylko do odczytu, dopóki nie otworzysz połączenia na ich zapisy.
Aplikacja towarzysząca: monitoruj agentów w podróży
Użyj Claude, Codex, Antigravity CLI lub innego dostawcy AI.
Wysyłaj bugi i prośby bezpośrednio do swojego publicznego backlogu.
Agenci, których czytasz jak rozmowę
Każdy agent ma rolę, twarz i wątek, który czytasz jak komunikator.
