Blog

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

De MCP-spec van 28 juli 2026 haalt sessierisico's weg maar legt beveiliging bij de integrator. Zo ontwerpt u gateway, beleid en audits per toolcall.

· Door

Twee gescheiden groepen serverkasten met daartussen één messing doorgang met een hangslot, en op de voorgrond een opengeslagen register met een gezegeld document.
Na de MCP-spec van 28 juli 2026 loopt al het toolverkeer via één gateway die elke call afdwingt, ondertekent en vastlegt.Beeld: IamVera.ai — originele redactionele illustratie

Sinds de MCP-specificatie 2026-07-28 verdwijnen sessie-ID's en wordt OAuth aangescherpt, maar de spec dwingt consent, autorisatie en toolsafety niet zelf af. U moet MCP-integraties daarom zelf beveiligen met een gateway die elke toolcall onderschept, beleid-als-code, gebonden agentidentiteiten en een herleidbare, cryptografisch gesigneerde audittrail.

Op 28 juli 2026 publiceerde het Model Context Protocol-project de specificatie 2026-07-28, volgens de projectdocumentatie de grootste revisie sinds de lancering. De spec beschrijft expliciete principes voor user consent, dataprivacy en toolsafety, maar zegt er zelf bij dat het protocol deze niet afdwingt. Voor iedereen die MCP inzet in een hoog-trust omgeving betekent dat: de verantwoordelijkheid voor beveiliging verschuift naar de hosts, servers en gateways die u zelf inricht.

Wat verandert er precies door de MCP-specificatie van 28 juli 2026?

De belangrijkste wijzigingen die de specificatie zelf noemt, zijn:

  • een stateless architectuur, waarbij de vaste sessie plaatsmaakt voor handles;
  • het verdwijnen van de Mcp-Session-Id-header en van dynamische clientregistratie;
  • aangescherpte OAuth-autorisatie, met verwijzing naar RFC 9207 en Client ID Metadata Documents;
  • nieuwe MCP-specifieke HTTP-headers en rijkere MCP Apps;
  • een deprecatievenster van twaalf maanden voor oudere versies.

Naar onze inschatting is de kern hiervan dat een reeks oude risico's op protocolniveau wordt weggenomen — sessiehijacking en spontane serverprompts worden lastiger — terwijl de spec tegelijk erkent dat consent, autorisatie en dataminimalisatie een implementatiekeuze blijven. Het protocol biedt de bouwstenen; de sloten zet u er zelf op.

Welke nieuwe beveiligingsrisico's ontstaan op de integratielaag?

Onafhankelijke security-analyses plaatsen deze update in een breder beeld. Akamai beschrijft de nieuwe spec als een enterprise-gerichte, stateless architectuur die oude risico's wegneemt, maar waarschuwt dat rijke UI-apps en asynchrone taken security-grenzen introduceren die volledig door ontwikkelaars moeten worden ontworpen. SecurityWeek wijst specifiek op de nieuwe MCP-headers (zoals MCP-Method en MCP-Name) en op risico's als protocol-confusion en desync-aanvallen, plus datalekken via verkeerd geconfigureerde x-mcp-headers.

De praktische consequentie: wie MCP inbouwt in een gevoelige workflow kan niet volstaan met naar het model kijken. Het aanvalsvlak zit óók in de HTTP-laag, de endpoint-configuratie en de gateway ertussen. Dat sluit aan bij bredere aandacht voor identiteits- en toegangsbeheer voor AI-agents volgens NIST: een agent die tools aanroept, heeft een eigen, gebonden identiteit nodig, niet een gedeelde sleutel.

Hoe richt ik een MCP-security-gateway en beleid-als-code in?

Microsoft publiceerde binnen zijn Agent Governance Toolkit een MCP Security Gateway-spec waarin alle MCP-verkeer tussen agents en toolservers via één gateway loopt. Die gateway biedt volgens de specificatie onder meer:

  • interceptie van toolcalls en scanning van responses;
  • message-signing en sessie-authenticatie;
  • rate-limiting en afdwinging van autorisatie;
  • integratie van een CVE-feed en detectie van schema-drift;
  • audit en metrics van al het verkeer.

Vertaal dit naar concrete ontwerpvragen voor uw eigen architectuur:

  1. Waar in uw omgeving zit de "firewall" voor MCP-verkeer, en loopt echt alle verkeer daardoorheen?
  2. Wie beheert het beleid-als-code dat per toolcall bepaalt wat is toegestaan, onder welke identiteit en delegatie?
  3. Worden calls en responses gesigneerd en gelogd, zodat u ze later kunt reconstrueren?

Dit is dezelfde beweging die wij eerder beschreven bij AI-governance van beleidsdocument naar runtime-handhaving: beleid dat pas werkt als het tijdens uitvoering wordt afgedwongen, niet alleen op papier staat. Meer achtergrond bundelen we in de themahub over AI-security en integratiebeveiliging.

Wat moet ik per MCP-integratie kunnen aantonen voor audits en toezicht?

Dat verifieerbaarheid verder gaat dan een gateway, laat OPAQUE zien. Volgens de aankondiging via PR Newswire breidt OPAQUE het Agent Governance Toolkit uit met een Agent Manifest en Confidential MCP: MCP-servers die in een confidential-computing-runtime draaien, governance-policies in hardware afdwingen en onafhankelijk verifieerbaar bewijs produceren van elke toolcall en agentactie. De boodschap: voor hoog-trust domeinen is het niet genoeg dat een server "veilig" heet — hij moet bewijs leveren van zijn gedrag.

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

  • een inventaris van MCP-servers, tools en agents per workflow;
  • beleid-als-code dat vastlegt welke toolcalls zijn toegestaan, onder welke identiteit en delegatie;
  • een gateway of confidential MCP-laag die alle calls onderschept, tekent, rate-limitet en auditeert;
  • een reconstrueerbare tijdlijn: welke agent riep welke tool aan, met welke parameters en welk resultaat;
  • een expliciete koppeling naar privacy- en compliancetaken, zoals dataminimalisatie en logging.

Die laatste twee punten raken direct aan wat u contractueel moet vastleggen; wij gingen daar eerder op in bij auditrechten en bewijsverplichtingen in AI-contracten.

Een verificatielaag zoals Vera kan hierbij helpen als zichtlaag: het is geen vervanging voor MCP-securitygear en geen taalmodel, maar het kan per workflow verificatiestappen, correcties en bronnen zichtbaar maken voor inspectie. Vera's Semantic Privacy Shield is zo ontworpen dat gevoelige documentwaarden vóór AI-verwerking op EU-infrastructuur worden vervangen door synthetische, sessiegebonden equivalenten, waarbij bij een mislukte privacycontrole niets wordt doorgestuurd. Dat ondersteunt controle, maar garandeert geen correctheid en het professionele eindoordeel blijft bij u.

Bronnen en referenties

  1. The 2026-07-28 SpecificationModel Context Protocol · 2026-07-28
  2. The New MCP Specification: What Security Teams Must Prepare ForAkamai · 2026-06-25
  3. New Enterprise-Ready MCP Specification Brings New Security ChallengesSecurityWeek · 2026-06-26
  4. MCP Security Gateway - Agent Governance ToolkitMicrosoft · 2026-07-22
  5. OPAQUE Extends the Agent Governance Toolkit with Verifiable Identity and Confidential MCPPR Newswire · 2026-06-23

Bronnen: Het artikel steunt op de officiële MCP-specificatie 2026-07-28, security-analyses van Akamai en SecurityWeek, de MCP Security Gateway-spec uit Microsofts Agent Governance Toolkit en OPAQUE's aankondiging via PR Newswire.

← Alle artikelen in dit thema ← Alle artikelen