Conectar Perplexity con Snowflake

​

Acerca del conector de Snowflake

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.

​

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

​

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

​

Recomendado: User OAuth

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

​

Alternativa: cuenta de servicio (par de claves)

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.

​

Configurar roles y acceso

​

Configuración de roles con User OAuth

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 <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 recién creados, por lo que muchas organizaciones ya lo tienen configurado. Ejecuta DESC USER <username> para comprobarlo antes de cambiar nada.

​

Configuración de roles con cuenta de servicio

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.

​

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

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.

​

Controlar lo que Perplexity puede hacer

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.

​

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

​

Seguridad y control de nivel empresarial

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

​

Guía de configuración

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.

​

Requisitos previos

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

​

Paso 1: generar un par de claves (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

​

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 cuenta de servicio

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.

​

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, consulta la documentación de GRANT de Snowflake.

​

Paso 5: conceder acceso al historial de consultas y al historial de accesos

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
QUERY_HISTORY	Metadatos de consulta, rendimiento y patrones de uso
ACCESS_HISTORY	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.

​

Verificar el 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) añadir a la lista de permitidos las direcciones IP

Si tu cuenta de Snowflake restringe las conexiones entrantes por IP, añade a la lista de permitidos 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 a Perplexity

​

Para User OAuth: primero la configuración del administrador

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

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 por parte del administrador, los usuarios individuales pueden conectarse siguiendo los pasos siguientes.

​

Conectar (todos los usuarios)

Los usuarios solo verán el método de autenticación correspondiente al conector que su administrador haya configurado.

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

OAuth (conector Snowflake (User OAuth)). 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 tus DEFAULT_SECONDARY_ROLES activados mediante OAUTH_USE_SECONDARY_ROLES = IMPLICIT. Si tus roles predeterminados ya están configurados, no hace falta ninguna acción.

Si a tu sesión le faltan datos que esperabas ver, pide a tu administrador de Snowflake que verifique tu DEFAULT_ROLE y tus DEFAULT_SECONDARY_ROLES (consulta Configuración de roles con User OAuth).

​

Usar tus datos de Snowflake

Una vez conectado, referencia tus datos de Snowflake en tareas de Computer. Menciona bases de datos, esquemas o tablas y Perplexity las consultará como parte de flujos de trabajo de varios pasos, todo de forma asíncrona en un entorno aislado seguro en la nube. Prueba consultas como:

• “Resume las tendencias de ingresos de la tabla de ventas del Q4 y destaca las métricas 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 analítica?"

• "Compara los datos del 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 deshabilitado. 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 en la lista de permitidos de tu política de red de Snowflake.

• Confirma que el rol tiene privilegios USAGE en los warehouses, bases de datos y esquemas necesarios.

• Pide a los usuarios que vuelvan a conectar el conector tras cualquier cambio de política.

​

Error “Invalid private key”

Asegúrate de estar pegando la clave privada (snowflake_computer_key.p8), no la pública. El archivo debe empezar por -----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 OAuth utiliza el DEFAULT_ROLE del usuario como rol principal, con los 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 tiene OAUTH_USE_SECONDARY_ROLES = IMPLICIT.

• Ejecuta DESC USER <username> y comprueba DEFAULT_ROLE y DEFAULT_SECONDARY_ROLES: la sesión utiliza exactamente lo que allí se haya configurado.

• Si el usuario no tiene configuración de roles individualizada y quieres que acceda a todo lo que se le ha concedido, establece 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 es Enterprise Edition o superior.

​

Privilegios insuficientes en las vistas ACCOUNT_USAGE

Verifica que se haya ejecutado GRANT IMPORTED PRIVILEGES como ACCOUNTADMIN y que PERPLEXITY_ROLE esté concedido al usuario.

​

La autenticación con par de claves falla

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

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