Pular para o conteúdo principal

Segurança

O Datafala não vê os seus dados​

A API nunca conecta ao seu banco e nunca recebe credenciais dele. Ela conhece apenas o DDL, as descrições, o contexto e os exemplos que você cadastrou no painel. Os resultados das consultas ficam só no seu sistema.

SQL Guard​

Todo SQL gerado pela LLM, todo exemplo salvo no painel e todo caso de avaliação passam pelo SQL Guard, que analisa a consulta como árvore sintática (não por texto) no dialeto do seu schema. Ele recusa tudo o que não está explicitamente permitido:

  1. Um único statement, e ele precisa ser SELECT (CTEs não recursivas são aceitas). INSERT, UPDATE, DELETE, DDL, SELECT ... INTO, bloqueios (FOR UPDATE) e múltiplos statements são recusados.
  2. Só tabelas cadastradas e visíveis. Tabelas de sistema (pg_catalog, information_schema, mysql, performance_schema, sys) nunca são aceitas. No Firebird, objetos com prefixos RDB$, MON$ e SEC$ são ignorados na importação e não podem ser consultados.
  3. Só colunas cadastradas e visíveis. SELECT * é expandido e recusado se alcançar uma coluna oculta.
  4. Funções por lista de permissão por dialeto (agregação, data, texto, matemática e condicionais). Funções perigosas como pg_sleep, pg_read_file, dblink, SLEEP, BENCHMARK e LOAD_FILE são bloqueadas, assim como variáveis @@/@ e comentários executáveis /*! */ no MySQL. No Firebird, GEN_ID, NEXT VALUE FOR, RDB$GET_CONTEXT, RDB$SET_CONTEXT e chamadas a procedures/UDFs não permitidas são recusadas.
  5. Placeholders e parâmetros batem: todo %(nome)s tem valor em params, e vice-versa.
  6. LIMIT sempre aplicado, reescrito na árvore, exceto em agregações que provadamente retornam uma linha. Um LIMIT maior que max_rows é reduzido. No Firebird, o Guard limita com FIRST/SKIP ou ROWS conforme a consulta.

No Firebird, consultas sem FROM também são recusadas; não use RDB$DATABASE para contornar a exigência de consultar uma tabela cadastrada. EXECUTE BLOCK, EXECUTE PROCEDURE, SELECT ... WITH LOCK, PLAN e outras formas que não sejam um SELECT permitido também são bloqueadas.

Se o primeiro SQL é rejeitado, a API pede uma correção à LLM uma única vez, informando só códigos genéricos, para que a LLM nunca descubra o que você ocultou.

Defesa em profundidade

O Guard é a primeira camada. A segunda é sua: um usuário de banco somente leitura, com acesso só às tabelas cadastradas e tempo máximo por consulta. Veja Executar o SQL.

Chaves e segredos​

  • API keys: 256 bits aleatórios, guardadas apenas como hash SHA-256 e mostradas uma única vez.
  • Chave da sua LLM: guardada cifrada (Fernet) e decifrada só no momento da chamada ao provedor.
  • Senhas do painel: Argon2, com política de senha forte e limite de tentativas de login.

O que vai para a LLM​

O prompt leva o schema visível (sem tabelas e colunas ocultas), o contexto, os exemplos, a data de hoje e a pergunta. Comentários de feedback e casos de avaliação nunca entram no prompt. Como a explanation pode repetir trechos do prompt, não coloque segredos no contexto do painel.

Os dados enviados à LLM seguem a política do provedor que você escolheu, na sua conta. O administrador do tenant pode ver no Histórico do painel exatamente o prompt enviado em cada pergunta.

Transporte e headers​

Toda chamada usa HTTPS. As respostas de /v1 trazem Cache-Control: no-store; não dependa de cache HTTP para reaproveitar respostas, use o histórico ou o seu próprio cache por request_id.