Big Three

Guia

Acesso somente leitura ao banco para Claude, Gemini e Codex

Perguntar a um modelo sobre seus dados é útil. Entregar a ele a senha do banco, não. O Big Three coloca um pequeno broker no meio: o modelo pede, o broker confere e executa um SELECT, e a senha nunca sai do cofre do seu Windows.

Atualizado em November 4, 2026

O caminho de uma consulta

Um modelo nunca abre uma conexão. Ele envia um pedido ao broker, um processo pequeno dentro do Big Three. O broker lê a senha no Gerenciador de Credenciais do Windows, abre uma transação somente leitura, executa a consulta e devolve as linhas, com limite.

  1. Você salva uma conexão uma vez. A senha vai direto para o cofre do sistema.
  2. Em cada conversa você escolhe quais conexões os modelos podem consultar. Nenhuma por padrão.
  3. Um modelo autorizado pede ao broker um SELECT.
  4. O broker confere a consulta, executa em transação somente leitura com tempo e limite de linhas, e devolve resultados ou erros sanitizados.
  5. Toda chamada vai para um registro de auditoria.

Passo um: crie um usuário só com SELECT

Essa é a camada que importa. Aconteça o que acontecer acima dela, o próprio banco se recusa a escrever. Crie um usuário dedicado e dê a ele apenas as tabelas que os modelos podem ver. Troque os nomes e a senha.

PostgreSQL

CREATE ROLE big_three_ro LOGIN PASSWORD 'escolha-uma-senha-longa';
GRANT CONNECT ON DATABASE meubanco TO big_three_ro;
GRANT USAGE ON SCHEMA public TO big_three_ro;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO big_three_ro;
ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT ON TABLES TO big_three_ro;

MySQL

CREATE USER 'big_three_ro'@'localhost' IDENTIFIED BY 'escolha-uma-senha-longa';
GRANT SELECT ON meubanco.* TO 'big_three_ro'@'localhost';

Oracle

CREATE USER big_three_ro IDENTIFIED BY "escolha-uma-senha-longa";
GRANT CREATE SESSION TO big_three_ro;
GRANT SELECT ON app.pedidos TO big_three_ro;

Passo dois: conecte no Big Three

Abra Bancos de dados na barra lateral, escolha o motor, preencha a conexão e aperte Salvar e testar. A senha é guardada no Gerenciador de Credenciais do Windows e não é mostrada de volta. Depois, numa conversa, marque as conexões que os modelos podem consultar.

As camadas, uma a uma

  • Um usuário de banco só com SELECT. O banco recusa todo o resto. Esta é a que importa.
  • Um filtro SQL. Comandos que não são uma leitura simples são rejeitados antes de chegarem ao banco.
  • Transações somente leitura. Mesmo uma consulta que escapasse não conseguiria escrever.
  • Tempo limite e limite de linhas. Uma consulta descontrolada é cortada, e uma tabela enorme não inunda o chat.
  • Erros sanitizados. As mensagens de erro são limpas para não vazar detalhes da conexão.
  • Registro de auditoria. Você pode ver o que foi pedido.

Um limite honesto

O cofre do sistema pertence ao seu usuário do Windows. Um modelo que você autorize a executar comandos arbitrários como você poderia lê-lo do mesmo jeito que o broker. Por isso o usuário do banco deve ter só SELECT, e por isso os modelos começam em somente leitura. O modelo de ameaças completo está em SECURITY.md.

Dúvidas sobre o acesso ao banco

Um modelo consegue ver a senha do meu banco?

Não. A senha vai do formulário direto para o Gerenciador de Credenciais do Windows. Ela nunca é mostrada de volta, nunca vai para um log e nunca é enviada a um modelo. O broker só a lê no momento de abrir uma conexão.

Um filtro de SQL basta para proteger o banco?

Não, e o Big Three não depende só dele. A camada que importa é um usuário de banco que só pode fazer SELECT. O filtro SQL, as transações somente leitura, os tempos limite e os limites de linhas são camadas extras por cima disso.

Quais bancos são compatíveis?

PostgreSQL, MySQL e Oracle. Os modelos podem executar SELECT nas conexões que você liberar em cada conversa; o Gemini ainda não consegue usar as ferramentas de banco.

Continue lendo