Todo programa, toda integração e todo agente de IA que passa a operar dentro de uma empresa carrega consigo pelo menos uma credencial: uma chave que abre a porta de algum sistema. Segundo o relatório State of Secrets Sprawl 2026, da empresa de segurança GitGuardian, publicado em março de 2026, foram encontradas 28,65 milhões de credenciais novas expostas em código público ao longo de 2025 — alta de 34% sobre o ano anterior e o maior salto anual já registrado pela empresa.
Uma fatia relevante desse crescimento está ligada diretamente à IA: as credenciais associadas a serviços de inteligência artificial somaram 1.275.105 no mesmo levantamento, um aumento de 81% em um ano. Cada agente novo colocado para funcionar é, em geral, mais uma credencial circulando pela empresa — e poucas delas têm dono definido, prazo de validade ou acesso limitado à tarefa que deveriam cumprir.
A OWASP, fundação internacional de referência em segurança de software, formalizou esse cenário em 2025 com uma lista dos dez riscos mais comuns em identidades usadas por programas e agentes, não por pessoas. Entre eles estão o excesso de privilégio, a credencial sem prazo para expirar e o desligamento incompleto quando um projeto termina. Para quem decide colocar agentes em produção, sobra uma pergunta simples e pouco feita: a chave que este agente carrega abre exatamente o quê — e por quanto tempo?
Mais chaves do que qualquer equipe consegue contar
Nenhuma empresa decide, de uma vez, ter milhares de credenciais de sistemas circulando. Elas se acumulam aos poucos: uma integração aqui, um agente ali, cada um recebendo acesso a um sistema para resolver uma tarefa específica. O problema é que essa credencial raramente é revista depois — ela simplesmente continua lá, ativa, muito depois de a tarefa original ter mudado ou terminado.
O mesmo relatório da GitGuardian mediu esse hábito de forma direta: 64% das credenciais confirmadas como válidas em 2022 continuavam ativas e exploráveis em janeiro de 2026. Quatro anos depois, a maioria delas nunca tinha sido trocada nem cancelada — apenas esquecida em algum lugar do sistema.
A lista da OWASP nomeia exatamente esse padrão. Um dos dez riscos, batizado de identidade com excesso de privilégio, descreve credenciais de programas e agentes com acesso muito além do que a função exige. Outro, credencial de longa duração, descreve chaves e certificados sem data para expirar. Um terceiro, desligamento incompleto, descreve o que acontece quando ninguém revoga o acesso de um projeto encerrado.
O Relatório de Investigações de Violações de Dados de 2026, da Verizon, mostra por que isso importa na prática. O abuso de credenciais caiu para 13% como porta de entrada inicial em ataques — era 22% no ano anterior —, mas, quando contado em qualquer etapa do ataque, e não só no primeiro passo, ele segue no topo, presente em 39% das violações analisadas. O próprio relatório cita rotação inadequada de credenciais e ausência de acesso mínimo em contas de sistemas e serviços entre as causas de fundo mais comuns em violações que envolveram terceiros.
Nas empresas brasileiras e latino-americanas que começam a colocar agentes de IA para atender clientes, atualizar cadastros ou consultar sistemas financeiros, o padrão se repete: a integração nasce rápido, alguém reaproveita uma credencial já existente ou cria uma com acesso amplo "para não travar depois", e ninguém volta para estreitar aquele acesso quando a rotina se estabiliza.
Por que a chave mestra parece o caminho mais rápido
Quando um agente precisa se conectar a um sistema de pagamento, a uma planilha ou a um sistema de atendimento, o caminho mais rápido é entregar a ele uma credencial de acesso amplo — a mesma que uma pessoa usaria para fazer qualquer coisa naquele sistema. Configurar acesso restrito a apenas duas ou três funções, dentro de uma ferramenta que tem dezenas delas, parece trabalho demais para uma automação que "só vai fazer uma coisa".
O problema aparece quando esse agente erra, é manipulado ou simplesmente é usado além do previsto. Como ele herdou o mesmo alcance de uma credencial de uso geral, a ação executada carrega todo esse poder — mesmo que a tarefa original exigisse muito menos. E, no registro do sistema, o que fica gravado é o nome genérico da conta ou do agente, não a pessoa ou o processo que deveria responder por aquilo.
É exatamente essa combinação que a OWASP cataloga como uso indevido de identidade de máquina: alguém reaproveita uma credencial ampla porque configurar uma estreita parece burocracia, e o risco só aparece meses depois, numa investigação em que ninguém consegue dizer com segurança quem autorizou o quê.
O que precisa existir na prática
Resolver isso não é uma questão de confiar mais ou menos no agente. É uma questão de arquitetura: cada credencial precisa nascer estreita, ter dono e ter prazo.
Credencial pessoal por ferramenta conectada. Cada integração usada por um agente ou por uma pessoa tem sua própria chave de acesso — nunca uma credencial genérica repassada entre várias automações ou pessoas diferentes.
Acesso liberado função por função, mesmo dentro da mesma ferramenta. Se um sistema conectado tem trinta funções e o agente só precisa de duas para cumprir a tarefa, são essas duas que ficam liberadas — não a ferramenta inteira.
Prazo de revisão para cada credencial, sem exceção. Nenhuma chave fica ativa indefinidamente só porque ninguém lembrou de reavaliá-la; a revisão periódica é parte do funcionamento, não uma tarefa extra de alguém.
Aprovação humana antes de qualquer ação sensível. Antes de o agente executar algo com impacto real — mover dinheiro, alterar um cadastro crítico, publicar um documento —, a ação para e pede confirmação de uma pessoa, dentro da própria conversa.
Trilha de auditoria que liga a ação a quem a originou. Cada uso de uma credencial fica registrado de um jeito que aponta para a pessoa ou o processo responsável, não apenas para o nome genérico do agente.
É assim que a Skyller foi desenhada: cada ferramenta conectada recebe credencial própria, o acesso é liberado função por função, e ações sensíveis passam por confirmação humana antes de acontecer.
O que muda quando cada chave tem dono
O primeiro ganho aparece na hora de investigar algo fora do comum. Com credencial estreita e pessoal por ferramenta, saber o que um agente específico pode ter feito deixa de ser um exercício de suposição e vira uma consulta direta — porque o alcance daquela chave já era limitado desde o início.
O segundo ganho aparece quando um projeto termina ou uma ferramenta é substituída. Desativar aquela credencial específica não exige rastrear quem mais dependia dela, porque ela nunca foi compartilhada com nada além da tarefa para a qual nasceu.
O terceiro é o que mais pesa à medida que a empresa cresce: adicionar o agente número cinquenta deixa de ser mais arriscado do que adicionar o quinto, porque cada um carrega apenas o acesso que a própria função exige — não o que sobrou de uma credencial emprestada. Na Skyller, revisar o que uma ferramenta específica autoriza, e revogar isso sem afetar mais nada, é uma tela de configuração, não uma investigação.
Um roteiro para revisar as chaves em uso
Antes de conectar o próximo agente a um sistema novo, vale reunir a área de TI e responder a estas perguntas sobre o que já está em funcionamento:
- Liste as credenciais que os agentes de IA já usam hoje. Incluindo as criadas de forma informal, por alguém tentando resolver uma tarefa pontual que continua rodando meses depois.
- Para cada uma, pergunte o que ela abre — não apenas em qual sistema. Sistemas costumam ter dezenas de funções; poucas credenciais realmente precisam de todas.
- Descubra há quanto tempo cada credencial não é trocada. Uma chave sem data de revisão é, na prática, uma chave sem dono.
- Defina quem aprova o quê antes de o agente agir. Nem toda ação exige confirmação manual, mas a que envolve dinheiro, dado crítico ou comunicação externa, exige.
- Confirme se o registro aponta para uma pessoa, e não só para o nome do agente. Sem isso, a próxima investigação vai esbarrar na mesma resposta vaga: "alguém do time, não sei quem".
