Conectar Perplexity con Snowflake | Perplexity Help Center

Acerca del conector de Snowflake

El conector de Snowflake te permite consultar datos en tu almacén de datos de Snowflake directamente desde Perplexity. Puedes buscar y combinar información en tus bases de datos de Snowflake, tus otras apps conectadas y la web, sin escribir SQL manualmente ni cambiar a la consola de Snowflake.

Está disponible en Perplexity Pro, Perplexity Max, Enterprise Pro, y Enterprise Max. La conexión a Snowflake se realiza por usuario: nadie más en tu organización puede consultar tus datos a menos que los sincronices en un Proyecto compartido.

Esta guía explica cómo funciona el conector, cómo elegir un método de autenticación, cómo configurar roles y acceso de solo lectura, y una configuración paso a paso. Si solo quieres la forma más rápida: la mayoría de las organizaciones deberían usar OAuth de usuario — ve a Guía de configuración.

A qué puede acceder el conector

Una vez habilitado, el conector se conecta de forma segura a tu cuenta de Snowflake y te permite buscar en las bases de datos, esquemas, tablas y vistas que tienes autorización para ver. Cuando tus datos de Snowflake cambian, el conector refleja esos cambios automáticamente en tu siguiente consulta.

Objetos de datos compatibles:

Tablas
Vistas y vistas materializadas
Esquemas
Bases de datos
Datos estructurados (tablas basadas en CSV, JSON y Parquet)

Los datos no estructurados (imágenes, audio y video almacenados en stages de Snowflake) no son compatibles.

Elegir un método de autenticación

La autenticación de Snowflake tiene dos dimensiones independientes: quién ejecuta las consultas (la identidad) y cómo esa identidad demuestra que es quien dice ser (la credencial). Perplexity incluye dos conectores en el directorio, cada uno asociado a una combinación recomendada:

Snowflake (OAuth de usuario) — cada usuario de Perplexity inicia sesión con su propia cuenta de Snowflake (TYPE = PERSON) mediante OAuth. Recomendado para la mayoría de las organizaciones.
Snowflake — todos los usuarios de Perplexity consultan a través de una única cuenta de servicio compartida (TYPE = SERVICE) usando una clave par. Úsalo cuando tus usuarios finales no tengan cuentas individuales de Snowflake.

Recomendado: OAuth de usuario

Con OAuth de usuario, cada persona se autentica con sus propias credenciales, las consultas se ejecutan con sus permisos nativos de Snowflake y obtienes un registro de auditoría claro por usuario, sin cuenta de servicio compartida ni necesidad de recrear tu control de acceso basado en roles (RBAC) dentro de Perplexity. Esto también se alinea con la dirección de Snowflake: su servidor MCP administrado solo admite OAuth 2.0 por ahora.

Nota: Con OAuth, el token de acceso queda vinculado a un único rol principal al iniciar sesión: el DEFAULT_ROLEdel usuario. Para asegurarte de que los usuarios puedan acceder a todo lo que se les ha concedido, configura roles secundarios (consulta Configuración de roles de OAuth de usuario).

Alternativa: cuenta de servicio (clave par)

Una cuenta de servicio compartida (TYPE = SERVICE + clave par) es adecuada cuando:

Tus usuarios finales no tienen cuentas individuales de Snowflake (por ejemplo, usuarios de negocio que consultan a través de Perplexity pero no tienen acceso directo a Snowflake).
Quieres que todas las consultas de Perplexity se ejecuten bajo una única identidad compartida para simplificar la auditoría.
Está configurando un entorno interno o de prueba en el que no se requiere una identidad por usuario.

Configure la cuenta de servicio con un rol dedicado y de alcance limitado — consulte Configuración del rol de la cuenta de servicio.

Una nota sobre los tokens de acceso programático (PAT): Snowflake también admite credenciales PAT, y el conector las acepta. No recomendamos PAT para nuevas configuraciones — los tokens caducan con rapidez y quedan vinculados de forma rígida a un solo rol en el momento de su creación, por lo que usamos una clave pública/privada en los ejemplos de esta guía. Si debes usar un PAT, establece ROLE_RESTRICTION en tu rol dedicado de Perplexity en el momento de la creación.

Configurar roles y acceso

Configuración de roles de OAuth de usuario

Una sesión OAuth se abre con DEFAULT_ROLE del usuario como rol principal; el cambio de rol dentro de una sesión no es compatible y Perplexity no muestra un selector de roles. Por lo tanto, lo que cada usuario tenga configurado para DEFAULT_ROLE y DEFAULT_SECONDARY_ROLES es exactamente lo que usa su sesión de Perplexity.

Establezca esto una sola vez, a nivel de la integración de seguridad:

OAUTH_USE_SECONDARY_ROLES = IMPLICIT

La predeterminación de este parámetro es NONE, lo que significa que las sesiones OAuth se abren con solo el rol principal activo. Configurarlo en IMPLICIT indica a Snowflake que también active automáticamente el DEFAULT_SECONDARY_ROLES de cada usuario DEFAULT_ROLE — algo que rara vez es lo que se desea.

Después, gestione uno de estos dos casos:

Caso A: los usuarios ya tienen roles predeterminados. Si los DEFAULT_ROLE y DEFAULT_SECONDARY_ROLES de tus usuarios ya están configurados como quieres, no hagas nada más. La configuración de IMPLICIT es suficiente: las preferencias existentes de cada usuario son las que usa su sesión de Perplexity.

Caso B: los usuarios aún no tienen roles predeterminados. Proporcione a cada sesión la unión de todos los roles concedidos a ese usuario configurando DEFAULT_ROLE en PUBLIC y DEFAULT_SECONDARY_ROLES en ALL:

ALTER USER <username> SET DEFAULT_ROLE = PUBLIC, DEFAULT_SECONDARY_ROLES = ('ALL');

Nota: Desde el cambio de Snowflake de agosto de 2024, DEFAULT_SECONDARY_ROLES = ('ALL') es el valor predeterminado para los usuarios creados recientemente, por lo que muchas organizaciones ya lo tienen configurado. Ejecute DESC USER <username> para comprobarlo antes de cambiar nada.

Configuración del rol de la cuenta de servicio

Una cuenta de servicio es un único usuario dedicado que funciona bajo un rol específico, normalmente PERPLEXITY_ROLE. El patrón PUBLIC + ('ALL') usado para OAuth no se aplica aquí. En su lugar, establezca el DEFAULT_ROLE del usuario de servicio en tu rol dedicado y conceda a ese rol solo los privilegios que Perplexity necesita. Esto sigue las prácticas recomendadas para cuentas de servicio de Snowflake.

El SQL completo para crear este usuario se encuentra en el Guía de configuración a continuación.

(Opcional) Restringir qué roles se pueden usar mediante OAuth

Para limitar a qué roles de Snowflake pueden autenticarse los usuarios a través de la integración OAuth de Perplexity, delimítelo a nivel de la integración de seguridad:

PRE_AUTHORIZED_ROLES_LIST — una lista de अनुमति roles permitidos a través de esta integración.
BLOCKED_ROLES_LIST — una lista de roles bloqueados en esta integración.

ALTER SECURITY INTEGRATION PERPLEXITY_OAUTH
  SET PRE_AUTHORIZED_ROLES_LIST = ('ANALYST_ROLE', 'READ_ONLY_ROLE');

Usa esto para mantener los roles sensibles (por ejemplo ACCOUNTADMIN) fuera por completo del flujo OAuth.

Controlar lo que Perplexity puede hacer

El conector ejecuta SQL a través de una superficie de herramientas (procedente del conector de Snowflake de Merge). El Snowflake (OAuth de usuario) conector expone herramientas granulares y con nombre, incluida una herramienta dedicada de consulta de solo lectura (execute_sql_readonly) que solo acepta SELECT, WITH, SHOW, DESCRIBE, EXPLAIN, VALUES, y LIST, y rechaza DDL/DML y la entrada con varias sentencias. El conector de cuenta de servicio Snowflake expone una herramienta general de execute_sql que acepta SQL arbitrario, incluidos DDL y DML.

El control autoritativo es RBAC de Snowflake. Sin importar qué herramienta se invoque, las consultas se ejecutan bajo el rol que permita tu configuración, por lo que aplicar solo lectura a nivel del rol de Snowflake es la medida de respaldo fiable, y es el único límite de aplicación en el conector de cuenta de servicio.

Patrón recomendado: aplicar solo lectura con un rol dedicado. Provisione un rol como PERPLEXITY_READ_ONLY que conceda solo USAGE y SELECT sobre las bases de datos, esquemas y tablas que desea que Perplexity consulte, y no no grant INSERT, UPDATE, DELETE, CREATE, DROP, OWNERSHIP, o warehouse MODIFY. Luego asegúrese de que los usuarios se autentiquen en ese rol:

Asígnelo como el DEFAULT_ROLE, o
Delimite la integración OAuth con PRE_AUTHORIZED_ROLES_LIST y/o excluya los roles con capacidad de escritura con BLOCKED_ROLES_LIST (ver Restringir qué roles se pueden usar mediante OAuth).

Con RBAC configurado de esta manera, Snowflake rechaza cualquier intento de escritura de Perplexity, sin importar qué herramienta se use.

Nota: La configuración del conector incluye un Permisos de herramientas que enumera las herramientas disponibles. En el Snowflake (OAuth de usuario) conector, puede acotar qué herramientas se exponen; para una configuración de solo lectura, habilite solo las herramientas de lectura (por ejemplo execute_sql_readonly, list_*, describe_*, get_*) para mantener fuera de la superficie las herramientas de escritura/DDL. Trate esto como una capa de defensa en profundidad, no como el límite autoritativo: el RBAC de Snowflake (arriba) es lo que aplica el acceso de forma fiable.

Privacidad y seguridad de los datos

Cuando está conectado, el conector de Snowflake puede realizar las siguientes acciones en tu nombre:

Ejecutar consultas SQL sobre tus datos de Snowflake
Consultar Cortex Search y Cortex Analyst
Ejecutar UDF personalizadas y procedimientos almacenados

Si revoca el acceso o elimina un rol en Snowflake, esos datos dejan de ser accesibles de inmediato desde Perplexity. Si desconecta Snowflake en Perplexity, puede elegir si conservar o eliminar los datos almacenados en caché.

Seguridad y control de nivel empresarial

Para organizaciones Enterprise, Perplexity ofrece certificación SOC 2 Type II, cifrado de extremo a extremo, estrictas medidas de privacidad de datos y controles granulares de acceso de usuarios. Sus datos de Snowflake nunca se utilizan para el entrenamiento de IA.

La conexión de Snowflake se realiza por usuario: nadie más en tu organización puede consultar tus datos. Sin embargo, si sincroniza datos con un Proyecto compartido, cualquiera que tenga acceso a ese Proyecto puede buscarlos.

Los administradores de la organización pueden habilitar o deshabilitar el conector para todos los usuarios desde la pantalla de Permisos en Configuración de la organización. La aplicación de permisos de lectura/escritura se gestiona a nivel de rol en Snowflake (ver Controlar lo que Perplexity puede hacer).

Guía de configuración

Elige la opción que coincida con tu método de autenticación:

OAuth de usuario (recomendado): Un administrador de la organización configura la aplicación OAuth una sola vez y luego los usuarios inician sesión individualmente. Vaya directamente a Conectar Snowflake a Perplexity; el SQL de los pasos 1 a 6 es solo para configuraciones de cuenta de servicio.
Cuenta de servicio (par de claves): Ejecute la configuración SQL de los pasos 1 a 6 y luego conecte en el paso 7.

Requisitos previos

ACCOUNTADMIN rol (o un rol con CREATE USER y GRANT privilegios)
OpenSSL instalado localmente (preinstalado en macOS) — solo configuraciones de cuenta de servicio

Paso 1: Generar un par de claves (cuenta de servicio)

Desde la terminal, genere una clave privada RSA:

openssl genrsa 2048 | openssl pkcs8 -topk8 -inform PEM -out snowflake_computer_key.p8 -nocrypt

Luego genere la clave pública correspondiente:

openssl rsa -in snowflake_computer_key.p8 -pubout -out snowflake_computer_key.pub

Paso 2: Crear un rol y un 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;

Paso 3: Crear el usuario de la cuenta de servicio

Ejecuta esto como ACCOUNTADMIN. Reemplaza el valor de RSA_PUBLIC_KEY por el contenido de tu archivo snowflake_computer_key.pub (sin las líneas de encabezado y pie de página).

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;

Nota: TYPE = SERVICE marca esto como una cuenta no humana; no establezca una contraseña. DEFAULT_ROLE = PERPLEXITY_ROLE lo limita a un único rol dedicado con solo los privilegios que necesita Perplexity.

Paso 4: Conceder acceso a tus datos

-- 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 un acceso más selectivo, consulte la documentación de Snowflake GRANT.

Paso 5: Conceder acceso al historial de consultas y al historial de acceso

Perplexity utiliza dos vistas en el esquema SNOWFLAKE.ACCOUNT_USAGE para crear un mapa de datos que permita generar consultas con precisión:

Vista	Finalidad
`QUERY_HISTORY`	Metadatos de consulta, rendimiento y patrones de uso
`ACCESS_HISTORY`	Registro de auditoría a nivel de objeto (solo Enterprise Edition)

USE ROLE ACCOUNTADMIN;
GRANT IMPORTED PRIVILEGES ON DATABASE SNOWFLAKE TO ROLE PERPLEXITY_ROLE;

Nota: ACCESS_HISTORY solo está disponible en Snowflake Enterprise Edition o superior; Perplexity recurre automáticamente a QUERY_HISTORY en Standard Edition. Omitir este paso reduce la precisión de las consultas. Para saber cómo Perplexity utiliza estas vistas, consulte Comprender el mapa de datos.

Verificar acceso

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;

Paso 6: (Opcional) Permitir direcciones IP

Si tu cuenta de Snowflake restringe las conexiones entrantes por IP, permite las IP 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;

Paso 7: Conectar Snowflake con Perplexity

Para OAuth de usuario: primero la configuración del administrador

Si tu organización usa OAuth, un administrador de la organización configura el Snowflake (OAuth de usuario) conector una sola vez antes de que los usuarios individuales puedan autenticarse. En Configuración de la organización → Conectores → Snowflake (OAuth de usuario), el administrador ve un panel de tres pasos:

Administrar aplicación OAuth — registra Perplexity como cliente OAuth en tu cuenta de Snowflake. Esto te guía para crear un Snowflake personalizado SECURITY INTEGRATION y pegar de vuelta en Perplexity el Client ID y el Client Secret resultantes.
Autenticarse con Snowflake (OAuth de usuario) — el administrador se autentica una vez para verificar que la integración funcione de extremo a extremo.
Generar un mapa de datos (opcional) — genera opcionalmente un mapa de datos para la organización (consulta Comprender el mapa de datos) y añade contexto complementario para mejorar la precisión.

En el paso 1, crea la integración de seguridad en el lado de Snowflake. Ejecuta esto 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';

Recupera el Client ID y el Client Secret para pegarlos de vuelta en Perplexity:

SELECT SYSTEM$SHOW_OAUTH_CLIENT_SECRETS('PERPLEXITY_OAUTH');

Una vez completada la configuración del administrador, los usuarios individuales pueden conectarse siguiendo los pasos a continuación.

Conectar (todos los usuarios)

Los usuarios solo ven el método de autenticación que coincida con el conector que haya configurado tu administrador.

Ve a Conectores en Configuración y busca el conector Snowflake o Snowflake (OAuth de usuario).
Haz clic en Activar → Añadir conector.
Autentícate usando el método configurado (consulta abajo).
Haz clic en Permitir para completar la configuración.

Autenticación con par de claves (conector de Snowflake). Introduce el identificador de tu cuenta de Snowflake, el nombre de usuario y la clave privada (snowflake_computer_key.p8).

OAuth (conector de Snowflake (OAuth de usuario)). Se te redirigirá a Snowflake para iniciar sesión. No hay selector de rol: tu sesión usa tu DEFAULT_ROLE como rol principal, con tu DEFAULT_SECONDARY_ROLES activada mediante OAUTH_USE_SECONDARY_ROLES = IMPLICIT. Si los valores predeterminados de tu rol ya están configurados, no es necesario hacer nada.

Si tu sesión no muestra datos que esperabas ver, pide a tu administrador de Snowflake que verifique tu DEFAULT_ROLE y DEFAULT_SECONDARY_ROLES (ver Configuración de roles de OAuth de usuario).

Uso de tus datos de Snowflake

Una vez conectado, referencia tus datos de Snowflake en Computer sesiones. Menciona bases de datos, esquemas o tablas y Perplexity los consultará como parte de flujos de trabajo de varios pasos, todo de forma asincrónica en un entorno seguro de cloud sandbox. Prueba consultas como:

“Resume las tendencias de ingresos de la tabla de ventas del cuarto trimestre y destaca los indicadores clave”
“Encuentra todos los registros de clientes actualizados en los últimos 30 días”
“¿Cuáles son los productos con mejor rendimiento según el esquema de analytics?”
“Compara los datos de pipeline de este trimestre con las cifras del trimestre anterior”

Solución de problemas

Snowflake no está habilitado para tu organización

Si estás en una organización Enterprise y no puedes habilitar el conector, es posible que un administrador lo haya desactivado. Ponte en contacto con el administrador de tu organización o con el soporte de Perplexity.

Problemas de conexión y autenticación

Verifica que las direcciones IP de Perplexity estén permitidas en la política de red de tu Snowflake.
Confirma que el rol tenga USAGE privilegios sobre los warehouses, bases de datos y esquemas requeridos.
Pide a los usuarios que vuelvan a conectar el conector después de cualquier cambio en la política.

Error “Invalid private key”

Asegúrate de que estás pegando la clave privada (snowflake_computer_key.p8), no la clave pública. El archivo debe comenzar con -----BEGIN PRIVATE KEY-----.

Autenticación rechazada por la política de autenticación actual

Ejecuta SHOW AUTHENTICATION POLICIES como ACCOUNTADMIN y asegúrate de que PERPLEXITY_USER esté cubierto por una política que incluya KEYPAIR. Si es necesario:

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

OAuth: el usuario ve datos limitados después de conectar

La sesión de OAuth usa el DEFAULT_ROLE del usuario como rol principal, con roles secundarios activados mediante OAUTH_USE_SECONDARY_ROLES = IMPLICIT. Si a un usuario le falta el acceso esperado:

Confirma que la integración de seguridad tenga OAUTH_USE_SECONDARY_ROLES = IMPLICIT.
Ejecuta DESC USER <username> y revisa DEFAULT_ROLE y DEFAULT_SECONDARY_ROLES — la sesión usa exactamente lo que está configurado allí.
Si el usuario no tiene configuración de rol por usuario y quieres que acceda a todo lo que se le ha concedido, configura DEFAULT_ROLE = PUBLIC y DEFAULT_SECONDARY_ROLES = ('ALL').
Pídele que desconecte y vuelva a conectar el conector para emitir un token nuevo después de cambiar cualquiera de estos ajustes.

La vista ACCESS_HISTORY devuelve un error

Confirma que tu cuenta de Snowflake sea Enterprise Edition o superior.

Privilegios insuficientes en las vistas de ACCOUNT_USAGE

Verifica GRANT IMPORTED PRIVILEGES se ejecutó como ACCOUNTADMIN y que PERPLEXITY_ROLE se haya concedido al usuario.

La autenticación con clave pública y privada falla

Vuelve a ejecutar DESC USER PERPLEXITY_USER para confirmar que la huella digital de la clave pública esté poblada.

Si los problemas persisten después de actualizar estos ajustes, contacta con el soporte de Perplexity para obtener ayuda.