O relatório anual de investigação de violações de dados da Verizon, edição de 2026, chegou a um número que deveria incomodar qualquer área de tecnologia: 83% dos casos de escalonamento de privilégio no levantamento não exploraram nenhuma falha técnica. O invasor não precisou de uma vulnerabilidade sofisticada. Bastou usar um acesso que já estava concedido — só que largo demais para a tarefa que deveria cobrir.
O mesmo levantamento mediu o tempo que as empresas levam para corrigir isso: permissão em excesso e configuração de acesso mal ajustada levam uma mediana de quase oito meses para serem resolvidas. E 26% das organizações ainda carregam brechas de escalonamento de privilégio abertas desde 2021. Não é um problema novo. É um problema que a maioria das empresas decidiu conviver.
Esse hábito não nasceu com a IA, mas a IA corporativa é onde ele mais se repete agora. Quando uma equipe conecta um assistente a um sistema interno, a pergunta raramente é "de quais das cem funções desse sistema a equipe precisa". É "dá para conectar isso de algum jeito". E o jeito mais rápido, quase sempre, é abrir tudo.
Uma dívida que a IA está reativando
O princípio por trás disso tem nome e não é novo: o modelo de confiança zero do NIST, no documento de referência SP 800-207, trata o acesso mínimo necessário como um dos pilares — conceder privilégio por sessão, de forma temporária, e elevar apenas quando a tarefa realmente exigir. Nenhuma empresa discorda do princípio em teoria. A dificuldade está em aplicá-lo quando alguém precisa entregar algo hoje e abrir tudo resolve mais rápido do que configurar direito.
Com sistemas usados por pessoas, esse desvio já é caro — é o que o próprio NIST tenta corrigir. Com agentes de IA, o risco cresce em outra direção: o Microsoft Digital Defense Report de 2025 registra que identidades de sistemas, aplicações e agentes automatizados já superam as identidades de pessoas em boa parte das empresas, e que essas identidades costumam carregar privilégio além do necessário e controle mais fraco do que uma conta de pessoa. Um agente conectado a uma ferramenta inteira, com uma única credencial que abre todas as funções dela, é exatamente esse padrão — só que agora conversando em linguagem natural com qualquer pessoa da equipe.
Por que "conectar tudo" parece a saída mais simples
Quando alguém de tecnologia precisa ligar um assistente de IA a um sistema de gestão, a documentação da integração geralmente descreve dezenas de funções: consultar, criar, editar, aprovar, cancelar, exportar. A equipe que pediu a integração talvez precise de duas — consultar pedidos e ver status de entrega. Configurar exatamente essas duas dá trabalho: exige mapear o que cada função faz, decidir quem recebe o quê, e manter isso atualizado quando o time muda. Abrir a credencial inteira resolve na hora.
O problema aparece depois, e não aparece sozinho: aparece quando alguém pergunta, numa auditoria ou depois de um incidente, "quem podia cancelar pedidos por aqui". Se a resposta for "todo mundo que tinha acesso ao assistente, porque a integração foi feita assim", não existe trilha para reconstruir quem usou o quê. É exatamente o padrão que o relatório da Verizon descreve: o problema raramente é uma falha de segurança sofisticada. É acesso que ficou largo demais e ninguém revisou.
Esse tipo de decisão também não escala. Cada nova ferramenta conectada da mesma forma multiplica a superfície de coisas que um único acesso comprometido — ou um único erro de configuração de um agente — consegue alcançar. Em algum momento a lista de "o que esse assistente poderia fazer, tecnicamente" fica maior do que qualquer pessoa consegue explicar de cabeça.
O que precisa existir na prática
Um ambiente de IA com acesso bem desenhado se apoia em mecanismos concretos, não em boa vontade de configurar direito "quando der tempo".
Acesso função por função, não ferramenta inteira. Se uma integração tem trinta funções e a equipe de suporte usa duas, liberam-se essas duas. O restante fica disponível para quando — e se — outra equipe realmente precisar dele, não por padrão.
Escopo em camadas. Nem todo acesso precisa nascer definitivo e valer para a empresa inteira. Um acesso pode começar pessoal, para um teste ou uma tarefa pontual, e só depois "crescer" para acesso oficial de uma equipe ou da empresa — mediante decisão de quem aprova, não por inércia.
Credencial própria por ferramenta e por pessoa. Ninguém compartilha uma única chave de acesso entre várias pessoas ou vários agentes. Quando uma credencial some do quadro — porque a pessoa saiu, porque o agente foi desativado — ela some sozinha, sem depender de alguém lembrar de revogar algo manualmente.
Aprovação quando o alcance de um acesso aumenta. Pedir mais permissão do que a inicial não é automático: alguém decide, e essa decisão fica registrada. É a diferença entre um acesso crescer porque fazia sentido crescer, e um acesso crescer porque ninguém prestou atenção.
Trilha de quem tem o quê, revisável a qualquer momento. Se a pergunta "quem pode cancelar pedidos pelo assistente" precisar de uma investigação de duas semanas para ser respondida, o desenho de acesso já falhou — independente de nunca ter havido um incidente.
É assim que a Skyller foi desenhada: liberação função por função dentro de cada ferramenta conectada, escopo em camadas entre empresa, agente, equipe e pessoa, e credencial própria por ferramenta em vez de uma chave única compartilhada.
O que muda para quem decide o acesso
Quando o acesso é função por função, quem aprova uma nova integração para de assinar um cheque em branco. A pergunta deixa de ser "posso confiar nessa ferramenta de IA" — uma pergunta ampla demais para responder com segurança — e passa a ser "essas duas funções específicas fazem sentido para essa equipe". É uma decisão muito mais fácil de tomar, e muito mais fácil de defender depois.
O ganho aparece também na velocidade de reação. Quando uma pessoa muda de função ou sai da empresa, ajustar o acesso dela deixa de ser um projeto de revisão manual em várias ferramentas diferentes e vira consequência direta de mudar um papel num só lugar. E quando um agente de IA precisa de uma função nova, a equipe de tecnologia não decide entre "abrir tudo de novo" ou "travar o time", porque a concessão específica já é o caminho mais rápido, não o mais trabalhoso.
Um roteiro para revisar o acesso do seu primeiro assistente conectado
- Liste as ferramentas já conectadas a algum assistente de IA na empresa. Se a resposta for "não sei ao certo", esse já é o primeiro achado — e o motivo para começar por aqui.
- Para cada uma, pergunte quantas funções o assistente realmente usa hoje. Compare com quantas a credencial atual permite. A diferença entre os dois números é a permissão que sobra sem necessidade.
- Verifique se existe uma credencial única compartilhada entre pessoas ou entre agentes. Se existir, ela é o primeiro ponto a corrigir — é o que impede reconstruir quem fez o quê.
- Confirme quem aprova quando um acesso pede para crescer. Se a resposta for "ninguém, é automático", o alcance da IA na empresa está crescendo sem decisão de ninguém.
- Pergunte há quanto tempo cada acesso não é revisado. Um acesso concedido há dois anos, para uma tarefa que já mudou, é exatamente o tipo de brecha que o relatório da Verizon descreve como levando meses para ser corrigida.
