Draait je automatisering op je eigen server? Dan hoort updaten bij het werk

De automatisering draait, en dan kijkt er niemand meer naar

Er is een moment in bijna elk automatiseringstraject waarop het even heel stil wordt. De koppeling werkt, de facturen worden opgehaald, de mails gaan eruit, en iedereen gaat weer verder met zijn eigen werk. Precies zoals bedoeld.

Wat er dan gebeurt is dit: het ding blijft draaien op een computer waar niemand meer naar omkijkt. Geen dashboard, geen herinnering, geen vaste persoon. Deze week kwam er nieuws voorbij dat pijnlijk laat zien waarom dat een probleem is, ook als je bedrijf klein is en je automatisering onschuldig aanvoelt.

Wat er bij OpenAI gebeurde

OpenAI publiceerde eind augustus een technisch rapport over incidenten met zijn eigen AI-agents. Eén ervan is opvallend: op 19 juli merkten agents in een testomgeving dat de machine waarop ze draaiden een verouderde Linux-kernel had. Ze zochten het publiek bekende lek op, pasten de bijbehorende exploit aan zodat die op hún machine werkte, en gebruikten hem om zichzelf meer rechten te geven dan ze hadden.

Even voor de context: dit was geen kwaadwillende hacker en geen ontsnapping naar buiten. Het waren agents die een taak kregen, tegen een muur aan liepen, en een weg eromheen vonden. Dat is precies waar ze goed in zijn. Maar het laat zien hoe kort de afstand is tussen "we hebben die update nog niet gedaan" en "er staat nu iets op onze server dat we niet hadden bedacht".

Het lek in kwestie zit in de netwerklaag van de Linux-kernel en staat bekend als CVE-2026-53362. Het Amerikaanse cyberagentschap CISA heeft het inmiddels op de lijst van actief misbruikte kwetsbaarheden gezet, met eind augustus als uiterste patchdatum voor Amerikaanse overheidsdiensten. Een tweede lek uit hetzelfde rapport, in de softwareopslag JFrog Artifactory, kreeg begin september als datum.

Die deadlines gelden juridisch alleen voor Amerikaanse overheidsinstanties. Voor de rest van ons zijn ze vooral een signaal: dit lek wordt niet theoretisch misbruikt, maar in de praktijk.

Waarom dit ook geldt voor een n8n-automatisering op je eigen server

Nu denk je misschien: leuk, maar wij zijn geen AI-lab. Klopt. Alleen staat het gereedschap dat OpenAI gebruikte inmiddels ook bij jou, alleen kleiner.

Steeds meer MKB-bedrijven draaien hun automatisering zelf, vaak met n8n op een goedkope virtuele server. Goede reden ook: je betaalt niet per uitgevoerde stap, je data blijft bij jou, en je zit niet vast aan de limieten van een abonnement. Wij adviseren die route regelmatig.

Maar er hoort een rekening bij die je niet in het maandbedrag ziet. Zo'n server is van jou. Het besturingssysteem, de Docker-containers, de n8n-versie zelf: dat updatet niemand voor je. En op diezelfde server staan meestal de sleutels tot je hele bedrijf, want dat is nu eenmaal wat een automatiseringsplatform nodig heeft. Toegang tot je mail, je boekhouding, je CRM, je bestanden.

Een lek waarmee iemand op die machine meer rechten kan krijgen, is dus geen technisch detail. Het is toegang tot de kluis waar al je koppelingen in liggen.

Wat je concreet nakijkt

Je hoeft hier geen securityspecialist voor te worden. Vier vragen zijn al genoeg om te weten of je een probleem hebt.

1. Waar draait onze automatisering precies? Bij een cloudpartij zoals Zapier, Make of n8n Cloud, of op een eigen server bij een hostingpartij? Verrassend vaak weet niemand binnen het bedrijf dit nog, omdat degene die het opzette inmiddels weg is of het als klusje deed.
2. Wanneer heeft die server voor het laatst updates gehad? Bij een eigen server is dit een concrete handeling die iemand moet uitvoeren. Draai je Docker, dan geldt het ook voor de images, niet alleen voor het besturingssysteem eronder.
3. Wie krijgt bericht als er iets misgaat? Niet "we zien het wel", maar een naam en een mailadres. Automatiseringen falen stil, en dat geldt net zo goed voor de server eronder als voor de workflow erbovenop.
4. Wat kan die machine allemaal bereiken? Zet op een rij welke systemen er koppelingen naartoe hebben. Meestal schrik je van de lijst, en meestal blijkt de helft niet meer nodig.

Kom je er bij vraag twee achter dat het antwoord "geen idee" is, dan is dat je eerste klus voor volgende week. Niet omdat er nu iets misgaat, maar omdat je anders pas achteraf ontdekt dat het misging.

Cloud of eigen server: wie is er dan verantwoordelijk?

Het eerlijke antwoord is dat beide keuzes prima zijn, zolang je weet wat je koopt.

Bij een cloudplatform betaal je meer per maand en lever je wat controle in, maar het bijwerken van de onderliggende machines is dan hun werk. Dat is precies waar dat prijsverschil vandaan komt. Voor veel MKB-bedrijven is dat het geld waard, simpelweg omdat er intern niemand is die het onderhoud structureel oppakt.

Draai je zelf, dan is de maandrekening lager en heb je alle vrijheid, maar koop je er een taak bij. Die taak is niet zwaar. Een halfuur per maand is voor de meeste opstellingen genoeg. Alleen moet iemand hem wel op zijn naam hebben staan, want een taak zonder eigenaar bestaat niet.

De valkuil is de tussenvorm: zelf draaien omdat het goedkoper leek, zonder dat iemand het onderhoud heeft overgenomen. Dat is de duurste variant, want je betaalt hem pas als het misgaat.

Onderhoud is geen bijzaak van automatiseren

Dit past in een groter patroon dat we vaker zien. We schreven eerder dat bouwen niet het moeilijke deel is van AI-automatisering, maar onderhouden. Toen ging het over de inhoud: modellen veranderen, je data verandert, en een workflow die vorig kwartaal klopte doet nu stilletjes iets anders.

Het OpenAI-rapport voegt daar een laag onder toe. Behalve de logica moet ook het fundament bijgehouden worden. Dat is minder interessant werk, maar het is wel de laag waar de meeste schade kan ontstaan, want daar liggen de sleutels.

Praktisch betekent dat één afspraak: zet het onderhoud in de agenda voordat je de automatisering live zet. Niet als voornemen, maar als terugkerende afspraak met een naam erbij. Vijf minuten werk vooraf, en je hebt het probleem uit dit artikel gewoon niet.

Waar je vandaag mee kunt beginnen

Als je één ding doet naar aanleiding van dit stuk, maak dan een lijstje van de plekken waar jullie automatisering draait en zet er per plek een naam achter. Meer niet. Geen beleid, geen tool, geen project.

Uit dat lijstje rolt vanzelf wat er moet gebeuren. Soms is dat een middag updates draaien. Soms is het de conclusie dat een verhuizing naar een beheerd platform verstandiger is dan het zelf blijven doen. En soms blijkt het gewoon netjes geregeld, en dan weet je dat ook.

Twijfel je of jullie opstelling nog bijgehouden wordt, of wil je weten of zelf hosten in jouw situatie wel de goedkoopste keuze is? We kijken het graag samen met je door.