Quando uma pessoa muda de função dentro da mesma empresa, o comum é sair dali com dois pacotes de acesso somados, não um trocado pelo outro: o antigo continua valendo e o novo se soma a ele. A mudança de cargo tem processo, aprovação e data. A perda do acesso anterior, na maioria das empresas, não tem nenhuma das três.
O relatório de Cenário de Segurança de Identidade de 2025, da CyberArk, com a participação de 2.600 responsáveis por segurança em organizações de médio e grande porte, mediu esse desequilíbrio em outra escala: as identidades de máquina já superam as humanas em mais de 80 para 1 dentro das empresas, e a inteligência artificial deve ser, em 2025, a maior fonte de novas identidades com acesso privilegiado. Mesmo assim, 68% dos participantes admitiram que a organização não tem controles de identidade adequados para essas tecnologias.
A ligação entre os dois fatos é direta: um agente de IA nasce herdando boa parte do acesso de quem o configurou. Se essa pessoa já carrega o excesso comum de quem mudou de área algumas vezes, o agente herda o mesmo excesso — só que passa a operar com ele o tempo todo, sem ninguém revisando depois. Para quem decide sobre segurança e adoção de IA, esse é o detalhe que costuma escapar: o problema do acesso acumulado não nasceu com a IA, mas ela o reproduz em escala maior e mais rápido.
O acesso que vira bola de neve
A prática tem nome no mercado de identidade: acúmulo de privilégio. Acontece porque conceder acesso resolve um problema com data e dono — alguém precisa entrar num sistema hoje —, enquanto retirar não resolve problema nenhum na hora; apenas reduz um risco que talvez nunca vire incidente. O resultado, em qualquer empresa que cresce, é a mesma assimetria: fica-se bom em conceder e ruim em revogar.
Uma pesquisa da Beyond Identity com 1.121 pessoas nos Estados Unidos, no Reino Unido e na Irlanda, publicada em 2022, encontrou que 83% dos ex-funcionários continuaram conseguindo entrar em contas do empregador anterior depois de sair da empresa — não porque alguém tivesse decidido manter o acesso, mas porque ninguém teve a tarefa explícita de fechá-lo. Se isso acontece quando a pessoa sai de vez, é razoável esperar que aconteça com ainda mais frequência quando ela só muda de time, situação em que, aos olhos de quem administra o acesso, nada parece ter mudado.
O relatório de Segurança de Dados de 2025, da Varonis, mediu o mesmo resíduo por outro caminho: 88% das organizações têm contas ativas mas paradas — perfis que seguem com acesso liberado muito depois de deixarem de ser usados na rotina. Cada uma dessas contas corresponde a uma permissão que alguém concedeu por um motivo específico, num momento específico, e que segue valendo mesmo depois que o motivo deixou de existir.
Com agentes de IA, o padrão se repete em velocidade maior. Um agente criado para apoiar a área financeira, por exemplo, costuma herdar o perfil de quem o configurou — inclusive o que essa pessoa acumulou de funções anteriores. Quando outras pessoas do time passam a usar esse mesmo agente, ou quando quem o criou muda de função, raramente alguém revisita o que ele ainda pode ver e fazer.
O resultado é um excesso de privilégio que ninguém decidiu conceder de propósito: ele só nunca foi retirado. E quanto mais tempo uma permissão desnecessária fica ativa, maior é a janela para que alguém a use de um jeito que não deveria — uma credencial vazada, um agente mal configurado ou uma pessoa mal-intencionada aproveitam exatamente o acesso que já estava ali, acumulado, à espera.
As identidades de máquina já superam as identidades humanas em mais de 80 para 1 dentro das organizações.
Revisões que viram carimbo automático
A resposta mais comum é a revisão periódica de acesso: uma vez por ano, o time de segurança manda uma planilha para os gestores confirmarem se cada pessoa ainda precisa do que tem. Na prática, a maioria confirma tudo sem checar linha por linha — a lista é longa, o prazo é curto, e ninguém quer ser o gestor que travou o trabalho de um colega por engano.
Outra saída comum é o acesso por grupo: em vez de configurar permissão pessoa por pessoa, cria-se um grupo — "financeiro", "vendas" — e todo mundo daquela área herda o mesmo pacote. Isso resolve a velocidade de entrada de gente nova, mas transforma o grupo num arquivo de tudo que já foi liberado para alguém dali, algum dia, por algum motivo. Sair da área raramente tira a pessoa do grupo.
A terceira tentativa é registrar tudo e revisar depois: monitorar cada ação, guardar todo log, confiar que uma auditoria futura vai identificar o que passou do ponto. Isso serve para reconstruir um incidente depois que ele já aconteceu — não para impedir que aconteça. Um registro detalhado do que um agente de IA fez com um acesso que não deveria ter é, na melhor das hipóteses, uma explicação tardia.
Nenhuma das três soluções ataca a causa: elas tratam o sintoma — muito acesso circulando — sem mexer no motivo, que é a ausência de gatilho para retirar. Enquanto a única ação com prazo e dono continuar sendo conceder, o acúmulo vai seguir sendo o caminho de menor resistência.
O que precisa existir na prática
Um ambiente que resolve acúmulo de privilégio — para pessoas e para os agentes de IA que elas criam — depende de mecanismos verificáveis, não de boa vontade.
Acesso definido pelo papel atual, não pela soma do histórico. O perfil de permissão vem do cargo que a pessoa ocupa hoje e é recalculado a cada mudança: quem troca de função ganha o pacote novo e perde o antigo no mesmo movimento, em vez de simplesmente acumular os dois.
Escopo em camadas para cada agente de IA. Um agente não herda automaticamente tudo o que quem o criou pode acessar. Ele recebe um perfil próprio, definido pela tarefa que executa — empresa, agente, pessoal e sessão funcionam como camadas separadas, e o que vale numa não passa para a outra sem uma decisão explícita.
Aprovação humana antes de qualquer acesso mais sensível ser concedido. Pedir um acesso novo — para uma pessoa ou para um agente — passa por alguém que avalia se aquilo faz sentido para a função exercida, com a decisão registrada, e não por um formulário que qualquer gestor aprova sem examinar.
Revisão disparada por evento, não por calendário. Mudança de área, saída da empresa ou troca de responsabilidade de um agente disparam a revisão de acesso na hora, em vez de esperar a próxima rodada anual, quando o excesso já ficou meses acumulado.
Trilha de auditoria de quem concedeu o quê e quando. Toda concessão, toda revogação e toda aprovação ficam registradas de um jeito consultável — para uma pessoa ou para um agente, dá para responder em minutos de onde veio determinado acesso.
É assim que a Skyller foi desenhada: acesso conforme o papel de cada pessoa, escopo em camadas para os agentes que a equipe cria, e aprovação com trilha de auditoria como padrão, não como configuração à parte.
Menos acesso parado, mais confiança
Um ambiente onde o acesso reflete o papel atual, e não a soma de tudo que alguém já teve, reduz o que a área de segurança chama de superfície de exposição: se uma credencial vaza ou um agente é mal configurado, o estrago possível tem o tamanho da função exercida, não o tamanho de tudo que foi acumulado ao longo do tempo.
A equipe de TI também ganha uma resposta rápida para a pergunta que qualquer auditoria faz: quem pode acessar o quê, hoje. Sem um mecanismo assim, essa resposta exige um projeto — levantar planilhas, cruzar sistemas, entrevistar gestores de cada área. Com uma trilha de auditoria por evento, ela vira uma consulta de minutos.
Para quem muda de cargo, o ganho é velocidade sem o efeito colateral: o acesso novo chega tão rápido quanto chegaria de qualquer jeito, sem a necessidade de manter o antigo "por garantia" enquanto o processo formal não anda. E, para os agentes de IA que o time cria, o raciocínio se repete: um agente com escopo bem definido pode ser reaproveitado por outras pessoas com mais segurança, porque o que ele pode fazer é visível e limitado — não uma soma de permissões que ninguém sabe mais de onde vieram.
Perguntas para a próxima revisão de acesso
- Quantas pessoas hoje têm acesso de um cargo que já deixaram para trás? Se a resposta exige levantar informação manualmente, o problema não é de disciplina — é de processo: falta um gatilho que ligue automaticamente a mudança de função à mudança de acesso.
- Quando um agente de IA é criado, ele recebe um perfil próprio ou herda o de quem o configurou? Se a resposta for "herda", todo excesso que essa pessoa já carrega passa direto para o agente — e para quem for reaproveitá-lo depois.
- A revisão de acesso acontece quando algo muda, ou só uma vez por ano? Um calendário fixo garante que o acesso errado fique ativo, em média, metade do intervalo entre uma revisão e outra.
- A trilha de auditoria mostra quem concedeu cada permissão e quando — ou só que ela existe? Uma trilha que não responde "quem autorizou isso" em poucos minutos não cumpre a função de uma trilha.
