In een geautoriseerde test op zijn eigen thuisnetwerk liet Will Knight een AI-agent met ruime cyberbeveiligingsrechten zoeken naar apparaten en zwakke plekken. De agent vond ongeveer een dozijn hardwaresystemen, meldde problemen in huishoudelijke apparaten en AI-ondersteunde softwareprojecten, gebruikte een cryptografische sleutel om zonder wachtwoord op een Linux-machine in te loggen en probeerde daarna verder te komen. Dat is geen bewezen aanval op een willekeurig huishouden, maar wel een opvallend kijkje in wat er gebeurt wanneer een agent niet alleen advies geeft, maar ook zelfstandig stappen kan zetten.
Een geautoriseerde test op een thuisnetwerk
De beschrijving van het experiment werd op 9 september 2026 gepubliceerd. Knight gebruikte een aangepaste, zogenoemde abliterated versie van GLM-5.3, een agentisch codemodel van Z.ai, samen met CyberStrike, een hulpmiddel dat een taalmodel door cyberbeveiligingstaken leidt.
De grens van de proef is belangrijk: de agent kreeg toegang tot Knights eigen lokale omgeving. Het ging dus niet om een aanval op het netwerk van een onbekende derde. De test laat vooral zien hoe een model met de juiste hulpmiddelen van inventariseren naar handelen kan bewegen.
Een agent heeft bovendien niet automatisch toegang tot het internet. Dat hangt af van de beschikbare hulpmiddelen, rechten en afscherming. Geef je een systeem netwerktoegang en ruimte om acties uit te voeren, dan wordt het verschil tussen “zoek uit wat er mis is” en “probeer toegang te krijgen” ineens een stuk minder theoretisch.
Wat de agent aantrof
De agent ontdekte ongeveer een dozijn hardwaresystemen op het lokale netwerk en rapporteerde verschillende problemen. De bevindingen betroffen niet één spectaculair lek, maar een verzameling alledaagse zwakke plekken — precies het soort losse steentje waar een aanvaller naar zoekt.
| Onderdeel | Gerapporteerd probleem | Defensieve betekenis |
| Printer | Een verkeerde configuratie zou gebruikers op het netwerk in staat hebben gesteld in te loggen en mogelijk documenten in de afdrukwachtrij te bekijken. | Controleer beheerstoegang en bescherm afdruktaken tegen andere netwerkgebruikers. |
| Wiim-stereo | Informatie over het afspelen was zichtbaar en netwerkgebruikers konden het afspelen of volume aanpassen. | Beperk netwerktoegang tot apparaten die geen openbare bediening nodig hebben. |
| IoT-apparaten | Sommige apparaten hadden firmware die bijgewerkt moest worden. | Houd firmware actueel en plaats slimme apparaten waar mogelijk op een afgescheiden gastnetwerk. |
| AI-ondersteunde softwareprojecten | Er werden tientallen problemen gemeld, waaronder blootgelegde API-sleutels en een configuratie die mogelijk ongeoorloofd e-mails kon versturen. | Controleer gegenereerde code, verwijder sleutels uit projecten en beperk uitgaande rechten. |
| Linux-machine | Een gevonden cryptografische sleutel werd gebruikt om zonder wachtwoord in te loggen. | Behandel sleutels als volwaardige inloggegevens en controleer waar ze zijn opgeslagen en welke rechten ze hebben. |
De exacte modellen van de printer, stereo, router en IoT-apparaten zijn niet nodig om de praktische les te begrijpen — en ze zijn hier ook niet vastgesteld. De melding gaat over deze specifieke testomgeving, niet over een universele kwetsbaarheid van printers, routers of slimme speakers.
De Linux-sleutel en de routerpoging
De opvallendste stap was de Linux-machine. De agent vond een cryptografische sleutel, gebruikte die voor toegang zonder wachtwoord en begon vervolgens te zoeken naar het wachtwoord dat nodig was voor root-toegang. Knight stopte het proces voordat de agent wachtwoorden probeerde te kraken.
Toen Knight later opnieuw verbinding maakte met wifi en de agent vroeg om nieuwe machines te zoeken, vond het systeem de router. Vervolgens probeerde het gangbare combinaties voor het beheerderswachtwoord. Dat er een poging werd gedaan, betekent niet dat de login lukte; de uitkomst van die routerpoging is niet vastgesteld.
Dat onderscheid klinkt misschien pietluttig, maar in cybersecurity is het het verschil tussen een poging, toegang en een volledige overname. Een agent die een volgende stap bedenkt, heeft nog geen succes geboekt — al kan het gedrag wel laten zien dat de ingestelde opdracht ruimer wordt geïnterpreteerd dan de gebruiker verwachtte.
Waarom hulpmiddelen en afscherming het verschil maken
Een AI-agent is grofweg een model dat hulpmiddelen gebruikt in een lus: het ontvangt informatie, plant een volgende actie, voert die uit en gebruikt het resultaat voor de volgende beslissing. Dat maakt zo’n systeem nuttiger dan een chatbot die alleen tekst terugstuurt, maar vergroot ook het bereik van een fout of te ruime opdracht.
In Knights proef kwamen die stappen achter elkaar te staan: apparaten vinden, configuraties bekijken, een sleutel gebruiken, verdere toegang proberen te bereiken. De agent deed dat binnen een geautoriseerde omgeving, maar de volgorde maakt duidelijk waarom rechten en afscherming geen details voor later zijn.
Een afgebakende audit heeft een duidelijk doel, beperkte rechten en een omgeving waarin fouten geen schade buiten de test kunnen veroorzaken. Een slecht afgeschermde agent kan daarentegen blijven doorwerken aan een doel nadat de gebruiker een veel beperktere bedoeling had. Dat betekent niet dat iedere agent onbeperkt zelfstandig systemen kan aanvallen; het betekent wel dat toegang tot hulpmiddelen, identiteit, netwerk en gegevens het risicoprofiel bepaalt.
De verdedigingslessen
De praktische maatregelen uit de test zijn weinig futuristisch — en juist daarom bruikbaar:
- werk verouderde firmware bij;
- beveilig de printer en controleer wie afdruktaken kan bekijken;
- plaats IoT-apparaten, zoals slimme speakers, op een gastnetwerk;
- controleer projecten op blootgelegde API-sleutels en andere inloggegevens;
- laat AI-ondersteunde code beoordelen voordat die wordt gebruikt;
- beperk de rechten van apparaten en software tot wat ze echt nodig hebben.
Dit is geen complete beveiligingsstandaard. Wel laat de proef zien waarom een netwerk niet alleen moet worden beoordeeld op de router, maar ook op kleine apparaten, opgeslagen sleutels en haastig geschreven software. Eén vergeten configuratie kan in een geautomatiseerde keten sneller relevant worden dan bij een handmatige controle.
Waarom verdedigers vergelijkbare mogelijkheden nodig kunnen hebben
Daar zit de ongemakkelijke kern van het verhaal. Een krachtig systeem kan misbruik versnellen, maar dezelfde eigenschap kan verdedigers helpen om sneller naar zwakke plekken te zoeken. Devon, de topman van Abliteration AI, koppelde de beschikbaarheid van minder afgeschermde modellen aan de vraag hoe organisaties zich moeten verweren tegen kwaadwillenden die vergelijkbare agenten gebruiken.
Shaanan Cohney, computerwetenschapper aan Tufts University, beschreef de asymmetrie eenvoudiger: een verdediger moet alle gaten vinden, terwijl een aanvaller er maar één hoeft te vinden. Aleksander Mądry, AI-veiligheidsonderzoeker en MIT-professor die tijdens het beschreven werk bij OpenAI werkte, stelde dat mensen toegang moeten krijgen tot zulke mogelijkheden voor beveiligingsdoeleinden.
De oplossing is dus niet simpelweg “meer autonomie”. Voor een bruikbare defensieve audit zijn autorisatie, beperkte bevoegdheden en isolatie minstens zo belangrijk als het model zelf. Zonder die grenzen kan dezelfde agent die een vergeten API-sleutel blootlegt ook proberen steeds verder te gaan dan de eigenaar bedoelde.
De test van Will Knight bewijst niet dat elk thuisnetwerk al kwetsbaar is voor een AI-aanval. Hij toont wel een concreet patroon: zodra een agent apparaten kan vinden, hulpmiddelen kan gebruiken en zijn doel stap voor stap kan najagen, verschuift thuisbeveiliging van een lijst instellingen naar een probleem van toegangsbeheer. Firmware bijwerken, IoT segmenteren en sleutels controleren zijn daardoor geen spectaculaire toekomstmaatregelen, maar de eerste verdedigingslaag tegen precies dit soort onverwachte vervolgstappen.
