O Conector Snowflake permite consultar dados no seu data warehouse Snowflake diretamente no Perplexity. Você pode pesquisar e combinar informações em seus bancos de dados Snowflake, em seus outros aplicativos conectados e na web — sem escrever SQL manualmente nem alternar para o console do Snowflake.
Está disponível em Perplexity Pro, Perplexity Max, Enterprise Pro e Enterprise Max. A conexão com o Snowflake é feita por usuário — ninguém mais na sua organização pode consultar seus dados, a menos que você os sincronize em um Projeto compartilhado.
Este guia aborda como o conector funciona, como escolher um método de autenticação, como configurar funções e acesso somente leitura, e uma configuração passo a passo. Se você só quer o caminho mais rápido: a maioria das organizações deve usar OAuth do usuário — ir para Guia de configuração.
Uma vez ativado, o conector se conecta com segurança à sua conta Snowflake e permite pesquisar em todos os bancos de dados, esquemas, tabelas e views que você tem autorização para ver. Quando seus dados do Snowflake mudam, o conector reflete essas alterações automaticamente na sua próxima consulta.
Objetos de dados compatíveis:
Tabelas
Views e materialized views
Esquemas
Bancos de dados
Dados estruturados (tabelas com suporte a CSV, JSON e Parquet)
Dados não estruturados (imagens, áudio e vídeo armazenados em estágios do Snowflake) não são compatíveis.
A autenticação do Snowflake tem duas dimensões independentes: quem as consultas são executadas como (a identidade) e como essa identidade comprova a si mesma (a credencial). A Perplexity oferece dois conectores no diretório, cada um correspondendo a uma combinação recomendada:
Snowflake (OAuth de Usuário) — cada usuário do Perplexity faz login com sua própria conta Snowflake (TYPE = PERSON) via OAuth. Recomendado para a maioria das organizações.
Snowflake — todos os usuários do Perplexity consultam por meio de uma única conta de serviço compartilhada (TYPE = SERVICE) usando um par de chaves. Use isso quando seus usuários finais não tiverem contas individuais do Snowflake.
Com o User OAuth, cada pessoa se autentica com suas próprias credenciais, as consultas são executadas sob suas permissões nativas do Snowflake, e você obtém um trilho de auditoria claro por usuário — sem conta de serviço compartilhada e sem precisar recriar seu controle de acesso baseado em funções (RBAC) dentro do Perplexity. Isso também está alinhado com a própria direção do Snowflake: seu servidor MCP gerenciado suporta apenas OAuth 2.0 hoje.
Observação: Com OAuth, o token de acesso fica vinculado a uma única função principal no momento do login — a do usuário DEFAULT\_ROLE. Para garantir que os usuários possam acessar tudo o que lhes foi concedido, configure funções secundárias (veja Configuração de função OAuth do usuário).
Uma conta de serviço compartilhada (TYPE = SERVICE + par de chaves) é apropriada quando:
Seus usuários finais não têm contas individuais do Snowflake (por exemplo, usuários corporativos que fazem consultas por meio do Perplexity, mas não têm acesso direto ao Snowflake).
Você quer que todas as consultas do Perplexity sejam executadas sob uma única identidade compartilhada para simplificar a auditoria.
Você está configurando um ambiente interno ou de teste em que a identidade por usuário não é necessária.
Configure a conta de serviço com uma função dedicada e de escopo restrito — veja Configuração de função da conta de serviço.
Uma observação sobre os Tokens de Acesso Programático (PATs): O Snowflake também oferece suporte a credenciais PAT, e o conector as aceita. Nós não recomendamos PAT para novas configurações — os tokens expiram em um prazo curto e ficam vinculados de forma rígida a uma única função no momento da criação, então usamos um par de chaves nos exemplos ao longo deste guia. Se você precisar usar um PAT, defina ROLE\_RESTRICTION para sua função dedicada do Perplexity no momento da criação.
Uma sessão OAuth se abre com o usuário DEFAULT\_ROLE como a função principal; a troca de função dentro de uma sessão não é compatível e a Perplexity não exibe um seletor de função. Portanto, tudo o que cada usuário tiver definido para DEFAULT\_ROLE e DEFAULT\_SECONDARY\_ROLES é exatamente o que a sessão do Perplexity deles usa.
Defina isto uma vez, no nível da integração de segurança:
OAUTH\_USE\_SECONDARY\_ROLES = IMPLICIT
da Snowflake o padrão para este parâmetro é NONE, o que significa que as sessões OAuth são abertas com apenas a função principal ativa. Defini-lo como IMPLICIT instrui a Snowflake a também ativar cada usuário’s DEFAULT\_SECONDARY\_ROLES automaticamente. Sem isso, os usuários veem apenas os dados acessíveis por meio de seus DEFAULT\_ROLE — raramente o que você quer.
Em seguida, trate um dos dois casos:
Caso A — os usuários já têm padrões de função. Se os seus usuários’ DEFAULT\_ROLE e DEFAULT\_SECONDARY\_ROLES já estão configurados do jeito que você quer, não faça mais nada. O IMPLICIT a configuração é suficiente — os padrões existentes de cada usuário são o que sua sessão do Perplexity usa.
Caso B — os usuários ainda não têm padrões de função. Dê a cada sessão a união de todas as funções concedidas a esse usuário definindo DEFAULT\_ROLE para PUBLIC e DEFAULT\_SECONDARY\_ROLES para ALL:
ALTER USER \SET DEFAULT\_ROLE = PUBLIC, DEFAULT\_SECONDARY\_ROLES = ('ALL');
Observação: Desde a mudança da Snowflake em agosto de 2024, DEFAULT\_SECONDARY\_ROLES = ('ALL') é o padrão para usuários recém-criados, então muitas organizações já têm isso configurado. Execute DESC USER \ para verificar antes de mudar qualquer coisa.
Uma conta de serviço é um único usuário dedicado que opera sob uma função específica — normalmente PERPLEXITY\_ROLE. O PUBLIC + ('ALL') padrão usado para OAuth não se aplica aqui. Em vez disso, defina o usuário de serviço DEFAULT\_ROLE para sua função dedicada e conceda a essa função apenas os privilégios de que a Perplexity precisa. Isso segue o princípio da Snowflake melhores práticas para conta de serviço.
O SQL completo para criar este usuário está em Guia de configuração abaixo.
Para limitar quais funções do Snowflake os usuários podem autenticar por meio da integração OAuth do Perplexity, configure o escopo no nível da integração de segurança:
PRE\_AUTHORIZED\_ROLES\_LIST — uma lista de permissões de funções permitidas por meio desta integração.
BLOCKED\_ROLES\_LIST — uma lista de bloqueio de funções impedidas nesta integração.
ALTER SECURITY INTEGRATION PERPLEXITY\_OAUTH
SET PRE\_AUTHORIZED\_ROLES\_LIST = ('ANALYST\_ROLE', 'READ\_ONLY\_ROLE');
Use isso para manter funções sensíveis (por exemplo, ACCOUNTADMIN) totalmente fora do fluxo de OAuth.
O conector executa SQL por meio de uma interface de ferramenta (proveniente do conector Snowflake da Merge). O conector Snowflake (OAuth de Usuário) expõe ferramentas granulares e nomeadas — incluindo uma ferramenta dedicada de consulta somente leitura (execute\_sql\_readonly) que aceita apenas SELECT, WITH, SHOW, DESCRIBE, EXPLAIN, VALUES e LIST, e rejeita DDL/DML e entrada com múltiplas instruções. O conector Snowflake de conta de serviço expõe uma ferramenta geral execute\_sql que aceita SQL arbitrário, incluindo DDL e DML.
O controle autoritativo é o Snowflake RBAC. Não importa qual ferramenta seja invocada, as consultas são executadas sob a função permitida pela sua configuração, portanto aplicar somente leitura no nível da função do Snowflake é o respaldo confiável — e esse é o único limite de aplicação no conector da conta de serviço.
Padrão recomendado — imponha somente leitura com uma função dedicada. Provisione uma função, como PERPLEXITY\_READ\_ONLY, que conceda apenas USAGE e SELECT nos bancos de dados, esquemas e tabelas que você deseja que o Perplexity consulte, e não conceda INSERT, UPDATE, DELETE, CREATE, DROP, OWNERSHIP ou MODIFY no warehouse. Em seguida, certifique-se de que os usuários se autentiquem nessa função:
Defina como do usuário DEFAULT\_ROLE, ou
Delimite a integração OAuth com PRE\_AUTHORIZED\_ROLES\_LIST e/ou exclua funções com capacidade de escrita com BLOCKED\_ROLES\_LIST (veja Restringir quais funções podem ser usadas via OAuth).
Com o RBAC configurado dessa forma, o Snowflake rejeita qualquer tentativa de gravação do Perplexity, independentemente de qual ferramenta seja chamada.
Observação: As configurações do conector incluem um painel Permissões de ferramentas que lista as ferramentas disponíveis. No conector Snowflake (OAuth de Usuário), você pode restringir quais ferramentas são expostas — para uma configuração somente leitura, habilite apenas as ferramentas de leitura (por exemplo, execute\_sql\_readonly, list\_\*, describe\_\*, get\_\*) para manter as ferramentas de escrita/DDL fora da superfície. Trate isso como defesa em profundidade, não como a fronteira autoritativa: o RBAC do Snowflake (acima) é o que realmente impõe o acesso.
Quando conectado, o Conector Snowflake pode realizar as seguintes ações em seu nome:
Execute consultas SQL em seus dados do Snowflake
Consultar o Cortex Search e o Cortex Analyst
Executar UDFs e procedures armazenadas personalizadas
Se você revogar o acesso ou remover uma função no Snowflake, esses dados ficam imediatamente inacessíveis no Perplexity. Se você desconectar o Snowflake no Perplexity, pode escolher se deseja manter ou excluir quaisquer dados em cache.
Para organizações Enterprise, a Perplexity oferece certificação SOC 2 Type II, criptografia de ponta a ponta, medidas rigorosas de privacidade de dados e controles granulares de acesso de usuários. Seus dados do Snowflake nunca são usados para treinamento de IA.
A conexão com o Snowflake é feita por usuário — mais ninguém na sua organização pode consultar seus dados. No entanto, se você sincronizar dados para um Projeto compartilhado, qualquer pessoa com acesso a esse Projeto poderá pesquisá-los.
Os administradores da organização podem ativar ou desativar o conector para todos os usuários a partir da tela Permissões nas Configurações da organização. A imposição de leitura/gravação é tratada no nível da função do Snowflake (veja Controlando o que o Perplexity pode fazer).
Escolha o caminho que corresponde ao seu método de autenticação:
OAuth do usuário (recomendado): Um administrador da organização configura o app OAuth uma única vez, e então os usuários entram individualmente. Vá direto para Conecte o Snowflake ao Perplexity — o SQL nas etapas 1–6 é apenas para configurações de conta de serviço.
Conta de serviço (par de chaves): Execute a configuração de SQL nas etapas 1–6 e, em seguida, conecte-se na etapa 7.
ACCOUNTADMIN função (ou uma função com CREATE USER e GRANT privilégios)
OpenSSL instalado localmente (pré-instalado no macOS) — somente configurações de conta de serviço
No seu terminal, gere uma chave privada RSA:
openssl genrsa 2048 | openssl pkcs8 -topk8 -inform PEM -out snowflake\_computer\_key.p8 -nocrypt
Em seguida, gere a chave pública correspondente:
openssl rsa -in snowflake\_computer\_key.p8 -pubout -out snowflake\_computer\_key.pub
USE ROLE ACCOUNTADMIN;
-- Create a dedicated role
CREATE ROLE IF NOT EXISTS PERPLEXITY\_ROLE
COMMENT = 'Role for Perplexity service account';
-- Create a warehouse (or use an existing one)
CREATE WAREHOUSE IF NOT EXISTS PERPLEXITY\_WAREHOUSE
WAREHOUSE\_SIZE = 'XSMALL'
AUTO\_SUSPEND = 60
AUTO\_RESUME = TRUE
COMMENT = 'Warehouse for Perplexity queries';
-- Grant warehouse usage to the role
GRANT USAGE ON WAREHOUSE PERPLEXITY\_WAREHOUSE TO ROLE PERPLEXITY\_ROLE;
Execute como ACCOUNTADMIN. Substitua o valor de RSA\_PUBLIC\_KEY pelo conteúdo do arquivo snowflake\_computer\_key.pub (sem as linhas de cabeçalho e rodapé).
USE ROLE ACCOUNTADMIN;
CREATE USER PERPLEXITY\_USER
TYPE = SERVICE
DEFAULT\_ROLE = PERPLEXITY\_ROLE
DEFAULT\_WAREHOUSE = PERPLEXITY\_WAREHOUSE
COMMENT = 'Service account for Perplexity'
RSA\_PUBLIC\_KEY = 'MIIBIjANBgkqhki...your\_public\_key\_here...IDAQAB';
-- Grant the dedicated role to the service account
GRANT ROLE PERPLEXITY\_ROLE TO USER PERPLEXITY\_USER;
Observação: TYPE = SERVICE marca isto como uma conta não humana — não defina uma senha. DEFAULT\_ROLE = PERPLEXITY\_ROLE restringe isso a uma única função dedicada, com apenas os privilégios de que o Perplexity precisa.
-- Grant access to a specific database
GRANT USAGE ON DATABASE MY\_DATABASE TO ROLE PERPLEXITY\_ROLE;
-- Grant access to all schemas in a database (current and future)
GRANT USAGE ON ALL SCHEMAS IN DATABASE MY\_DATABASE TO ROLE PERPLEXITY\_ROLE;
GRANT USAGE ON FUTURE SCHEMAS IN DATABASE MY\_DATABASE TO ROLE PERPLEXITY\_ROLE;
-- Grant read access to all tables and views (current and future)
GRANT SELECT ON ALL TABLES IN DATABASE MY\_DATABASE TO ROLE PERPLEXITY\_ROLE;
GRANT SELECT ON FUTURE TABLES IN DATABASE MY\_DATABASE TO ROLE PERPLEXITY\_ROLE;
GRANT SELECT ON ALL VIEWS IN DATABASE MY\_DATABASE TO ROLE PERPLEXITY\_ROLE;
GRANT SELECT ON FUTURE VIEWS IN DATABASE MY\_DATABASE TO ROLE PERPLEXITY\_ROLE;
Para um acesso mais seletivo, consulte o Documentação GRANT do Snowflake.
Perplexity usa duas visualizações na SNOWFLAKE.ACCOUNT\_USAGE esquema para criar um Mapa de Dados para geração precisa de consultas:
|
Ver |
Propósito |
|
|
Metadados da consulta, desempenho e padrões de uso |
|
|
Trilha de auditoria em nível de objeto (somente na edição Enterprise) |
USE ROLE ACCOUNTADMIN;
GRANT IMPORTED PRIVILEGES ON DATABASE SNOWFLAKE TO ROLE PERPLEXITY\_ROLE;
Observação: ACCESS\_HISTORY está disponível apenas no Snowflake Enterprise Edition ou superior; o Perplexity faz fallback para QUERY\_HISTORY na Edição Standard automaticamente. Pular esta etapa reduz a precisão das consultas. Para saber como o Perplexity usa essas visualizações, consulte Entendendo o Mapa de Dados.