El conector de Snowflake te permite consultar datos de tu almacén de datos de Snowflake directamente desde Perplexity. Puedes buscar y combinar información en tus bases de datos de Snowflake, en tus demás aplicaciones conectadas y en la web, sin escribir SQL a mano ni cambiar a la consola de Snowflake.
Está disponible en Perplexity Pro, Perplexity Max, Enterprise Pro y Enterprise Max. La conexión con Snowflake se realiza por usuario: nadie más en tu organización puede consultar tus datos a menos que los sincronices a 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 un paso a paso de configuración. Si solo buscas el camino más rápido: la mayoría de las organizaciones deberían utilizar User OAuth: salta directamente a la Guía de configuración.
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 estás autorizado a ver. Cuando tus datos de Snowflake cambien, el conector reflejará esos cambios automáticamente en tu siguiente consulta.
Objetos de datos admitidos:
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 vídeo almacenados en stages de Snowflake) no son compatibles.
La autenticación de Snowflake tiene dos dimensiones independientes: quién ejecuta las consultas (la identidad) y cómo esa identidad demuestra que lo es (la credencial). Perplexity ofrece dos conectores en el directorio, cada uno con una combinación recomendada:
Snowflake (User OAuth): 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) utilizando un par de claves. Úsalo cuando tus usuarios finales no tengan cuentas individuales de Snowflake.
Con User OAuth, cada persona se autentica con sus propias credenciales, las consultas se ejecutan bajo sus permisos nativos de Snowflake y obtienes una pista de auditoría clara 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 coincide con la propia dirección de Snowflake: su servidor MCP gestionado solo admite OAuth 2.0 hoy en día.
Nota: con OAuth, el token de acceso se vincula a un único rol principal en el inicio de sesión: el DEFAULT\_ROLE del 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 con User OAuth).
Una cuenta de servicio compartida (TYPE = SERVICE + par de claves) es apropiada 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ás configurando un entorno interno o de prueba en el que no se requiere identidad por usuario.
Configura la cuenta de servicio con un rol dedicado y de alcance estrecho: consulta Configuración de roles con cuenta de servicio.
Nota sobre los tokens de acceso programático (PAT): Snowflake también admite credenciales PAT y el conector los acepta. No recomendamos PAT para configuraciones nuevas: los tokens caducan en un plazo corto y se vinculan estrictamente a un único rol en el momento de la creación, por lo que en los ejemplos de esta guía usamos un par de claves. Si tienes que usar un PAT, establece ROLE\_RESTRICTION a tu rol dedicado de Perplexity en el momento de la creación.
Una sesión OAuth se abre con el DEFAULT\_ROLE del usuario como rol principal; no se admite el cambio de rol dentro de una sesión y Perplexity no muestra un selector de roles. Por lo tanto, lo que cada usuario tenga configurado como DEFAULT\_ROLE y DEFAULT\_SECONDARY\_ROLES es exactamente lo que utiliza su sesión de Perplexity.
Configura esto una vez, a nivel de la integración de seguridad:
OAUTH\_USE\_SECONDARY\_ROLES = IMPLICIT
El valor predeterminado de este parámetro en Snowflake es NONE, lo que significa que las sesiones OAuth se abren solo con el rol principal activo. Establecerlo en IMPLICIT le indica a Snowflake que active también automáticamente los DEFAULT\_SECONDARY\_ROLES de cada usuario. Sin esto, los usuarios solo verán los datos accesibles a través de su DEFAULT\_ROLE, algo que rara vez es lo deseado.
Después gestiona uno de estos dos casos:
Caso A: los usuarios ya tienen roles predeterminados. Si el DEFAULT\_ROLE y los DEFAULT\_SECONDARY\_ROLES de tus usuarios ya están configurados como deseas, no hagas nada más. El ajuste IMPLICIT es suficiente: los valores predeterminados existentes de cada usuario son lo que utilizará su sesión de Perplexity.
Caso B: los usuarios aún no tienen roles predeterminados. Dale a cada sesión la unión de todos los roles concedidos a ese usuario estableciendo DEFAULT\_ROLE en PUBLIC y DEFAULT\_SECONDARY\_ROLES en ALL:
ALTER USER \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 recién creados, por lo que muchas organizaciones ya lo tienen configurado. Ejecuta DESC USER \ para comprobarlo antes de cambiar nada.
Una cuenta de servicio es un único usuario dedicado que se ejecuta bajo un rol específico, normalmente PERPLEXITY\_ROLE. El patrón PUBLIC + ('ALL') utilizado para OAuth no se aplica aquí. En su lugar, establece el DEFAULT\_ROLE del usuario de servicio en tu rol dedicado y concede a ese rol solo los privilegios que Perplexity necesita. Esto sigue las buenas prácticas de Snowflake para cuentas de servicio.
El SQL completo para crear este usuario está en la Guía de configuración más abajo.
Para limitar en qué roles de Snowflake pueden autenticarse los usuarios a través de la integración OAuth de Perplexity, establece el alcance a nivel de la integración de seguridad:
PRE\_AUTHORIZED\_ROLES\_LIST: lista de permitidos con los roles autorizados a través de esta integración.
BLOCKED\_ROLES\_LIST: lista de denegados con los roles bloqueados de esta integración.
ALTER SECURITY INTEGRATION PERPLEXITY\_OAUTH
SET PRE\_AUTHORIZED\_ROLES\_LIST = ('ANALYST\_ROLE', 'READ\_ONLY\_ROLE');
Úsalo para mantener los roles sensibles (por ejemplo, ACCOUNTADMIN) totalmente fuera del flujo OAuth.
El conector ejecuta SQL a través de una superficie de herramientas (procedente del conector de Merge para Snowflake). El conector Snowflake (User OAuth) expone herramientas con nombre y granulares, 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 las entradas con múltiples sentencias. El conector Snowflake de cuenta de servicio expone una herramienta general execute\_sql que acepta SQL arbitrario, incluidos DDL y DML.
El control autorizado es el RBAC de Snowflake. Independientemente de la herramienta que se invoque, las consultas se ejecutan bajo el rol que tu configuración permita, por lo que aplicar el modo de solo lectura a nivel del rol de Snowflake es el respaldo fiable, y es la única frontera de aplicación en el conector de cuenta de servicio.
Patrón recomendado: aplicar solo lectura con un rol dedicado. Aprovisiona un rol como PERPLEXITY\_READ\_ONLY que conceda solo USAGE y SELECT en las bases de datos, esquemas y tablas que quieras que Perplexity consulte, y no conceda INSERT, UPDATE, DELETE, CREATE, DROP, OWNERSHIP ni MODIFY del warehouse. Luego asegúrate de que los usuarios se autentican en ese rol:
Estableciéndolo como el DEFAULT\_ROLE del usuario, o
Delimitando la integración OAuth con PRE\_AUTHORIZED\_ROLES\_LIST o excluyendo los roles con capacidad de escritura con BLOCKED\_ROLES\_LIST (consulta Restringir qué roles se pueden usar mediante OAuth).
Con el RBAC configurado de esta forma, Snowflake rechaza cualquier intento de escritura de Perplexity, independientemente de la herramienta invocada.
Nota: los ajustes del conector incluyen un panel de Permisos de herramientas con las herramientas disponibles. En el conector Snowflake (User OAuth) puedes acotar qué herramientas se exponen: para una configuración de solo lectura, habilita solo las herramientas de lectura (por ejemplo execute\_sql\_readonly, list\_\*, describe\_\*, get\_\*) para dejar las herramientas de escritura/DDL fuera de la superficie. Trátalo como defensa en profundidad, no como la frontera autoritativa: el RBAC de Snowflake (arriba) es lo que aplica de forma fiable el acceso.
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 UDFs y procedimientos almacenados personalizados.
Si revocas el acceso o eliminas un rol en Snowflake, esos datos dejan de ser accesibles desde Perplexity de inmediato. Si desconectas Snowflake en Perplexity, puedes elegir si conservar o eliminar los datos en caché.
Para organizaciones Enterprise, Perplexity ofrece la certificación SOC 2 Tipo II, cifrado de extremo a extremo, estrictas medidas de privacidad de datos y controles granulares de acceso de usuarios. Tus datos de Snowflake nunca se utilizan para entrenar la IA.
La conexión con Snowflake se realiza por usuario: nadie más en tu organización puede consultar tus datos. Sin embargo, si sincronizas datos con un Proyecto compartido, cualquier persona con acceso a ese Proyecto podrá buscar en ellos.
Los administradores de la organización pueden habilitar o deshabilitar el conector para todos los usuarios desde la pantalla de Permisos en la configuración de la organización. La aplicación de lectura/escritura se gestiona a nivel del rol de Snowflake (consulta Controlar lo que Perplexity puede hacer).
Elige el camino que se ajuste a tu método de autenticación:
User OAuth (recomendado): un administrador de la organización configura la aplicación OAuth una vez y, a continuación, los usuarios inician sesión individualmente. Salta directamente a Conectar Snowflake a Perplexity: el SQL de los pasos 1 a 6 es solo para configuraciones con cuenta de servicio.
Cuenta de servicio (par de claves): ejecuta la configuración SQL de los pasos 1 a 6 y conecta en el paso 7.
Rol ACCOUNTADMIN (o un rol con privilegios de CREATE USER y GRANT).
OpenSSL instalado localmente (viene preinstalado en macOS): solo para configuraciones con cuenta de servicio.
Desde tu terminal, genera una clave privada RSA:
openssl genrsa 2048 | openssl pkcs8 -topk8 -inform PEM -out snowflake\_computer\_key.p8 -nocrypt
A continuación, genera la clave pública correspondiente:
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;
Ejecuta esto como ACCOUNTADMIN. Sustituye el valor RSA\_PUBLIC\_KEY por el contenido de tu archivo snowflake\_computer\_key.pub (sin las líneas de encabezado y pie).
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 esta cuenta como no humana: no establezcas una contraseña. DEFAULT\_ROLE = PERPLEXITY\_ROLE la delimita a un rol dedicado con solo los privilegios que Perplexity necesita.
-- 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, consulta la documentación de GRANT de Snowflake.
Perplexity utiliza dos vistas en el esquema SNOWFLAKE.ACCOUNT\_USAGE para construir un Mapa de datos que permite generar consultas con precisión:
|
Vista |
Propósito |
|
|
Metadatos de consulta, rendimiento y patrones de uso |
|
|
Pista 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 usa estas vistas, consulta Entender el Mapa de datos.