Conectar Devin a Databricks

Devin puede trabajar dentro de tus workspaces de Databricks como un compañero de trabajo asíncrono: explorar catálogos, depurar jobs fallidos, optimizar consultas SQL, escribir y probar cuadernos, y entregar cambios a través de tu flujo de trabajo habitual de Git. Esta guía te muestra cómo ponerlo en marcha con una entidad de servicio de Databricks dedicada con la que Devin se autentica, gobernada por Unity Catalog.

La integración se compone de tres piezas que ya controlas: una entidad de servicio de Databricks, la CLI de Databricks instalada mediante un blueprint de environment y, opcionalmente, el plugin de skills de Databricks. Databricks, sus workspaces y todos los permisos permanecen en tu cuenta.

Elige cómo se autentica Devin

Devin se autentica en Databricks como la entidad de servicio de una de estas dos formas. Ambas usan la misma entidad de servicio, la CLI instalada por el blueprint y los permisos de Unity Catalog; solo se diferencian en la credencial.

Vía	Ideal para	Configuración
Opción A: secreto de cliente OAuth	Empezar rápido. Tres Devin Secrets y un blueprint breve.	Genera un secreto de OAuth en la entidad de servicio y guárdalo en Devin Secrets.
Opción B: federación de tokens OIDC	Ampliar la integración, o cualquier equipo que prefiera no gestionar un secreto de Databricks. Databricks recomienda encarecidamente la federación de tokens para cargas de trabajo automatizadas, ya que no hay nada que rotar.	Confía en el emisor OIDC de Devin mediante una política de federación; en cada sesión se intercambia un token de identidad de Devin de corta duración por un token OAuth de Databricks.

Empieza con la Opción A si quieres poner a Devin a funcionar con Databricks hoy mismo. Más adelante puedes pasar a la Opción B sin tocar la entidad de servicio ni sus permisos.

¿Por qué conectar Devin a Databricks?

Devin trabaja allí donde vive tu plataforma de datos. La mayor parte del trabajo en Databricks no consiste solo en editar cuadernos en un repo. Consiste en revisar por qué falló un job, leer el schema de una tabla, ejecutar una query contra un warehouse o inspeccionar un proceso. Darle el CLI a Devin convierte todo eso, de preguntas dirigidas a una persona, en tareas que Devin puede resolver por sí mismo.
Una única identidad auditable. Devin actúa como una entidad de servicio creada por ti, de modo que cada API call, query y ejecución de job queda registrada en los audit logs de Databricks y en el linaje de Unity Catalog bajo esa identidad, y no bajo el token personal de un ingeniero.
Unity Catalog decide qué puede tocar Devin. OAuth decide si Devin puede autenticarse. Los permisos de Unity Catalog y del workspace deciden qué puede leer o modificar. Puedes empezar en modo read-only en producción, darle a Devin un catálogo de sandbox donde construir y ampliar el ámbito solo cuando hayas visto cómo se comporta.
Una vía sin secretos almacenados. Con la federación de tokens OIDC (Opción B), Devin nunca almacena un token de Databricks ni un client secret. Cada sesión intercambia un token de identidad de Devin de 60 segundos por un token OAuth de Databricks de corta duración.

Descripción general

Sesión de Devin
  │  La CLI de Databricks se autentica como la entidad de servicio
  │    Opción A: client ID + client secret desde Devin Secrets
  │    Opción B: token OIDC de Devin de corta duración, validado por una política de federación
  ▼
Databricks emite un access token OAuth de corta duración para la entidad de servicio
  │
  ▼
APIs del workspace, SQL warehouses, jobs, Unity Catalog
  (limitados por los permisos del workspace y los permisos de Unity Catalog)

La configuración consta de cuatro partes:

Parte	Dónde se encuentra	Qué hace
Entidad de servicio	Cuenta de Databricks	La identidad con la que actúa Devin. Se asigna a los workspaces que Devin necesita.
Autenticación	Cuenta de Databricks + Devin	Opción A: OAuth M2M con un client secret almacenado en Devin Secrets. Opción B: federación de tokens OIDC, sin secreto almacenado.
Databricks CLI	Blueprint de Devin	Se instala en la instantánea y se configura para autenticarse como la entidad de servicio.
Permisos	Workspace de Databricks + Unity Catalog	Derechos del workspace, permisos de SQL warehouses y jobs, y permisos sobre catálogos/esquemas.

El plugin de skills de Databricks es una quinta capa opcional: enseña a Devin flujos de trabajo propios de Databricks (Asset Bundles, jobs, SQL, Unity Catalog) sobre la base del CLI.

Requisitos previos

Databricks

Una cuenta de Databricks en AWS, Azure o GCP con acceso de admin de cuenta para la persona que realice la configuración. La creación de entidades de servicio, secretos OAuth y políticas de federación se realiza a nivel de cuenta.
Uno o más workspaces con Unity Catalog habilitado. Esta guía asume que Unity Catalog gobierna los datos a los que Devin debe acceder.
La CLI de Databricks en la máquina del propio admin para los comandos a nivel de cuenta que se indican más abajo. Para estos sirve cualquier versión reciente. La copia de Devin se instala por separado en el Paso 2.

Devin

Permiso para editar el blueprint de environment de tu organización (Settings > Environment > Blueprints).
Para la Opción A, permiso para agregar Devin Secrets.
Para la Opción B, la URL del issuer OIDC y el ID de organización de Devin. El Paso 2 muestra cómo obtener ambos de un token dentro de una sesión de Devin. Consulta Autenticación en la nube con OIDC para más contexto.

Red

Las sesiones de Devin deben poder acceder al host de tu workspace por HTTPS (por ejemplo, https://dbc-xxxx.cloud.databricks.com, https://adb-xxxx.azuredatabricks.net o https://xxxx.gcp.databricks.com). Si tu organización usa una política de red de Devin, agrega el host del workspace y, para los comandos a nivel de cuenta, el host de la cuenta (accounts.cloud.databricks.com, accounts.azuredatabricks.net o accounts.gcp.databricks.com).
Para la Opción B, Databricks debe poder obtener el JWKS de Devin en https://<your-devin-host>/.well-known/jwks.json a través de internet público para verificar las firmas de los tokens.

Paso 1: Crear una entidad de servicio

Crea una entidad de servicio dedicada para Devin en lugar de reutilizar una de la que dependan otras automatizaciones. Una entidad dedicada mantiene limpios los registros de auditoría y las revisiones de permisos. Desde una máquina en la que hayas iniciado sesión en la cuenta de Databricks (no en un workspace):

databricks account service-principals create --display-name devin-sessions

Anota dos valores de la salida:

Campo	Se usa para
`applicationId`	El client ID de OAuth. Se usa en el secreto `DATABRICKS_CLIENT_ID` (Opción A) o en el perfil de la CLI (Opción B), y en las sentencias `GRANT`.
`id`	El ID numérico de la entidad de servicio. Necesario para crear un secreto de OAuth (Opción A) o asociar una política de federación (Opción B).

Después, asigna la entidad de servicio a cada workspace que Devin vaya a usar. Puedes hacerlo en la consola de la cuenta, en User management → Service principals, o con la CLI:

databricks account workspace-assignment update <WORKSPACE_ID> <SERVICE_PRINCIPAL_ID> \
  --json '{"permissions": ["USER"]}'

Usa USER, no ADMIN. Devin no necesita permisos de admin del workspace.

Paso 2: Conectar Devin a la entidad de servicio

Sigue una de las dos opciones siguientes. Cada una es completa por sí sola: instala la CLI de Databricks mediante un blueprint en Settings > Environment > Blueprints y configura la CLI para autenticarse como la entidad de servicio del Paso 1.

Opción A: secreto de cliente OAuth. OAuth M2M estándar: la entidad de servicio obtiene un secreto de cliente, que almacenas en Devin Secrets. Es la forma más rápida de empezar.
Opción B: federación de tokens OIDC. Cada sesión de Devin puede emitir un token OpenID Connect de corta duración firmado por Devin. La federación de tokens de Databricks permite que la entidad de servicio confíe en ese emisor, de modo que Devin intercambia su propio token de identidad por un token OAuth de Databricks. Nunca se crea ni se almacena ningún secreto de Databricks, y por eso Databricks la recomienda encarecidamente para cargas de trabajo automatizadas.

Los tokens de acceso personal (PAT) vinculados a un usuario humano no se recomiendan en ninguna de las dos opciones: omiten la entidad de servicio, caducan de forma impredecible y atribuyen las acciones de Devin a una persona.

Opción A: secreto de cliente OAuth

¿Prefieres no gestionar ningún secreto de Databricks? Salta a la Opción B: federación de tokens OIDC. También puedes empezar aquí y cambiar más adelante: sustituye el blueprint por el de la Opción B, crea la política de federación y luego elimina el secreto de OAuth y el Devin Secret DATABRICKS_CLIENT_SECRET.

1. Genera un secreto de OAuth

En la consola de la cuenta, abre la entidad de servicio del paso 1 y genera un secreto de OAuth. Establece la vigencia más corta que permita tu proceso de rotación (el máximo es de 730 días) y limita el secreto a los ámbitos de API que Devin necesita, como sql, jobs y unity-catalog. Evita seleccionar todos los ámbitos.

2. Agrega los Devin Secrets

En Devin, agrega lo siguiente como Devin Secrets en la pestaña Secrets del blueprint que editarás a continuación (de organización o de repositorio):

Secreto	Valor
`DATABRICKS_HOST`	La URL del workspace en el que Devin debe trabajar, por ejemplo `https://dbc-xxxx.cloud.databricks.com` o `https://adb-xxxx.azuredatabricks.net`, sin el sufijo `/api`. No el host `accounts.*`.
`DATABRICKS_CLIENT_ID`	El `applicationId` de la entidad de servicio (un UUID) del paso 1, no el `id` numérico
`DATABRICKS_CLIENT_SECRET`	El secreto de OAuth que generaste

La CLI selecciona OAuth M2M automáticamente cuando hay un client ID y un client secret, por lo que DATABRICKS_AUTH_TYPE no es necesario. Configúralo como oauth-m2m solo si quieres descartar explícitamente cualquier otro método. Los secretos se inyectan como variables de entorno al inicio de cada nueva sesión, así que la CLI no necesita ningún archivo de perfil. Un secreto rotado se aplica en la siguiente sesión nueva sin necesidad de recompilar.

3. Agregar el blueprint

Solo instala la CLI. La autenticación proviene por completo de los tres secretos anteriores.

initialize:
  - name: Install Databricks CLI
    run: |
      sudo rm -f /usr/local/bin/databricks
      curl -fsSL https://raw.githubusercontent.com/databricks/setup-cli/main/install.sh | sudo sh
      databricks --version

knowledge:
  - name: databricks-auth
    contents: |
      The `databricks` CLI authenticates as a service principal using the DATABRICKS_HOST,
      DATABRICKS_CLIENT_ID, and DATABRICKS_CLIENT_SECRET environment variables, which are
      provided as Devin Secrets. Do not run `databricks auth login`, do not set DATABRICKS_TOKEN,
      and do not ask for a personal access token. Check auth with `databricks current-user me`.
      Write only to the devin_dev catalog; production catalogs are read-only. Ship notebook and
      job changes through a pull request.

No escribas los secretos en un archivo durante initialize; todo lo que se escriba ahí queda incorporado en la instantánea.

Tampoco configures DATABRICKS_TOKEN ni dejes un perfil ~/.databrickscfg en la instantánea. Las credenciales en conflicto son la causa más habitual de que falle la autenticación M2M.

4. Compila la instantánea

Guarda el blueprint y espera a que la compilación muestre Éxito; luego inicia una nueva sesión. Las sesiones existentes conservan la instantánea anterior. Continúa en el Paso 3.

Opción B: federación de tokens OIDC

Las sesiones de Devin emiten tokens de identidad de corta duración (iss, sub, aud), y una política de federación en la entidad de servicio le indica a Databricks que confíe en ellos. El blueprint instala la CLI devin-oidc, envuelve databricks para que cada llamada lleve un token nuevo y escribe un perfil que apunta a tu entidad de servicio. Luego lees los claims del token desde una sesión y creas una política que coincida con ellos.

¿Prefieres ir primero por el camino más corto? Empieza por la Opción A y vuelve aquí cuando quieras prescindir del secreto almacenado.

1. Agrega el blueprint

Debes reemplazar dos marcadores de posición del perfil con tus propios valores:

Marcador de posición	Reemplazar con
`<your-workspace-url>`	La URL del workspace en el que Devin debe trabajar, por ejemplo `https://dbc-xxxx.cloud.databricks.com` o `https://adb-xxxx.azuredatabricks.net`, sin el sufijo `/api`. No el host `accounts.*`. Es el mismo valor que `DATABRICKS_HOST` en la Opción A.
`<service-principal-applicationId>`	El `applicationId` de la entidad de servicio (un UUID) que aparece en la salida de `databricks account service-principals create` del Paso 1. No el `id` numérico, que solo se usa para asociar la política de federación.

initialize:
  - uses: github.com/CognitionAI/actions/setup-devin-oidc@main

  - name: Install Databricks CLI
    run: |
      sudo rm -f /usr/local/bin/databricks
      curl -fsSL https://raw.githubusercontent.com/databricks/setup-cli/main/install.sh | sudo sh
      sudo mv /usr/local/bin/databricks /usr/local/bin/databricks-bin

  - name: Wrap the CLI so each call carries a fresh Devin OIDC token
    run: |
      sudo tee /usr/local/bin/databricks > /dev/null <<'EOF'
      #!/usr/bin/env bash
      set -euo pipefail
      DATABRICKS_OIDC_TOKEN="$(devin-oidc token --audience "${DATABRICKS_DEVIN_AUDIENCE:-databricks}")"
      export DATABRICKS_OIDC_TOKEN
      exec /usr/local/bin/databricks-bin "$@"
      EOF
      sudo chmod +x /usr/local/bin/databricks

  - name: Write Databricks CLI profile
    run: |
      cat > ~/.databrickscfg <<'EOF'
      [DEFAULT]
      host      = <your-workspace-url>
      auth_type = env-oidc
      client_id = <service-principal-applicationId>
      audience  = databricks
      EOF
      chmod 600 ~/.databrickscfg

knowledge:
  - name: databricks-auth
    contents: |
      The `databricks` CLI is preconfigured to authenticate as a service principal through
      Devin OIDC token federation. Do not run `databricks auth login`, do not set
      DATABRICKS_TOKEN, and do not ask for a personal access token. Check auth with
      `databricks current-user me`. Write only to the devin_dev catalog; production catalogs
      are read-only. Ship notebook and job changes through a pull request.

Elemento	Propósito
`setup-devin-oidc`	Instala la CLI `devin-oidc`, que emite tokens de identidad de Devin (detalles).
Wrapper	Los tokens de identidad de Devin caducan a los 60 segundos, por lo que cada llamada a la CLI emite el suyo.
`auth_type = env-oidc`	Fija la CLI a la federación de tokens para que nunca recurra a un PAT ni a un inicio de sesión interactivo.
`host` / `client_id`	La URL del workspace y el `applicationId` de la entidad de servicio de la tabla anterior.
`audience`	La audiencia que solicita el wrapper y que deberás indicar en la política de federación de más abajo.
`knowledge`	Indica a Devin que la CLI ya está autenticada para que no intente ejecutar `databricks auth login`.

El perfil no contiene ningún secreto, por lo que puede escribirse sin riesgo durante initialize. Si vienes de la Opción A, elimina el Devin Secret DATABRICKS_CLIENT_SECRET en cuanto tengas aplicada la política que se describe abajo, para que la CLI no vea dos credenciales.

2. Compila la instantánea

Guarda el blueprint y espera a que la compilación muestre Éxito. Ningún elemento del blueprint depende de la política de federación que crearás a continuación, así que no tendrás que volver a compilarlo después.

3. Crear la política de federación

Una vez compilado el blueprint, las sesiones de Devin pueden emitir tokens de identidad. Usa uno para leer los claims exactos en los que Databricks debe confiar y luego crea en la entidad de servicio una política de federación que coincida con ellos.

Lee tu issuer y subject

Inicia una nueva sesión de Devin y pídele que ejecute lo siguiente. Solo imprime los claims de identidad del token, nunca el token en sí.

devin-oidc token --audience databricks | python3 -c '
import sys, json, base64
p = sys.stdin.read().strip().split(".")[1]
c = json.loads(base64.urlsafe_b64decode(p + "=="))
print(json.dumps({k: c[k] for k in ("iss", "sub", "aud")}, indent=2))'

Formato esperado:

{
  "iss": "https://app.devin.ai",
  "sub": "org_id:<your-org-id>",
  "aud": "databricks"
}

En los despliegues enterprise, iss es tu URL personalizada de Devin (por ejemplo, https://yourcompany.devinenterprise.com). Copia iss y sub exactamente como aparecen. No pegues el token sin procesar en tickets ni documentos; es una credencial de portador durante los siguientes 60 segundos.

Escribe la política de federación

Guarda esto como devin-federation-policy.json, sustituyendo los valores del paso anterior:

{
  "description": "Allow Devin sessions to authenticate as the devin-sessions service principal",
  "oidc_policy": {
    "issuer": "https://<your-devin-host>",
    "audiences": ["databricks"],
    "subject": "org_id:<your-org-id>"
  }
}

Los tres campos son de coincidencia exacta:

issuer debe ser igual al iss del token, incluido el esquema y sin barra final.
audiences debe incluir el audience que solicita Devin (databricks en esta guía).
subject debe ser igual al sub del token. El subject predeterminado es el ID de tu organización, por lo que todas las sesiones de la organización pueden autenticarse como este principal. Esta es la granularidad adecuada para Databricks, ya que las políticas de federación comparan el subject como una cadena literal. Los claims por sesión, como devin_id, cambian en cada sesión y no pueden coincidir con una política estática.

Deja subject_claim, jwks_uri y jwks_json sin definir. Databricks usa de forma predeterminada el claim sub y descubre el JWKS a partir del /.well-known/openid-configuration del issuer.

Adjunta la política a la entidad de servicio

databricks account service-principal-federation-policy create <SERVICE_PRINCIPAL_ID> \
  --policy-id devin-sessions \
  --json @devin-federation-policy.json

Confirma que existe:

databricks account service-principal-federation-policy list <SERVICE_PRINCIPAL_ID>

El perfil que escribió el blueprint ya apunta a esta entidad de servicio, así que no hace falta recompilar. Continúa al Paso 3.

Recompilaciones y fijado de versiones

Tanto el script de instalación de Databricks como setup-devin-oidc@main siguen sus ramas main upstream, por lo que una compilación completa incorpora las versiones nuevas; una compilación diferencial omite initialize y conserva las versiones que ya están en la instantánea hasta que cambie el blueprint. Si necesitas compilaciones reproducibles, descarga el instalador desde una etiqueta de versión en lugar de main (por ejemplo, .../databricks/setup-cli/v1.17.0/install.sh), que instala exactamente esa versión de la CLI, y fija la acción a un SHA de confirmación (setup-devin-oidc@<sha>).

Paso 3: Otorgar permisos

La autenticación solo acredita quién es Devin. Lo que Devin puede ver o modificar lo definen los permisos del workspace y los permisos de Unity Catalog, que puedes ajustar en cualquier momento sin tocar el blueprint. Empieza con el perfil más restringido que sirva para la tarea y amplíalo de forma deliberada.

Perfiles de permisos

Perfil	Trabajo habitual	Permisos de Unity Catalog	Permisos del workspace
Explore (empieza aquí)	Responder preguntas sobre los datos, documentar schemas, investigar jobs fallidos y proponer correcciones de queries en un PR	`USE CATALOG`, `USE SCHEMA`, `SELECT`, `BROWSE` en los catálogos de producción; `READ VOLUME` allí donde Devin necesite archivos	`CAN USE` en un SQL warehouse; `CAN VIEW` en los jobs y procesos que Devin deba investigar
Build	Prototipar tablas, funciones y cuadernos en un sandbox; ejecutar pruebas con datos reales de solo lectura	Permisos de Explore en producción, más la propiedad de (o `ALL PRIVILEGES` sobre) un catálogo o schema `devin_dev` dedicado	Permisos de Explore, más `CAN MANAGE RUN` en los jobs del sandbox y una política de clúster restrictiva si Devin puede iniciar cómputo
Operate	Volver a ejecutar o reparar jobs de producción concretos una vez validados Explore y Build	Permisos de Explore, más `MODIFY` en las tablas concretas en las que escribe un job	`CAN MANAGE RUN` en los jobs concretos, concedido job por job y no a nivel de todo el workspace

Las sentencias de permiso apuntan a la entidad de servicio mediante su ID de aplicación:

-- Explore: solo lectura sobre el catálogo analytics de producción
GRANT USE CATALOG, BROWSE ON CATALOG analytics TO `<sp-application-id>`;
GRANT USE SCHEMA, SELECT ON SCHEMA analytics.gold TO `<sp-application-id>`;
GRANT READ VOLUME ON VOLUME analytics.gold.landing TO `<sp-application-id>`;

-- Build: un catálogo sandbox propiedad de Devin, aislado de producción
CREATE CATALOG IF NOT EXISTS devin_dev;
ALTER CATALOG devin_dev OWNER TO `<sp-application-id>`;

Si prefieres la administración basada en grupos, agrega la entidad de servicio a un grupo como devin-agents y otorga los permisos al grupo en su lugar.

Los cambios de código deben seguir pasando por pull requests. Devin puede leer datos de producción para comprender un problema y validar una corrección en el sandbox, pero el cambio en el cuaderno, la definición del job o el Asset Bundle se aplica mediante tu proceso de revisión habitual, no editando producción directamente.

Paso 4: Instalar el plugin de skills de Databricks (opcional)

Databricks publica Agent Skills que enseñan a los coding agents los flujos de trabajo de Databricks: Asset Bundles, jobs, SQL, Unity Catalog y Spark. Instalarlas como un plugin de Devin le aporta a Devin ese conocimiento además del CLI.

Abre Customize → Plugins y elige Add plugin → From repository.
Ingresa el repositorio databricks/databricks-agent-skills y el subdirectorio plugins/databricks/claude. El manifest del plugin está en esa subcarpeta, así que al instalarlo desde el repository root aparece No plugin manifest found.
Instálalo en el ámbito de Organization si usaste un blueprint de organización en el paso 2. Si usaste un blueprint del repositorio, declara el plugin en el archivo .devin/config.json de ese repositorio (consulta herencia y niveles) para que solo las sesiones que tengan el CLI reciban también las skills.
Fija el plugin a un commit una vez que funcione, para que los cambios upstream no lleguen a tus sesiones sin revisar.

La skill principal del plugin recomienda ejecutar databricks auth login para configurar un profile. Ese flujo con navegador interactivo no puede completarse en una sesión de Devin desatendida y aquí no hace falta: la entrada knowledge del paso 2 le indica a Devin que el CLI ya está autenticado.

Paso 5: Verificar

Inicia una nueva sesión (una vez que la compilación del blueprint se complete correctamente) y pídele a Devin que ejecute:

databricks --version
databricks current-user me

current-user me debería devolver la entidad de servicio, con userName igual a su ID de aplicación. Para confirmar qué método de autenticación eligió la CLI:

databricks auth describe

Para la Opción A, esto devuelve oauth-m2m; para la Opción B, env-oidc. Que la autenticación sea correcta no significa que Devin pueda acceder a tus datos. Confirma que se apliquen los permisos del Paso 3:

databricks catalogs list
databricks warehouses list
databricks grants get catalog <catalog-name>

Reemplaza <catalog-name> por un catálogo que hayas concedido en el Paso 3 (en los ejemplos se usa analytics). Luego pídele a Devin que ejecute una consulta pequeña de solo lectura sobre un warehouse en el que tenga CAN USE y, si configuraste un perfil de compilación, que cree y elimine una tabla en devin_dev. Una consulta sobre una tabla de producción en la que Devin no tenga SELECT debería fallar; ese fallo indica que el límite de permisos está funcionando.

Solución de problemas

Síntoma	Se aplica a	Causa y solución
Errores sobre credenciales en conflicto o más de un método de autenticación	Opción A	Elimina `DATABRICKS_TOKEN`, `DATABRICKS_USERNAME` y cualquier perfil de `~/.databrickscfg`. La CLI no adivina cuando hay más de un método de autenticación configurado.
`DATABRICKS_OIDC_TOKEN` no está definido o está vacío	Opción B	Se omitió el wrapper o no está instalado. Comprueba que `which databricks` apunte al wrapper y que `devin-oidc token --audience databricks` funcione por sí solo.
`invalid_grant` o un error que menciona el subject	Opción B	El `subject` de la política no coincide exactamente con el `sub` del token. Vuelve a ejecutar el script de claims del paso 2 y compáralos carácter por carácter.
Error que menciona el audience	Opción B	El campo `audiences` de la política no incluye el audience que solicita el wrapper. Ambos usan `databricks` de forma predeterminada; mantenlos idénticos.
Error que menciona el issuer, JWKS o la firma	Opción B	`issuer` tiene un error tipográfico (barra final, `http`, host incorrecto) o Databricks no puede acceder a `https://<your-devin-host>/.well-known/jwks.json`. Carga esa URL desde fuera de tu red para confirmar que es pública.
Token expirado	Opción B	Los tokens de identidad de Devin duran 60 segundos. Usa el wrapper en lugar de generar un token manualmente.
La CLI no reconoce `env-oidc`	Opción B	La instantánea tiene una CLI antigua (o el package legacy de Python `databricks-cli`). Elimina el package antiguo del blueprint y vuelve a compilarlo.
Autenticado, pero `catalogs list` está vacío o se deniega una query	Ambas	El principal está autenticado pero no autorizado. Revisa la asignación del workspace (paso 1) y los grants de Unity Catalog (paso 3) con `databricks grants get catalog <name>`.
Tiempos de espera de conexión o fallos de DNS	Ambas	El host del workspace no es accesible desde Devin. Agrégalo (y el host de la cuenta, si es necesario) a tu política de red de Devin.

Soporte

Para la configuración del lado de Databricks (entidades de servicio, secretos de OAuth, políticas de federación, Unity Catalog), consulta la documentación de autenticación de Databricks (cambia a la edición de Azure o GCP según corresponda). Para la configuración del lado de Devin (blueprints, OIDC, plugins, política de red), escribe a support@cognition.ai o contacta con tu equipo de cuenta.

Primeros pasos

Conceptos clave

Incorporación de Devin

Trabajar con Devin

Guías de producto

Integraciones

Admin

Notas de la versión

Conectar Devin a Databricks

Elige cómo se autentica Devin

¿Por qué conectar Devin a Databricks?

Descripción general

Requisitos previos

Paso 1: Crear una entidad de servicio

Paso 2: Conectar Devin a la entidad de servicio

Opción A: secreto de cliente OAuth

1. Genera un secreto de OAuth

2. Agrega los Devin Secrets

3. Agregar el blueprint

4. Compila la instantánea

Opción B: federación de tokens OIDC

1. Agrega el blueprint

2. Compila la instantánea

3. Crear la política de federación

Recompilaciones y fijado de versiones

Paso 3: Otorgar permisos

Perfiles de permisos

Paso 4: Instalar el plugin de skills de Databricks (opcional)

Paso 5: Verificar

Solución de problemas

Soporte

​Elige cómo se autentica Devin

​¿Por qué conectar Devin a Databricks?

​Descripción general

​Requisitos previos

​Paso 1: Crear una entidad de servicio

​Paso 2: Conectar Devin a la entidad de servicio

​Opción A: secreto de cliente OAuth

​1. Genera un secreto de OAuth

​2. Agrega los Devin Secrets

​3. Agregar el blueprint

​4. Compila la instantánea

​Opción B: federación de tokens OIDC

​1. Agrega el blueprint

​2. Compila la instantánea

​3. Crear la política de federación

​Recompilaciones y fijado de versiones

​Paso 3: Otorgar permisos

​Perfiles de permisos

​Paso 4: Instalar el plugin de skills de Databricks (opcional)

​Paso 5: Verificar

​Solución de problemas

​Soporte

Elige cómo se autentica Devin

¿Por qué conectar Devin a Databricks?

Descripción general

Requisitos previos

Paso 1: Crear una entidad de servicio

Paso 2: Conectar Devin a la entidad de servicio

Opción A: secreto de cliente OAuth

1. Genera un secreto de OAuth

2. Agrega los Devin Secrets

3. Agregar el blueprint

4. Compila la instantánea

Opción B: federación de tokens OIDC

1. Agrega el blueprint

2. Compila la instantánea

3. Crear la política de federación

Recompilaciones y fijado de versiones

Paso 3: Otorgar permisos

Perfiles de permisos

Paso 4: Instalar el plugin de skills de Databricks (opcional)

Paso 5: Verificar

Solución de problemas

Soporte