Credenciais em tarefas longas de agentes de IA

A tarefa continua depois que o acesso inicial vence

Um agente começa a preparar uma análise às 9h. Ele consulta documentos, espera uma aprovação e retoma o trabalho no fim da tarde. O token usado na primeira etapa já expirou. A autorização do usuário pode ter mudado. Outro worker pode assumir a execução depois de uma falha.

Renovar o acesso automaticamente parece a solução simples. O risco aparece quando a renovação reaproveita uma credencial ampla, mantém autoridade depois do fim da tarefa ou cria duas versões válidas em workers concorrentes.

Este guia trata de uma fronteira específica: como uma execução longa obtém credenciais válidas ao longo do trabalho sem entregar o segredo ao modelo, ampliar permissões ou deixar acesso residual depois do estado terminal?

A página sobre delegação de acesso para agentes de IA define quem concede autoridade, para qual finalidade e sobre quais objetos. O guia de gestão de segredos para agentes cobre armazenamento, injeção, rotação e revogação. Aqui, o foco está na renovação dentro de uma unidade de trabalho que atravessa tempo, espera e troca de worker.

Separe três relógios

Uma execução longa costuma misturar prazos que deveriam ser tratados separadamente.

Duração da tarefa

É o período em que a unidade de trabalho ainda possui utilidade. Uma preparação de reunião pode perder validade depois do horário do encontro. Uma conciliação pode terminar quando o lote fecha. O prazo pertence ao processo empresarial.

Duração da autorização

É o período em que a pessoa, aplicação ou política permite que o agente atue. Mudança de função, revogação, retirada de consentimento ou alteração de política podem encerrar essa autoridade antes do prazo da tarefa.

Duração da credencial

É a validade técnica do token ou certificado usado numa chamada. Credenciais curtas reduzem a janela de exposição, mas exigem um mecanismo seguro para obter outra quando a tarefa ainda está autorizada.

Renovar apenas porque o token venceu ignora os dois relógios anteriores. Antes de emitir outra credencial, o sistema precisa confirmar que a tarefa continua válida e que a autoridade permanece vigente.

O modelo não deve administrar tokens

O texto da credencial fica fora de prompts, memória, checkpoints, logs e artefatos. O agente pode solicitar uma capacidade, como ler_documento_aprovado ou criar_rascunho_no_crm. O runtime decide se a tarefa pode usar essa capacidade e obtém a credencial no ponto da chamada.

Um fluxo seguro pode seguir esta sequência:

o orquestrador identifica tarefa, etapa e objeto;
a política confirma validade, ator, finalidade e ação permitida;
o broker de credenciais consulta o mecanismo de autenticação;
uma credencial curta é emitida ou recuperada do cache seguro;
o conector anexa a credencial à chamada;
o sistema de destino devolve resultado e identificador;
o runtime registra metadados, sem guardar o valor secreto;
o agente recebe somente o resultado necessário para continuar.

O modelo não escolhe escopos, não lê refresh token e não decide por conta própria quando prolongar autoridade. Essas decisões ficam em componentes determinísticos e auditáveis.

Vincule a renovação à unidade de trabalho

O registro de execução precisa carregar referências suficientes para avaliar acesso sem copiar o segredo:

| Campo | Função | |---|---| | task_id | identifica a unidade de trabalho | | actor_id | identifica pessoa, aplicação ou agente solicitante | | purpose | declara a finalidade aprovada | | resource_scope | limita cliente, pasta, conta ou objeto | | allowed_action | separa leitura, preparação e escrita | | authorization_ref | aponta para a concessão ou política vigente | | credential_ref | aponta para o material no cofre ou broker | | task_expires_at | encerra trabalho empresarial vencido | | authorization_expires_at | força nova decisão de autoridade | | last_access_check | mostra quando a política foi revalidada | | terminal_state | orienta revogação e descarte |

A credencial pode mudar várias vezes. A identidade da tarefa e o contrato de autoridade permanecem estáveis até uma mudança formal.

Revalide antes de renovar

A renovação deve falhar fechada quando uma condição material não pode ser confirmada.

Verifique:

a tarefa continua em estado executável;
o prazo empresarial ainda não venceu;
o ator continua ativo e autorizado;
a finalidade permanece a mesma;
o objeto continua dentro do escopo;
a próxima ação foi aprovada para aquela etapa;
a política não mudou desde a última checagem;
o sistema não recebeu pedido de cancelamento;
o custo e o volume continuam dentro dos limites;
não existe incidente ou contenção sobre a ferramenta.

Uma execução retomada depois de horas não deve herdar autoridade apenas porque possui um checkpoint válido. Estado de trabalho e autorização são objetos diferentes.

Evite a corrida entre workers

Dois workers podem tentar renovar o mesmo acesso quase ao mesmo tempo. Isso acontece depois de retentativa, recuperação de falha, processamento paralelo ou atraso na atualização do cache.

Se o provedor usa refresh token de uso único, duas trocas concorrentes podem produzir um ramo válido e outro erro. Se o armazenamento aceita a gravação atrasada do worker perdedor, o sistema pode substituir a credencial nova por uma referência já inválida.

Use uma operação de renovação por vez para cada família de credencial. Um desenho inicial inclui:

chave de coordenação por conexão, identidade e recurso;
lock curto ou comparação de versão no armazenamento;
leitura da versão atual antes da troca;
chamada única ao provedor;
gravação atômica da nova referência e da nova versão;
invalidação lógica da referência anterior;
liberação do lock;
nova leitura pelos workers que aguardavam.

A aplicação precisa tratar a resposta do provedor conforme a documentação específica. Alguns serviços rotacionam o refresh token a cada uso. Outros emitem novo access token e preservam o mecanismo de atualização. Não presuma comportamento uniforme entre Google, Microsoft, Slack, CRM ou outro destino.

Renove perto do ponto de uso

Renovar todas as credenciais no início de uma tarefa longa cria autoridade ociosa. O agente pode passar horas analisando arquivos antes de precisar escrever no CRM.

Prefira aquisição tardia:

leitura recebe credencial de leitura quando a consulta começa;
preparação local não recebe acesso de escrita;
escrita recebe credencial somente depois da aprovação;
cada ferramenta usa audiência e escopo próprios;
a credencial expira após uma janela compatível com a etapa.

Essa abordagem reduz o período em que uma credencial sensível permanece utilizável. Também permite que uma tarefa continue preparando trabalho depois que uma ação externa foi bloqueada.

Trate falha de renovação como estado operacional

Uma resposta 401, invalid_grant ou equivalente pode representar expiração, revogação, escopo retirado, rotação perdida, mudança de política ou conexão removida. Repetir sem diagnóstico pode aumentar bloqueios e esconder uma decisão humana.

Modele estados como:

acesso_valido;
renovacao_em_andamento;
reautorizacao_necessaria;
acesso_revogado;
politica_alterada;
tarefa_expirada;
bloqueado_por_incidente;
concluido_sem_acao_externa.

Quando a renovação falhar:

interrompa novas chamadas à ferramenta afetada;
preserve o checkpoint sem incluir tokens;
classifique a causa conhecida;
evite retentativa automática em erro permanente;
informe quem precisa agir;
ofereça reautorização somente quando a finalidade continuar válida;
reconcilie ações cuja confirmação ficou incerta;
mantenha outras capacidades bloqueadas ou disponíveis conforme a política.

Uma falha de acesso pode permitir uma saída parcial útil, como relatório interno sem atualização no sistema. Essa decisão precisa estar prevista no contrato da tarefa.

Revogue quando a tarefa chega ao fim

Conclusão, cancelamento e falha terminal encerram a necessidade operacional. O mecanismo deve:

impedir novas emissões para a tarefa;
revogar grant ou família de tokens quando o provedor permitir;
apagar cópias transitórias e caches vinculados;
encerrar sessões técnicas;
bloquear tarefas filhas ainda não iniciadas;
preservar apenas referências e evidências permitidas;
confirmar que chamadas posteriores são negadas;
registrar o motivo e o horário do encerramento.

Um token expirado reduz risco futuro. Um refresh token ainda válido pode recriar acesso. O estado terminal precisa alcançar os dois.

Exemplo: preparação e registro de uma reunião

Considere um agente que prepara uma reunião comercial, espera revisão e registra uma tarefa no CRM.

Etapa 1: leitura

A tarefa recebe acesso de leitura à oportunidade e às atividades da carteira do vendedor. O runtime usa escopo limitado ao objeto. O agente produz um briefing interno.

Etapa 2: espera

O briefing aguarda revisão. Nenhuma credencial de escrita fica guardada no checkpoint. O estado registra somente referências, fontes e a aprovação pendente.

Etapa 3: revalidação

Quando a pessoa aprova a próxima ação, o sistema confirma vínculo do vendedor, estado da oportunidade, validade da aprovação e permissão para criar tarefa.

Etapa 4: escrita

O broker obtém credencial curta para a operação específica. O conector cria a tarefa com chave idempotente e registra o identificador retornado.

Etapa 5: encerramento

A execução confirma o efeito no CRM, entra em estado concluído e encerra a autorização vinculada à tarefa. Uma retentativa tardia encontra estado terminal e não recebe nova credencial.

O fluxo evita manter acesso de escrita durante todo o período entre preparação e aprovação.

Testes que pressionam a renovação

Use ambiente de teste, identidades próprias e dados sintéticos. Inclua:

token vence antes de uma leitura permitida;
token vence durante uma chamada;
autorização é revogada enquanto a tarefa espera;
usuário muda de função antes da escrita;
dois workers tentam renovar ao mesmo tempo;
worker perde a resposta depois da rotação;
cache entrega referência antiga;
refresh token usado anteriormente reaparece;
escopo solicitado é maior que o original;
tarefa expira antes da aprovação;
cancelamento chega durante a renovação;
conexão é removida no sistema de origem;
chamada externa conclui, mas a confirmação se perde;
tarefa terminal tenta obter nova credencial;
log de erro tenta imprimir cabeçalho de autenticação.

O teste passa quando a política correta aparece também no destino: ação autorizada concluída uma vez, ação proibida negada, credencial ausente dos registros e acesso encerrado ao final.

Métricas para operar essa fronteira

Acompanhe:

renovações por unidade de trabalho;
tarefas que pedem acesso depois do vencimento;
falhas por expiração, revogação e rotação concorrente;
tentativas com referência antiga;
tempo entre estado terminal e revogação;
credenciais emitidas sem uso;
escopos solicitados e efetivamente usados;
tarefas que continuaram depois da retirada de autoridade;
reautorizações exigidas;
ações externas sem confirmação;
segredos encontrados em logs ou checkpoints;
workers que não adotaram a versão nova.

Muitas renovações podem indicar duração inadequada da tarefa, etapas grandes demais ou aquisição antecipada. Poucas falhas também podem esconder tokens permanentes. Leia a métrica junto com prazo, escopo e revogação.

Checklist para tarefas longas

[ ] Tarefa, autorização e credencial possuem prazos separados?
[ ] O modelo fica sem acesso ao valor dos tokens?
[ ] Cada renovação revalida finalidade, objeto e ação?
[ ] A aquisição ocorre perto do ponto de uso?
[ ] Leitura e escrita usam escopos próprios?
[ ] Existe coordenação contra renovação concorrente?
[ ] A nova referência substitui a antiga de forma atômica?
[ ] Erros permanentes deixam de receber retentativa automática?
[ ] Checkpoints guardam referências, sem guardar segredos?
[ ] Mudança de função, revogação e cancelamento bloqueiam continuidade?
[ ] Ações externas usam idempotência e confirmação?
[ ] Estados terminais encerram emissão, cache e sessão?
[ ] Testes incluem worker concorrente e resposta perdida?
[ ] Logs provam a decisão sem revelar a credencial?

Fontes oficiais verificadas em 22 de setembro de 2026

OAuth 2.0 best practices, Google for Developers. A página orienta escopo mínimo, armazenamento seguro, tratamento de expiração ou revogação e descarte de tokens sem uso.
How user authorization works, Google for Developers. A documentação distingue access token, refresh token, escopo e uso assíncrono.
Refresh tokens in the Microsoft identity platform, Microsoft Learn. O comportamento de substituição e descarte precisa seguir a plataforma usada.
Managed Agents API on Agent Platform overview, Google Cloud. A documentação recomenda menor privilégio, credenciais curtas e teste com dados sintéticos.

Os fornecedores possuem ciclos e políticas diferentes. Confirme biblioteca, tipo de cliente, fluxo OAuth, escopos, validade, rotação, revogação e armazenamento usados pela integração real.

A renovação precisa renovar a decisão

Uma credencial nova só deve existir quando a tarefa continua válida, a autoridade permanece vigente e a próxima ação ainda cabe no escopo aprovado.

Mantenha tokens fora do modelo, coordene workers concorrentes, adquira acesso perto do uso e encerre a família de credenciais quando a unidade chegar ao estado terminal. Assim, tarefas longas atravessam horas e retomadas sem transformar continuidade em permissão permanente.