top of page
Buscar

Identidade de agentes de IA: quem é o agente e em nome de quem ele age?

Foto do escritor: Wanderson Marchi
Wanderson Marchi
há 10 minutos
6 min de leitura

Um agente de IA abre um chamado, lê uma caixa de e-mail e executa um comando em produção. Na semana seguinte, alguém pergunta no incidente: quem fez isso? O log responde com o nome de uma pessoa que nem estava na frente do computador.

Agentes executam ações com credenciais reais, e na maioria dos pilotos essas credenciais são emprestadas: a chave pessoal de alguém, um token de serviço compartilhado, um PAT esquecido em um arquivo de configuração. O problema não é a IA. É que o IAM ainda não sabe responder duas perguntas: quem é o agente e em nome de quem ele age.

No texto anterior, vimos que a pergunta central do OAuth é a delegação. Agentes levam essa pergunta ao limite, porque quem age já não é uma pessoa clicando, e sim um software que decide sozinho o que chamar e em que ordem.


Um cenário comum

Imagine uma empresa que coloca um agente para triar chamados de acesso. Para funcionar rápido, o desenvolvedor cola no agente o token pessoal dele, com permissão de escrita em todos os repositórios e no sistema de chamados. Três meses depois, um texto malicioso escondido em um chamado induz o agente a apagar uma configuração de produção (prompt injection).

No log, quem apagou foi o desenvolvedor, que estava de férias. Ninguém sabe qual agente agiu, quem o acionou nem quanto acesso ele tinha de fato. O incidente não foi causado por uma falha de modelo: foi causado por uma identidade que nunca existiu.


Agente não é usuário nem conta de serviço

Cada um desses três tipos de identidade pede controles diferentes:

  • Usuário: passa pelo RH, tem MFA e ciclo de vida, e age por decisão própria, dentro de uma sessão.

  • Conta de serviço: executa um fluxo fixo e previsível, escrito por alguém. O que ela faz está no código.

  • Agente: decide o caminho em tempo de execução, a partir de instruções em linguagem natural e do conteúdo que lê. O comportamento não é totalmente previsível, e o que ele lê pode influenciar o que ele faz.

Daí vêm quatro exigências: identidade própria, distinguível de pessoas e de outros agentes; um dono responsável; escopo mínimo por tarefa; e vínculo registrado com quem o acionou. O rascunho de conceito do NCCoE, do NIST (fevereiro de 2026), segue essa linha: propõe aplicar padrões de identidade já existentes aos agentes, para que os sistemas de gestão de acesso distingam agentes de pessoas e para que os agentes sejam conhecidos, confiáveis e bem governados. O OWASP Top 10 for Agentic Applications for 2026, publicado em dezembro de 2025, também inclui o abuso de identidade e de privilégio entre os riscos.


Três modelos de credencial

Há três formas de dar credencial a um agente. Elas não são excludentes, mas têm riscos bem diferentes:

Modelo

Como funciona

Vantagem

Risco principal

Credencial própria

O agente é um cliente OAuth registrado, com dono, e usa suas próprias credenciais (client credentials).

Identidade clara e escopo definido.

Perde a informação de quem pediu. Todos os usuários passam a compartilhar os direitos do agente.

Delegação do usuário

O agente age com a autorização da pessoa, obtida por consentimento OAuth.

Limita o agente ao que o usuário pode e registra quem pediu.

Herda tudo o que a pessoa pode, muito além do que a tarefa exige.

Token de curta duração por tarefa

Um token com escopo e destino estreitos é emitido para cada tarefa e expira sozinho.

Menor dano em caso de vazamento.

Exige infraestrutura de emissão e uma política clara de escopos.

Na prática, o desenho maduro combina os três: o agente tem identidade própria (modelo 1) e, quando age para uma pessoa, recebe um token delegado, de curta duração e restrito ao que a tarefa exige (modelos 2 e 3). O que nunca deve acontecer é o agente usar a credencial pessoal de alguém.


Delegação sem apagar o agente: o token exchange

O OAuth 2.0 Token Exchange (RFC 8693) diferencia duas semânticas. Na personificação (impersonation), o agente se torna indistinguível do usuário: quem recebe o token trata o agente como se fosse a pessoa. Na delegação (delegation), o agente mantém a própria identidade e age em nome do usuário.

Para agentes, a delegação é a escolha certa. O token emitido carrega o usuário no campo sub e o agente na declaração act. Assim, a API e o log enxergam as duas identidades ao mesmo tempo. A declaração may_act complementa o desenho ao dizer quem está autorizado a agir em nome de quem.

Há um segundo cuidado: o destino do token. Com os indicadores de recurso (RFC 8707), o token nasce para uma API específica, e um token vazado não serve em outra.


Ferramentas via MCP: escopo mínimo e aprovação humana

Quando o agente acessa ferramentas por servidores MCP em transporte HTTP, a especificação de autorização do MCP se apoia em padrões que você já conhece: OAuth 2.1 (ainda um rascunho no IETF), PKCE, metadados de recurso protegido (RFC 9728) e indicadores de recurso (RFC 8707). O próprio rascunho do NCCoE inclui o MCP, o OAuth 2.0 e 2.1, o OpenID Connect e o SCIM entre os padrões que considera aplicar a agentes. Quatro pontos merecem atenção:

  • A autorização é opcional na especificação. Um servidor MCP sem ela aceita qualquer cliente. Verifique se está ligada.

  • O servidor precisa validar o destino do token. Ele deve aceitar apenas tokens emitidos para ele e não pode aceitar nem repassar tokens emitidos para outros recursos. Isso impede que um token emitido para outro serviço seja aceito e proíbe o repasse do token recebido a outras APIs (token passthrough).

  • Escopo mínimo, com elevação sob demanda. O cliente deve pedir só o que a operação exige (privilégio mínimo). Se faltar escopo, o servidor responde com 403 e insufficient_scope, e o cliente pede mais. Use esse ponto para exigir aprovação humana: leitura passa, enquanto escrita, exclusão e envio para fora pedem confirmação no momento da ação.

  • Em servidores MCP que rodam na própria máquina (transporte stdio), a credencial vem do ambiente. Não há fluxo OAuth: a chave fica em variável de ambiente ou arquivo de configuração. Trate-a como segredo de verdade: cofre, vida curta e rotação.


Auditoria: quem pediu, qual agente agiu, que dado acessou

Auditar um agente é registrar, para cada ação, as três respostas que faltaram no cenário do início. O registro mínimo:

Pergunta

O que registrar

Quem pediu?

Identidade do solicitante (sub), a origem do pedido e um identificador de correlação.

Qual agente agiu?

Identidade do agente (act ou client_id) e a versão da configuração em uso.

O que foi feito?

Ferramenta, operação, recurso e dado acessado, com os escopos do token.

Quem aprovou?

Decisão de aprovação humana, quando exigida, com data e hora.

Dois complementos fecham o ciclo. O primeiro é a revogação: desativar a identidade do agente impede novos tokens, e a vida curta dos tokens já emitidos limita o resto. O segundo é o ciclo de vida: o agente entra no inventário de identidades não humanas, com dono e data de revisão, e sai dele quando o piloto termina.


Erros comuns

  • Colar a chave pessoal no agente. O log passa a mostrar a pessoa, nunca o agente, e a saída do colaborador quebra o agente.

  • Uma credencial compartilhada por todos os agentes. Não dá para separar responsabilidades nem revogar um sem derrubar os outros.

  • Delegação com escopo total "para funcionar". O agente herda o pior caso de tudo o que a pessoa pode fazer.

  • Tokens de longa duração. Um token que vaza e vale por semanas é uma credencial permanente. Prefira minutos, com renovação controlada.

  • Repassar o token do usuário a outros serviços. Cada recurso deve receber um token emitido para ele.

  • Aprovação humana só no início da sessão. Aprove a ação de risco quando ela acontece, mostrando o que será feito.

  • Confiar no que o agente lê. O conteúdo de um e-mail ou de um chamado pode conter instruções maliciosas. A defesa não é só filtrar o texto: é limitar o que o agente pode fazer mesmo que seja enganado, com privilégio mínimo e aprovação nas ações críticas.

  • Agente sem dono e sem prazo. O piloto termina, o agente continua vivo e vira mais uma identidade não humana órfã.


Checklist para pilotos

  1. Registre o agente como identidade própria, com dono e data de revisão.

  2. Proíba credenciais pessoais em agentes.

  3. Escolha o modelo: delegação para ações em nome de uma pessoa, identidade própria para tarefas autônomas.

  4. Defina escopos mínimos por ferramenta, com token de destino específico e vida de minutos.

  5. Exija aprovação humana para escrita, exclusão e envio para fora da empresa.

  6. Confirme que os servidores MCP têm autorização ligada e validam o destino do token.

  7. Registre solicitante, agente, dado acessado e decisão de aprovação em cada ação.

  8. Teste a revogação de ponta a ponta: desative o agente e confirme que ele para de agir. Inclua o agente no inventário de identidades não humanas.


Conclusão

Agente não é usuário nem conta de serviço: é uma identidade nova, que age por delegação. Se o seu log não responde quem pediu, qual agente agiu e que dado ele acessou, o agente ainda não tem identidade própria. Ele apenas empresta a de alguém.

No próximo texto, falamos de PAM na prática: do cofre de senhas ao acesso just-in-time.


Referências

Comentários

bottom of page