As senhas se tornaram um problema de segurança por um motivo simples: elas podiam ser separadas das pessoas que deveriam autenticar. Uma vez compartilhado ou roubado, o mesmo segredo podia ser reutilizado até que alguém percebesse o uso indevido e revogasse a credencial. Não por acaso, as empresas passaram anos migrando desse modelo para acessos vinculados de forma mais estreita à identidade e ao contexto de quem faz a solicitação.
Os agentes de inteligência artificial estão reintroduzindo exatamente essa fraqueza nos fluxos automatizados — só que em velocidade de máquina e atravessando vários sistemas ao mesmo tempo. Uma credencial concedida para uma tarefa legítima pode continuar ativa depois que o trabalho termina, que o propósito do agente muda ou que a pessoa que o autorizou troca de função.
Se você cuida de infraestrutura, integrações ou segurança em uma empresa que começou a adotar agentes, este é um daqueles assuntos que valem a leitura antes do próximo incidente, e não depois. Vamos entender o problema e, principalmente, como resolvê-lo.
Por que um agente não é uma aplicação comum
Uma aplicação convencional segue instruções predefinidas. Um agente, por outro lado, pode decidir quais ferramentas acionar e quais passos executar. Isso muda tudo, porque um acesso esquecido pode ser usado de maneiras que a pessoa que o autorizou jamais imaginou.
Pense em um agente autorizado a montar uma proposta de renovação para um cliente. Ele pode precisar de acesso temporário ao CRM, a planilhas de preços, ao e-mail e ao sistema de contratos. Se essas conexões dependem de tokens reutilizáveis ou de uma conta de serviço permanente, o agente pode continuar com acesso depois que a proposta estiver pronta.
A partir daí, basta uma instrução maliciosa escondida em um documento, uma ferramenta comprometida ou um fluxo posterior para que o agente recupere ou envie informações que nada têm a ver com a tarefa original. É o tipo de cenário que a indústria chama de injeção de prompt, e ele se torna muito mais perigoso quando o agente tem nas mãos credenciais amplas e duradouras.
O tamanho do problema em números
Pode parecer uma preocupação teórica, mas os dados mostram o contrário. As chamadas identidades não humanas — contas de serviço, chaves de API, tokens OAuth, certificados de máquina e, agora, agentes de IA — já superam as identidades humanas nas empresas em uma proporção estimada entre 45 e 100 para 1.
E boa parte delas está mal protegida. O OWASP, organização de referência em segurança de aplicações, registrou 24 milhões de credenciais de identidades não humanas vazadas no GitHub ao longo de 2025 — e cerca de 70% das que haviam vazado em 2022 continuavam válidas. Um levantamento de 2025 do Non-Human Identity Management Group apontou que 73% dos segredos mantidos por essas identidades carregam permissões excessivas.
A governança também está atrasada. Em pesquisa recente, 92% dos entrevistados disseram que suas ferramentas tradicionais de gestão de identidade não conseguem lidar com os riscos de IA e de identidades não humanas, e metade relatou não haver um responsável claro pelas identidades dos agentes. Uma análise da Cloud Security Alliance de 2026 foi além: mais de 16% das organizações sequer registram a criação de identidades ligadas a IA.
Enquanto isso, a adoção dispara. Pacotes de frameworks de agentes como LangChain, LangGraph, CrewAI e o SDK de agentes da OpenAI somaram 483 milhões de downloads apenas em maio de 2026. A distância entre a velocidade de implantação e a maturidade da governança só aumenta.
Os incidentes que já aconteceram
Os vazamentos já não são hipotéticos. Em agosto de 2025, o Google Threat Intelligence Group documentou uma campanha de roubo de dados em instâncias Salesforce explorando a integração Salesloft Drift — sem malware, apenas abuso de tokens na velocidade de uma integração. Em abril de 2026, a Vercel sofreu uma violação no mesmo estilo, em que uma integração OAuth de terceiros comprometida expôs segredos de banco de dados, chaves de assinatura e credenciais de clientes.
O padrão é o mesmo: uma credencial válida, com permissões amplas, nas mãos erradas.
Segredos estáticos não combinam com fluxos autônomos
Credenciais reutilizáveis são perigosas porque transformam acesso em posse. Quem — ou o que — detiver o segredo pode usá-lo até que ele expire, seja rotacionado ou revogado. Esse modelo já é arriscado para usuários humanos, e as consequências crescem quando é aplicado a agentes capazes de acionar ferramentas, interagir com aplicações e disparar fluxos de trabalho.
É comum que equipes conectem agentes a credenciais já existentes para que eles executem tarefas de negócio. Esse atalho transforma o agente em um detentor independente de acesso, em vez de um executor temporário das instruções de uma pessoa. E ele combina dois riscos que as empresas tradicionalmente gerenciavam separadamente: a credencial pode ser roubada, ou o agente pode usar uma credencial válida para realizar uma ação não autorizada ou não pretendida.
Quando isso acontece, a empresa perde a conexão entre a credencial, a pessoa que autorizou seu uso e a tarefa para a qual ela foi concedida. Um log de acesso convencional pode mostrar qual token chamou determinada API e quando. Mas talvez não mostre quem deu a instrução ao agente, qual objetivo ele perseguia, quais decisões intermediárias tomou e se a ação final permaneceu dentro do que foi originalmente pedido.
O que a autenticação sem senha pode nos ensinar
A autenticação moderna sem senha oferece uma lição valiosa. Em vez de exigir que o usuário apresente um segredo reutilizável, ela se apoia em uma prova criptográfica vinculada a um autenticador e avalia a identidade, o dispositivo e o contexto da solicitação. Isso torna as credenciais muito mais difíceis de roubar, compartilhar ou reutilizar.
O acesso dos agentes deveria seguir o mesmo princípio, sem tratá-los exatamente como usuários humanos. Em vez de guardar um segredo de longa duração, o agente deveria solicitar acesso para um propósito definido, com cada pedido avaliado frente à autoridade da pessoa, à tarefa atribuída e ao risco da ação proposta.
Qualquer acesso concedido deveria cobrir apenas os sistemas, dados e ações necessários — e terminar quando a tarefa for concluída ou quando a autoridade que o sustentava mudar. Agentes podem precisar agir rápido, mas velocidade não exige posse permanente de credenciais sensíveis.
O OWASP resumiu essa ideia em um princípio batizado de “menor agência”, o equivalente agêntico do velho conceito de menor privilégio. Sua lista Top 10 para Aplicações Agênticas de 2026, publicada em dezembro de 2025 e revisada por mais de cem pesquisadores de segurança, classifica esse tipo de falha como abuso de identidade e privilégio.
O desafio real: controlar a autoridade delegada
A parte mais difícil do acesso de agentes não é autenticar o agente. É controlar o que acontece depois que uma pessoa delega autoridade a ele.
Quando alguém orienta um agente a agir, ele passa a exercer uma autoridade delegada. Suas permissões podem vir do cargo daquela pessoa, das políticas do processo de negócio ou de restrições impostas pelo serviço de destino. Cada ação precisa continuar rastreável até a pessoa que iniciou a tarefa e até as políticas que a permitiram.
Essa cadeia fica mais difícil de preservar quando um agente aciona várias ferramentas, chama outro agente ou continua trabalhando depois que quem o iniciou já não está presente. As equipes de segurança precisam conseguir saber não só quem começou o processo, mas o que essa pessoa aprovou e se cada ação seguinte permaneceu dentro desses limites.
Um token, sozinho, não preserva essa cadeia. Ele pode indicar um escopo e uma validade, mas não necessariamente estabelece quem delegou a tarefa, como essa pessoa foi autenticada, qual resultado foi aprovado ou se ela continuava autorizada a delegar. É por isso que verificação de identidade e autenticação se tornam fundamentais para a governança de agentes. Quanto maior o risco da ação, maior a confiança necessária na identidade e na autoridade de quem a delega. Atividades rotineiras podem se apoiar na autenticação e nas políticas existentes, enquanto fluxos sensíveis podem exigir verificação reforçada antes que o agente possa agir.
Do ponto de vista técnico, as peças para resolver isso já existem e estão convergindo. Padrões como SPIFFE e SPIRE oferecem identidade criptográfica para cargas de trabalho, e o mecanismo de troca de tokens do OAuth 2.0 permite emitir credenciais que preservam a cadeia de delegação. O problema, segundo a literatura recente, é que a adoção dessas ferramentas está bem atrás do ritmo de implantação dos agentes.
Acesso intermediado: útil, mas com limites
A abstração de credenciais dá às equipes de segurança um caminho prático para manter segredos reutilizáveis fora dos fluxos dos agentes. Em vez de colocar uma chave de API na configuração do agente ou atribuir a ele uma conta de serviço permanente, a organização guarda a credencial atrás de um intermediário, uma camada de aplicação de políticas.
O agente precisa solicitar acesso por essa camada a cada ação específica. O intermediário avalia política, risco e contexto de identidade antes de emitir uma credencial de curta duração, limitada àquela ação. Solicitações de maior risco podem disparar aprovação adicional ou verificação de identidade mais forte. Em ambientes legados, o intermediário pode manter uma credencial de longa duração, mas impedindo que o agente tenha acesso direto a ela.
Curta duração não significa baixo risco
Aqui cabe um alerta importante. Uma credencial válida por poucos minutos ainda pode autorizar um pagamento danoso, uma transferência de dados ou uma alteração de configuração. O escopo precisa restringir o que o agente pode fazer, e não apenas por quanto tempo ele pode ficar conectado.
Limitar o acesso por sistema, dado, ação e duração reduz o raio de impacto de um incidente e cria uma trilha de auditoria mais clara. Cada ação pode ser rastreada até a pessoa que iniciou a tarefa, a autoridade delegada ao agente e a política que a aprovou.
Essas proteções, no entanto, desmoronam se o agente conseguir alcançar o sistema de destino diretamente, ou repassar trabalho para outro agente fora do caminho controlado. Controles de endpoint e de rede precisam bloquear essas rotas alternativas, enquanto os registros de auditoria preservam a ligação entre o pedido original, a autoridade por trás dele e a ação resultante.
O que as equipes de segurança devem fazer agora
O primeiro passo é um inventário honesto: quais agentes acessam sistemas de negócio, quais credenciais eles usam e quem autorizou essas conexões. Credenciais embutidas em arquivos de configuração de agentes ou vinculadas a contas de serviço permanentes merecem atenção especial — elas costumam ser as mais esquecidas e as mais perigosas.
Em seguida, vem a restrição de acesso por sistema, dado, ação e duração. Atividades sensíveis podem exigir autenticação reforçada ou aprovação explícita, e os controles de endpoint e de rede devem impedir que os agentes contornem o caminho intermediado.
Por fim, o acesso dos agentes precisa ser revisado sempre que funcionários mudam de cargo, fluxos são alterados, ferramentas são adicionadas ou agentes começam a delegar trabalho a outros agentes. Essas mudanças podem ampliar o alcance prático de uma credencial mesmo quando as permissões documentadas continuam iguais.
Vale acompanhar também as referências que estão se consolidando. O NIST, por meio do seu Centro de Padrões e Inovação em IA, lançou em fevereiro de 2026 uma iniciativa específica de padrões para agentes, acompanhada de um documento conceitual sobre identidade e autorização de agentes que especialistas recomendam tratar desde já como boa prática, e não como prévia de exigências futuras.
E no Brasil, onde entra a LGPD?
Para empresas brasileiras, há uma camada extra de responsabilidade. A Lei Geral de Proteção de Dados tem entre seus princípios a responsabilização e a prestação de contas, o que exige que a organização consiga demonstrar as medidas adotadas para proteger dados pessoais.
Um agente com credenciais amplas e sem trilha de auditoria clara torna essa demonstração muito difícil. Se ele acessar indevidamente dados de clientes, pacientes ou funcionários, a empresa pode ter de comunicar o incidente à ANPD e aos titulares — e explicar como aquilo aconteceu. Em setores que lidam com dados sensíveis, como saúde, a exigência é ainda maior. Ter um mapa de quem autorizou cada agente e o que cada um pode acessar deixa de ser boa prática e passa a ser uma necessidade de conformidade.
Evitando uma nova geração de senhas
Os agentes de IA podem acelerar a proliferação de credenciais e ampliar seu impacto nos negócios. Se as equipes conectarem agentes copiando chaves para arquivos de configuração ou atrelando-os a contas de serviço permanentes, a segurança perde o controle sobre onde os privilégios estão, como são usados e quando deveriam ser revogados.
A abordagem mais segura mantém as credenciais privilegiadas fora do alcance dos agentes e concede permissões apenas para a tarefa em questão. A política vincula essa autoridade a uma origem verificada e encerra o acesso quando o trabalho termina ou quando a base que o justificava muda.
Assim, as organizações conseguem aproveitar os agentes sem permitir que um acesso pensado para uma tarefa específica vire um direito permanente — e, com isso, mais uma versão do problema das senhas que passaram anos tentando resolver.
