Um teste autorizado na própria rede doméstica de Will Knight mostrou que um agente de IA pode identificar cerca de uma dúzia de sistemas de hardware, apontar falhas em dispositivos e projetos de software, usar uma chave criptográfica para entrar em uma máquina Linux sem senha e tentar credenciais comuns do roteador. O resultado não foi uma invasão contra terceiros: foi um experimento controlado no ambiente do próprio autor, descrito em um relato publicado em 9 de setembro de 2026.
O caso é importante porque o agente não ficou restrito a responder perguntas. Com permissões amplas e ferramentas para executar tarefas de cibersegurança, ele avançou da descoberta para tentativas de acesso e continuou perseguindo o objetivo recebido. Ao mesmo tempo, encontrou problemas que podem ser úteis para uma auditoria defensiva — desde firmware desatualizado até credenciais expostas.
O que foi testado de fato
Will Knight conduziu o teste em sua própria rede local e com autorização. O agente era uma versão sem salvaguardas comuns do GLM-5.3, modelo de programação desenvolvido pela Z.ai, acessada por meio da Abliteration AI e orientada pelo CyberStrike, um recurso criado para conduzir modelos de linguagem em tarefas de cibersegurança.
A experiência identificou cerca de uma dúzia de sistemas de hardware na rede e catalogou várias fragilidades. Também encontrou dezenas de problemas em projetos de software feitos com auxílio de IA, incluindo credenciais de API expostas e uma configuração que poderia permitir o envio não autorizado de e-mails.
O ponto central é a autorização: o teste ocorreu na rede de Will Knight. Ele não demonstra que um agente tenha invadido a casa de outra pessoa nem que todas as redes domésticas estejam vulneráveis.
Do escaneamento ao acesso tentado
A sequência relatada ajuda a entender a diferença entre um assistente que apenas sugere comandos e um agente que usa ferramentas em um ciclo de ação. Depois de localizar equipamentos, o sistema investigou caminhos de acesso disponíveis no ambiente autorizado.
Em uma máquina Linux, encontrou uma chave criptográfica e a utilizou para fazer login sem senha. Em seguida, começou a procurar a senha necessária para obter acesso de administrador — uma etapa que Will Knight interrompeu antes de uma tentativa de adivinhação de senha.
Quando o roteador voltou a aparecer após uma reconexão ao Wi-Fi, o agente tentou combinações comuns de senha administrativa. O relato não estabelece que o login tenha funcionado. Essa diferença é decisiva: uma tentativa de acesso não equivale a um comprometimento bem-sucedido.
Impressora, aparelho de som, IoT e código
Os achados mais reveladores não dependiam de um cenário cinematográfico. Eram falhas banais, espalhadas por equipamentos e projetos que normalmente ficam fora do radar do proprietário.
| Área analisada | Problema relatado | Implicação defensiva |
| Impressora | Uma configuração permitia que qualquer pessoa na rede fizesse login, com possível exposição de documentos na fila de impressão. | Revisar autenticação e proteger o acesso à impressora. |
| Aparelho de som Wiim | Informações sobre a reprodução ficavam expostas, e usuários da rede podiam alterar a música ou o volume. | Restringir controles de rede e revisar quais dispositivos podem acessá-los. |
| Dispositivos IoT | Alguns equipamentos precisavam de atualização de firmware. | Manter o firmware atualizado e separar dispositivos como alto-falantes inteligentes em uma rede de convidados. |
| Projetos com auxílio de IA | Foram relatados dezenas de problemas, incluindo credenciais de API expostas e uma configuração que poderia permitir envio não autorizado de e-mails. | Revisar segredos, permissões e código antes da implantação. |
| Máquina Linux | Uma chave criptográfica encontrada permitiu login sem senha. | Auditar chaves armazenadas e remover acessos que não sejam necessários. |
Nenhum desses achados autoriza concluir que toda impressora, todo aparelho Wiim ou qualquer dispositivo IoT tenha o mesmo problema. O valor do teste está em mostrar como uma auditoria ampla pode encontrar pontos esquecidos em lugares diferentes — e não em transformar um caso específico em diagnóstico universal.
Por que permissões e isolamento importam
Um agente de IA acessa a internet ou outros sistemas apenas quando recebe ferramentas, permissões e caminhos de rede para isso — ou quando os controles de isolamento falham. Portanto, “agente de IA” não significa automaticamente acesso irrestrito.
A diferença prática está no limite imposto à tarefa. Uma auditoria defensiva delimitada deve trabalhar com autorização explícita, ambiente contido, credenciais separadas e ações que possam ser interrompidas. Um agente com permissões amplas, por outro lado, pode encadear descoberta, uso de credenciais e novas tentativas sem que cada passo tenha sido especificado pelo operador.
É aí que a autonomia muda o risco. O modelo não precisa receber uma lista completa de comandos para perseguir um objetivo; basta que disponha de ferramentas e margem de ação suficientes. Quanto maior a permissão, maior precisa ser o controle sobre o que o agente pode alcançar e fazer.
As lições para a defesa
As medidas derivadas do experimento são simples, mas não triviais:
- Atualize o firmware de dispositivos conectados que dependam de manutenção do fabricante.
- Proteja a impressora, especialmente as funções de administração e o acesso à fila de impressão.
- Separe dispositivos IoT, como alto-falantes inteligentes, em uma rede de convidados ou em outro segmento com permissões limitadas.
- Revise credenciais expostas, incluindo chaves criptográficas e tokens de API armazenados em máquinas ou projetos.
- Faça uma revisão do código produzido com auxílio de IA antes de colocá-lo em uso, com atenção a permissões e envio de mensagens.
- Limite as ferramentas do agente ao que a tarefa exige e mantenha uma forma clara de interromper sua execução.
Essa lista é uma consequência prática do caso, não um padrão completo de segurança doméstica. Ainda assim, ela aponta para uma mudança de foco: não basta perguntar se um dispositivo está conectado. É preciso perguntar o que ele expõe, quem pode controlá-lo e o que acontece quando um agente passa a investigar a rede de forma sistemática.
Por que a defesa pode precisar de capacidades semelhantes
A discussão não termina na ameaça. Devon, CEO da Abliteration AI, questionou como impedir que atores mal-intencionados usem agentes implantados por empresas de infraestrutura crítica. A preocupação acompanha um argumento: se agentes capazes se espalharem, defensores também precisarão de ferramentas para encontrar falhas antes que alguém as explore.
O pesquisador de cibersegurança e direito Shaanan Cohney, da Tufts University, resumiu a assimetria em uma comparação direta: “Os atacantes costumam adotar novidades cedo. Para proteger um castelo, é preciso garantir que não haja buracos nem tijolos soltos em lugar algum. Para invadi-lo, basta encontrar um único tijolo solto.” (Tradução do original.)
Aleksander Mądry, professor do MIT e profissional da OpenAI, defendeu que as pessoas precisam ter acesso a essas capacidades e que haverá espaço para ferramentas independentes e de código aberto na segurança. (Tradução do original.)
O teste de Will Knight não prova que uma rede doméstica esteja condenada a ser invadida por IA. Ele mostra algo mais útil: quando um agente recebe ferramentas, credenciais e liberdade suficientes, problemas pequenos podem ser encadeados em uma investigação que vai além da instrução inicial. A consequência prática é clara: autorização, isolamento e revisão contínua deixam de ser detalhes de configuração e passam a ser a própria barreira entre uma auditoria defensiva e um acesso que ninguém pretendia conceder.
