Delegação de acesso para agentes de IA: como fazer

Agir em nome de alguém cria uma cadeia de autoridade

Um vendedor pede que um agente consulte sua agenda, recupere uma oportunidade e prepare o próximo contato. A mesma solicitação pode terminar em três resultados muito diferentes: um rascunho interno, uma tarefa criada no CRM ou uma mensagem enviada ao cliente.

A identidade do vendedor ajuda a localizar os dados corretos. Ela não deveria conceder ao agente toda a capacidade disponível na conta daquela pessoa.

Delegação de acesso para agentes de IA define qual autoridade uma pessoa transfere para uma execução automatizada, sobre quais objetos, por quanto tempo e para produzir qual efeito. O desenho preserva três participantes: a pessoa que possui ou concede a autoridade, o agente que interpreta a tarefa e a identidade técnica que chama o sistema de destino.

Quando esses papéis são misturados, o log registra apenas “Ueliton atualizou o CRM” ou “integração alterou o registro”. A empresa perde a resposta para uma pergunta básica: quem pediu, quem executou e qual autorização permitiu a ação?

Autenticação, autorização e delegação resolvem problemas diferentes

Os termos aparecem juntos, mas cada camada responde uma pergunta.

Autenticação confirma identidades

O sistema verifica quem é a pessoa, a aplicação ou o workload. Senha, certificado, chave e token podem participar dessa confirmação.

Autorização decide o que uma identidade pode fazer

Depois da autenticação, políticas e permissões determinam operações, objetos e ambientes acessíveis. Uma identidade pode consultar uma oportunidade e continuar bloqueada para alterar preço.

Delegação vincula uma autoridade a uma finalidade

A pessoa autoriza um agente ou aplicação a usar parte de sua capacidade durante uma tarefa. A delegação deveria carregar escopo, finalidade, validade e condições de uso.

O guia sobre identidade e credenciais para agentes de IA organiza contas, tokens, rotação e revogação. A delegação trata do contrato específico entre pessoa, agente, tarefa e efeito.

Quando a identidade do usuário faz sentido

Usar identidade delegada costuma ser adequado quando o resultado depende do direito individual da pessoa.

Exemplos:

consultar a agenda particular do solicitante;
localizar documentos que aquela pessoa pode acessar;
preparar uma atualização dentro da carteira comercial do vendedor;
criar uma tarefa em nome do responsável pela oportunidade;
executar uma ação que exige consentimento ou atribuição individual;
manter preferências e limites vinculados ao usuário.

A identidade própria do agente costuma funcionar melhor em rotinas recorrentes com responsabilidade organizacional, como processar uma fila de documentos ou gerar um relatório operacional. Nesses casos, atrelar o fluxo à conta de um funcionário cria dependência desnecessária.

A escolha pode combinar os dois modelos. O agente usa identidade própria para trabalhar e recebe uma autorização curta do usuário somente na etapa que exige autoridade individual.

O contrato mínimo de uma delegação

Uma delegação legível precisa responder a dez elementos.

1. Principal

É a pessoa ou entidade que concede autoridade. Sua identidade deve estar autenticada e vinculada ao objeto da tarefa.

2. Ator automatizado

É o agente, aplicação ou processo que usará a delegação. Nome genérico como automacao prejudica atribuição e revogação seletiva.

3. Finalidade

Registre o trabalho autorizado: preparar reunião, criar próxima ação, atualizar cadastro específico ou consultar disponibilidade. “Usar o CRM” descreve uma conexão, não uma finalidade.

4. Ações permitidas

Separe leitura, preparação, criação, alteração, envio, exclusão e transação. Verbos distintos carregam consequências distintas.

5. Objetos permitidos

A autorização pode alcançar uma oportunidade, carteira, pasta, calendário, cliente ou conjunto de registros. Escopo por sistema inteiro costuma ser amplo demais.

6. Restrições de campo e valor

Mesmo dentro do objeto correto, certos campos precisam permanecer protegidos. Um agente pode criar nota interna e ficar impedido de alterar preço, estágio, dados bancários ou consentimento.

7. Validade

Defina início, expiração e condição de renovação. A duração deve acompanhar a unidade de trabalho, em vez de sobreviver por meses por conveniência.

8. Limites operacionais

Volume, frequência, horário, ambiente, canal e custo podem restringir o uso. Dez atualizações em uma carteira conhecida possuem risco diferente de dez mil alterações noturnas.

9. Aprovação

Algumas delegações permitem preparar a ação e exigem decisão humana antes do efeito. A autorização para montar um rascunho não inclui automaticamente o envio.

10. Evidência

O registro precisa ligar solicitação, política, ferramenta, objeto, resultado e confirmação no destino. Sem essa cadeia, a autorização existe no papel e desaparece durante a operação.

Quatro padrões de implementação

Preparação sem acesso delegado

O agente recebe apenas os dados necessários e produz um artefato interno. A pessoa executa a ação no sistema.

Esse padrão reduz risco e funciona bem no começo. Ele pode manter trabalho manual demais quando a rotina já possui critérios estáveis e volume relevante.

Sessão delegada pelo usuário

A pessoa autentica a conexão e permite um conjunto de operações durante uma sessão. O sistema preserva usuário, aplicação e escopos.

É útil para trabalho interativo. A arquitetura precisa tratar expiração, revogação, troca de dispositivo e retomada. O artigo sobre sessões de agentes de IA detalha esse ciclo.

Identidade do agente com política de representação

O agente usa conta própria. Uma camada de política confirma que ele pode agir sobre determinado objeto em nome do usuário solicitante.

Esse padrão melhora atribuição técnica e controle central. Exige que o sistema registre simultaneamente o ator automatizado e o sujeito representado.

Autorização de uso único

Uma ação sensível recebe um grant ou token válido para uma operação específica. Depois do uso ou da expiração, a autorização perde efeito.

O padrão é adequado para publicar, aprovar condição, enviar comunicação relevante ou alterar um registro crítico. Ele reduz o risco de uma aprovação pontual liberar a sessão inteira.

O token precisa ficar fora do contexto do modelo

Um agente raramente precisa ler o valor de uma credencial. O runtime, gateway ou conector pode obter o token, anexá-lo à chamada autorizada e ocultá-lo das mensagens, traces e saídas do modelo.

Práticas importantes:

armazenar tokens e segredos em serviço apropriado;
emitir credenciais curtas quando a infraestrutura permitir;
limitar audiência, escopo, objeto e ambiente;
impedir impressão em logs e mensagens de erro;
separar token de acesso e mecanismo de renovação;
evitar que refresh tokens circulem no histórico do agente;
revogar grants antigos depois de mudança de função ou encerramento;
testar se workers e filas respeitam a revogação.

O artigo sobre gestão de segredos para agentes de IA mostra como entregar credenciais ao runtime sem convertê-las em conteúdo do modelo.

Consentimento amplo cria uma autorização difícil de explicar

Telas de conexão costumam pedir acesso a e-mail, arquivos, calendário e contatos de uma vez. Para o usuário, aceitar pode parecer o preço inevitável para testar a ferramenta.

Uma implementação responsável reduz essa amplitude:

solicita somente os escopos necessários ao caso atual;
explica qual trabalho será executado;
separa leitura de escrita;
mostra quando haverá efeito externo;
permite negar uma capacidade sem perder todo o produto;
apresenta conexões ativas e última utilização;
oferece revogação compreensível;
pede nova autorização diante de expansão relevante.

Consentimento inicial não valida qualquer uso futuro. Mudança de finalidade, novo sistema, novo tipo de dado ou autonomia maior pede revisão do contrato.

Tarefas longas precisam revalidar autoridade

Uma tarefa pode começar com acesso válido e continuar depois que a pessoa perde a função, revoga a conexão ou altera a instrução.

Revalide a autorização:

ao retomar depois de pausa;
antes de uma ferramenta sensível;
quando o objeto muda;
depois de uma aprovação;
quando a execução ultrapassa a duração prevista;
antes do efeito final;
após mudança de política, vínculo ou permissão.

O fluxo deve falhar de forma contida quando a autoridade expirou. Salvar o estado e solicitar nova autorização é melhor do que reutilizar silenciosamente uma credencial antiga.

Os agentes de IA para tarefas longas também precisam de checkpoints, idempotência e limites para retomar sem repetir consequências.

Multiagentes não podem multiplicar autoridade

Um agente coordenador pode delegar subtarefas a outros agentes. Essa passagem não deveria ampliar permissões.

Cada handoff precisa preservar:

principal original;
ator que delegou a subtarefa;
agente destinatário;
finalidade reduzida;
objetos permitidos;
ações necessárias;
validade restante;
proibição de redelegação, quando aplicável;
identificador comum da execução.

O agente especializado recebe a menor capacidade compatível com sua etapa. Uma cadeia em que cada participante repassa o token completo produz autoridade difusa e dificulta revogar somente um ramo.

A arquitetura multiagente para empresas ajuda a separar papéis, estado compartilhado e responsabilidade pelo resultado final.

A trilha precisa mostrar ator e sujeito

Um registro útil para ação delegada contém:

usuário que iniciou ou autorizou;
agente e versão que interpretaram a tarefa;
identidade técnica usada na chamada;
concessão ou aprovação aplicada;
finalidade e processo;
ferramenta, operação e objeto;
campos relevantes, com mascaramento;
política e decisão de autorização;
horário, sessão e trace;
resultado técnico;
efeito confirmado no sistema oficial;
motivo de bloqueio, alteração ou revogação.

Registrar somente o usuário atribui ao humano uma execução que ele pode não ter revisado. Registrar somente o agente apaga a origem da autoridade. Os dois precisam aparecer.

Como testar a delegação antes da produção

Inclua casos que pressionem as fronteiras reais:

usuário tenta acessar objeto fora da própria carteira;
agente solicita uma ação ausente do escopo;
token expira entre preparação e execução;
aprovação é reutilizada em outro objeto;
usuário revoga a conexão com tarefa enfileirada;
agente subordinado tenta ampliar o escopo;
sessão troca de canal ou dispositivo;
objeto muda depois da aprovação;
sistema de destino confirma a ação, mas a resposta se perde;
log ou erro tenta expor a credencial;
funcionário muda de função durante uma tarefa;
ferramenta sensível recebe parâmetros produzidos por conteúdo externo.

O teste precisa observar bloqueio, alerta, preservação do estado e reconciliação. Uma mensagem de erro correta não basta se a ação indevida aconteceu no destino.

Métricas para governar acesso delegado

grants ativos por usuário e aplicação;
autorizações sem uso recente;
escopos concedidos e efetivamente usados;
tokens permanentes ainda em circulação;
ações bloqueadas por escopo, objeto ou validade;
aprovações reutilizadas ou vencidas;
tempo para revogar uma conexão;
execuções que continuaram depois da revogação;
ações sem ator e sujeito identificáveis;
falhas de confirmação no destino;
incidentes por tipo de delegação;
acessos ampliados depois de mudança de função.

Volume baixo de bloqueios pode indicar bom desenho ou ausência de fiscalização. Combine métricas, amostras e testes periódicos.

Checklist de delegação de acesso para agentes

A finalidade da autorização está explícita?
Pessoa, agente e identidade técnica aparecem separadamente?
Leitura, preparação e execução usam escopos distintos?
A autorização delimita objetos e campos?
Validade acompanha a duração da tarefa?
Tokens ficam fora do contexto do modelo?
Ações sensíveis usam aprovação ou autorização de uso único?
Tarefas longas revalidam acesso?
Subagentes recebem escopo reduzido?
Revogação alcança filas, sessões e workers ativos?
Logs ligam autorização ao efeito confirmado?
Casos de negação, expiração e mudança de função foram testados?
Existe alternativa operacional quando o acesso é revogado?

Autoridade delimitada permite ampliar capacidade

Agentes passam a produzir valor real quando conseguem consultar sistemas, preparar decisões e executar partes do trabalho. Esse ganho depende de uma cadeia de autoridade que continue legível durante toda a execução.

A empresa precisa saber quem concedeu acesso, qual agente usou, em qual tarefa, sobre qual objeto, com que limite e qual efeito ocorreu. Delegações curtas, específicas e revogáveis reduzem o alcance de falhas sem transformar cada uso em um projeto de segurança.

A pergunta prática vem antes da integração: qual é a menor autoridade capaz de concluir esta unidade de trabalho? A resposta orienta identidade, token, política, aprovação, log e teste.