MCP-audit voor kleine teams: een checklist op vier assen

Vorige week dinsdag installeerde een COO waar we mee werken een MCP-server op haar MacBook. Ze had een nuttige thread gelezen over Notion-pagina's rechtstreeks in haar assistent trekken, plakte de JSON-config over, en binnen vier minuten hield een connector waar ze nog nooit van had gehoord een read-write OAuth-token vast voor de complete kennisbank van het bedrijf, plus een offline-refresh scope die elke wachtwoordwissel overleeft.

Zij is niet het probleem. Ze deed precies wat de documentatie haar opdroeg. Het probleem is dat haar laptop, op een doodgewone werkdag, nu een node is in een agentic systeem dat niemand binnen haar bedrijf kan benoemen, auditen of intrekken. Vermenigvuldig dat met haar ops-team, haar finance-team en twee mede-oprichters, en je hebt de MCP-estate van een doorsnee bedrijf onder de €30M in 2026.

Na de recente golf supply chain-incidenten in agent-tooling (browser-extensies die stilletjes credentials wegsluisden uit lokale vault-apps, en marketplace-connectors die unsigned binaries onder permissive namen uitleveren) schreven we een checklist op vier assen die elke retainerklant nu twee keer per jaar samen met ons doorloopt. Niks exotisch. Het is het soort vraag dat je verzekeringsmakelaar zou stellen als je verzekeringsmakelaar wist wat MCP was.

Waarom een MCP-audit naast je bestaande posture valt

Heb je al een SOC2-rapport, een MDM, of zelfs maar een Notion-pagina met de titel "Security", dan dekt geen daarvan dit af. MDM ziet wat er op OS-niveau is geïnstalleerd; het ziet geen JSON-bestand dat leeft in ~/Library/Application Support/Claude/claude_desktop_config.json. SSO dekt SaaS-logins; het ziet geen persoonlijke OAuth-token die een connector er ondertussen bijbakte. SOC2 dekt de apps die op het moment van audit in scope zaten, en dat is per definitie niet het nieuwe agentic oppervlak.

De Model Context Protocol-specificatie is bewust permissive opgezet. Hij definieert hoe hosts, clients en servers met elkaar praten; trust, identity en provenance laat de spec bewust over aan de host. Dat is de juiste ontwerpkeuze. Het betekent ook dat het inperken van de blast radius volledig bij jou ligt.

As 1: provenance van tool-calls

Voor elke MCP-server die op een device van het bedrijf staat, moet je binnen vijf minuten drie vragen kunnen beantwoorden.

• Welke persoon (of agent die namens een persoon handelt) triggerde de laatste honderd tool-calls?
• Welke fysieke binary, in welke versie, beantwoordt die calls?
• Waar belanden die calls en hun argumenten in rust, en hoe lang blijven ze daar staan?

"Mijn laptop" is geen antwoord op vraag twee. "De laatste versie van mcp-server-postgres" ook niet. Je wil een vastgepinde versie, een checksum en een pad. We scoren dit van 0 tot 3.

0  no logging; cannot enumerate installed servers
1  can list servers; no per-call log
2  per-call log, local only, no integrity guarantees
3  per-call log, signed binary, shipped to a SIEM or append-only file

Bedrijven onder de €30M scoren bij de eerste audit bijna altijd 0 of 1. Naar 2 komen kost ongeveer een dag per laptopvloot, vooral omdat je mensen moet uitleggen dat command: "uvx" in een config-bestand geen naam is. Het is een downloader.

As 2: rate limits per tool

De eerste keer dat een agent-loop misgaat, gaat het hard. We hebben een verkeerd geconfigureerde planning-loop ongeveer 14.000 calls naar een Linear-workspace zien sturen in één middag, het maandquotum van de klant zien opbranden tegen 11 uur 's ochtends, en de hele support-inbox op een workflow zien CC'en die intern had moeten blijven. De agent deed precies wat hem werd opgedragen. De tool-laag had geen rem.

Je audit moet voor elke connector vragen:

• Wat is de rate limit van de upstream API op de OAuth-token die in gebruik is?
• Wat is de cap per tool per minuut binnen de MCP-server zelf?
• Wat gebeurt er bij de cap? Hard fail, soft degrade of silent drop?

De meeste kant-en-klare MCP-servers antwoorden op die drie vragen met "ja, nee, geen idee". Dat is een fix die je in één middag uitrolt door de server in een dunne proxy te wikkelen die calls per tool per minuut telt en boven de drempel een gestructureerde error teruggeeft. Past die proxy er niet in, schrijf de drempel dan op zijn minst in de system prompt en bouw een harde call-teller in de host. De agent gaat geen limiet handhaven die hij niet kan zien.

Eén ding dat hardop gezegd moet worden: de rate limit van een OAuth-token is een eigenschap van de token, niet van de tool. Eén agent-loop die een rate-limited endpoint raakt, hongert elke andere workflow uit die diezelfde token gebruikt, inclusief de workflows waar op dat moment een mens actief op zit te wachten.

As 3: blast radius van OAuth-scopes

Dit is de as die verzekeraars de stuipen op het lijf jaagt, en terecht. De meeste MCP-servers vragen om veel bredere OAuth-scopes dan de feitelijke tools blootleggen. Een connector waarmee een agent agenda-items kan lezen, heeft regelmatig een token met calendar.events.write, contacts.readonly en de offline refresh-scope. Het meeste daarvan gaat de agent nooit gebruiken. Een gelekte token wel.

De audit loopt de OAuth-grants van elke actieve connector langs en beantwoordt drie vragen.

1. Welke scopes heeft de token?
2. Welke daarvan worden daadwerkelijk gebruikt door tools die de host blootlegt?
3. Wat is de worst-case actie die een aanvaller met die token kan ondernemen als hij hem nu zou extraheren?

Voor de onderliggende mechanica is de scope-guidance van de OAuth working group kort en de moeite waard om eens per jaar opnieuw te lezen. De regel die voor onze wereld telt: scope down bij de identity provider, niet bij de client. Vraagt de connector een bredere scope dan je wil verlenen, dan is dat een situatie waarin je de connector forkt, geen situatie waarin "we zullen voorzichtig zijn".

0  full-account scope, offline refresh, no expiry
1  broad scope, refresh, 90-day expiry
2  narrow scope, refresh, 30-day expiry
3  narrow scope, no refresh, short-lived (24h), per-user

De populairste connectors zitten vandaag op 0 of 1. Naar 2 brengen is voor elke half-fatsoenlijke backend developer een klus van één avond. Naar 3 is lastiger, omdat sommige upstream identity providers short-lived per-user tokens niet schoon ondersteunen, maar het loont voor alles wat geld, klantdata of productie-infrastructuur raakt.

As 4: de install-whitelist voor niet-engineers

Dit is de as waar de COO zich daadwerkelijk druk om maakt. Ze gaat jouw threat model niet lezen. Ze wil weten: mag ik dit ding uit deze Twitter-thread installeren, ja of nee?

Ons standaardantwoord is een korte lijst die op een indexkaart past. We geven de niet-engineer een green list (alles wat signed, reproducible en read-only is tegen een account dat het bedrijf al beheert) en een harde regel: niets buiten de green list zonder een Slack-bericht naar ops. We hebben geleerd om niet te leunen op "vraag het eerst als je twijfelt". De mensen die je het liefst eerst wil laten vragen, zijn precies de mensen die het zekerst weten dat ze niets hoeven te vragen.

De green list bij een typische klant ziet er zo uit:

• Read-only filesystem servers die wijzen naar één specifieke folder onder ~/work/
• Read-only document-connectors (Notion, Drive, Confluence) gekoppeld aan een non-admin account
• Calendar read voor de eigen agenda van de gebruiker, geen write
• Alles wat gesigned is door de host-vendor en in het officiële connector-register staat

De amber list (toegestaan met een paragraaf onderbouwing en een review na 30 dagen):

• Alles wat e-mail aanmaakt of verstuurt
• Alles wat payment-credentials in handen heeft, ook read-only Stripe
• Alles wat een productie-database leest, zelfs read-only
• Alles wat lokaal shell-commando's uitvoert, punt

De red list (nee, einde verhaal):

• Connectors geïnstalleerd vanuit een paste-from-thread waar niemand in het bedrijf van heeft gehoord
• Alles wat de breedste scope-variant van een OAuth-grant aanvraagt
• Alles waarvan de binary leeft op een persoonlijk GitHub-account met onder de 200 sterren en zonder signing

Het doel van de indexkaart is niet om compleet te zijn. Het doel is om een niet-technische COO een seconde-beslissing te geven. Groen? Installeren. Amber of rood? Even ops aanstoten.

De score, en wat je ermee doet

We tellen de vier assen op tot een score van 12. Alles onder de 6 is een remediation van deze week: minimaal versies pinnen, minimaal één scope versmallen, en de indexkaart uitrollen. Een score van 6 tot 9 is een plan voor dit kwartaal met een echte review aan het einde. Boven de 9 is zeldzaam, en betekent meestal dat we een klant auditen die al eens een token kwijtraakte en die les zonder ons heeft geleerd.

De score is niet het punt. Het punt is dat de volgende keer dat de COO op een dinsdagmiddag iets installeert, het antwoord op "wat is er net veranderd aan ons aanvalsoppervlak" minuten kost, geen weken.

Toen we deze lente de MCP-estate bij een Rotterdamse logistieke klant auditten, was de verrassing niet de slechte scopes. De verrassing was dat twee connectors maanden eerder waren geïnstalleerd door een ex-medewerker, nog steeds actief waren en refresh-tokens vasthielden die de offboarding schoon hadden overleefd. We losten het op door de host in een dunne governor te wikkelen die elke token intrekt zonder actuele SSO-gekoppelde eigenaar, en die stap zit nu vast in onze standaard AI-agents-setup. De hele fix kostte minder dan een dag.

Wil je vandaag beginnen, maak dan een lijst van elke MCP-server die op elke laptop in je bedrijf staat. Alleen de lijst. Geen scopes, geen versies, geen rate limits. Kost het je meer dan dertig minuten om die lijst rond te krijgen, dan weet je al wat je eerste as-1-score gaat worden.