Make.com en n8n audit: wat we scoren voor we offreren

Een Nederlands e-commerce MKB belde ons afgelopen maart over een workflow-agent retrofit. Hun operations lead — één persoon, die ook leveranciers en CS-escalaties doet — had een Make.com-account met 67 actieve scenarios en een self-hosted n8n op een Hetzner-bak met nog eens 23 workflows. Sommige scenarios praatten via webhook met n8n. Sommige n8n-workflows schreven terug naar Make. Niemand in het team kon de graph tekenen.

Voor we ook maar een offerte sturen op dit werk, doen we een audit. Geen verkoopfoefje; we hebben er al drie laten lopen. Een engineer is er ongeveer twee dagen mee bezig en het leest als een checklist, want dat is het ook. We scoren drie dingen, in deze volgorde: scenario-versiedrift op de top 40 scenarios, webhook-secret rotatie op de top 25 endpoints, en welke workflows een overstap naar self-hosted n8n zouden overleven zonder de AVG-vereiste execution log om drie uur 's nachts kwijt te raken.

Wat elk van die drie nou eigenlijk inhoudt:

Waarom die hybride überhaupt ontstaat

Make.com is wat een niet-engineer als eerste pakt. De UI is goed, de templates werken, en je kan het overdragen aan iemand op marketing zonder dat er een Slack-kanaal voor tickets bij hoort. n8n komt later in beeld, meestal als het bedrijf tegen een integratie aanloopt die Make niet aankan, of als een finance director vraagt waarom een SaaS-rekening €890 per maand is voor wat in feite Zapier met een ander logo is. Dus installeren ze n8n op één VPS, bouwen de nieuwe workflow daar, en nu zijn er twee automation-platformen die met elkaar praten via HTTP en aannames.

Dat is prima. Wij bouwen nieuwe hybrides ook bewust zo. Het probleem is niet de hybride; het is dat hij twee jaar lang groeit zonder dat iemand bijhoudt wat aan wat gekoppeld zit. Tegen de tijd dat iemand klaar is voor een AI-agent erbovenop — inbox-triage, order-routing, leverancierscommunicatie — heeft de basis acht ongelabelde scenarios die niemand durft te verwijderen want "volgens mij heeft het magazijn die nodig".

De volwassenheidscurve is deprimerend voorspelbaar. Jaar één: marketing pakt Make voor één use-case, meestal leadcapture. Jaar twee: operations erft het en plakt er vijf scenarios bij voor order-routing en CS-triage. Jaar drie: een engineer zet n8n op een vrije VPS om de Make-pricing boven de 10.000 operations te ontwijken. Jaar vier: de founder leest over AI-agents en wil er een bovenop de inbox. Op dat moment heeft de basis 90 ongelabelde flows, vier auteurs die niet meer in dienst zijn, en minstens één webhook die nog naar de ngrok-tunnel van een ex-contractor wijst. Die ngrok is geen grap; we hebben het twee keer gezien.

De audit bestaat om een getal te plakken op die angst.

Scenario-versiedrift, top 40

Make.com houdt een versie bij van elk scenario. Elke edit, save of rollback verhoogt het versienummer. Wat het dashboard je niet laat zien, is welke scenarios afwijken van de versie die een collega het laatst heeft beoordeeld. Na twee jaar in een account met 67 scenarios zie je een handvol op versie 312 staan en andere die nog op 4 hangen.

We trekken de scenario-lijst via de Make API en sorteren op run-count over de laatste 90 dagen. De top 40 op run-count dekt, in onze ervaring, ergens tussen de 92% en 97% van alle executies. Dat is de slice die ertoe doet.

Voor elk van die 40 scoren we:

• Drift-ernst — verschil tussen huidige versionId en de versie in een export die de klant ergens heeft staan (Git, Drive, waar dan ook). Geen baseline-export betekent automatisch de maximale drift-score.
• Auteur-concentratie — hoeveel verschillende users het scenario in de afgelopen 12 maanden hebben bewerkt. Eén auteur met 80 edits is gezonder dan vier auteurs met elk 20.
• Module-mix volatiliteit — nieuwe module-types die zijn toegevoegd zonder bijbehorende notitie in het "Notes"-veld van het scenario.

Een scenario dat op alle drie rood scoort, noemen we een fossiel-in-beweging: hij draait elke dag, drift elke week, en niemand in het team kan uitleggen wat hij doet. Je retrofit geen AI-agent op een fossiel-in-beweging. Je herbouwt eerst de onderliggende workflow, of je sluit hem uit van de scope van de agent.

Het Make API-endpoint dat we aanroepen, voor wie het wil weten:

GET https://eu2.make.com/api/v2/scenarios?teamId=...&pg[limit]=100
Authorization: Token <mk_api_token>

De response geeft je lastEdit, scheduling en een usedPackages-array. De drift-berekening zit niet in de API; het is een git diff tussen de geëxporteerde blueprint-JSON en wat de klant gearchiveerd had. Heeft de klant niets gearchiveerd, dan wordt de audit eerst een baseline-oefening voor we verder gaan.

Webhook-secret rotatie, top 25 endpoints

Dit is het onderdeel dat de meeste audits laat zakken. Met afstand.

Elke Make custom webhook en elke n8n webhook-node heeft een URL. De meeste klanten beveiligen ze met één van drie dingen: een HMAC-signature op de body, een gedeelde bearer-token in een header, of — we hadden gewild dat dit zeldzamer was — niks. Alleen een obscure URL en de hoop dat niemand een subdomain-scan draait.

We pakken de top 25 webhook-endpoints op inkomend volume over 90 dagen. Voor elk scoren we:

• Aanwezigheid van een secret — valideert het endpoint überhaupt? HMAC, bearer, mTLS of niets.
• Rotatie-cadans — wanneer is het secret voor het laatst vervangen? Boven de 18 maanden is rood.
• Opslag-hygiëne — staat het secret als plaintext in een scenario-module, of wordt het opgehaald uit een connection of credential store?
• Blast radius — als dit ene secret zou lekken, hoeveel andere endpoints delen het dan?

In ongeveer tweederde van de audits bevat de top 25 minstens één webhook zonder enige validatie. In een derde zit een webhook-secret ouder dan de jongste medewerker van het bedrijf. Eén keer vonden we een webhook-secret hardcoded in een Make-scenario dat was geforkt, geëxporteerd, opnieuw geïmporteerd en in 2022 in een Slack-DM gedeeld. Dat secret was nog steeds actief.

De fix is niet romantisch. Je roteert, je zet HMAC-verificatie aan beide kanten, en je slaat secrets op in Make-connections of n8n-credentials in plaats van in module-velden. De n8n-documentatie over webhook-authenticatie behandelt de validatiepatronen van begin tot eind.

Wil de klant een AI-agent vóór een van deze webhooks zetten — en dat willen ze bijna altijd, want agents zijn dol op events — dan moet dit onderdeel groen zijn voor we tekenen.

AVG-overlevingskans van de execution log om 03:00

Dit is het onderdeel dat ons twee keer per jaar het sales-gesprek uitgewerkt krijgt, en het is het onderdeel dat we nooit overslaan.

Nederlandse MKB'ers die persoonsgegevens verwerken vallen onder de AVG, de Nederlandse implementatie van de GDPR. Artikel 30 van de GDPR vereist een register van verwerkingsactiviteiten, en artikel 5(2) vereist dat je naleving kunt aantonen. In de praktijk: als de Autoriteit Persoonsgegevens vraagt "laat me de execution log zien van deze geautomatiseerde beslissing op 14 maart om 03:00", moet je die produceren. Niet bij benadering. Produceren.

Make.com cloud bewaart execution logs op basis van je abonnement. Self-hosted n8n bewaart wat je database aanhoudt en wat je prune-instellingen toelaten. De logging-documentatie van n8n beschrijft de retention-controls; de defaults zijn niet AVG-compatibel voor workflows die persoonsgegevens raken.

Voor de derde score van de audit pakken we de top 10 workflows die persoonsgegevens raken (klantmail, naam, orderadres, alles wat herleidbaar is naar een persoon) en stellen we per workflow één vraag: als we Make morgen overzetten naar self-hosted n8n, en de Autoriteit Persoonsgegevens vraagt over zes maanden naar de 03:00-uitvoering van deze workflow, kunnen we die dan produceren?

Het antwoord hangt van vijf dingen af:

• Staat EXECUTIONS_DATA_SAVE_ON_SUCCESS op all (niet op none)?
• Is EXECUTIONS_DATA_PRUNE uitgezet, of is je prune-venster langer dan je AVG-retentieplicht?
• Wordt de Postgres of MySQL onder n8n elke nacht gebackupt, met een geteste restore?
• Worden de secrets en credentials van de workflow versie-bewaakt naast de execution-metadata?
• Logt de workflow genoeg om de beslissing te reconstrueren — de inputs, de gekozen branch, de output — in plaats van alleen "ran OK"?

Drie daarvan zijn configuratie. Twee zijn architectuur. De architectuur-vragen zijn de reden dat sommige workflows de overstap overleven en de meeste niet.

In de e-commerce MKB-audit van maart waren van de 23 self-hosted n8n-workflows er precies drie AVG-overleefbaar om 03:00:

1. De Mollie-betalingsbevestiging-handler, omdat de developer die hem bouwde CTO was geweest bij een fintech en uit gewoonte overlogde.
2. De leveranciers-PO-generator, omdat die zijn eigen audit trail naar een aparte Postgres-tabel schreef die de rest van n8n niet beheerde.
3. De klant-refund-router, omdat dat de enige workflow was met saveExecutionProgress: true in de instellingen, per ongeluk aangezet tijdens een debug-sessie.

Dat was de hele overleefbare oppervlakte. De andere 20 workflows zouden een AP-onderzoek niet doorstaan. Dat schreven we in gewoon Nederlands in het rapport.

Wat we met de score doen

Elke audit eindigt op één pagina met drie getallen en een advies. De getallen zijn op een schaal van 100, gewogen: drift telt 25, webhooks tellen 35, AVG-overleefbaarheid telt 40. We wegen AVG het zwaarst omdat het boeteplafond op €20.000.000 ligt, en omdat het de gate is die bepaalt of je überhaupt veilig een agent boven op de workflow kan zetten.

Boven de 70: we offreren de agent-retrofit, scopen die op de groene workflows, en schrijven de herbouwen voor de rode workflows in een fase-twee SOW.

Tussen de 40 en 70: we offreren eerst twee weken remediatie. De retrofit volgt daarna. Een klant heeft hier nog nooit over geredetwist.

Onder de 40: we adviseren eerst een stack-consolidatie voor er aan AI gewerkt wordt. Meestal betekent dat de Make-scenarios die ertoe doen verhuizen naar n8n, de rest opruimen, en de execution-log laag herbouwen voor er iets anders gebeurt. Ongeveer een derde van de tijd bedankt de klant ons en gaat ergens anders heen. Prima.

Het remediatie-werk zelf is ondankbaar. Blueprints exporteren naar Git, webhook-secrets roteren, ontbrekende log-statements schrijven, overlappende scenarios dedupliceren, n8n's prune-venster afstemmen op een opgeschreven retentiebeleid. We scopen op workflow in plaats van per uur, omdat uurtjes op dit soort opruimwerk altijd uitlopen en de klant een getal verdient waarop hij kan plannen. Een typische remediatie-fase voor een stack rond de 50 kost ongeveer twee weken van één engineer, soms drie als de database-laag een aparte audit trail nodig heeft.

Het kleinste wat je vandaag kunt doen

Open je Make-dashboard. Sorteer de scenarios op aantal executies over de laatste 90 dagen. Kijk naar de top vijf. Vraag jezelf per scenario af: heb ik de blueprint-JSON ergens geëxporteerd? Is het antwoord bij ook maar één van de vijf nee, dan is je drift-score nog geen getal, maar een vraagteken. Exporteer de blueprints vandaag en commit ze in een private Git-repo. Morgen heb je een baseline.

Toen we afgelopen winter de workflow-agent laag bouwden voor een Nederlandse groothandel, liepen we precies hier tegenaan: hun topscenario was in 18 maanden 84 keer bewerkt zonder geëxporteerde baseline, en de agent die we erbovenop legden bleef de drift erven. We hebben het opgelost door elke scenario-blueprint te versiebeheren in Git als onderdeel van ons procesautomatisering-retainer, met een nachtelijke diff-alert zodra er iets bewoog. Drie maanden later was de score van 41 naar 88.