Pular para o conteúdo principal

Conectando o Perplexity ao Snowflake

Integre seu data warehouse Snowflake ao Perplexity, permitindo pesquisa instantânea em bancos de dados, schemas, tabelas e views

Escrito por Emilio Morales

Sobre o Conector do Snowflake

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.

 

O que o conector pode acessar

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.

 

Escolhendo um método de autenticação

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."

 

Recomendado: OAuth de usuário

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).

 

Alternativa: conta de serviço (par de chaves)

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.

 

Configurando funções e acesso

Configuração de função OAuth do usuário

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 <username> 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 <username> para verificar antes de mudar qualquer coisa.

 

Configuração de função da conta de serviço

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 faz 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.

 

(Opcional) Restringindo quais funções podem ser usadas via OAuth

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.

 

Controlando o que o Perplexity pode fazer

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:

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.

 

Privacidade e segurança de dados

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.

 

Segurança e controle de nível empresarial

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).

 

Guia de configuração

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.

 

Pré-requisitos

  • 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

 

Etapa 1: Gerar um par de chaves (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

 

Etapa 2: Criar uma role e um warehouse

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;

 

Etapa 3: Criar o usuário da conta de serviço

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.

 

Etapa 4: conceda acesso aos seus dados

-- 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.

 

Etapa 5: Conceda acesso ao histórico de consultas e ao histórico de acesso

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

QUERY_HISTORY

Metadados da consulta, desempenho e padrões de uso

ACCESS_HISTORY

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.

Verificar acesso

USE ROLE ACCOUNTADMIN;
GRANT ROLE PERPLEXITY_ROLE TO USER <your_username>;
USE ROLE PERPLEXITY_ROLE;
USE WAREHOUSE PERPLEXITY_WAREHOUSE;
SELECT * FROM SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY LIMIT 5;
SELECT * FROM SNOWFLAKE.ACCOUNT_USAGE.ACCESS_HISTORY LIMIT 5;

 

Etapa 6: (Opcional) Adicione endereços IP à lista de permissões

Se sua conta Snowflake restringir conexões de entrada por IP, coloque na lista de permissões os IPs de esta página:

USE ROLE ACCOUNTADMIN;
CREATE NETWORK POLICY PERPLEXITY_COMPUTER_POLICY
  ALLOWED_IP_LIST = (...US IPs from the link above...);
ALTER USER PERPLEXITY_USER SET NETWORK_POLICY = PERPLEXITY_COMPUTER_POLICY;

 

Etapa 7: Conecte o Snowflake ao Perplexity

Para OAuth de usuário: configuração do administrador primeiro

Se a sua organização usa OAuth, um administrador da organização configura o conector Snowflake (OAuth de Usuário) uma vez antes que usuários individuais possam se autenticar. Em Configurações da organização → Conectores → Snowflake (OAuth do usuário), o administrador verá um painel de três etapas:

  1. Gerenciar aplicativo OAuth — registre a Perplexity como um cliente OAuth em sua conta Snowflake. Isso o orienta na criação de um Snowflake personalizado SECURITY INTEGRATION e colando o Client ID e o Client Secret resultantes de volta no Perplexity.

  2. Autentique-se com Snowflake (OAuth de usuário) — o administrador se autentica uma vez para verificar se a integração funciona de ponta a ponta.

  3. Gerar um mapa de dados (opcional) — opcionalmente, gere um mapa de dados para a organização (veja Entendendo o Mapa de Dados) e adicione contexto complementar para melhorar a precisão.

Na etapa 1, crie a integração de segurança no lado do Snowflake. Execute isto como ACCOUNTADMIN:

USE ROLE ACCOUNTADMIN;
CREATE SECURITY INTEGRATION PERPLEXITY_OAUTH
  TYPE = OAUTH
  ENABLED = TRUE
  OAUTH_CLIENT = CUSTOM
  OAUTH_CLIENT_TYPE = 'CONFIDENTIAL'
  OAUTH_REDIRECT_URI = 'https://ah.merge.dev/oauth/callback'
  OAUTH_ISSUE_REFRESH_TOKENS = TRUE
  OAUTH_REFRESH_TOKEN_VALIDITY = 7776000
  OAUTH_USE_SECONDARY_ROLES = IMPLICIT
  COMMENT = 'OAuth security integration for Perplexity';

Recupere o Client ID e o Client Secret para colar de volta no Perplexity:

SELECT SYSTEM$SHOW_OAUTH_CLIENT_SECRETS('PERPLEXITY_OAUTH');

Assim que a configuração do administrador for concluída, os usuários individuais podem se conectar usando as etapas abaixo.

 

Conectar (todos os usuários)

Os usuários só veem o método de autenticação correspondente ao conector configurado pelo administrador.

  1. Ir para Conectores nas Configurações e encontre o Snowflake ou Snowflake (OAuth de Usuário) conector.

  2. Clique Ativar → Adicionar Conector.

  3. Autentique-se usando o método configurado (veja abaixo).

  4. Clique Permitir para concluir a configuração.

Autenticação por par de chaves (conector Snowflake). Insira o identificador da sua conta Snowflake, o nome de usuário e a chave privada (snowflake_computer_key.p8).

 

OAuth (conector do Snowflake (OAuth do usuário)). Você será redirecionado para o Snowflake para fazer login. Não há seletor de função — sua sessão usa seu DEFAULT_ROLE como a função principal, com o seu DEFAULT_SECONDARY_ROLES ativado via OAUTH_USE_SECONDARY_ROLES = IMPLICIT. Se os padrões da sua função já estiverem configurados, nenhuma ação será necessária.

Se faltarem dados em sua sessão que você espera ver, peça ao administrador do Snowflake para verificar seu DEFAULT_ROLE e DEFAULT_SECONDARY_ROLES (veja Configuração de função OAuth do usuário).

 

Usando seus dados do Snowflake

Depois de conectado, consulte seus dados do Snowflake em Computador tarefas. Mencione bancos de dados, esquemas ou tabelas e o Perplexity os consultará como parte de fluxos de trabalho de várias etapas — tudo de forma assíncrona em um sandbox seguro na nuvem. Experimente consultas como:

  • “Resuma as tendências de receita da tabela de vendas do 4º trimestre e destaque as principais métricas”

  • “Encontre todos os registros de clientes atualizados nos últimos 30 dias”

  • “Quais são os produtos com melhor desempenho com base no esquema de análises?”

  • “Compare os dados do pipeline deste trimestre com os números do trimestre anterior”

 

Solução de problemas

Snowflake não está habilitado para sua organização

Se você estiver em uma organização Enterprise e não conseguir ativar o conector, talvez um administrador o tenha desativado. Entre em contato com o administrador da sua organização ou com o suporte da Perplexity.

Problemas de conexão e autenticação

  • Verifique se os endereços IP da Perplexity estão incluídos na allowlist na sua política de rede do Snowflake.

  • Confirme se a função tem USAGE privilégios nos warehouses, bancos de dados e schemas necessários.

  • Peça aos usuários que reconectem o conector após quaisquer alterações na política.

Erro de "chave privada inválida"

Certifique-se de que você está colando a chave privada (snowflake_computer_key.p8), não a chave pública. O arquivo deve começar com -----BEGIN PRIVATE KEY-----.

Autenticação rejeitada pela política de autenticação atual

Executar SHOW AUTHENTICATION POLICIES como ACCOUNTADMIN e garantir PERPLEXITY_USER está coberto por uma política que inclui KEYPAIRSe necessário:

CREATE AUTHENTICATION POLICY PERPLEXITY_AUTH_POLICY
  AUTHENTICATION_METHODS = ('KEYPAIR')
  CLIENT_TYPES = ('DRIVERS');
ALTER USER PERPLEXITY_USER SET AUTHENTICATION POLICY PERPLEXITY_AUTH_POLICY;

OAuth: o usuário vê dados limitados após conectar

A sessão OAuth usa o do usuário DEFAULT_ROLE como a função principal, com funções secundárias ativadas por meio de OAUTH_USE_SECONDARY_ROLES = IMPLICIT. Se um usuário estiver sem o acesso esperado:

  • Confirme que a integração de segurança tem OAUTH_USE_SECONDARY_ROLES = IMPLICIT.

  • Executar DESC USER <username> e verificar DEFAULT_ROLE e DEFAULT_SECONDARY_ROLES — a sessão usa exatamente o que está configurado lá.

  • Se o usuário não tiver nenhuma configuração de função por usuário e você quiser que ele acesse tudo o que lhe foi concedido, defina DEFAULT_ROLE = PUBLIC e DEFAULT_SECONDARY_ROLES = ('ALL').

  • Peça que desconectem e reconectem o conector para emitir um novo token após alterar qualquer uma dessas configurações.

A visualização ACCESS_HISTORY retorna um erro

Confirme se sua conta Snowflake é da edição Enterprise ou superior.

Privilégios insuficientes nas views ACCOUNT_USAGE

Verificar GRANT IMPORTED PRIVILEGES foi executado como ACCOUNTADMIN e que PERPLEXITY_ROLE é concedido ao usuário.

Falha na autenticação por par de chaves

Executar novamente DESC USER PERPLEXITY_USER para confirmar se a impressão digital da chave pública está preenchida.

 

Se os problemas persistirem após atualizar essas configurações, entre em contato com o suporte da Perplexity para obter ajuda.

Sobre o Conector do Snowflake
O que o conector pode acessar
Escolhendo um método de autenticação
Configurando funções e acesso
Controlando o que o Perplexity pode fazer
Privacidade e segurança de dados
Guia de configuração
Usando seus dados do Snowflake
Solução de problemas