Lascia che i tuoi agenti interroghino il database,
in sola lettura finché non decidi altrimenti
AgentsRoom gestisce le tue connessioni MySQL, PostgreSQL, SQL Server, MongoDB, SQLite e Google BigQuery e dà ai tuoi agenti di coding IA un modo per eseguire query su di esse. In sola lettura per impostazione predefinita, una istruzione alla volta, con la password tenuta fuori portata.
Un agente che può leggere le righe reali smette di tirare a indovinare sui tuoi dati. Un agente che non può scriverle smette di essere un rischio da sorvegliare riga per riga.
Come AgentsRoom raggiunge un database in una subnet privata e risponde a una query in sola lettura di un agente IA.
Un agente di coding IA che non vede i tuoi dati scrive codice contro lo schema che ha immaginato. Inventa una colonna, dà per scontato che un enum abbia tre valori quando ne ha sette, e spiega un bug con una teoria invece che con una riga. Dargli una connessione al database risolve il problema, ed è anche il modo più rapido di trasformare un agente utile in un incidente. AgentsRoom è costruito attorno a questa tensione.
Salvi le tue connessioni nell'app come faresti in qualsiasi client di database: motore, host, porta, utente, database e TLS quando il server lo richiede. Se il database non è raggiungibile da internet, la connessione viene instradata tramite un tunnel SSH o una sessione di port forwarding AWS SSM, usando le connessioni SSH e SSM che hai già salvato in AgentsRoom. È così che un database che sta in una subnet privata diventa qualcosa che puoi interrogare senza aprirlo al mondo.
Ogni connessione nasce in sola lettura. Un SELECT viene eseguito. Un'istruzione che modificherebbe i dati no, finché non hai reso scrivibile quella specifica connessione e confermato l'operazione. Viene accettata una sola istruzione per chiamata, quindi nulla di extra si nasconde dietro un punto e virgola, e i risultati sono limitati perché una query troppo ampia non possa sommergere un agente o una finestra. Una connessione può anche essere contrassegnata come produzione, il che rende la conferma più difficile da dare per sbaglio.
Leggere non è tutto il lavoro. Una connessione salvata su una macchina si ritrova sulle altre, così configuri un database una volta sola invece che una volta per computer. E un database si esporta in un file, si ripristina da un file, oppure si copia direttamente su un altro server, attraverso gli stessi tunnel: le operazioni per cui prima dovevi uscire dall'app.
Un client di database che dà per scontato che alla guida ci sia un agente
MySQL, PostgreSQL, SQL Server, MongoDB, SQLite e Google BigQuery, con i motori server raggiungibili in reti private e le protezioni attive per impostazione predefinita.
Connessioni MySQL, PostgreSQL, SQL Server e MongoDB
Salva una connessione per database: host, porta, utente, il database da aprire e TLS quando il server lo richiede. Il tuo database locale, quello di staging e la replica di produzione vivono nella stessa lista, pronti da scegliere invece che da ridigitare.
Raggiungi un database privato
Un database in una subnet privata non è un caso speciale. Instrada la connessione tramite un tunnel SSH o una sessione di port forwarding AWS SSM e AgentsRoom la apre per te, riutilizzando le connessioni SSH e SSM che hai già salvato nell'app. Un'istanza Google Cloud SQL si raggiunge con il suo nome di connessione tramite il Cloud SQL Auth Proxy, con il tuo login gcloud e senza memorizzare nulla.
In sola lettura per impostazione predefinita
Una nuova connessione può leggere e nient'altro. Le query restituiscono righe, le istruzioni che cambierebbero i dati vengono rifiutate. Nessuno deve ricordarsi di attivare la modalità sicura, perché la modalità sicura è il punto di partenza di ogni connessione.
Due lucchetti prima di una scrittura
Scrivere richiede due atti deliberati, non uno. La connessione deve essere resa scrivibile, e l'operazione stessa deve essere confermata in modo esplicito. Un singolo clic distratto non può concatenarsi in un UPDATE senza clausola WHERE.
Una sola istruzione per chiamata
Ogni chiamata porta esattamente un'istruzione. Tutto ciò che è impilato dietro un punto e virgola viene rifiutato invece che eseguito, quindi una lettura che sembra una lettura non può contrabbandare con sé una seconda istruzione. In più, i risultati sono limitati.
La produzione è contrassegnata
Contrassegna una connessione come produzione e la conferma diventa più severa. Il database che conta smette di sembrare identico alla copia locale, sia per te alla fine di una lunga giornata sia per un agente che sta smaltendo una lista di task.
Le tue connessioni, su ogni macchina
Una connessione salvata sulla macchina dell'ufficio si ritrova sul portatile: nome, host, porta, utente, database predefinito e il tunnel che attraversa. L'unica cosa che resta indietro è la password, cifrata sulla macchina dove l'hai digitata, così ogni macchina te la chiede una volta sola.
Esportare, importare, copiare
Scarica un database in un file .sql, rimetti un file del genere dentro un database, oppure copia un database direttamente su un altro. La destinazione viene salvata prima di essere sovrascritta, e sostituirla del tutto è una decisione a parte, da confermare.
Gli agenti interrogano il database, non tengono mai la password
Le tue credenziali di database sono conservate da AgentsRoom, non distribuite. Un agente chiede di eseguire una query su una connessione che conosce per nome, l'app apre la connessione, esegue l'istruzione e restituisce le righe. La password non fa mai parte di ciò che l'agente riceve, né della query che scrive, né della conversazione che conserva.
La regola di sola lettura è l'altra metà del discorso, e un agente non può uscirne a forza di parole. Lo strumento con cui un agente interroga rifiuta tutto ciò che non è una lettura, a meno che non valgano due condizioni: la connessione è scrivibile e hai attivato "Consenti agli agenti di scrivere" per quella connessione. L'opzione è disattivata per impostazione predefinita, e il controllo avviene nell'app desktop invece che nel processo dell'agente. Le tue scritture nella console chiedono sempre una conferma esplicita, volutamente più difficile da dare quando la connessione è contrassegnata come produzione. Una volta che una connessione è aperta alle scritture degli agenti, queste vengono eseguite senza quella conferma, quindi riserva l'opzione a un database che affideresti all'agente. In tutti gli altri casi, il peggio che può produrre una query sbagliata resta una risposta sbagliata, non una tabella persa.
La regola dell'istruzione singola chiude la falla classica. Una chiamata che porta una sola istruzione non può essere estesa con un punto e virgola e una seconda, quindi una query che in revisione sembra innocua non può fare altro al momento dell'esecuzione. SQL Server non ha bisogno di quel punto e virgola, quindi lì una lettura è un SELECT o un WITH senza alcuna parola chiave di scrittura o di transazione, ed è eseguita dentro una transazione che viene sempre annullata con un rollback. Unito ai risultati limitati, un errore resta un errore invece di diventare un'esportazione.
Sei motori, e diciamo quali mancano
MySQL e MariaDB, PostgreSQL, SQL Server (Azure SQL e Amazon RDS for SQL Server inclusi), MongoDB, SQLite e Google BigQuery. Ognuno ha il proprio driver invece di uno strato di traduzione, perché sono davvero diversi: una sessione PostgreSQL o SQL Server è legata a un solo database, MongoDB riceve una query e non SQL, T-SQL non ha bisogno di un punto e virgola tra due istruzioni, ogni esportazione si appoggia agli strumenti forniti con quel motore, SQLite è semplicemente un file sul tuo computer, senza host, utente né password, e una connessione BigQuery è un progetto Google Cloud con un set di dati predefinito, a cui accedi con il tuo account Google (gcloud auth application-default login), senza alcuna chiave salvata. I quattro motori server si raggiungono in modo diretto, oppure tramite un tunnel SSH o una sessione di port forwarding AWS SSM quando non sono esposti su internet.
Oracle, Redis e gli altri non sono supportati. Su SQL Server accedi con un login SQL (l'autenticazione Windows, Active Directory ed Entra ID non è disponibile), e non ci sono esportazione, importazione né copia. Su BigQuery, Google fattura ogni query in base ai byte che legge, quindi ogni connessione ha un tetto di fatturazione per query (1 GiB per impostazione predefinita, modificabile): una query che lo supera viene rifiutata invece di essere addebitata. Aprire una tabella è gratuito e in sola lettura, i tuoi agenti usano gli stessi strumenti db_list, db_schema e db_query con le stesse protezioni e vedono i byte letti da ogni query, e anche lì non ci sono esportazione, importazione né copia. Meriti di saperlo prima del download, non dopo. Quale motore arriva dopo lo decide ciò che le persone chiedono, quindi se manca il tuo, dì quale sul backlog pubblico e verrà conteggiato.
Richiedi il tuo motore di databaseSposta un database, non limitarti a leggerlo
Esporta un database in un file. Importa un file dentro un database. Oppure copia un database direttamente su un altro, anche attraverso il tunnel SSH o la sessione AWS SSM che hai già salvato. Ogni motore si appoggia ai propri strumenti ufficiali, che scrivono su disco in streaming, così un database da diversi gigabyte diventa una barra di avanzamento e non un crash.
Quegli strumenti arrivano con il database, non con AgentsRoom: mysqldump e mysql, pg_dump e psql, mongodump e mongorestore. SQL Server non ha un equivalente che trasmetta un intero database, quindi le sue connessioni non hanno esportazione, importazione né copia. Quando gli strumenti mancano, l'app dice esattamente quali e ti lascia indicare la cartella che li contiene, come dovrebbe fare un client di database: avviata dal Dock o dal menu Start, un'app vede solo un PATH minimo e altrimenti li darebbe per mancanti su una macchina che li ha.
È nella copia che un clic sbagliato costa una giornata, quindi è costruita attorno a questo e non attorno al caso ideale.
- Una connessione in sola lettura rifiuta l'importazione in partenza, prima ancora che venga aperto qualcosa.
- La destinazione viene salvata in un file che scegli tu prima che venga applicata una sola istruzione.
- La conferma nomina la connessione e il database, e alza la voce quando la connessione è contrassegnata come produzione.
- Eliminare e ricreare il database di destinazione è un'opzione separata, e su una connessione di produzione devi ridigitare il nome del database.
Da un database privato a una risposta
Salva la connessione, instradala, poi interrogala o lascia che lo faccia un agente.
Salva la connessione
Aggiungi il database: host, porta, utente, il nome del database e TLS se il server lo richiede. Dagli un nome che riconoscerai in seguito, e contrassegnalo come produzione se è quello che è.
Instradala se è privata
Se il database non è raggiungibile direttamente, punta la connessione su un tunnel SSH o una sessione di port forwarding AWS SSM costruita a partire dalle connessioni già salvate in AgentsRoom. Un database in una subnet privata diventa raggiungibile senza esporlo pubblicamente. Su Google Cloud, scegli invece l'istanza Cloud SQL: AgentsRoom avvia il Cloud SQL Auth Proxy per te.
Interrogalo, o lascia che lo interroghi un agente
Esegui la tua istruzione dall'app, oppure lascia che un agente ne esegua una via MCP. In sola lettura finché non lo cambi, una sola istruzione per chiamata, risultati limitati, e una conferma esplicita tra qualsiasi scrittura e i tuoi dati.
Quando a un agente servono le righe vere
I momenti in cui leggere i dati di produzione è la strada più breve verso la correzione.
Debug sui dati reali
Il bug si manifesta solo per una manciata di account. Lascia che l'agente legga quelle righe e troverà il valore che rompe la logica, invece di proporre tre teorie su come potrebbero essere fatti i dati.
Un database che non è pubblico
Il database vive in una subnet privata senza endpoint pubblico. Instrada la connessione tramite un tunnel SSH o una sessione AWS SSM costruita sulle tue connessioni salvate, e interrogalo senza aprire una porta su internet.
Lascia che l'agente verifichi, non che indovini
Prima di scrivere una migrazione o una query, un agente può guardare cosa è davvero memorizzato. Legge, riferisce e, a meno che tu non abbia aperto quella connessione alle scritture degli agenti, non ha alcun modo di cambiare qualcosa mentre lo fa.
Produzione, senza il rischio di scrittura
Leggere la produzione è spesso necessario, scriverci quasi mai lo è nel mezzo di un task. Contrassegna la connessione come produzione, tienila in sola lettura, e la differenza tra indagare e rompere smette di dipendere dall'attenzione di qualcuno.
Aggiorna lo staging con dati reali
Il bug si riproduce solo su righe vere. Copia il database sul tuo server di staging, attraverso il tunnel che hai già salvato, dopo aver messo in salvo in un file quello che c'era prima.
Apri il portatile e c'è già tutto
Le tue connessioni seguono il tuo account: stessi host, stessi tunnel, stessi contrassegni di sola lettura e di produzione. Con le password sincronizzate attive, anche le password ti seguono, con crittografia end-to-end, e non devi ridigitare nulla; senza, ogni macchina ti chiede la password una volta sola.
Come fanno i miei agenti a interrogare il database?
Tramite AgentsRoom MCP, con quattro strumenti. db_list restituisce le tue connessioni salvate e i loro metadati, db_schema percorre gli schemi, le tabelle e le colonne senza una riga di SQL, db_query esegue una singola istruzione e restituisce le righe, e db_connection_new propone un database che non hai ancora salvato. AgentsRoom apre la connessione, incluso il tunnel SSH o la sessione AWS SSM che le sta davanti quando c'è. Quello che torna all'agente è un insieme di risultati, mai una credenziale.
Gli agenti possono scrivere solo quando attivi "Consenti agli agenti di scrivere" su una connessione che è anche scrivibile. Questa opzione, da attivare volontariamente, è disattivata per impostazione predefinita e si sincronizza con la connessione su tutto il tuo account. Una volta attivata, le scritture vengono eseguite subito, quindi usala solo se ti fidi dell'agente su quel database. L'app desktop verifica il permesso nel suo processo principale, e db_query accetta comunque una sola istruzione per chiamata.
Registrare un database può essere anche interamente compito dell'agente. db_connection_new mantiene il percorso rivisto: apre il modulo di creazione precompilato con l'host, l'utente e la connessione SSH o AWS SSM attraverso cui raggiungerlo, e sei tu a rivederlo, a digitare la password e a salvare, senza che nulla venga memorizzato prima che tu lo faccia. A meno che tu non disattivi "Gli agenti possono gestire le connessioni" (Impostazioni, attivo per impostazione predefinita), db_connection_save scrive la connessione direttamente, e la password continua a non passare mai dalla conversazione: viene copiata da un segreto della cassaforte che l'agente si limita a nominare. L'agente ottiene ciò che gli serve per ragionare sui tuoi dati, e nessuno dei modi in cui quell'accesso di solito si trasforma in un incidente è a sua disposizione.
Anche ogni query di un agente è visibile. Le chiamate a db_query e db_schema arrivano nella scheda Attività del pannello di destra, con l'SQL e le prime righe restituite, in un registro per ogni database; l'avatar dell'agente compare sul pulsante Database e, con il badge Agente al lavoro, nella tua lista Database. Puoi seguirlo anche dal telefono, nella scheda dell'agente dell'app mobile. Quel registro viaggia solo tra il tuo computer e il tuo telefono, cifrato end-to-end e con i segreti mascherati: nessun risultato viene salvato su un server.
Scopri AgentsRoom MCPLa stessa scheda Attività che elenca le tue chiamate db_query e db_schema, ripresa qui su un server SSH salvato : un agente esegue tre comandi, ognuno arriva con il suo output, il suo codice di uscita e la sua durata, poi il registro di quella connessione si apre per intero. Quel registro resta sul tuo computer.
Quali database sono supportati?
Un agente IA può scrivere sul mio database?
Come raggiungo un database in una subnet privata?
I miei agenti vedono la password del database?
Un agente può eseguire più istruzioni in una volta sola?
Cosa cambia contrassegnare una connessione come produzione?
Cosa succede con una query che restituisce moltissime righe?
Un agente può aggiungere una connessione a un database?
Come fa un agente a conoscere il mio schema?
Le mie connessioni ai database si sincronizzano tra le mie macchine?
Posso esportare un database e importarlo altrove?
Come è protetto l'account che contiene le mie connessioni?
Screenshot
Schermate reali dell'app, aggiunte man mano che questa funzione evolve.
Connetti Google BigQuery con il tuo login Google personale 
Limita quanto può fatturare una singola query BigQuery, per connessione 
Le connessioni TLS dirette verificano il certificato del server, con un'opzione per i server con certificati autofirmati
Potrebbe interessarti anche
RDS tramite AWS SSM
Raggiungi dalla tua macchina un'istanza Amazon RDS priva di endpoint pubblico, tramite aws ssm start-session e il documento AWS-StartPortForwardingSessionToRemoteHost. Nessun bastion da mantenere, nessuna VPN, nessuna regola SSH in ingresso. AgentsRoom apre la sessione su una porta di loopback e ci collega attraverso il suo client di database. MySQL, PostgreSQL, SQL Server e MongoDB, quindi RDS MySQL, RDS PostgreSQL, RDS for SQL Server, Aurora e DocumentDB.
Cloud SQL Auth Proxy
Raggiungi dalla tua macchina un'istanza Cloud SQL per MySQL o PostgreSQL, anche con IP privato, senza una VM bastion. AgentsRoom avvia il Cloud SQL Auth Proxy su una porta di loopback con le tue Application Default Credentials di gcloud, supporta l'autenticazione database IAM e permette agli agenti IA di interrogarla in sola lettura.
Connessioni SSH
Salva le tue connessioni SSH, apri un terminale SSH integrato ed esegui Claude Code, Codex o Antigravity CLI direttamente sul tuo server remoto o VPS. Autenticazione con chiave SSH o password, profili di connessione per progetto, senza un client SSH separato.
Gestore di segreti
Conserva chiavi API, token e password nel portachiavi del tuo sistema operativo, richiamali come {{secret:NAME}} nei comandi di sviluppo e negli ambienti degli agenti, e lascia che AgentsRoom li risolva all'avvio. Gli agenti vedono i nomi, mai i valori, e nulla viene mai sincronizzato su un server.
Dev Terminals
Gestore di terminali e lanciatore di processi per progetto. Avvia backend, frontend e worker con un clic, in locale o su un server remoto.
AgentsRoom MCP
Il server MCP che permette ai tuoi agenti di pilotare AgentsRoom stesso: progetti, terminali, backlog e connessioni, con le protezioni che ne fanno parte.
Dai ai tuoi agenti i dati, non le chiavi
Scarica AgentsRoom, salva le tue connessioni MySQL, PostgreSQL, SQL Server, MongoDB, SQLite e Google BigQuery, raggiungi quelle server tramite un tunnel SSH o una sessione AWS SSM, e lascia che i tuoi agenti le interroghino, in sola lettura finché non apri una connessione alle loro scritture.
App companion: monitora i tuoi agenti in movimento
Usa Claude, Codex, Antigravity CLI o un altro provider IA.
Invia bug e richieste direttamente nel tuo backlog pubblico.
Agenti che leggi come una conversazione
Ogni agente ha un ruolo, una faccia e un thread che leggi come un'app di messaggistica.
