Existe uma pergunta de desenho que quase nunca é feita explicitamente e que define o modelo de risco inteiro: quando o agente chama uma API, ele age como si mesmo ou como você?
Três modelos, três consequências
Identidade própria. O agente tem service account e permissões definidas para ele. Auditoria clara, mas a permissão é a união do que qualquer usuário poderia precisar — e ela não muda conforme quem pediu.
Impersonação. O agente assume a identidade do usuário. A permissão fica correta por usuário, mas o log mostra a pessoa fazendo coisas que ela não fez. Numa investigação, você acusa a pessoa errada.
On-behalf-of. O token carrega as duas identidades: quem age e por conta de quem. É o único modelo que preserva atribuição e escopo ao mesmo tempo — e é o que a maioria das implementações não usa, porque dá mais trabalho no primeiro dia.
Impersonação não é delegação. É apagar o rastro de quem realmente executou.
A regra que não pode ser violada
Qualquer que seja o modelo, o teto é o mesmo: o agente nunca deve conseguir fazer algo que o usuário delegante não poderia fazer sozinho. A autorização efetiva é a interseção entre o que o agente pode e o que o humano pode.
Quando essa interseção não é aplicada, o agente vira mecanismo de escalonamento: o estagiário pede um relatório e a service account com permissão ampla entrega dado que ele não teria acesso pela interface normal. Ninguém invadiu nada — o desenho autorizou.
O que registrar
- Identidade do agente e identidade humana delegante, em campos separados.
- Escopo efetivo calculado para aquela chamada, não o escopo máximo do agente.
- Validade da delegação — ela deve expirar com a sessão, não com a service account.
O caso sem humano
Agente disparado por cron ou por evento não tem delegante. Esse é o caso que exige mais escrutínio, não menos, porque não há teto natural de permissão. Trate como carga de trabalho autônoma: escopo mínimo fixo, sem elevação possível, e alerta em qualquer desvio de padrão.
