A gestão de acesso privilegiado moderna resolveu um problema difícil para humanos: como dar poder de administrador sem que a pessoa carregue esse poder o dia inteiro. A resposta foi JIT — solicitar, usar, devolver, com auditoria. Para agentes, essa resposta ainda não foi aplicada.
Como fica na prática
O desenho tem três estados, não um:
- Repouso. O agente tem permissão de leitura no escopo em que opera, e nada mais. É o estado em que ele passa a maior parte do tempo.
- Elevado. Para uma operação específica, ele solicita escrita — com recurso nomeado, motivo derivado da tarefa e TTL curto, na casa de minutos.
- Revogado. A permissão expira sozinha ao fim da tarefa. Ninguém precisa lembrar de retirar.
A diferença em relação a simplesmente dar escrita permanente é que a janela de exposição deixa de ser a vida da service account e passa a ser a duração da operação.
Quem decide a elevação
Esse é o ponto que trava a maioria das implementações. Se o próprio agente decide quando se elevar, o controle é decorativo — um contexto envenenado simplesmente pede elevação junto com o resto.
A decisão precisa morar fora do modelo: numa política avaliada pela camada de orquestração, com base em atributos que o modelo não controla — qual tarefa, qual usuário delegou, qual recurso, qual horário. Política como código no caminho da chamada de ferramenta.
Se o agente pode se auto-elevar sob instrução, você não tem JIT. Tem permissão permanente com passos extras.
Onde isso já é possível hoje
Não é teórico. Provedores de nuvem oferecem elevação temporária com aprovação e TTL, e um motor de política no gateway consegue negar ou permitir por atributo antes de a chamada sair. O que falta quase sempre não é tecnologia — é a decisão de que o agente começa em leitura, que é a parte que exige disciplina no primeiro dia do projeto.
