Como Dar Acesso ao Claude ao Snowflake Sem Expor PII

Você quer que Claude — ou Cursor, ou ChatGPT, ou qualquer agente ciente do MCP — responda perguntas sobre seus dados do Snowflake. Você também não quer que o agente leia números de seguro social, notas de clientes em texto livre ou qualquer coisa sujeita ao GDPR / HIPAA / SOC 2. A configuração padrão do MCP entrega ao agente tudo o que seu papel de conexão pode ver. Esse é o problema.

Este post passa por cinco camadas de defesa, ordenadas do mais barato ao mais completo. Cada uma é independente — escolha as que correspondem à sua tolerância ao risco. Todo o conjunto leva cerca de uma hora para ser configurado em uma conta existente do Snowflake.

A Postura Padrão (e Por Que Está Errada)

Um servidor MCP típico para Snowflake — incluindo o oficial — conecta-se com uma conta de serviço, expõe uma ferramenta de query e permite que o modelo execute qualquer SQL que o papel possa executar. Esse papel geralmente é limitado a um armazém e um banco de dados, mas raramente a colunas ou conjuntos de linhas. O modelo obtém uma interface SQL fluente para seu armazém e o armazém confia em cada consulta que vê.

O raio de explosão é grande. De acordo com o Relatório de Custo de Violação de Dados da IBM de 2025, o custo médio de uma violação de dados atingiu $4,88M, com violações envolvendo exposição extensa de dados em nuvem custando 23% a mais que a média. Permitir que um agente de IA execute consultas não curadas contra um armazém de produção é exatamente a categoria de exposição de dados em nuvem que impulsiona o prêmio.

Camada 1: Um Papel MCP Dedicado

Primeiro passo, toda vez: crie um papel que exista apenas para o agente. Não reutilize o papel de análise, não reutilize o papel do dbt e definitivamente não use SYSADMIN.

• Conceda USAGE no armazém que você deseja que o agente use. Use um armazém pequeno e dedicado (X-Small ou Small) para que uma consulta descontrolada tenha um teto de custo limitado.
• Conceda USAGE no banco de dados e nos esquemas específicos que o agente deve ver.
• Conceda SELECT nas visualizações específicas que o agente deve consultar — não em tabelas brutas. As visualizações oferecem um lugar para aplicar mascaramento, filtros e junções sem modificar os dados subjacentes.
• Nunca conceda CREATE, INSERT, UPDATE, DELETE ou TRUNCATE. O agente é um papel somente leitura.

Um papel somente leitura com concessões de SELECT somente em visualizações é aproximadamente 80% do que a maioria das equipes precisa. Os 20% restantes são onde o risco de PII realmente reside.

Camada 2: Políticas de Mascaramento em Nível de Coluna

O Snowflake suporta políticas de mascaramento que são acionadas com base no papel em execução. A mesma instrução SELECT retorna o valor bruto para um papel de analista e um valor mascarado para o papel do agente. Este é o controle de PII mais importante porque não depende do agente ou do servidor MCP se comportando corretamente.

Uma política de mascaramento que retorna SHA2(email) para qualquer papel exceto ANALYTICS_HUMAN significa que mesmo se o modelo for quebrado para produzir uma consulta SELECT *, ele recebe hashes, não endereços. A política é aplicada na camada do mecanismo SQL, não na camada da aplicação.

Aplica políticas de mascaramento a cada coluna marcada como PII. Se você ainda não tiver etiquetas de PII, uma ferramenta de auditoria (ou o agente de governança Data Workers) pode escanear o esquema e marcar automaticamente colunas candidatas — e-mails, números de telefone, SSNs, colunas de texto livre, endereços IP, datas de nascimento.

Camada 3: Políticas de Acesso a Linhas

O mascaramento oculta valores. As políticas de acesso a linhas ocultam linhas inteiras. Para dados multi-inquilinos — ou qualquer caso em que o agente deva ver apenas os dados de um cliente, uma região ou um ano fiscal — as políticas de acesso a linhas são o primitivo certo.

Padrões comuns: limitar o papel do agente aos últimos 90 dias de dados, excluir linhas marcadas como sensíveis = verdadeiro, restringir a um specific tenant_id. Assim como as políticas de mascaramento, essas são aplicadas dentro do mecanismo — nenhum código da camada da aplicação pode contorná-las.

Camada 4: Registro de Auditoria

Cada consulta que o agente executa deve ser auditável por pelo menos 30 dias. A visualização QUERY_HISTORY do Snowflake é a fonte da verdade — inclui o texto SQL, o papel em execução, os horários de início e término e as linhas retornadas. Envie isso para seu SIEM (Datadog, Splunk, S3+Athena) para que você possa responder 'o que o agente viu na semana passada' sem escrever código personalizado.

• Marque cada consulta acionada pelo agente com um cabeçalho de comentário (por exemplo, /* mcp_agent=data_workers, session=abc123 */) para que você possa filtrar o QUERY_HISTORY de forma trivial.
• Configure um alerta para qualquer consulta de agente que retorne mais de 10.000 linhas. Isso quase nunca é o comportamento pretendido.
• Configure um tempo limite rígido de consulta no armazém do agente (tente 60 segundos para começar). Agentes descontrolados são baratos quando não podem executar por 30 minutos.

Camada 5: Catálogo Consciente do Esquema como uma Barreira

A vazamento de PII mais sutil é aquele que vem do agente escolhendo a tabela errada. O agente não sabe que customers_legacy foi descontinuada em 2024, mas nunca excluída. Ele não sabe que orders_raw tem dados de pagamento não redigidos, mas orders tem a versão limpa. Sem um catálogo, o agente escolhe qualquer tabela que pareça certa.

Um catálogo de dados que o agente lê antes de escrever SQL resolve isso. O agente pergunta ao catálogo: 'Onde estão os dados do pedido?' e o catálogo responde com a visualização governada, a propriedade, a atualidade e as etiquetas de PII. O agente nunca vê a tabela legada porque o catálogo nunca a expõe.

Isso é exatamente o que o Agente de Catálogo da Data Workers faz. Ele expõe a descoberta do catálogo como ferramentas MCP, então quando Claude o consulta sobre 'dados do pedido', ele obtém a resposta governada — mesma forma de resposta, mesmas políticas de mascaramento aplicadas. O próprio catálogo impõe o que o agente pode ver.

O Que Cada Camada Te Oferece

Perguntas Frequentes

Esses controles funcionam com ChatGPT e Cursor também, ou apenas com Claude? Sim. Todos esses são controles do lado do Snowflake. Eles se aplicam independentemente de qual cliente MCP está se conectando — Claude, Cursor, OpenClaw, ChatGPT (via MCP remoto) ou um agente personalizado.

E quanto ao BigQuery e Databricks? As mesmas cinco camadas. O BigQuery tem visualizações autorizadas e controles de acesso em nível de coluna; o Databricks tem filtros de linha do Unity Catalog e máscaras de coluna. A nomenclatura difere, o padrão não.

O mascaramento quebrará junções ou agregações? As políticas de mascaramento preservam o tipo de dado, então JOIN e GROUP BY ainda funcionam — eles apenas operam no valor mascarado. Para máscaras baseadas em HASH, isso significa que 'agrupado por e-mail hash' ainda fornece contagens por cliente.

Como posso saber se meu servidor MCP atual está vazando PII? Execute uma consulta contra o QUERY_HISTORY filtrada pelo seu papel de agente, olhe para o texto SQL e verifique se alguma dessas consultas seleciona colunas que deveriam ter sido mascaradas. Se você não consegue dizer se uma coluna deveria ser mascarada, você ainda não tem etiquetagem de PII — comece por aí.

O agente de governança da Data Workers envia uma ferramenta pii_audit_snowflake que faz a varredura, a marcação e a geração de políticas em uma única chamada. É de código aberto. O objetivo deste post, no entanto, é que você não precisa dele — cinco controles em nível SQL e uma hora de trabalho fecham a maior parte do