Identidade de Agentes de IA: Quem Está Agindo em Nome do Seu Usuário, e com Qual Permissão

Quando um assistente de IA apenas respondia perguntas, a pergunta de segurança era "o que ele pode dizer?". Quando um agente agenda reuniões, envia e-mails, consulta o ERP e dispara pagamentos, a pergunta muda: "quem está agindo, em nome de quem e com que permissão?". Para quem decide arquitetura, esse é hoje um dos pontos mais negligenciados em projetos de agentes.

O problema: o agente age com autoridade emprestada

Um agente raramente tem identidade própria. Ele opera com a autoridade de um usuário, e muitas vezes a cadeia é maior do que parece: o usuário, o processo do agente, o token de acesso e possíveis subagentes. O atalho mais comum nos pilotos é uma chave de API compartilhada, de longa duração e com acesso amplo. Funciona na demonstração, mas cria três problemas em produção:

• Sem atribuição: com credencial compartilhada, o log mostra que "o sistema" fez algo, não qual agente nem a pedido de quem.
• Sem contenção: se o agente for enganado por uma instrução maliciosa escondida em um documento (prompt injection), ele leva consigo todo o acesso que a chave permite.
• Sem revogação fina: desligar um agente problem��tico significa trocar a chave de todos.

O desenho que funciona: delegação com escopo estreito e vida curta

A boa notícia é que não é preciso inventar nada novo. O ecossistema de identidade já tem os blocos, e o protocolo MCP, por exemplo, adotou OAuth 2.1 como base de autorização para servidores remotos. Na prática, cinco princípios organizam o projeto:

• Uma identidade por agente. Cada agente tem sua própria conta de serviço. Nada de credenciais compartilhadas entre agentes ou entre ambientes.
• Delegação explícita (on-behalf-of). O padrão de troca de tokens (RFC 8693) permite emitir um token que carrega duas identidades: quem delegou (o usuário) e quem executa (o agente). Cada ação fica atribuída aos dois.
• Escopo mínimo por operação. "Criar evento na agenda" é uma permissão; "ler toda a agenda" é outra. Se o agente precisar de mais, ele solicita elevação (step-up) e a decisão passa de novo pelo servidor de autorização, ou por uma aprovação humana quando a ação é sensível.
• Tokens de vida curta. Janelas de alguns minutos, emitidas sob demanda, limitam o estrago de um vazamento. Subagentes só podem receber um subconjunto das permissões do agente que os criou, nunca mais.
• Validação e revogação centralizadas. Toda chamada é validada em um único servidor de autorização, e a revogação vale na hora. Comportamentos anômalos (volume incomum de dados, atividade fora do horário, pedidos de mais permissão) devem poder disparar essa revogação automaticamente.

O que o executivo deve perguntar ao time

Você não precisa dominar OAuth para cobrar o essencial. Em uma revisão de projeto, quatro perguntas separam um piloto de um sistema pronto para produção: (1) cada agente tem credencial própria ou usa uma chave compartilhada? (2) conseguimos listar, para qualquer ação, qual usuário delegou e qual agente executou? (3) quanto tempo vive um token e com qual escopo? (4) em quanto tempo conseguimos revogar o acesso de um agente específico, sem afetar os demais?

Duas armadilhas merecem atenção. A primeira é a expansão silenciosa: cada nova ferramenta conectada ao agente pode ampliar seu alcance sem passar por revisão de segurança, então a inclusão de ferramentas deve seguir o mesmo processo de aprovação de um novo acesso. A segunda é a dívida de auditoria: protótipos com chaves de longa duração tendem a ir para produção do jeito que estão, e corrigir isso depois custa bem mais do que desenhar certo no início.

Na metodologia de roadmap de IA que usamos como referência, identidade e permissões entram na camada de governança e segurança, e não como um detalhe de implementação. Tratar o agente como um colaborador com crachá próprio, acesso mínimo e trilha de auditoria é o que permite ampliar a autonomia com confiança, passo a passo.