Conecte o Devin ao Databricks

O Devin pode atuar dentro dos seus workspaces do Databricks como um colega de trabalho assíncrono: explorando catálogos, depurando jobs que falharam, otimizando SQL, escrevendo e testando notebooks e entregando mudanças pelo seu fluxo de trabalho Git habitual. Este guia mostra como colocar isso em prática com uma entidade de serviço dedicada do Databricks, usada pelo Devin para se autenticar e governada pelo Unity Catalog.

A integração é formada por três peças que você já controla: uma entidade de serviço do Databricks, a CLI do Databricks instalada por meio de um blueprint de ambiente e (opcionalmente) o plugin de skills do Databricks. O Databricks, seus workspaces e todas as permissões permanecem na sua conta.

Escolha como o Devin se autentica

O Devin se autentica no Databricks como a entidade de serviço de duas formas possíveis. Ambas usam a mesma entidade de serviço, a CLI instalada pelo blueprint e as concessões do Unity Catalog; a diferença está apenas na credencial.

Caminho	Ideal para	Configuração
Opção A: client secret OAuth	Começar rapidamente. Três Devin Secrets e um blueprint curto.	Gere um segredo OAuth na entidade de serviço e armazene-o nos Devin Secrets.
Opção B: federação de tokens OIDC	Expandir a integração ou qualquer equipe que prefira não gerenciar um segredo do Databricks. O Databricks recomenda fortemente a federação de tokens para cargas de trabalho automatizadas, já que não há nada para rotacionar.	Estabeleça confiança no issuer OIDC do Devin com uma policy de federação; cada sessão troca um token de identidade de curta duração do Devin por um OAuth token do Databricks.

Comece pela Opção A se quiser o Devin rodando com o Databricks hoje mesmo. Você pode migrar para a Opção B depois, sem mexer na entidade de serviço nem em suas concessões.

Por que conectar o Devin ao Databricks?

O Devin atua onde sua plataforma de dados está. A maior parte do trabalho no Databricks não se resume a editar notebooks em um repo. É investigar por que um job falhou, ler o schema de uma tabela, executar uma query em um warehouse ou inspecionar um pipeline. Dar o CLI ao Devin transforma tudo isso de perguntas feitas a um humano em tarefas que o próprio Devin pode realizar.
Uma única identidade auditável. O Devin atua como uma entidade de serviço criada por você, então cada chamada à API, query e execução de job aparece nos audit logs do Databricks e na linhagem do Unity Catalog sob essa identidade, e não sob o token pessoal de um engenheiro.
O Unity Catalog decide o que o Devin pode acessar. O OAuth decide se o Devin pode se autenticar. As concessões do Unity Catalog e as permissões do workspace decidem o que ele pode ler ou alterar. Você pode começar com acesso somente leitura em produção, dar ao Devin um catalog de sandbox para construir e só ampliar o escopo depois de observar como ele se comporta.
Um caminho sem segredo armazenado. Com a federação de tokens OIDC (Opção B), o Devin nunca armazena um token ou client secret do Databricks. Cada sessão troca um token de identidade do Devin válido por 60 segundos por um token OAuth do Databricks de curta duração.

Visão geral

Sessão do Devin
  │  A CLI do Databricks autentica como a entidade de serviço
  │    Opção A: client ID + client secret dos Devin Secrets
  │    Opção B: token OIDC do Devin de curta duração, correspondido por uma policy de federação
  ▼
O Databricks emite um access token OAuth de curta duração para a entidade de serviço
  │
  ▼
APIs do workspace, SQL warehouses, jobs, Unity Catalog
  (limitados pelas permissões do workspace e pelos grants do Unity Catalog)

A configuração tem quatro partes:

Parte	Onde fica	O que faz
Entidade de serviço	Conta Databricks	A identidade que o Devin assume. Atribuída aos workspaces de que o Devin precisa.
Autenticação	Conta Databricks + Devin	Opção A: OAuth M2M com um client secret armazenado no Devin Secrets. Opção B: federação de tokens OIDC, sem segredo armazenado.
Databricks CLI	Blueprint do Devin	Instalada no snapshot e configurada para autenticar como a entidade de serviço.
Permissões	Workspace Databricks + Unity Catalog	Direitos no workspace, permissões de SQL warehouse e jobs, e concessões de catalog/schema.

O plugin de skills do Databricks é uma quinta camada, opcional: ele ensina ao Devin fluxos de trabalho específicos do Databricks (Asset Bundles, jobs, SQL, Unity Catalog) em cima da CLI.

Pré-requisitos

Databricks

Uma conta Databricks na AWS, Azure ou GCP com acesso de account admin para a pessoa que fará a configuração. A criação de entidades de serviço, segredos OAuth e políticas de federação acontece no nível da conta.
Um ou mais workspaces com o Unity Catalog ativado. Este guia pressupõe que o Unity Catalog governa os dados que o Devin deve acessar.
A CLI do Databricks na máquina do próprio admin, para os comandos de nível de conta abaixo. Qualquer versão recente serve. A cópia usada pelo Devin é instalada separadamente na etapa 2.

Devin

Permissão para editar o blueprint de ambiente da sua organização (Configurações > Ambiente > Blueprints).
Para a Opção A, permissão para adicionar Devin Secrets.
Para a Opção B, a URL do issuer OIDC e o ID da organização do seu Devin. A etapa 2 mostra como obter ambos a partir de um token dentro de uma sessão do Devin. Consulte Autenticação em nuvem com OIDC para mais contexto.

Rede

As sessões do Devin precisam alcançar o host do seu workspace por HTTPS (por exemplo, https://dbc-xxxx.cloud.databricks.com, https://adb-xxxx.azuredatabricks.net ou https://xxxx.gcp.databricks.com). Se a sua organização usa uma network policy do Devin, adicione o host do workspace e, para comandos de nível de conta, o host da conta (accounts.cloud.databricks.com, accounts.azuredatabricks.net ou accounts.gcp.databricks.com).
Para a Opção B, o Databricks precisa conseguir buscar o JWKS do Devin em https://<your-devin-host>/.well-known/jwks.json pela internet pública para verificar as assinaturas dos tokens.

Etapa 1: Criar uma entidade de serviço

Crie uma entidade de serviço dedicada ao Devin em vez de reutilizar uma que outras automações já usam. Uma entidade dedicada mantém os logs de auditoria e as revisões de permissão organizados. Em uma máquina onde você esteja conectado à conta do Databricks (e não a um workspace):

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

Anote dois valores da saída:

Campo	Usado para
`applicationId`	O client ID do OAuth. Usado no segredo `DATABRICKS_CLIENT_ID` (Opção A) ou no perfil da CLI (Opção B), e em declarações `GRANT`.
`id`	O ID numérico da entidade de serviço. Necessário para criar um segredo OAuth (Opção A) ou vincular uma policy de federação (Opção B).

Em seguida, atribua a entidade de serviço a cada workspace que o Devin deve usar. Faça isso no console da conta em User management → Service principals ou pela CLI:

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

Use USER, não ADMIN. O Devin não precisa ser admin do workspace.

Etapa 2: Conecte o Devin à entidade de serviço

Siga uma das duas opções abaixo. Cada uma é completa por si só: instala a CLI do Databricks por meio de um blueprint em Configurações > Ambiente > Blueprints e configura a CLI para autenticar como a entidade de serviço criada na Etapa 1.

Opção A: client secret do OAuth. OAuth M2M padrão: a entidade de serviço recebe um client secret, que você armazena nos Secrets do Devin. É a forma mais rápida de começar.
Opção B: federação de tokens OIDC. Cada sessão do Devin pode gerar um token OpenID Connect de curta duração assinado pelo Devin. A federação de tokens do Databricks permite que a entidade de serviço confie nesse issuer, de modo que o Devin troca seu próprio token de identidade por um token OAuth do Databricks. Nenhum segredo do Databricks chega a ser criado ou armazenado, e é por isso que o Databricks recomenda fortemente essa abordagem para cargas de trabalho automatizadas.

Personal access tokens (PATs) vinculados a um human user não são recomendados em nenhuma das opções. Eles contornam a entidade de serviço, expiram de forma imprevisível e atribuem as ações do Devin a uma pessoa.

Opção A: client secret OAuth

Prefere não gerenciar nenhum segredo do Databricks? Vá direto para a Opção B: federação de tokens OIDC. Você também pode começar por aqui e mudar depois: troque para o blueprint da Opção B, crie a policy de federação e, em seguida, exclua o segredo OAuth e o Devin Secret DATABRICKS_CLIENT_SECRET.

1. Gere um segredo OAuth

No console da conta, abra a entidade de serviço da Etapa 1 e gere um segredo OAuth. Defina o menor tempo de vida compatível com seu processo de rotação (o máximo é 730 dias) e restrinja o segredo aos escopos de API de que o Devin precisa, como sql, jobs e unity-catalog. Evite selecionar todos os escopos.

2. Adicione os Devin Secrets

No Devin, adicione os itens a seguir como Devin Secrets na aba Secrets do blueprint que você editará em seguida (organização ou repositório):

Segredo	Valor
`DATABRICKS_HOST`	A URL do workspace em que o Devin deve atuar, por exemplo `https://dbc-xxxx.cloud.databricks.com` ou `https://adb-xxxx.azuredatabricks.net`, sem o sufixo `/api`. Não é o host `accounts.*`.
`DATABRICKS_CLIENT_ID`	O `applicationId` da entidade de serviço (um UUID) obtido na Etapa 1, e não o `id` numérico
`DATABRICKS_CLIENT_SECRET`	O segredo OAuth que você gerou

A CLI seleciona o OAuth M2M automaticamente quando há um client ID e um client secret, portanto DATABRICKS_AUTH_TYPE não é obrigatório. Defina-o como oauth-m2m apenas se quiser descartar explicitamente todos os outros métodos. Os segredos são injetados como variáveis de ambiente no início de cada nova sessão, então a CLI não precisa de um arquivo de perfil. Um segredo rotacionado passa a valer na próxima sessão, sem necessidade de rebuild.

3. Adicione o blueprint

Instala apenas a CLI. A autenticação é feita inteiramente pelos três segredos acima.

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.

Não grave os segredos em um arquivo durante o initialize; tudo o que for escrito ali fica embutido no snapshot.

Também não defina DATABRICKS_TOKEN nem deixe um perfil ~/.databrickscfg no snapshot. Credenciais conflitantes são a causa mais comum de falha na autenticação M2M.

4. Faça o build do snapshot

Salve o blueprint e aguarde o build exibir Success; em seguida, inicie uma nova sessão. As sessões existentes mantêm o snapshot antigo. Prossiga para a Etapa 3.

Opção B: federação de tokens OIDC

As sessões do Devin emitem tokens de identidade de curta duração (iss, sub, aud), e uma policy de federação na entidade de serviço instrui o Databricks a confiar neles. O blueprint instala a CLI devin-oidc, encapsula o databricks para que cada chamada leve um token novo e grava um perfil que aponta para a sua entidade de serviço. Em seguida, você lê as claims do token em uma sessão e cria uma policy que corresponda a elas.

Quer o caminho mais curto primeiro? Comece pela Opção A e volte aqui quando estiver pronto para abrir mão do segredo armazenado.

1. Adicione o blueprint

Dois espaços reservados no perfil devem ser substituídos pelos seus próprios valores:

Espaço reservado	Substitua por
`<your-workspace-url>`	A URL do workspace em que o Devin deve trabalhar, por exemplo `https://dbc-xxxx.cloud.databricks.com` ou `https://adb-xxxx.azuredatabricks.net`, sem o sufixo `/api`. Não é o host `accounts.*`. É o mesmo valor de `DATABRICKS_HOST` na Opção A.
`<service-principal-applicationId>`	O `applicationId` da entidade de serviço (um UUID) exibido na saída de `databricks account service-principals create` na Etapa 1. Não é o `id` numérico, que serve apenas para anexar a policy de federação.

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.

Componente	Finalidade
`setup-devin-oidc`	Instala a CLI `devin-oidc`, que emite tokens de identidade do Devin (detalhes).
Wrapper	Os tokens de identidade do Devin expiram após 60 segundos, então cada chamada da CLI emite o seu próprio.
`auth_type = env-oidc`	Fixa a CLI na federação de tokens, de modo que ela nunca recorra a um PAT ou a login interativo.
`host` / `client_id`	A URL do workspace e o `applicationId` da entidade de serviço da tabela acima.
`audience`	O audience que o wrapper solicita e que você vai informar na policy de federação abaixo.
`knowledge`	Informa ao Devin que a CLI já está autenticada, para que ele não tente executar `databricks auth login`.

O perfil não contém nenhum segredo, portanto é seguro gravá-lo durante o initialize. Se você estiver migrando da Opção A, remova o Devin Secret DATABRICKS_CLIENT_SECRET assim que a policy abaixo estiver configurada, para que a CLI não encontre duas credenciais.

2. Faça o build do snapshot

Salve o blueprint e aguarde até que o build exiba Success. Nada no blueprint depende da policy de federação que você vai criar em seguida, portanto não será necessário refazer o build depois.

3. Crie a policy de federação

Com o blueprint construído, as sessões do Devin podem emitir tokens de identidade. Use um deles para ler exatamente em quais claims o Databricks precisa confiar e, em seguida, crie na entidade de serviço uma policy de federação que corresponda a elas.

Leia seu issuer e subject

Inicie uma nova sessão do Devin e peça que ele execute o comando a seguir. Ele imprime apenas as claims de identidade do token, nunca o token em si.

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

Em deployments enterprise, iss é a sua URL personalizada do Devin (por exemplo, https://yourcompany.devinenterprise.com). Copie iss e sub exatamente como foram impressos. Não cole o token bruto em tickets ou documentos; ele é uma credencial bearer válida pelos próximos 60 segundos.

Escreva a policy de federação

Salve isto como devin-federation-policy.json, substituindo os valores da etapa 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>"
  }
}

Os três campos exigem correspondência exata:

issuer deve ser igual ao iss do token, incluindo o esquema e sem barra no final.
audiences deve incluir a audience que o Devin solicita (databricks, neste guia).
subject deve ser igual ao sub do token. O subject padrão é o ID da sua organização, portanto todas as sessões da organização podem se autenticar como esse principal. Essa é a granularidade adequada para o Databricks, porque as policies de federação comparam o subject como uma string literal. Claims por sessão, como devin_id, mudam a cada sessão e não podem ser correspondidas por uma policy estática.

Deixe subject_claim, jwks_uri e jwks_json sem definição. O Databricks usa por padrão a claim sub e descobre o JWKS a partir do /.well-known/openid-configuration do issuer.

Vincule a policy à entidade de serviço

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

Confirme que ela existe:

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

O perfil que o blueprint escreveu já aponta para essa entidade de serviço, então não é preciso reconstruir nada. Continue para a Etapa 3.

Rebuilds e fixação de versão

Tanto o script de instalação do Databricks quanto o setup-devin-oidc@main acompanham seus branches main upstream, ou seja, um build completo incorpora novas versões; já um build diferencial pula o initialize e mantém as versões já presentes no snapshot até que o blueprint seja alterado. Se você precisa de builds reproduzíveis, baixe o instalador a partir de uma tag de versão em vez de main (por exemplo, .../databricks/setup-cli/v1.17.0/install.sh), o que instala exatamente aquela versão do CLI, e fixe a GitHub Action em um SHA de commit (setup-devin-oidc@<sha>).

Etapa 3: Conceder permissões

A autenticação apenas comprova quem é o Devin. O que o Devin pode ver ou alterar é definido pelas permissões do workspace e pelas concessões do Unity Catalog, que você pode ajustar a qualquer momento sem mexer no blueprint. Comece com o perfil mais restrito que atenda ao trabalho e amplie de forma deliberada.

Perfis de permissão

Perfil	Trabalho típico	Concessões no Unity Catalog	Permissões no workspace
Explore (comece aqui)	Responder perguntas sobre dados, documentar schemas, investigar jobs que falharam, propor correções de query em um PR	`USE CATALOG`, `USE SCHEMA`, `SELECT`, `BROWSE` nos catálogos de produção; `READ VOLUME` onde o Devin precisar de arquivos	`CAN USE` em um SQL warehouse; `CAN VIEW` nos jobs e pipelines que o Devin deve investigar
Build	Prototipar tabelas, funções e notebooks em um sandbox; executar testes com dados reais em modo somente leitura	Concessões do Explore em produção, mais a propriedade (ou `ALL PRIVILEGES`) de um catálogo ou schema `devin_dev` dedicado	Permissões do Explore, mais `CAN MANAGE RUN` nos jobs de sandbox e uma policy de cluster restritiva caso o Devin possa iniciar computação
Operate	Reexecutar ou reparar jobs de produção específicos depois que Explore e Build estiverem comprovados	Concessões do Explore, mais `MODIFY` nas tabelas específicas em que um job escreve	`CAN MANAGE RUN` nos jobs específicos, concedido job a job em vez de para todo o workspace

Os statements de concessão apontam para a entidade de serviço pelo seu ID de aplicação:

-- Explore: somente leitura no catalog de análises de produção
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: um catalog de sandbox pertencente ao Devin, isolado da produção
CREATE CATALOG IF NOT EXISTS devin_dev;
ALTER CATALOG devin_dev OWNER TO `<sp-application-id>`;

Se você preferir administração baseada em grupos, adicione a entidade de serviço a um grupo como devin-agents e conceda as permissões ao grupo.

Alterações de código devem continuar passando por pull requests. O Devin pode ler dados de produção para entender um problema e validar uma correção no sandbox, mas a alteração no notebook, na definição de job ou no Asset Bundle é aplicada por meio do seu processo normal de revisão, e não editando a produção diretamente.

Etapa 4: Instale o plugin de skills do Databricks (opcional)

O Databricks publica Agent Skills que ensinam aos coding agents os fluxos de trabalho do Databricks: Asset Bundles, jobs, SQL, Unity Catalog e Spark. Instalá-los como um plugin do Devin dá ao Devin esse conhecimento, além da CLI.

Abra Customize → Plugins e escolha Add plugin → From repository.
Informe o repositório databricks/databricks-agent-skills e o subdiretório plugins/databricks/claude. O manifest do plugin fica nessa subpasta, portanto a instalação a partir do repository root retorna No plugin manifest found.
Instale no escopo Organization caso tenha usado um blueprint de organização na Etapa 2. Se usou um blueprint de repositório, declare o plugin no .devin/config.json desse repositório (consulte herança e níveis), assim apenas as sessões que têm a CLI também recebem as skills.
Fixe o plugin em um commit assim que ele estiver funcionando, para que mudanças upstream não cheguem às suas sessões sem revisão.

A skill principal do plugin recomenda executar databricks auth login para configurar um perfil. Esse fluxo interativo no navegador não pode ser concluído em uma sessão do Devin sem supervisão, e não é necessário aqui: a entrada knowledge da Etapa 2 informa ao Devin que a CLI já está autenticada.

Etapa 5: Verificar

Inicie uma nova sessão (após o build do blueprint ser concluído com sucesso) e peça ao Devin para executar:

databricks --version
databricks current-user me

current-user me deve retornar a entidade de serviço, com userName igual ao ID de aplicação. Para confirmar qual método de autenticação a CLI escolheu:

databricks auth describe

Na Opção A, isso retorna oauth-m2m; na Opção B, env-oidc. Uma autenticação bem-sucedida não significa que o Devin consegue acessar seus dados. Confirme que as concessões da Etapa 3 estão em vigor:

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

Substitua <catalog-name> por um catálogo que você concedeu na Etapa 3 (os exemplos ali usam analytics). Em seguida, peça ao Devin para executar uma pequena consulta somente leitura em um warehouse no qual ele tenha CAN USE e, caso você tenha configurado um perfil de Build, para criar e remover uma tabela em devin_dev. Uma consulta a uma tabela de produção na qual o Devin não tenha SELECT deve falhar; essa falha mostra o limite de permissão funcionando.

Solução de problemas

Sintoma	Aplica-se a	Causa e solução
Erros sobre credenciais conflitantes ou mais de um método de autenticação	Opção A	Remova `DATABRICKS_TOKEN`, `DATABRICKS_USERNAME` e qualquer perfil em `~/.databrickscfg`. A CLI se recusa a adivinhar quando há mais de um método de autenticação configurado.
`DATABRICKS_OIDC_TOKEN` não definido ou vazio	Opção B	O wrapper foi ignorado ou não foi instalado. Confirme que `which databricks` aponta para o wrapper e que `devin-oidc token --audience databricks` funciona sozinho.
`invalid_grant` ou um erro mencionando o subject	Opção B	O `subject` da policy não é exatamente igual ao `sub` do token. Execute novamente o script de claims da etapa 2 e compare caractere por caractere.
Erro mencionando a audience	Opção B	O campo `audiences` da policy não inclui a audience que o wrapper solicita. Ambos usam `databricks` por padrão; mantenha-os idênticos.
Erro mencionando o issuer, o JWKS ou a assinatura	Opção B	O `issuer` tem um erro de digitação (barra no final, `http`, host incorreto) ou o Databricks não consegue acessar `https://<your-devin-host>/.well-known/jwks.json`. Abra essa URL de fora da sua rede para confirmar que ela é pública.
Token expirado	Opção B	Os tokens de identidade do Devin duram 60 segundos. Use o wrapper em vez de gerar um token manualmente.
A CLI não reconhece `env-oidc`	Opção B	O snapshot tem uma CLI antiga (ou o pacote Python legado `databricks-cli`). Remova o pacote antigo do blueprint e refaça o build.
Autenticado, mas `catalogs list` está vazio ou uma query é negada	Ambos	O principal está autenticado, mas não autorizado. Verifique a atribuição de workspace (etapa 1) e as concessões do Unity Catalog (etapa 3) com `databricks grants get catalog <name>`.
Timeouts de conexão ou falhas de DNS	Ambos	O host do workspace não está acessível a partir do Devin. Adicione-o (e o host da conta, se necessário) à network policy do seu Devin.

Suporte

Para a configuração no lado do Databricks (entidades de serviço, segredos OAuth, policies de federação, Unity Catalog), consulte a documentação de autenticação do Databricks (alterne para a edição Azure ou GCP conforme necessário). Para a configuração no lado do Devin (blueprints, OIDC, plugins, network policy), entre em contato com support@cognition.ai ou com a sua equipe de conta.

Introdução

Diretrizes fundamentais

Integração do Devin

Trabalhando com o Devin

Guias do produto

Integrações

Admin

Notas de versão

Conecte o Devin ao Databricks

Escolha como o Devin se autentica

Por que conectar o Devin ao Databricks?

Visão geral

Pré-requisitos

Etapa 1: Criar uma entidade de serviço

Etapa 2: Conecte o Devin à entidade de serviço

Opção A: client secret OAuth

1. Gere um segredo OAuth

2. Adicione os Devin Secrets

3. Adicione o blueprint

4. Faça o build do snapshot

Opção B: federação de tokens OIDC

1. Adicione o blueprint

2. Faça o build do snapshot

3. Crie a policy de federação

Rebuilds e fixação de versão

Etapa 3: Conceder permissões

Perfis de permissão

Etapa 4: Instale o plugin de skills do Databricks (opcional)

Etapa 5: Verificar

Solução de problemas

Suporte

​Escolha como o Devin se autentica

​Por que conectar o Devin ao Databricks?

​Visão geral

​Pré-requisitos

​Etapa 1: Criar uma entidade de serviço

​Etapa 2: Conecte o Devin à entidade de serviço

​Opção A: client secret OAuth

​1. Gere um segredo OAuth

​2. Adicione os Devin Secrets

​3. Adicione o blueprint

​4. Faça o build do snapshot

​Opção B: federação de tokens OIDC

​1. Adicione o blueprint

​2. Faça o build do snapshot

​3. Crie a policy de federação

​Rebuilds e fixação de versão

​Etapa 3: Conceder permissões

​Perfis de permissão

​Etapa 4: Instale o plugin de skills do Databricks (opcional)

​Etapa 5: Verificar

​Solução de problemas

​Suporte

Escolha como o Devin se autentica

Por que conectar o Devin ao Databricks?

Visão geral

Pré-requisitos

Etapa 1: Criar uma entidade de serviço

Etapa 2: Conecte o Devin à entidade de serviço

Opção A: client secret OAuth

1. Gere um segredo OAuth

2. Adicione os Devin Secrets

3. Adicione o blueprint

4. Faça o build do snapshot

Opção B: federação de tokens OIDC

1. Adicione o blueprint

2. Faça o build do snapshot

3. Crie a policy de federação

Rebuilds e fixação de versão

Etapa 3: Conceder permissões

Perfis de permissão

Etapa 4: Instale o plugin de skills do Databricks (opcional)

Etapa 5: Verificar

Solução de problemas

Suporte