Credenciais compartilhadas no Vercel Connect: quem pode gerenciar

Credenciais compartilhadas de conectores agora podem ter uma pessoa responsável sem que ela precise se tornar Owner da equipe na Vercel. Em 11 de setembro de 2026, a Vercel lançou Connector Permissions para equipes Pro e Enterprise. Com o recurso, um Owner pode reservar a criação e o gerenciamento de conectores a Owners e a pessoas que tenham a permissão Connector Manager.

Há uma ressalva: a função Member já inclui Connector Manager. Portanto, a configuração só estabelece um limite claro de responsabilidade quando as funções atribuídas à equipe também são revisadas.

O que muda no controle de credenciais compartilhadas

Um conector do Vercel Connect é o registro da equipe que representa um serviço como Slack, GitHub, Microsoft ou um provedor personalizado. Ele pode armazenar ou intermediar a credencial usada por vários projetos. Por isso, alterá-lo é uma operação no nível da equipe, não uma simples edição no app.

Connector Permissions estabelece um controle sobre quem pode administrar esse registro. Um Owner ativa a restrição em Team Settings. A partir daí, somente um Owner ou alguém com a permissão estendida Connector Manager pode criar ou gerenciar conectores.

Essa permissão abrange conectores de toda a equipe, conexões de projetos, instalações e tokens. Ela não reúne todas as decisões de acesso em um único controle.

Essa separação é importante. Um Connector Manager pode cuidar da conexão compartilhada, enquanto um app implantado ainda comprova equipe, projeto e ambiente por meio do Vercel OIDC — a identidade de implantação que a Vercel emite para o app em execução — e de um vínculo de projeto. Em seguida, o provedor aplica seus próprios escopos. Se publicar uma mensagem ou atualizar um cadastro de cliente exigir uma decisão humana, essa aprovação continua pertencendo ao workflow do aplicativo.

O guia anterior sobre autenticação no Vercel Connect detalha esse fluxo de troca de tokens. Esta versão muda quem pode manter a conexão, não como o app em execução comprova que pode solicitar um token.

A conta que importa é o tamanho do grupo com poder de mudança

O número relevante aqui não é mais um limite de API. É a quantidade de pessoas que podem alterar um recurso da equipe que contém credenciais.

Quando toda pessoa desenvolvedora pode editar um conector compartilhado, cada alteração na equipe, transição de prestador e correção urgente em produção amplia o escopo da revisão. Com Connector Permissions, o grupo de gerenciamento fica explícito. As demais pessoas continuam trabalhando com vínculos de projeto já aprovados por quem mantém o conector.

O lançamento de 11 de setembro não anuncia uma mudança direta de preço. A cobrança do Vercel Connect considera solicitações de token e triggers, não atribuições de Connector Manager. Uma página específica de preços do Connect informa que os preços atualizados da versão beta entram em vigor em 25 de setembro de 2026: o plano Pro custa $3.00 por 1,000 solicitações de token, enquanto o preço do Enterprise é personalizado. A configuração de permissão não é descrita como uma mudança nessa métrica de uso em runtime.

O custo operacional, porém, pode cair. Menos pessoas precisam dos dados de configuração do provedor, do client secret, do contexto da instalação e da autoridade para alterar conexões de projetos. Quem desenvolve deixa de depender do Owner quando a pessoa responsável pode executar esse trabalho, enquanto o Owner preserva o controle sobre quem recebe essa autoridade.

Como fazer uma passagem de responsabilidade clara

Considere a Northstar Agency como exemplo. Maya é a Owner na Vercel. Jon é Developer, tem Connector Manager e mantém as conexões de serviços compartilhadas. Priya é Developer sem Connector Manager e desenvolve o app do cliente. Leah responde pela regra de negócio que determina se o app pode enviar ou atualizar algo.

Esse processo mantém as responsabilidades bem separadas.

1. 1

   Audite os acessos herdados

   Maya revisa a lista da equipe antes de ativar a restrição. Quem ocupa as funções Owner ou Member já conta com Connector Manager. Pessoas nas funções Developer, Security, Billing, Viewer ou Contributor podem receber Connector Manager como permissão estendida quando a função-base for adequada ao restante de suas atribuições.

2. 2

   Defina quem mantém o conector

   Maya abre Settings, acessa Members e usa Manage Role para Jon. Ele permanece na função Developer e recebe Connector Manager. O registro da passagem identifica o conector, a conta no provedor, os projetos e ambientes vinculados, o responsável no provedor e o procedimento de escalonamento para rotação ou revogação.

3. 3

   Ative Connector Permissions

   Maya abre Team Settings, localiza Connector Permissions e ativa a restrição. Jon passa a cuidar da criação e do gerenciamento de conectores sem receber a função Owner completa.

1. 1

   Mantenha o escopo do provedor separado

   Jon registra os escopos, recursos ou detalhes de autorização solicitados ao provedor. Connector Manager define quem pode manter o conector na Vercel. A concessão do provedor define o que a credencial resultante pode fazer. A regra de aprovação de Leah continua no app, pois nenhuma dessas configurações decide se uma ação de negócio real deve prosseguir.

2. 2

   Teste o fluxo da solicitação

   Priya executa uma solicitação de escopo limitado a partir do projeto de QA vinculado. O fluxo definido é: identidade OIDC da implantação de QA, vínculo de projeto do Vercel Connect, token do provedor com escopo de leitura e resposta da API do provedor. Jon confirma a solicitação do token e a autorização na aba Observability do conector. Maya também confirma que Priya não consegue usar o fluxo de gerenciamento do conector.

Esse último passo é o teste de aceitação. Um documento de política não basta. Quem desenvolve deve conseguir usar o fluxo de runtime aprovado e, ao mesmo tempo, não deve poder alterar o conector compartilhado, a menos que isso faça parte de suas atribuições.

Quem deve usar esse controle agora

Uma startup Pro com uma pessoa na engenharia de plataforma

Quem fundou a empresa pode manter a função Owner e conceder Connector Manager à pessoa responsável pela plataforma. A equipe de produto continua trabalhando por meio dos projetos vinculados, enquanto as mudanças em conectores ficam com uma pessoa responsável e uma rota de escalonamento. O ganho é reduzir a dependência da pessoa fundadora sem ampliar o número de Owners da equipe.

Uma equipe de segurança Enterprise

Uma liderança de segurança pode separar a revisão da concessão do provedor da manutenção cotidiana do conector. A pessoa responsável cuida das instalações e conexões de projetos, enquanto a administração do provedor aprova os escopos relevantes. O ganho é um histórico de mudanças mais claro quando uma credencial compartilhada de agente atende vários apps.

Uma agência que entrega vários apps de clientes

A pessoa responsável pela operação da agência pode nomear quem cuidará dos conectores de cada ambiente de cliente e manter prestadores focados nos projetos atribuídos. O ganho aparece no próximo app: a equipe reutiliza um fluxo de conexão aprovado sem dar a toda pessoa desenvolvedora autoridade para editar a camada de credenciais compartilhadas.

Uma equipe de operações que adiciona ações de agentes

A liderança de operações deve usar Connector Permissions na passagem de responsabilidade pela credencial e manter ações de alto impacto condicionadas à etapa de aprovação do próprio produto. Assim, as responsabilidades ficam claras: Jon pode reparar a conexão, Priya pode entregar o workflow e Leah pode decidir quando um cadastro de cliente ou uma mensagem externa pode mudar.

O que essa configuração não faz

Ativar Connector Permissions não comprova que acessos existentes no provedor foram revogados. A revogação é uma ação separada, e a Vercel observa que a invalidação imediata depende de o provedor oferecer um endpoint de revogação.

A configuração também não restringe os escopos do provedor, não altera quais ambientes de implantação vinculados podem solicitar tokens, não adiciona aprovação humana às ações de agentes nem reduz as cobranças de uso do Connect. São controles separados, com responsáveis distintos.

Equipes Hobby não são afetadas, pois essa restrição de gerenciamento está disponível para Pro e Enterprise. Um protótipo individual sem conector compartilhado talvez ainda não precise de uma passagem de responsabilidade. Já uma equipe com credenciais compartilhadas de produção, vários apps desenvolvidos por agentes ou colaboradores externos deve estabelecer esse limite antes de adicionar o próximo conector.

O que fazer na segunda-feira

Tome uma providência nesta semana se um conector atende mais de um projeto ou se mais pessoas estão prestes a desenvolver agentes com ele. Espere se o conector ainda é um teste individual e ninguém mais depende dele. Se o seu código apenas consome, em runtime, um conector já vinculado, o fluxo não precisa mudar por causa deste lançamento.

Encerre o trabalho com uma linha por escrito e uma solicitação real: Maya responde pela política, Jon mantém o conector, e o fluxo de leitura em QA foi testado desde a identidade da implantação, passando pelo vínculo de projeto, até a resposta do provedor. Essa é a passagem de responsabilidade. A configuração serve apenas para aplicá-la.

Receba na newsletter a próxima mudança de plataforma explicada sem complicação.