MCP-integraties beveiligen na de spec van 28 juli 2026: wat u nu per toolcall moet aantonen

U moet per MCP-toolcall kunnen aantonen welke agent deze aanriep, met welke autorisatie, op welke data, en wat het resultaat was — vastgelegd in een cryptografisch gesigneerde audittrail die u zelf beheert.

De aanleiding is een analyse van 7 september 2026 van MCP-integraties en de beveiligingseisen die de spec van 28 juli 2026 stelt, welke stelt dat de specificatie sessierisico's op protocolniveau wegneemt maar consent, autorisatie en toolsafety niet zelf afdwingt. Een concreet voorbeeld: een MCP-server die gevoelige data exposeert kan technisch veilig communiceren, maar zonder gateway-beleid en audittrail weet u niet wie wat aanriep of waarom. In onze inschatting betekent dit dat beveiliging van MCP-integraties niet bij het protocol ligt, maar bij de gateway, het beleid en de verificatie die u zelf inricht.

Welke risico's neemt de spec weg en welke blijven over?

De MCP-specificatie 2026-07-28 verwijdert sessie-ID's en scherpt OAuth aan, wat sessie-hijacking en spontane serverprompts lastiger maakt. Tegelijk erkent de spec dat het protocol zelf consent, autorisatie en dataminimalisatie niet afdwingt. Dit betekent dat oude risico's op protocolniveau verdwijnen, maar nieuwe aanvalsvlakken ontstaan in de HTTP-laag, endpoint-configuratie en gateway-logica. Analyses wijzen op protocol-confusion, desync-aanvallen en datalekken via verkeerd geconfigureerde headers als concrete bedreigingen.

De risico's die u zelf moet beheersen zijn:

• Ongebonden agentidentiteiten — agents die tools aanroepen zonder eigen, traceerbare identiteit.
• Ontbrekende autorisatiecontrole per toolcall — geen beleid dat bepaalt welke agent welke tool mag aanroepen.
• Geen audittrail — geen herleidbare, cryptografisch gesigneerde registratie van wie wat deed en wanneer.
• Verkeerde HTTP-headers en endpoint-configuratie — MCP-headers als MCP-Method en MCP-Name die niet worden geverifieerd.
• Gedeelde sleutels in plaats van gebonden identiteiten — meerdere agents die dezelfde credentials gebruiken.

Hoe ontwerpt u een gateway die elke toolcall onderschept?

Een MCP Security Gateway moet alle verkeer tussen agents en toolservers centraliseren. Dit geeft u één plek waar u identiteit, autorisatie en logging kunt afdwingen. De gateway onderschept elke toolcall, verifieert de agentidentiteit, controleert het beleid, logt het verzoek en het resultaat, en stuurt alleen toe wat het beleid toestaat. Dit sluit aan bij bredere aandacht voor identiteits- en toegangsbeheer voor AI-agents: een agent die tools aanroept, heeft een eigen, gebonden identiteit nodig, niet een gedeelde sleutel.

Dit is dezelfde beweging als bij AI-governance in het algemeen: beleid dat pas werkt als het tijdens uitvoering wordt afgedwongen, niet alleen op papier staat. Een gateway zonder beleid is een logboek zonder regels.

Welke concrete controles moet u per workflow kunnen tonen?

Naar onze inschatting moet u per MCP-integratie het volgende kunnen demonstreren:

1. Documenteer welke agent welke MCP-server aanroept — vastleggen van agentidentiteit, serveradres en het doel van de integratie.
2. Definieer beleid-als-code per toolcall — expliciete regels die bepalen welke agent welke tool mag aanroepen, met welke parameters.
3. Bind agentidentiteiten aan sessies en autorisaties — geen gedeelde sleutels, maar per-agent credentials die aan een specifieke autorisatie zijn gekoppeld.
4. Onderteken en bewaar auditlogs cryptografisch — elke toolcall, het resultaat en de autorisatiebeslissing moet onweerlegbaar vastliggen.
5. Verifieer MCP-headers en endpoint-configuratie — controleer dat MCP-Method, MCP-Name en andere headers correct zijn en niet worden vervalst.
6. Stel contractueel vast wie auditrechten heeft — bepaal wie uw logs mag inzien en onder welke voorwaarden.

Wat kan tooling voor u doen en wat niet?

Verificatielagen kunnen helpen als zichtlaag: zij maken verificatiestappen, correcties en bronnen zichtbaar voor inspectie per workflow. Sommige tools vervangen gevoelige waarden door synthetische equivalenten voordat AI-verwerking plaatsvindt, zodat niets wordt doorgestuurd als een privacycontrole mislukt. Dit ondersteunt controle en naleving, maar garandeert geen correctheid van de agentbeslissing zelf. Het professionele eindoordeel — of een toolcall werkelijk nodig is, of het resultaat verstandig is — blijft bij u. Tooling kan transparantie en handhaving bieden; zij kan uw verantwoordelijkheid niet overnemen.