Deixe seus agentes consultarem o banco,
somente leitura até você decidir o contrário
O AgentsRoom gerencia as suas conexões MySQL, PostgreSQL, SQL Server, MongoDB, SQLite e Google BigQuery e dá aos seus agentes de IA de programação uma forma de executar consultas nelas. Somente leitura por padrão, uma instrução por vez, com a senha fora de alcance.
Um agente que consegue ler as linhas reais para de adivinhar sobre os seus dados. Um agente que não consegue escrever nelas deixa de ser um risco que você precisa supervisionar linha por linha.
Como o AgentsRoom alcança um banco de dados em uma sub-rede privada e responde a uma consulta somente leitura de um agente de IA.
Um agente de IA de programação que não enxerga os seus dados escreve código contra o esquema que ele imaginou. Ele inventa uma coluna, supõe que um enum tem três valores quando tem sete, e explica um bug com uma teoria em vez de uma linha. Dar a ele uma conexão de banco de dados resolve isso, e também é a forma mais rápida de transformar um agente prestativo em um incidente. O AgentsRoom foi construído em torno dessa tensão.
Você salva as suas conexões no aplicativo como faria em qualquer cliente de banco de dados: motor, host, porta, usuário, banco de dados, e TLS quando o servidor exige. Se o banco não é alcançável pela internet aberta, a conexão é roteada por um túnel SSH ou por uma sessão de redirecionamento de porta AWS SSM, usando as conexões SSH e SSM que você já salvou no AgentsRoom. É assim que um banco de dados em uma sub-rede privada vira algo que você pode consultar sem abri-lo para o mundo.
Toda conexão começa somente leitura. Um SELECT roda. Uma instrução que modificaria dados não roda, até você tornar aquela conexão específica gravável e confirmar a operação. Só uma instrução é aceita por chamada, então nada extra se esconde atrás de um ponto e vírgula, e os resultados são limitados para que uma consulta ampla não inunde um agente nem uma janela. Uma conexão também pode ser marcada como produção, o que torna a confirmação mais difícil de dar por acidente.
Ler não é o trabalho inteiro. Uma conexão salva em uma máquina aparece nas suas outras, então você configura um banco de dados uma vez em vez de uma vez por computador. E um banco pode ser exportado para um arquivo, restaurado a partir de um, ou copiado direto sobre outro servidor, pelos mesmos túneis: as operações pelas quais você costumava sair do aplicativo.
Um cliente de banco de dados que supõe que há um agente ao volante
MySQL, PostgreSQL, SQL Server, MongoDB, SQLite e Google BigQuery, com os motores de servidor alcançáveis em redes privadas, com as travas ligadas por padrão.
Conexões MySQL, PostgreSQL, SQL Server e MongoDB
Salve uma conexão por banco de dados: host, porta, usuário, o banco a abrir e TLS quando o servidor exige. O seu banco local, o de staging e a réplica de produção ficam todos na mesma lista, prontos para serem escolhidos em vez de redigitados.
Alcance um banco de dados privado
Um banco de dados em uma sub-rede privada não é um caso especial. Roteie a conexão por um túnel SSH ou por uma sessão de redirecionamento de porta AWS SSM e o AgentsRoom a abre para você, reaproveitando as conexões SSH e SSM que você já salvou no aplicativo. Uma instância Google Cloud SQL é alcançada pelo nome de conexão através do Cloud SQL Auth Proxy, com o seu próprio login gcloud e sem armazenar nada.
Somente leitura por padrão
Uma conexão nova consegue ler e nada mais. As consultas devolvem linhas, as instruções que mudariam dados são recusadas. Ninguém precisa lembrar de ativar o modo seguro, porque o modo seguro é onde toda conexão começa.
Duas travas antes de uma escrita
Escrever exige dois atos deliberados, não um. A conexão precisa ser tornada gravável, e a operação em si precisa ser confirmada explicitamente. Um único clique descuidado não consegue virar um UPDATE sem cláusula WHERE.
Uma instrução por chamada
Cada chamada carrega exatamente uma instrução. Qualquer coisa empilhada atrás de um ponto e vírgula é recusada em vez de executada, então uma leitura que parece uma leitura não consegue contrabandear uma segunda instrução junto. Além disso, os resultados são limitados.
Produção fica marcada
Marque uma conexão como produção e a confirmação fica mais dura. O banco de dados que importa para de parecer exatamente igual à cópia local, tanto para você no fim de um dia longo quanto para um agente atravessando uma lista de tarefas.
As suas conexões, em cada máquina
Uma conexão salva na máquina do escritório está lá no notebook: nome, host, porta, usuário, banco padrão e o túnel pelo qual ela passa. A única coisa que fica para trás é a senha, criptografada na máquina onde você a digitou, então cada máquina pede a senha uma vez.
Exportar, importar, copiar
Despeje um banco de dados em um arquivo .sql, jogue um arquivo desses dentro de um banco, ou copie um banco direto sobre outro. O destino é salvo antes de ser sobrescrito, e substituí-lo por inteiro é uma decisão separada, confirmada à parte.
Os agentes consultam o banco de dados, nunca ficam com a senha
As suas credenciais de banco de dados ficam armazenadas no AgentsRoom, não distribuídas. Um agente pede para executar uma consulta em uma conexão que conhece pelo nome, o aplicativo abre a conexão, executa a instrução e devolve as linhas. A senha nunca faz parte do que o agente recebe, nunca faz parte da consulta que ele escreve, e nunca faz parte da conversa que ele guarda.
A regra de somente leitura é a outra metade disso e, para um agente, não é algo de que ele consiga se safar na conversa. A ferramenta com que um agente consulta recusa tudo que não seja leitura, a menos que duas condições sejam verdadeiras: a conexão é gravável e você ativou "Permitir que os agentes escrevam" para essa conexão. A opção vem desativada por padrão, e a verificação acontece no aplicativo desktop e não no processo do agente. As suas próprias escritas no console continuam pedindo uma confirmação explícita, deliberadamente mais difícil de dar quando a conexão está marcada como produção. Quando uma conexão está aberta às escritas dos agentes, elas são executadas sem essa confirmação, então reserve a opção para um banco de dados que você confiaria ao agente. Em todos os outros casos, o pior desfecho de uma consulta ruim continua sendo uma resposta errada, não uma tabela perdida.
A regra de uma instrução por chamada fecha a brecha clássica. Uma chamada que carrega uma instrução não pode ser estendida com um ponto e vírgula e uma segunda, então uma consulta que parece inofensiva em uma revisão não consegue fazer outra coisa na hora da execução. O SQL Server não precisa desse ponto e vírgula, então ali uma leitura é um SELECT ou um WITH sem nenhuma palavra-chave de escrita ou de transação em lugar nenhum, e ela roda dentro de uma transação que sempre é revertida. Combinado com resultados limitados, um erro continua sendo um erro em vez de virar uma exportação.
Seis motores, e dizemos quais faltam
MySQL e MariaDB, PostgreSQL, SQL Server (Azure SQL e Amazon RDS for SQL Server incluídos), MongoDB, SQLite e Google BigQuery. Cada um tem o seu próprio driver, em vez de uma camada de tradução, porque eles são de fato diferentes: uma sessão PostgreSQL ou SQL Server fica presa a um único banco, o MongoDB recebe uma consulta e não SQL, o T-SQL não precisa de ponto e vírgula entre duas instruções, cada exportação roda as ferramentas que vêm com aquele motor, o SQLite é simplesmente um arquivo no seu computador, sem host, usuário nem senha, e uma conexão BigQuery é um projeto do Google Cloud e um conjunto de dados padrão, acessado com o seu próprio login Google (gcloud auth application-default login), sem nenhuma chave armazenada. Os quatro motores de servidor são alcançados diretamente, ou por um túnel SSH ou uma sessão de redirecionamento de porta AWS SSM quando não estão expostos na internet aberta.
Oracle, Redis e os demais não são suportados. No SQL Server, você entra com um login SQL (a autenticação Windows, Active Directory e Entra ID não é oferecida), e não há exportação, importação nem cópia. No BigQuery, o Google cobra cada consulta pelos bytes que ela lê, então cada conexão tem um teto de cobrança por consulta (1 GiB por padrão, ajustável): uma consulta acima dele é recusada em vez de cobrada. Abrir uma tabela é gratuito e somente leitura, os seus agentes usam as mesmas ferramentas db_list, db_schema e db_query com as mesmas travas e veem quantos bytes cada consulta leu, e lá também não há exportação, importação nem cópia. Você merece saber disso antes do download, não depois. Qual motor vem em seguida é decidido pelo que as pessoas pedem, então, se o seu está faltando, diga qual no backlog público e ele entra na conta.
Peça o seu motor de banco de dadosMova um banco de dados, não só leia
Exporte um banco de dados para um arquivo. Importe um arquivo para dentro de um banco. Ou copie um banco direto sobre outro, inclusive através do túnel SSH ou da sessão AWS SSM que você já salvou. Cada motor roda as suas próprias ferramentas oficiais, que escrevem em fluxo no disco, então um banco de vários gigabytes vira uma barra de progresso e não um travamento.
Essas ferramentas vêm com o banco de dados, não com o AgentsRoom: mysqldump e mysql, pg_dump e psql, mongodump e mongorestore. O SQL Server não tem um equivalente que transmita um banco de dados inteiro, então as conexões dele não têm exportação, importação nem cópia. Quando as ferramentas faltam, o aplicativo diz exatamente quais e deixa você apontar a pasta onde elas ficam, como um cliente de banco de dados deve fazer: aberto pelo Dock ou pelo menu Iniciar, um aplicativo enxerga só um PATH mínimo e, sem isso, diria que elas faltam em uma máquina que as tem.
É na cópia que um clique errado custa um dia, então ela foi construída em torno disso, e não em torno do caminho tranquilo.
- Uma conexão somente leitura recusa a importação de cara, antes de abrir qualquer coisa.
- O destino é exportado para um arquivo escolhido por você antes que uma única instrução seja aplicada.
- A confirmação diz o nome da conexão e o do banco de dados, e fala mais alto quando a conexão está marcada como produção.
- Apagar e recriar o banco de destino é uma opção separada, e em uma conexão de produção você precisa digitar o nome do banco.
De um banco de dados privado a uma resposta
Salve a conexão, roteie-a, depois consulte ou deixe um agente consultar.
Salve a conexão
Adicione o banco de dados: host, porta, usuário, o nome do banco, e TLS se o servidor exigir. Dê a ele um nome que você vá reconhecer depois, e marque como produção se for o caso.
Roteie se for privado
Se o banco de dados não for alcançável diretamente, aponte a conexão para um túnel SSH ou para uma sessão de redirecionamento de porta AWS SSM montada a partir das conexões já salvas no AgentsRoom. Um banco em uma sub-rede privada fica alcançável sem ser exposto publicamente. No Google Cloud, escolha a instância Cloud SQL: o AgentsRoom inicia o Cloud SQL Auth Proxy para você.
Consulte, ou deixe um agente consultar
Execute a sua instrução pelo aplicativo, ou deixe um agente executar uma por MCP. Somente leitura até você mudar isso, uma instrução por chamada, resultados limitados, e uma confirmação explícita entre qualquer escrita e os seus dados.
Quando um agente precisa das linhas reais
Os momentos em que ler os dados de produção é o caminho mais curto até a correção.
Depure com dados reais
O bug só aparece para um punhado de contas. Deixe o agente ler essas linhas e ele encontra o valor que quebra a lógica, em vez de propor três teorias sobre como os dados poderiam ser.
Um banco de dados que não é público
O banco de dados vive em uma sub-rede privada, sem endpoint público. Roteie a conexão por um túnel SSH ou por uma sessão AWS SSM montada sobre as suas conexões salvas, e consulte sem abrir uma porta para a internet.
Deixe o agente conferir, não adivinhar
Antes de escrever uma migração ou uma consulta, um agente pode olhar o que está realmente armazenado. Ele lê, ele relata e, a menos que você tenha aberto essa conexão às escritas dos agentes, não tem como mudar nada enquanto faz isso.
Produção, sem o risco de escrita
Ler a produção costuma ser necessário, escrever nela quase nunca é, no meio de uma tarefa. Marque a conexão como produção, mantenha-a somente leitura, e a diferença entre investigar e quebrar deixa de depender da atenção de alguém.
Atualize o staging com dados reais
O bug só se reproduz com linhas reais. Copie o banco de dados sobre o seu servidor de staging, pelo túnel que você já salvou, com o que estava lá exportado para um arquivo antes.
Você abre o notebook e está tudo lá
As suas conexões acompanham a sua conta: mesmos hosts, mesmos túneis, mesmas marcações de somente leitura e de produção. Com as senhas sincronizadas ativadas, as senhas também acompanham, criptografadas de ponta a ponta, e nada precisa ser redigitado; sem elas, cada máquina pede a senha uma vez.
Como os meus agentes consultam o banco de dados?
Pelo AgentsRoom MCP, com quatro ferramentas. db_list devolve as suas conexões salvas e os metadados delas, db_schema percorre os esquemas, as tabelas e as colunas sem uma linha de SQL, db_query executa uma instrução e devolve as linhas, e db_connection_new propõe um banco de dados que você ainda não salvou. O AgentsRoom abre a conexão, incluindo o túnel SSH ou a sessão AWS SSM na frente dela quando existe. O que volta para o agente é um conjunto de resultados, nunca uma credencial.
Os agentes só podem escrever quando você ativa "Permitir que os agentes escrevam" em uma conexão que também é gravável. Essa opção, que precisa ser ativada de propósito, vem desativada por padrão e é sincronizada com a conexão em toda a sua conta. Depois de ativada, as escritas são executadas imediatamente, por isso use-a apenas se você confiar esse banco de dados ao agente. O aplicativo desktop verifica a permissão no seu processo principal, e o db_query continua aceitando apenas uma instrução por chamada.
Registrar um banco de dados também pode ser trabalho inteiramente do agente. db_connection_new mantém o caminho revisado: abre o formulário de criação já preenchido com o host, o usuário e a conexão SSH ou AWS SSM pela qual o banco deve ser alcançado, e você revisa, digita a senha e salva, nada sendo armazenado até você fazer isso. A não ser que você desative "Os agentes podem gerenciar as conexões" (Configurações, ativado por padrão), db_connection_save grava a conexão diretamente, e a senha continua nunca atravessando a conversa: ela é copiada de um segredo do cofre que o agente apenas cita pelo nome. O agente recebe o que precisa para raciocinar sobre os seus dados, e nenhum dos caminhos pelos quais esse acesso costuma virar um incidente está disponível para ele.
Cada consulta que um agente executa também fica visível. As chamadas de db_query e db_schema chegam à aba Atividade do painel direito, com o SQL e as primeiras linhas retornadas, em um registro por banco de dados; o avatar do agente aparece no botão Bases de dados e, com o selo Agente trabalhando, na sua lista Bases de dados. Você também pode acompanhá-lo pelo celular, no cartão do agente do app mobile. Esse registro só trafega entre o seu computador e o seu celular, criptografado de ponta a ponta e com os segredos ocultos: nenhum resultado é armazenado em um servidor.
Descubra o AgentsRoom MCPA mesma aba Atividade que lista as suas chamadas db_query e db_schema, filmada aqui em um servidor SSH salvo: um agente executa três comandos, cada um chega com a sua saída, o seu código de saída e a sua duração, depois o registro dessa conexão abre inteiro. Esse registro fica no seu computador.
Perguntas frequentes
Faça outra perguntaQuais bancos de dados são suportados?
Um agente de IA pode escrever no meu banco de dados?
Como alcanço um banco de dados em uma sub-rede privada?
Os meus agentes veem a senha do banco de dados?
Um agente pode executar várias instruções de uma vez?
O que muda ao marcar uma conexão como produção?
O que acontece com uma consulta que devolve muitas linhas?
Um agente pode adicionar uma conexão de banco de dados?
Como um agente descobre o meu esquema?
As minhas conexões de banco de dados são sincronizadas entre as minhas máquinas?
Posso exportar um banco de dados e importar em outro lugar?
Como é protegida a conta que guarda as minhas conexões?
Capturas de tela
Capturas reais do app, adicionadas conforme este recurso evolui.
Conecte o Google BigQuery com seu próprio login do Google 
Limite o que uma consulta do BigQuery pode cobrar, por conexão 
Conexões TLS diretas verificam o certificado do servidor, com uma opção para servidores autoassinados
Você também pode gostar
RDS via AWS SSM
Alcance uma instância Amazon RDS que não tem endpoint público, a partir da sua própria máquina, com aws ssm start-session e o documento AWS-StartPortForwardingSessionToRemoteHost. Sem bastion para manter, sem VPN, sem regra SSH de entrada. O AgentsRoom abre a sessão em uma porta loopback e conecta o cliente de banco de dados através dela. MySQL, PostgreSQL, SQL Server e MongoDB, ou seja, RDS MySQL, RDS PostgreSQL, RDS for SQL Server, Aurora e DocumentDB.
Cloud SQL Auth Proxy
Alcance uma instância Cloud SQL para MySQL ou PostgreSQL a partir da sua própria máquina, inclusive com IP privado, sem uma VM bastion. O AgentsRoom inicia o Cloud SQL Auth Proxy em uma porta loopback com as suas Application Default Credentials do gcloud, oferece suporte à autenticação de banco de dados IAM e deixa agentes de IA consultá-la somente leitura.
Conexões SSH
Salve suas conexões SSH, abra um terminal integrado via SSH e execute o Claude Code, o Codex ou o Antigravity CLI diretamente no seu servidor remoto ou VPS. Autenticação por chave SSH ou senha, perfis de conexão por projeto, sem precisar de um cliente SSH separado.
Gerenciador de segredos
Armazene chaves de API, tokens e senhas no chaveiro do seu sistema operacional, referencie-os como {{secret:NAME}} nos comandos de dev e nos ambientes dos agentes, e deixe o AgentsRoom resolvê-los na inicialização. Os agentes veem os nomes, nunca os valores, e nada é sincronizado com um servidor.
Dev Terminals
Gerenciador de terminais e inicializador de processos por projeto. Inicie backend, frontend e workers com um clique, localmente ou em um servidor remoto.
AgentsRoom MCP
O servidor MCP que deixa os seus agentes pilotarem o próprio AgentsRoom: projetos, terminais, backlog e conexões, com as travas que vêm junto.
Dê os dados aos seus agentes, não as chaves
Baixe o AgentsRoom, salve as suas conexões MySQL, PostgreSQL, SQL Server, MongoDB, SQLite e Google BigQuery, alcance as de servidor por um túnel SSH ou por uma sessão AWS SSM, e deixe os seus agentes consultá-las, somente leitura, a menos que você abra uma conexão às escritas deles.
App complementar: acompanhe seus agentes em qualquer lugar
Use Claude, Codex, Antigravity CLI ou outro provedor de IA.
Envie bugs e pedidos direto para o seu backlog público.
Agentes que você lê como uma conversa
Cada agente tem uma função, um rosto e um fio que você lê como um app de mensagens.
