AI-agent audit trail: wat MCP en A2A niet loggen

Een MCP-tool-aanroep laat vrijwel niets achter. Het protocol vertelt uw agent wat een tool doet en hoe die aan te roepen is. Het legt niet vast wie de aanroep deed, namens wie, met welke argumenten, en wat er terugkwam. Dat gat is geen slordigheid van één implementatie. Een analyse van juni 2026 vond het in vijf agentprotocollen tegelijk, en de MCP-revisie van juli maakte het ene halve antwoord nog zwakker.

Wat kan een MCP- of A2A-aanroep achteraf eigenlijk bewijzen?

Een agent vroeg een MCP-server om een klantgegeven op te zoeken. Zes weken later wil iemand weten welke klantdossiers die agent in augustus heeft geraakt, namens wie, en of het antwoord dat hij gaf ook echt uit het dossier kwam dat hij zegt te hebben gelezen.

Waarschijnlijk haalt u dat uit uw applicatielogging, als iemand eraan gedacht heeft die te schrijven. Uit het protocol haalt u het niet. MCP definieert Tools, Resources en Prompts, plus een request/response-vorm om ze aan te roepen. A2A definieert Agent Cards, taakdelegatie en berichtuitwisseling. Geen van beide definieert een gebeurtenisrecord, een integriteitsgarantie of een replay-formaat.

Wat vond de gapanalyse van juni 2026?

In Governance Gaps in Agent Interoperability Protocols, op 30 juni 2026 op arXiv verschenen, toetsten Richard Kang en Yudho Diponegoro vijf protocollen aan zes governance-dimensies: lidmaatschap, deliberatie, stemming, behoud van afwijkende standpunten, escalatie naar een mens, en audit/replay. Elke combinatie kreeg Supported, Partial of Absent, beoordeeld op wat de specificatie vastlegt en niet op wat erbovenop te bouwen valt.

De matrix is somber en opvallend consistent. Stemming, behoud van afwijkende standpunten en menselijke escalatie zijn Absent in alle vijf onderzochte protocollen (MCP, A2A, ACP, ANP en ERC-8004). MCP scoorde 1 van de 12 mogelijke punten, A2A evenveel, ACP en ERC-8004 elk twee, ANP nul. De punten die er staan zijn halve punten: Agent Cards benaderen lidmaatschap, het propose/accept/reject-patroon van ACP benadert deliberatie, en ERC-8004 erft zijn onvervalsbaarheid van de blockchain.

Het ene punt van MCP stond bij audit, en de auteurs waren precies over de reden. Zij rekenden twee dingen mee: sessies die verbindingsstatus vasthouden, en tool-aanroepen die gestructureerde antwoorden met metadata opleveren. Daarna volgt de zin die telt: er is geen onvervalsbaar gebeurtenislogboek, geen hashketen en geen replay-garantie, dus audit hangt af van de implementatie en niet van de specificatie.

De conclusie van het paper hoort thuis in elke architectuurreview. Governance is geen ontbrekende functie bínnen deze protocollen. Het is een ontbrekende laag erboven.

Waarom maakte de spec van 28 juli 2026 het auditverhaal van MCP zwakker?

Dit is het deel dat het paper niet kon zien.

Het paper beoordeelde MCP tegen het schema van november 2025. Op 28 juli 2026 verscheen de specificatie 2026-07-28, en die schrapte de initialize/initialized-handshake en de Mcp-Session-Id-header volledig. Elk verzoek draagt nu zijn eigen protocolversie, clientidentiteit en capabilities in _meta, zodat elke aanroep achter een gewone round-robin load balancer op elke serverinstantie kan landen. Maar één van de twee constructies waarop MCP zijn enige governancepunt kreeg, bestaat niet meer.

In dezelfde release zijn Roots, Sampling en Logging verouderd verklaard via SEP-2577. Ze blijven minstens twaalf maanden werken, en nieuwe implementaties horen ze niet meer te gebruiken. De logging-voorziening van MCP was nooit een auditlog. Het is een diagnosekanaal zonder integriteitsgarantie en zonder bewaartermijn. Maar het was wel het enige logvormige primitief in het protocol, en er loopt nu een klok van twaalf maanden op.

Tussen het paper en de inkt van de specificatie ging de auditdekking van MCP dus van dun naar dunner. Die vier weken pleiten ervoor om een analyse op specificatieniveau te herlezen tegen de volgende release in plaats van haar te citeren als een vaststaand feit.

Dezelfde release legde het werk ergens anders neer. Mcp-Method en Mcp-Name werden verplicht op Streamable HTTP via SEP-2243, waardoor een component aan de rand kan routeren en meten zonder de body te lezen; de migratiemechaniek behandelden we apart. Ook de autorisatie is aangescherpt: issuervalidatie volgens RFC 9207, credentials gebonden aan de issuer die ze uitgaf, en Dynamic Client Registration verouderd verklaard ten gunste van Client ID Metadata Documents.

Behandel die headers als routeringshints en niet als bewijs. Ze komen van de client, een stateless proxy heeft geen schema om ze aan te toetsen, en de spec verplicht een server een verzoek te weigeren waarvan de headers en de body elkaar tegenspreken. Een beslissing aan de rand op basis van headers is een filter; de autorisatie zelf hoort daar waar de body gelezen wordt. De notitie Governance as Infrastructure van de Agentic AI Foundation zelf, enkele dagen na de spec gepubliceerd, maakt hetzelfde punt en gaat verder: de transportwijzigingen zijn governance-primitieven in infrastructuurkleren, en de trace context is voortaan de ruggengraat van de audit.

MCP bouwde dus geen audit trail. Het verplaatste de audit trail naar de infrastructuur, en de organisatie die MCP huisvest vindt dat die daar thuishoort.

Verandert de Agentic AI Foundation hier iets aan?

Uit zichzelf niet.

MCP, goose en AGENTS.md vormden bij de start de kern van de Agentic AI Foundation van de Linux Foundation. agentgateway, de Rust-proxy van Solo.io voor MCP-, A2A-, LLM-, HTTP- en gRPC-verkeer, werd op 4 juni 2026 opgenomen als hosted project. A2A is in augustus 2026 aanvaard als Growth Stage-project, gesteund door meer dan 150 organisaties. Op 14 september volgde MCPA, de eerste MCP-certificering.

Neutraal beheer is goed nieuws als de roadmap van één leverancier u zorgen baart. Het voegt aan geen van beide protocollen een governance-primitief toe. Wat het wél vertelt, is waar het antwoord verwacht wordt: de foundation huisvest nu zowel de protocollen als een gateway, en in die gateway zitten het beleid, de autorisatie en de toegangslogging.

Welk logboek is een Nederlandse mkb-onderneming vandaag echt verplicht?

Hier gaan de meeste leveranciersteksten over MCP-gateways te ver.

De logverplichtingen uit de AI-verordening zijn smaller en later dan de marketing suggereert. Artikel 12 eist dat AI-systemen met een hoog risico gebeurtenissen automatisch kunnen vastleggen gedurende de levensduur van het systeem. Artikel 19 verplicht aanbieders die logs minstens zes maanden te bewaren. Beide gelden alleen voor systemen met een hoog risico, en volgens artikel 113 treden ze in werking op 2 december 2027 voor bijlage III en op 2 augustus 2028 voor bijlage I. Een klantenserviceagent of een interne onderzoeksassistent bij een bedrijf van dertig man is vrijwel zeker geen van beide. Twijfelt u aan welke kant van die streep u staat, dan loopt onze EU AI Act-risicochecker de routes door de bijlagen met u door.

Wat vandaag wél bijt, is de AVG. Verantwoordingsplicht uit artikel 5(2) betekent dat u moet kunnen aantonen dat u zich aan de regels houdt, en aantonen kan niet wat u niet hebt vastgelegd. Een agent die via een MCP-server klantgegevens leest, verricht verwerkingen, en het verwerkingsregister uit artikel 30 moet die beschrijven. De Europese Commissie stelt in de Digital Omnibus voor om de vrijstellingsgrens in artikel 30(5) op te trekken van 250 naar 750 medewerkers, met financiële criteria en een uitzondering voor hoog risico, maar dat is een voorstel dat nog door de wetgever moet en geen basis voor een architectuurkeuze in 2026. De verantwoordingsplicht uit artikel 5(2) verdwijnt hoe dan ook niet.

En dan de valkuil. Legt uw auditlog tool-argumenten en antwoorden vast, en staan daar persoonsgegevens in, dan is dat logboek zélf een verwerking met een eigen grondslag, een eigen bewaartermijn en een eigen toegangsbeheer. Teams grijpen naar "log alles" en maken zo ongemerkt een tweede, slechter beheerde kopie van hun klantenbestand. De fiscale bewaarplicht trekt de andere kant op voor alles wat tot uw administratie hoort. Geen van beide problemen heeft een antwoord in het protocol.

Wat moet er in een auditrecord van een agent staan?

Zeven velden, en één daarvan krijgt u sinds juli gratis van het protocol. Het minimumrecord van de Agentic AI Foundation zelf telt er acht; dit is de versie voor een bedrijf dat nooit een platformteam zal aannemen.

• Wie het vroeg. De mens of het systeem als opdrachtgever, niet het serviceaccount waaronder de agent draait. Dit veld gaat in de praktijk het vaakst mis.
• Welke agent. Identiteit en versie, zodat gewijzigd gedrag aan een uitrol te koppelen is.
• Welke tool, op welke server. Gratis uit Mcp-Method en Mcp-Name bij de gateway, mits u het bij de body verifieert.
• Met welke argumenten. Niet gratis, en het veld met het persoonsgegevensprobleem. Hash of maskeer standaard, en log alleen volledig bij de toolklassen waarvan u besloten hebt dat het nodig is.
• Wat er terugkwam, of minstens een hash daarvan, zodat u later kunt aantonen dat het antwoord bij de bron paste.
• Onder welke autorisatie. Welk token, uitgegeven door welke issuer, met welke scopes. De RFC 9207-validatie en de issuerbinding maken dit vastlegbaar in plaats van giswerk.
• Wanneer, in een volgorde die u kunt afspelen. Een oplopende teller of een hashketen, want tijdstempels uit drie diensten ordenen zichzelf niet.

Loggen op headerniveau levert een gebruiksregistratie op. Argumenten en antwoorden loggen levert een audit trail op. Twee producten, andere kosten, andere juridische blootstelling: kies welke u bouwt vóórdat u iets aanzet.

Wanneer is een gateway het juiste antwoord, en wanneer overkill?

Het enterprisepatroon ligt vast: een gateway beëindigt en bewaakt elke aanroep van agent naar server, en een registry legt vast welke servers bestaan en wie ze mag gebruiken. Amazon, Microsoft, Kong en Solo.io beschrijven allemaal varianten van dezelfde vorm. Voor een organisatie met vijftig MCP-servers klopt dat.

Voor een bedrijf van 20 tot 50 medewerkers met drie servers klopt het meestal nog niet. Onze vuistregel: zet een gateway neer zodra de derde van deze punten waar is, niet de eerste.

1. Meer dan één agent gebruikt dezelfde MCP-server, waardoor logging per agent binnen de agent met zichzelf gaat ruziën.
2. Een tool-aanroep kan geld verplaatsen, iets naar een klant sturen, of schrijven in een bronsysteem.
3. Iemand buiten het bouwteam, een controller, een accountant of de securityvragenlijst van een klant, heeft antwoord nodig over wat de agent gedaan heeft.

Daaronder is gestructureerde logging in uw eigen agent, weggeschreven naar iets dat alleen toevoegt, eerlijk en toereikend. Daarboven bouwt u een gateway na, maar slechter. Bij bedrijven van 250 tot 500 medewerkers zien wij vaker het omgekeerde: een gateway die vroeg is aangeschaft, alleen headers logt, en intern wordt gepresenteerd als een audit trail waarvoor hij nooit is ingericht.

Leg de keuze nu vast. Achteraf reconstrueren wie wat heeft geautoriseerd is het enige wat niet meer lukt, en die vraag komt altijd zes weken te laat. Scoopt u agentwerk en wilt u het logontwerp rond hebben vóór de bouw, dan begint onze AI-agentontwikkeling daarmee, en zijn de kosten van maatwerk daarna beter te beoordelen.

Wat dit betekent als u dit kwartaal op MCP bouwt

Drie dingen, in deze volgorde. Leg de stateless wijzigingen van 28 juli naast wat uw leverancier daadwerkelijk heeft geïmplementeerd, want een server die nog sessie-identifiers uitdeelt, draait de spec van vorig jaar. Bepaal uw zeven velden en waar ze worden weggeschreven voordat de eerste tool live gaat, niet na het eerste incident. En behandel rechten en scoping als hetzelfde ontwerpgesprek, want een logregel van een handeling die niemand had mogen doen is bewijs, geen beheersmaatregel.

De protocollen dichten dit gat waarschijnlijk deels. Het extensiemechanisme van A2A kan nieuwe toestandsmachines uitdrukken, en het paper merkt op dat na ruim zes maanden actief extensie-ecosysteem nul governance-extensies waren voorgesteld. Zolang die er niet is, is de laag van u, en die zin hoort in uw architectuurdocument te staan.

Laatst bijgewerkt op 22 september 2026.

Veelgestelde vragen