Em 20 de agosto de 2026, o Centro Nacional de Segurança Cibernética do Reino Unido, junto com as agências equivalentes dos Estados Unidos, Canadá, Austrália e Nova Zelândia, publicou uma orientação interina sobre como conter os riscos de sistemas de IA que agem sozinhos, sem revisão humana a cada passo. A recomendação central é curta: nenhum agente de IA deveria operar com mais acesso do que a tarefa exige, e a empresa precisa manter, a qualquer momento, a capacidade de interromper o que ele está fazendo.
A orientação não nasceu no vazio. Nos últimos dois anos, assistentes de IA que executam comandos diretamente no computador de quem os instalou já apagaram diretórios inteiros por engano. Em um caso relatado em janeiro de 2026, um assistente apagou uma pasta com entre 15 mil e 27 mil fotos de família ao receber a tarefa de organizar apenas arquivos temporários de um programa de escritório — os arquivos passaram direto pela lixeira do sistema. Em outro caso, de outubro de 2025, um assistente tentou apagar a raiz inteira do sistema operacional de um desenvolvedor e só não teve sucesso porque o próprio sistema bloqueou parte dos comandos.
Para quem decide levar esse tipo de assistente para dentro da empresa, o ponto não é que "a IA pode dar errado" — qualquer sistema pode. É que, quando o assistente roda com o mesmo nível de acesso da pessoa que o instalou, o limite do estrago é o limite de acesso daquela pessoa. E, na maioria das instalações hoje, ninguém na área de TI fica sabendo o que aconteceu até o dano estar feito.
O que já deu errado, em detalhe
Os casos acima não são falhas de um fabricante específico — eles se repetem em famílias diferentes de assistentes que executam ações diretamente no computador, porque compartilham a mesma causa raiz: o assistente herda todas as permissões da conta que o abriu. Não existe, por padrão, uma fronteira entre o que a tarefa pedida precisa e tudo que aquela conta consegue alcançar.
Um levantamento com profissionais de tecnologia, citado pela consultoria de segurança Cycode em análise sobre os riscos de IA de 2026, encontrou que 80% dos profissionais de TI já viram um agente de IA executar uma tarefa sem autorização para aquela ação específica. O relatório associa isso ao que a organização internacional de segurança de aplicações OWASP chamou de "excesso de autonomia" — quando um sistema de IA recebe mais permissão do que a tarefa exige, e o problema só aparece quando já é tarde.
A combinação dos dois pontos é o que preocupa quem cuida de segurança: o assistente age fora do que foi autorizado, e a empresa só sabe depois. Um agente que apaga uma pasta é visível na hora. Um agente que lê um arquivo de credenciais, copia um documento confidencial ou muda uma configuração pode não deixar rastro nenhum — e é exatamente esse tipo de acesso amplo que a maioria das instalações concede sem perceber.
Por que só "ter cuidado" não resolve
A resposta mais comum ao ler esses casos é "então preciso revisar cada comando antes de deixar rodar". Na prática, isso não se sustenta: um assistente que executa dezenas de ações por tarefa transforma a revisão manual em um clique automático de "permitir", repetido tantas vezes que perde o sentido. A pessoa se cansa de revisar antes mesmo de a IA errar pela primeira vez.
É por isso que a orientação das agências de segurança não pede mais atenção da pessoa — pede um desenho técnico diferente. As recomendações centrais são: dar ao assistente uma identidade própria, distinta da identidade da pessoa que o usa; restringir as credenciais disponíveis a só o necessário para a tarefa; rodar o assistente dentro de um ambiente isolado, com fronteira própria, que bloqueie por padrão qualquer acesso não explicitamente liberado; e manter, sempre, um jeito confiável de interromper a atividade na hora.
Nenhum desses pontos depende de a pessoa lembrar de fazer alguma coisa toda vez. É desenho de sistema, não disciplina de uso — e é a diferença entre um incidente que vira manchete e um comando que simplesmente não teve para onde ir.
O que precisa existir na prática
Um ambiente de IA corporativa que assume comandos e ações em nome de alguém precisa amarrar, ao mesmo tempo, estes mecanismos:
Separação entre o que a IA pode ler e o que ela pode executar. Consultar um documento e apagar um arquivo são operações de risco completamente diferentes; tratá-las com a mesma permissão é o erro de origem por trás da maioria dos casos relatados.
Credencial pessoal por ferramenta conectada, nunca senha compartilhada. Se o acesso a um sistema é feito com a credencial da própria pessoa, qualquer ação fica automaticamente ligada a quem a autorizou — e desligar alguém da empresa desliga o acesso junto, sem depender de ninguém lembrar de revogar nada à parte.
Aprovação humana antes de qualquer ação que apague, envie ou publique algo. O agente para, mostra o que está prestes a fazer e espera confirmação dentro da própria conversa, em vez de executar e só depois avisar o que já aconteceu.
Um ambiente com fronteira própria, não a máquina inteira da pessoa. O que o assistente enxerga e alcança é definido pelo escopo da tarefa, não pelo alcance da conta que abriu a sessão.
Trilha de auditoria de cada ação executada. Sem registro, uma investigação de incidente vira reconstrução de memória; com registro, vira consulta de poucos minutos.
É assim que a Skyller foi desenhada: credencial pessoal por ferramenta conectada, aprovação humana antes de ação sensível e trilha de auditoria por padrão — não como configuração extra que alguém precisa lembrar de ligar depois.
O ganho para quem cuida da segurança
Quando esses mecanismos existem por desenho, o efeito prático para a área de TI é menos tempo apagando incêndio e mais previsibilidade. Uma ação sensível que exigiria confirmação nunca chega a acontecer sem ela; um comando fora do escopo simplesmente não encontra caminho para executar, porque o ambiente não concede o acesso — não porque alguém percebeu a tempo.
Isso também muda a conversa com a liderança. Em vez de responder "confiamos que a ferramenta se comporta bem", a área de TI passa a responder com fatos verificáveis: quais credenciais o assistente usa, quais ações exigem aprovação, o que foi registrado sobre cada execução.
E há um ganho de adoção, não só de segurança: quando as pessoas confiam que o ambiente tem fronteiras, elas usam o assistente com mais frequência para tarefas reais, em vez de evitá-lo por medo de um comando dar errado, ou de recorrer a uma versão pessoal sem nenhum desses controles.
Vale notar que nenhum desses mecanismos resolve tudo sozinho. Identidade própria sem trilha de auditoria ainda deixa a empresa sem saber o que aconteceu; aprovação humana sem escopo bem definido só empurra a decisão para uma pessoa que também não tem contexto suficiente. É a combinação dos quatro pontos, funcionando ao mesmo tempo, que fecha as brechas que os casos documentados exploraram.
Quatro perguntas antes de aprovar o próximo assistente de IA
Antes de liberar um assistente que executa ações diretamente em sistemas da empresa, vale levar estas perguntas para a próxima reunião de aprovação:
- O assistente tem uma identidade própria, separada da identidade de quem o usa? Se a resposta for não, toda ação dele aparece como se tivesse sido feita pela pessoa, inclusive as que ela nunca autorizou.
- Existe uma lista do que ele pode acessar, ou ele simplesmente herda tudo que a conta alcança? Herdar tudo é o padrão da maioria das instalações — e é exatamente o padrão que os incidentes documentados exploraram.
- Alguma ação exige confirmação humana antes de executar, ou tudo acontece e só depois é reportado? A diferença entre as duas está entre prevenir e lamentar.
- Se algo der errado, existe um registro que reconstrói o que aconteceu em minutos? Sem trilha de auditoria, a resposta a um incidente vira suposição.
