Vercel Agent acessa a produção por meio de um plano com scopes e uma única aprovação

A Vercel publicou uma análise de como o Vercel Agent acessa sistemas em produção. O problema de partida é familiar a quem já tentou entregar a produção a agentes: um pedido como "conserte o deploy" não diz de antemão quais ações serão necessárias nem quais permissões vão ser exigidas. Um acesso amplo significa que um erro pode atingir recursos alheios à tarefa. Já confirmar cada passo transforma a revisão em um clique automático em "Aprovar". A Vercel escolheu um terceiro caminho: o agente primeiro investiga, depois propõe um plano, e a aprovação do plano concede exatamente as permissões adicionais necessárias para executá-lo.

O plano como unidade de autorização

No exemplo de um deploy quebrado, o esquema funciona assim. O agente examina os deploys recentes e os logs de build e compara o deploy que falhou com o último que funcionava. Para isso, basta acesso somente leitura, e a investigação segue de forma automática. Se dela surgir a proposta de fazer um redeploy, o agente monta um plano e solicita o scope read-write:deployment. O usuário vê, em uma única decisão, tanto a ação quanto o acesso necessário para ela.

O plano conecta quatro camadas: intenção (o que o usuário quer), trabalho (as tarefas do agente), acesso (os scopes dessas tarefas) e imposição (tokens e verificações no lado da API). Cada plano salvo guarda as tarefas, o progresso e os scopes solicitados, que são somados ao longo de todas as etapas. O agente pode fazer uma consulta rápida de referência sem nenhum plano. Para investigações longas, é criado um plano somente leitura, para que o usuário acompanhe o andamento do trabalho.

O nível básico atualmente inclui todos os scopes registrados com o prefixo read:. A confirmação é necessária quando o plano vai além desse nível ou contém ações externas compatíveis, como abrir um pull request no GitHub. A Vercel faz questão de ressalvar: a leitura também pode expor dados sensíveis, então aprovação automática não significa ausência de risco.

Tokens que o modelo não consegue contornar

O Vercel Agent funciona como um Vercel App que o usuário autoriza no âmbito de uma equipe. Essa autorização é limitada pelas permissões do próprio usuário, então a aprovação de um plano não dá ao agente algo que a pessoa não tenha. O serviço OAuth troca a autorização por tokens de curta duração com scopes específicos, e as APIs verificam o token a cada requisição.

Um detalhe importante: deployment write é mais amplo do que um único redeploy. Se o plano cita o deploy X, isso por si só não restringe o token a esse deploy. Por isso a proteção se apoia em várias camadas, e as instruções dadas ao modelo sobre quando pedir aprovação não contam como fronteira de segurança. Se o agente tentar executar uma operação fora do token, a API a rejeita, mesmo que o modelo julgue a ação necessária.

A credencial usada depende do trabalho:

• investigação: token básico com scopes somente leitura;
• alterações aprovadas na Vercel: scopes básicos mais os adicionais aprovados;
• ações externas: credenciais e permissões do provedor específico.

Um único plano pode incluir tanto alterações na Vercel quanto um pull request. O usuário revisa tudo de uma vez, mas os provedores usam permissões separadas. O acesso ao GitHub é vinculado ao proprietário e ao repositório: a aprovação para acme/storefront não vale para acme/payments, que exige uma aprovação própria.

Registro único de scopes e retomada do trabalho

No início, o Vercel Agent tinha sua própria lista de permissões, que divergia do serviço OAuth responsável por emitir os tokens. Agora, ao iniciar a sessão, o agente carrega as definições de um registro comum de scopes para um catálogo em memória. O catálogo serve para validar o plano (nomes desconhecidos e incorretos são rejeitados antes de aparecerem para o usuário), para decidir se é preciso aprovação e para preparar o token.

Se uma tarefa, pelas regras do firewall, pedir um scope obsoleto, o sistema rejeita o plano e devolve a lista dos permitidos, para que o agente se corrija em vez de receber, por padrão, um acesso mais amplo. O catálogo é armazenado em cache, de modo que as verificações refletem o estado dele até a próxima atualização.

As falhas receberam tratamento à parte. A aprovação pode chegar depois de o chat original ter terminado, ou a conexão pode cair no meio de um redeploy. O plano guarda o estado, quem o aprovou e o horário. Antes de continuar, o runtime recarrega o plano e verifica se ele está ativo. Um plano interrompido não passa na verificação, mesmo que o token ainda tenha tempo de validade. Se a aprovação e a interrupção chegam ao mesmo tempo, o plano só passa de em espera para ativo se a interrupção ainda não tiver mudado o status. Substituir um plano por outro com permissões elevadas exige uma nova aprovação.

O que ficou em aberto

A Vercel lista com franqueza os pontos fracos. O agente escolhe os scopes com informações incompletas e pode pedir pouco ou demais. Um scope válido também pode ser mais amplo do que o necessário. A recusa da API pode indicar falta de permissão, um recurso errado ou uma operação que deve continuar proibida, e o agente precisa saber distinguir entre esses casos. Além disso, instruções maliciosas podem estar escondidas em conteúdo lido pelo agente, como os logs de build. Por isso, os planos funcionam em conjunto com isolamento em sandbox, políticas de rede, tratamento de segredos, limites, logs de auditoria e autorização de serviços.

O que levar para os seus sistemas de agentes

Para equipes que constroem agentes para infraestrutura, o esquema oferece alguns referenciais. Separe investigação e alteração. Mostre à pessoa a ação em linguagem simples, ao lado dos scopes. Use as definições de permissões da mesma fonte que emite os tokens. Verifique se o plano está ativo antes de cada uso de uma credencial, e não apenas na emissão. E não conte com as instruções do modelo para limitá-lo por conta própria: as restrições precisam estar na API.