Deixe seus agentes consultarem o banco,
somente leitura até você decidir o contrário
O AgentsRoom gerencia as suas conexões MySQL, PostgreSQL e MongoDB 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 e MongoDB, alcançáveis em redes privadas, com as travas ligadas por padrão.
Conexões MySQL, PostgreSQL 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.
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 é um padrão do qual ele consiga se safar na conversa. A ferramenta com que um agente consulta recusa tudo que não seja leitura, não importa o que aquela conexão permita. Tornar uma conexão gravável libera as escritas para você, no console, onde cada uma pede uma confirmação explícita que é deliberadamente mais difícil de dar quando a conexão está marcada como produção. O pior desfecho de um agente executando 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. Combinado com resultados limitados, um erro continua sendo um erro em vez de virar uma exportação.
Três motores, e dizemos quais faltam
MySQL e MariaDB, PostgreSQL e MongoDB. 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 fica presa a um único banco, o MongoDB recebe uma consulta e não SQL, e cada exportação roda as ferramentas que vêm com aquele motor. Os três alcançam um servidor diretamente, ou por um túnel SSH ou uma sessão de redirecionamento de porta AWS SSM quando ele não está exposto na internet aberta.
SQL Server, Oracle, SQLite, Redis e os demais não são suportados. 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. Quando 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.
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 nunca ganha a capacidade de 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. Cada máquina pede a senha uma vez, porque essa é a parte que nunca sai da máquina onde ela foi digitada.
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.
O db_query é somente leitura não importa o que a conexão permita. Tornar uma conexão gravável libera as escritas para você, no console, onde cada uma é confirmada explicitamente e onde uma conexão marcada como produção diz isso em alto e bom som. Não as libera para um agente: a regra de somente leitura do db_query vive no aplicativo desktop e não no processo MCP, então ela se mantém mesmo que alguém convença o agente a pedir outra coisa. Não é preciso uma senha para executar um DROP, e é por isso que a trava fica na instrução e não apenas na credencial.
O mesmo limite vale para registrar um banco de dados. db_connection_new 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 é armazenado até você fazer isso. 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.
Descubra o AgentsRoom MCPPerguntas frequentes
Quais bancos de dados são suportados?
MySQL e MariaDB, PostgreSQL e MongoDB. Cada um tem o seu próprio driver, e cada um é alcançável diretamente ou por um túnel SSH ou uma sessão de redirecionamento de porta AWS SSM. SQL Server, Oracle, SQLite e o resto não são suportados hoje. Se você precisa de um deles, peça no backlog público: a lista cresce conforme o que as pessoas realmente pedem.
Um agente de IA pode escrever no meu banco de dados?
Não. A ferramenta MCP com que um agente consulta, db_query, é somente leitura não importa o que a conexão permita: um SELECT, um SHOW ou um EXPLAIN passam, e um find ou um aggregate do MongoDB também, enquanto tudo que mudaria dados é recusado. Tornar uma conexão gravável libera as escritas para você no console, onde cada uma é confirmada explicitamente, não para um agente. A trava fica na instrução e não na senha, porque não é uma senha que basta para executar um DROP.
Como alcanço um banco de dados em uma sub-rede privada?
Roteie a conexão por um túnel SSH ou por uma sessão de redirecionamento de porta AWS SSM, montada a partir das conexões SSH e SSM que você já salvou no AgentsRoom. O aplicativo abre o túnel ou a sessão e conecta o banco de dados através dele, de modo que o banco continua inalcançável pela internet pública.
Os meus agentes veem a senha do banco de dados?
Não. Os agentes consultam por MCP nomeando uma conexão. O AgentsRoom detém as credenciais e executa a instrução ele mesmo, então a senha nunca é devolvida ao agente, nunca é escrita na consulta e nunca faz parte da conversa.
Um agente pode executar várias instruções de uma vez?
Não. Uma chamada carrega exatamente uma instrução. Qualquer coisa empilhada atrás de um ponto e vírgula é recusada em vez de executada, o que elimina a forma mais antiga de esconder uma escrita dentro de algo que parece uma leitura.
O que muda ao marcar uma conexão como produção?
Endurece a confirmação exigida antes de uma escrita. O banco de dados que importa deixa de se comportar como a cópia local, que é o que você quer no fim de um dia longo e o que você quer ainda mais de um agente atravessando uma lista de tarefas.
O que acontece com uma consulta que devolve muitas linhas?
Os resultados são limitados. Uma consulta que devolveria uma tabela enorme volta truncada em vez de inundar a janela ou o contexto do agente, então um SELECT amplo continua sendo um incômodo em vez de uma exportação dos seus dados.
Um agente pode adicionar uma conexão de banco de dados?
Ele pode propor uma, nunca salvar uma. db_connection_new abre o formulário de criação já preenchido com o host, a porta, o usuário e a conexão SSH ou AWS SSM pela qual o banco de dados deve ser alcançado, e você revisa, digita a senha e salva. Nada é armazenado até você fazer isso, e o agente nunca fornece uma credencial.
Como um agente descobre o meu esquema?
Com db_schema, que explora uma conexão salva sem nenhum SQL. Chamado sem argumento, ele lista os esquemas; com um banco de dados, lista as tabelas e as views; com uma tabela, devolve as colunas, seus tipos, se aceitam nulo, suas chaves e seus valores padrão. É mais barato e mais seguro do que fazer um agente consultar information_schema à mão.
As minhas conexões de banco de dados são sincronizadas entre as minhas máquinas?
A conexão sim, a senha não. O nome, o host, a porta, o usuário, o banco padrão, o escopo, as marcações de somente leitura e de produção e o túnel SSH ou SSM pelo qual ela passa acompanham a sua conta: uma conexão salva em uma máquina aparece nas outras em vez de ser redigitada. A senha continua criptografada no chaveiro da máquina onde você a digitou e nunca é enviada para nós, e é por isso que uma conexão que chega de outra máquina aparece marcada como aguardando a senha antes de poder ser aberta.
Posso exportar um banco de dados e importar em outro lugar?
Pode. Você exporta um banco de dados para um arquivo, importa um arquivo desses para dentro de um banco, ou copia um banco direto sobre outro, inclusive através dos túneis SSH ou SSM que você já salvou. Cada motor roda as suas próprias ferramentas oficiais (mysqldump e mysql, pg_dump e psql, mongodump e mongorestore), que vêm com o banco de dados e não com o AgentsRoom: se elas não forem encontradas, o aplicativo pede que você indique a pasta onde estão. Uma cópia só roda entre duas conexões do mesmo motor, porque um dump só é restaurado no motor que o gerou. Em uma conexão somente leitura o import é recusado, o destino é exportado para um arquivo escolhido por você antes que qualquer coisa seja escrita nele, e substituir o destino é uma opção separada cuja confirmação diz o nome do banco.
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 e MongoDB, ou seja, RDS MySQL, RDS PostgreSQL, Aurora e DocumentDB.
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 e MongoDB, alcance-as por um túnel SSH ou por uma sessão AWS SSM, e deixe os seus agentes consultá-las somente leitura.
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.