Identidade para agentes de IA: quem autoriza o software que age em seu nome?

Um chatbot responde. Um agente age.

Quando o agente lê uma planilha, consulta o CRM, atualiza um ticket ou aprova uma despesa, “o usuário estava logado” deixa de ser evidência suficiente. Qual usuário? Qual instância do agente? Com qual finalidade? Quem delegou aquela ação? A permissão valia para aquele sistema, naquele horário? Quem responde se o agente fez algo diferente do pedido?

Esse é o problema de identidade para agentes de IA. Não se resolve dando ao agente a chave de API de um administrador e gravando o prompt num log.

Em fevereiro de 2026, o National Cybersecurity Center of Excellence do NIST publicou o concept paper Accelerating the Adoption of Software and AI Agent Identity and Authorization. O documento ainda descreve um projeto em formação, não um padrão final. Mesmo assim, organiza o problema com precisão: identificação, autenticação, autorização, delegação, auditoria e mitigação de prompt injection precisam funcionar como um sistema.

A cadeia de autoridade que o log precisa provar

“O agente fez” não é uma identidade. Uma ação auditável precisa voltar até a pessoa, política ou sistema que delegou autoridade — sem apagar a identidade própria do agente.

O diagrama tem quatro atores diferentes. Colapsá-los numa única credencial é o atalho que transforma automação em caixa-preta.

A pessoa é o principal que expressa um objetivo. O agente é uma identidade não humana, ligada a uma versão, ambiente e execução. O servidor MCP é o recurso que oferece ferramentas e valida a autorização. O sistema final executa a ação com uma permissão adequada àquele destino.

Autenticar a pessoa responde “quem entrou?”. Identificar o agente responde “qual software agiu?”. Autorizar responde “o que podia fazer?”. Delegar responde “em nome de quem e dentro de qual limite?”. Auditoria precisa preservar todas as respostas.

O NIST está perguntando as questões certas

O concept paper do NIST não finge que uma conta de serviço resolve tudo. Ele pergunta se a identidade do agente deve ser fixa ou efêmera por tarefa, como aplicar menor privilégio quando as ações não são totalmente previsíveis, como mudar políticas quando o contexto muda e como vincular identidade humana a aprovações human-in-the-loop.

Também trata auditoria e não repúdio como problema central: ações e intenção precisam ser registradas de forma verificável e ligadas à autorização humana. E coloca prompt injection no mesmo escopo. Faz sentido. Um texto hostil vira incidente grave quando consegue usar uma autoridade que o agente já tinha.

Identidade, portanto, não é cadastro. É uma cadeia temporal de autoridade.

O que OAuth no MCP resolve

A especificação de autorização do MCP de 25 de novembro de 2025 usa padrões existentes em vez de inventar login para agentes. Em transportes HTTP, quando autorização é adotada, o servidor MCP funciona como resource server, o cliente MCP como cliente OAuth e um servidor de autorização emite tokens em nome do dono do recurso.

Entre os requisitos mais importantes:

• servidores de autorização implementam OAuth 2.1;
• o servidor MCP publica Protected Resource Metadata para o cliente descobrir onde autorizar;
• clientes usam PKCE para proteger o fluxo de código de autorização;
• o token é vinculado ao recurso pretendido, e o servidor valida sua audiência;
• tokens recebidos pelo servidor MCP não podem ser repassados diretamente para APIs a jusante.

O último item evita o problema do confused deputy: um token legítimo, emitido para um serviço, sendo reutilizado em outro que nunca deveria aceitá-lo. Se o servidor MCP precisar chamar uma API externa, ele usa outra credencial, emitida para aquela API. Token não é passe livre; tem destinatário.

OAuth resolve uma parte importante da estrada: emissão, descoberta, transporte e validação de autorização. Ele não decide sozinho se “enviar relatório” pode incluir dado confidencial, se uma transferência exige aprovação ou se um agente comprometido deve perder acesso imediatamente. Isso continua sendo política de produto e segurança.

Identidade não impede prompt injection — limita a explosão

Já explicamos por que prompt injection é uma vulnerabilidade estrutural. Se um agente lê conteúdo não confiável, esse conteúdo pode tentar redirecionar seu comportamento. Identidade forte não faz o modelo parar de interpretar a instrução maliciosa.

Ela muda o que acontece depois.

Um agente com permissão somente de leitura não apaga arquivos. Um token preso ao CRM não abre o repositório. Uma ação de alto impacto exige confirmação. Um log encadeado mostra qual entrada, ferramenta e credencial participaram. Um kill switch revoga a identidade antes que o incidente se espalhe.

Segurança de agente não depende de uma defesa perfeita contra manipulação. Depende de reduzir a autoridade disponível quando a manipulação inevitavelmente acontecer.

Checklist operacional antes de colocar o agente em produção

Use esta lista numa revisão de arquitetura. Cada “não” precisa de dono e prazo, não de esperança.

1. Identidade própria: cada agente tem identidade distinta por aplicação, ambiente e papel — sem chave administrativa compartilhada.
2. Vínculo de delegação: cada execução registra quem ou qual política iniciou a tarefa e qual objetivo foi autorizado.
3. Token curto: credenciais expiram rápido, podem ser revogadas e nunca aparecem em prompt, URL ou log.
4. Escopo mínimo: leitura e escrita são separadas; ferramentas de alto impacto não entram no conjunto padrão.
5. Audiência validada: cada servidor aceita apenas tokens emitidos para ele; token passthrough é proibido.
6. Aprovação proporcional: ações irreversíveis, financeiras, públicas ou destrutivas exigem confirmação fora do canal controlado pelo modelo.
7. Política contextual: acesso considera usuário, agente, recurso, sensibilidade, horário e risco da ação — não só um papel estático.
8. Auditoria completa: intenção, entrada, decisão, ferramenta, parâmetros relevantes, resultado e aprovador ficam ligados numa trilha consultável.
9. Revogação testada: existe um caminho rápido para suspender agente, token, ferramenta ou integração sem derrubar o resto do sistema.
10. Teste adversarial: conteúdo injetado não consegue ampliar escopo, trocar audiência, contornar aprovação nem apagar evidência.

Isso é o mínimo. Agentes que operam saúde, finanças, infraestrutura ou dados regulados precisam de controles específicos ao domínio.

A pergunta que deveria abrir toda arquitetura

Times costumam começar pelo que o agente consegue fazer. Segurança começa pelo inverso: qual é a menor autoridade que permite concluir a tarefa, e como provamos quem a concedeu?

O NIST aponta para identidade de workloads, OAuth/OIDC, SPIFFE/SPIRE, SCIM, controle baseado em atributos e Zero Trust como peças possíveis. Não existe um produto único que resolva todas. Existe uma propriedade que a arquitetura precisa preservar: nenhuma ação sem identidade, autoridade delimitada e evidência.

Na consultoria agêntica da Arvor, essa cadeia entra antes da escolha do framework. Mapeamos ferramentas, superfícies de dados, aprovações e limites de autonomia para que o agente seja útil sem virar um administrador invisível da empresa.

Dar uma identidade ao agente não o transforma em pessoa. Impede que a empresa trate ação autônoma como se ninguém tivesse feito.