Gevoelige velden in WebMCP: maskeren is niet hetzelfde als uitsluiten

Door E. Clein · Laatst bijgewerkt 23 september 2026 · 3 min lezen

Je laat een agent een formulier invullen en vervangt in het antwoord een identificatienummer door kruisjes. Dat oogt zorgvuldig. Maar als de agent dat nummer eerst als argument heeft verstuurd, was de volledige waarde al onderdeel van zijn werk. Bepaal daarom vóór registratie welke gegevens de agent helemaal niet nodig heeft.

Een concrete implementatie, nog geen standaardregel

Op 23 september 2026 voegde auto-webmcp in revisie 91cac38, aangeduid als versie 0.5.0, verwerking van gevoelige formuliervelden toe. Deze bibliotheek maakt tools van formulieren. De maker opende dezelfde ochtend WebMCP-issue #316 over herkenning en overdracht van gevoelige invoer. Dat voorstel staat open; er is geen nieuwe WebMCP-regel aangenomen.

De interessante les zit in de verschillende behandelingen van een veld. In de schema-analyzer worden velden met de classificatie block overgeslagen bij het opbouwen van het schema. Velden met redact blijven daarin staan. Een afzonderlijke filterfunctie beperkt teruggegeven veldwaarden en maskeert waarden die daarvoor zijn aangewezen.

Drie keuzes met verschillende gevolgen

De ontwerpnotitie benoemt die grens zelf: regels bepalen wat deze bibliotheek aanlevert, maar houden geen agent tegen die de pagina via DOM of screenshots leest. Ook hangt automatische herkenning af van kenmerken zoals veldnaam, label en autocomplete. Een onbekende benaming kan dus een aparte instelling of controle vereisen.

Neem de termen bovendien niet over als browsergarantie. data-webmcp-sensitive en requires_user zijn hier bibliotheekconventies, geen algemeen WebMCP-contract. Een andere integratie kan ze anders behandelen of negeren.

Controleer meer dan het nette eindantwoord

Een fictief voorbeeld: een klant wil de status van een aanvraag bekijken. Je systeem kan die aanvraag al vinden via de bestaande sessie en een aanvraag-ID. Ons ontwerpadvies: vraag de agent dan niet alsnog om een volledig identificatienummer. Laat de tool uitsluitend de noodzakelijke zoekgegevens accepteren en geef alleen de benodigde status terug.

Moet de gebruiker toch een gevoelige waarde invoeren, ontwerp dan een aparte gebruikersstap. Laat de agent uitleggen waar de gebruiker verdergaat, zonder die waarde in de chat uit te vragen. Controleer daarna de bevestigde processtatus, niet de ingevulde geheime waarde. Dit is eigen ontwerpadvies, geen garantie dat iedere agentclient zo’n overdracht ondersteunt.

Loop vervolgens de hele gegevensroute na: toolschema en eventuele standaardwaarden, argumenten, normaal resultaat, foutmeldingen en logging. Maskeren in één resultaatveld wist een eerdere modelinvoer niet. Een annotatie als consequentialHint informeert de client; zij dwingt deze gegevensgrens niet af.

Maak de grens toetsbaar met fictieve waarden

De meegeleverde tests controleren onder meer dat bepaalde velden ontbreken in het schema, dat vooraf ingevulde geheimen niet in het gestructureerde resultaat staan en dat allow een blokkeerregel kan overrulen. Ze gebruiken een nagebootste WebMCP-interface. We hebben code en testdefinities gelezen, niet de tests of een echte agentproef uitgevoerd; dit is geen volledige beveiligingsaudit of productaanbeveling.

Ons testadvies: gebruik herkenbare, volledig fictieve testwaarden. Controleer een leeg én vooraf ingevuld formulier, laat een validatiefout ontstaan en bekijk daarna schema, aanroep, antwoord en logs. Herhaal met een afwijkend veldlabel en met eventuele uitzonderingsinstellingen. Test ook de gewone browserroute als je agent die kan gebruiken.

De beslisregel voor je team: als de agent een waarde niet nodig heeft, ontwerp dan dat hij haar niet ontvangt. Als je alleen het antwoord maskeert, noem dat ook zo. Voor bredere maatregelen verwijzen we naar onze WebMCP-beveiligingsgids.