Agente sem identidade própria é credencial compartilhada com autonomia

O agente herda a chave de quem o colocou no ar

Existem três atalhos comuns para fazer um agente funcionar na primeira semana. Todos resolvem o prazo do projeto e todos criam o mesmo débito de arquitetura.

• Conta de serviço compartilhada: vários agentes e automações usam a mesma credencial técnica, com a soma das permissões de todos.
• Token amplo de integração: uma chave de API ou um token de acesso pessoal com escopo total, criado para testar e esquecido em produção.
• Conta do próprio usuário: o agente age com a sessão de quem o configurou e herda tudo o que essa pessoa pode fazer.

Os números da Cloud Security Alliance mostram o efeito. Entre os respondentes, 74% dizem que os agentes costumam receber mais acesso que o necessário, e 52% afirmam que os agentes herdam, ao menos às vezes, acessos criados para pessoas ou para outros sistemas. O agente não pede permissão excessiva. Ele recebe por padrão, porque o caminho curto é emprestar.

Credencial compartilhada apaga o autor da ação

A primeira perda é de atribuição. Quando cinco agentes usam a mesma chave, o registro de acesso diz que a chave agiu. Não diz qual agente, a pedido de quem, nem em qual tarefa.

A mesma pesquisa da Cloud Security Alliance aponta que 68% das organizações não conseguem distinguir com clareza a atividade de um agente da atividade de um humano. A VentureBeat Pulse Research, com 107 empresas ouvidas em junho de 2026, encontra o mesmo padrão por outro ângulo: só 32% dão a cada agente uma identidade própria, com escopo e gestão, e 69% compartilham credenciais em algum ponto da operação.

A segunda perda é de contenção. Se a chave é compartilhada, revogar o acesso de um agente desliga todos os que dependem dela. O time hesita, e o agente com problema continua rodando enquanto a decisão sobe de nível.

Esse é o elo que liga identidade a resposta a incidentes com agentes de IA. Desligar precisa ser barato, e só é barato quando cada agente tem a própria credencial, revogável sem efeito colateral sobre os outros.

Token de máquina já é a porta de entrada

O risco não é hipotético. Entre 8 e 18 de agosto de 2025, o grupo rastreado pelo Google Threat Intelligence Group como UNC6395 acessou instâncias de Salesforce de clientes usando tokens OAuth comprometidos da integração Salesloft Drift. O Google registra que o caso não decorre de vulnerabilidade na plataforma Salesforce.

Depois de exportar os dados, o grupo procurou segredos dentro deles: chaves de acesso da AWS, senhas e tokens do Snowflake. Uma credencial de máquina abriu o caminho para outras credenciais de máquina. Nenhum usuário foi enganado, nenhuma senha humana foi digitada.

Agora some autonomia a esse cenário. A OWASP incluiu no Top 10 para aplicações agênticas, publicado em dezembro de 2025, o item ASI03, abuso de identidade e de privilégio: credenciais vazadas permitem ao agente operar muito além do escopo pretendido.

A injeção de prompt, tratada em prompt injection e o perímetro de segurança da IA, decide o que o agente tenta fazer. A identidade decide o que ele consegue fazer. Com escopo mínimo, um sequestro de objetivo vira alerta. Com uma chave ampla e permanente, o mesmo sequestro vira vazamento.

Delegação não é personificação

O agente que age pelo usuário precisa de um modelo explícito de delegação. O padrão já existe há anos. A RFC 8693 do IETF, que define a troca de tokens no OAuth 2.0, separa dois conceitos que muitos projetos de agente misturam.

Na personificação, o agente recebe todos os direitos do usuário e se torna indistinguível dele. Na delegação, o agente mantém a própria identidade e fica registrado que ele age em nome do usuário. A especificação prevê a reivindicação act no token, que identifica quem está agindo e permite encadear agentes que chamam outros agentes.

A diferença é estrutural. Com personificação, o registro mostra apenas o usuário. Com delegação, mostra o agente, o usuário representado e a cadeia completa. É o fluxo que os provedores de identidade chamam de on-behalf-of.

A permissão efetiva também muda. Ela deixa de ser tudo o que o usuário pode fazer e passa a ser a interseção entre o que o usuário pode, o que o agente pode e o que aquela tarefa exige. O agente de atendimento não aprova crédito, mesmo quando o gerente que o acionou aprova.

Os controles que precisam existir antes do primeiro agente

Nada disso exige produto novo. Exige decisão de arquitetura tomada cedo, quando ainda é barata. Depois que vinte agentes rodam na mesma chave, separar identidades vira projeto de migração.

A Cloud Security Alliance mostra onde está a lacuna: só 22% aplicam os controles de acesso de forma muito consistente aos agentes, e 33% não sabem com que frequência as credenciais deles são trocadas.

• Identidade própria por agente, registrada em inventário, com dono nomeado e finalidade descrita.
• Escopo por ferramenta: cada ferramenta que o agente chama recebe só a permissão daquela operação, leitura separada de escrita.
• Credencial de curta duração, emitida por tarefa e expirada ao fim dela, em vez de chave permanente guardada em configuração.
• Delegação explícita quando o agente age por uma pessoa, com o usuário representado gravado no token e no registro.
• Trilha de auditoria por identidade: cada chamada registra o agente, o usuário representado, a ferramenta, os parâmetros e o resultado.
• Revogação individual, testada, que desliga um agente sem derrubar os demais.

O escopo por ferramenta conversa com o desenho de integração descrito em MCP como padrão de integração para agentes de IA: cada servidor de ferramenta é um ponto natural para aplicar a permissão. E o inventário é pré-requisito do resto, como tratamos em a IA que você não governa. Não se dá identidade ao agente que ninguém sabe que existe.

A NN desenha essa camada junto com o primeiro agente. Define a identidade de cada um, o escopo por ferramenta, o fluxo de delegação com o provedor de identidade do cliente e a trilha de auditoria que liga cada ação a um agente e a uma pessoa.

Agente sem identidade própria continua sendo credencial compartilhada com autonomia. A diferença entre um incidente contido e um vazamento está em uma decisão tomada antes da primeira subida: quem é o agente, o que ele pode fazer e em nome de quem.