Acesso somente leitura ao banco para uma IA: duas camadas independentes

O motivo da integração é prático: sem ver o banco, a IA chuta nome de campo e tabela, e o erro só aparece quando o código é compilado no ambiente. Por que isso acontece e que contexto dar está em A IA inventou um campo do Protheus. Como conferir o que uma conta de fato pode fazer está em Usuário somente leitura no SQL Server. Este texto junta as duas pontas: o desenho da integração e a ordem de validação.

O caminho de uma consulta

O assistente chama uma ferramenta do servidor de ferramentas (MCP). O servidor se descreve como somente leitura e, pelo desenho, confere o texto do comando antes de enviá-lo. Quais comandos ele aceita e recusa não foi verificado aqui: confira na documentação e no código do servidor que você usar. Se o comando passar, ele roda no SQL Server com o login dedicado, e as linhas voltam ao assistente.

O ponto do desenho está no que acontece quando a primeira camada falha. Se o servidor de ferramentas tiver um defeito e deixar um UPDATE passar, o SQL Server ainda o recusa, por falta de permissão. Filtrar texto é uma defesa frágil sozinha; a permissão do banco não depende do texto.

Camada 1: o login no banco

O login é criado por quem administra o banco, com um usuário no banco do Protheus e apenas o papel de leitura. O modelo, com nomes neutros:

CREATE LOGIN leitura_ia WITH PASSWORD = '<senha-forte>';

USE <banco_protheus>;
CREATE USER leitura_ia FOR LOGIN leitura_ia;
ALTER ROLE db_datareader ADD MEMBER leitura_ia;

Sem db_datawriter, sem db_owner, sem papéis administrativos e sem permissão de execução em procedures que escrevem. Um login por ambiente, cada um restrito ao banco correspondente.

Lembre que db_datareader lê todas as tabelas e views de usuário do banco: é uma decisão de escopo, e o artigo sobre verificação de permissões explica como conferir o alcance real. Confirme os papéis de servidor também: sysadmin anula qualquer restrição de banco.

Camada 2: o servidor de ferramentas

O servidor usado no desenho é um servidor MCP de terceiros, executado sob demanda, que se descreve como somente leitura. Cada ambiente é uma entrada separada de configuração, com o próprio login, host e banco. Assim a IA escolhe desenvolvimento por padrão, e produção só entra quando a pessoa pedir.

Trate a descrição do servidor como intenção, não como prova: o que ele bloqueia de fato é o que o teste do checklist abaixo deve mostrar, e o código dele merece leitura antes de você confiar. O texto livre de um comando tem muitas formas, e uma lista de palavras não cobre todas.

Duas regras de conduta

• Nunca contornar uma camada. Usar um usuário administrador “só dessa vez” anula o desenho inteiro.
• Se a IA precisar escrever, ela para e pede que uma pessoa execute. O erro de uma tentativa volta como texto; não é motivo para trocar de conexão.

Antes de liberar o uso, para cada ambiente:

1. Uma consulta de leitura simples, sobre uma tabela conhecida, retorna linhas.
2. Uma tentativa deliberada de alteração é recusada pelo servidor de ferramentas.
3. A mesma alteração, com o login dedicado fora do servidor de ferramentas, é recusada pelo SQL Server com erro de permissão.
4. Os itens 1 a 3 se repetem para produção antes de considerá-la liberada.

O item 3 exige cuidado: teste dentro de uma transação que termina em ROLLBACK e confirme que não há transação aberta depois. Como o outro artigo alerta, ROLLBACK não torna qualquer teste inofensivo. Faça isso só em base descartável, planejado por quem administra o banco, e nunca com uma escrita solta em tabela real.

O que este desenho não resolve

Leitura ainda expõe dados: registros de cliente chegam ao contexto do assistente. Também não limita custo de consulta. Para conhecer estrutura, o acesso a metadados basta, e é o ponto de partida mais seguro.

Ao trocar de cliente, as credenciais da configuração precisam apontar para o banco correto: a configuração global do desenho é atualizada à mão.