Een protocol is geen productbeleid
MCP maakt het mogelijk dat een host resources, prompts en tools van servers ontdekt en gebruikt. Die uniformiteit is waardevol, maar kan teams het valse gevoel geven dat een verbonden tool daarmee veilig is. Het protocol weet niet welk klantdossier gevoelig is, welke betaling goedkeuring vereist of welke actie binnen jouw organisatie onomkeerbaar is.
Teken daarom eerst de trust boundaries. Identificeer host, client, server, downstream systemen en menselijke eigenaar. Leg vast waar credentials leven, welke data een grens passeert en welk component de uiteindelijke beleidsbeslissing neemt. De modeloutput zelf mag nooit de enige autorisatiegrond zijn.
Bronnen [1]
Maak tools kleiner dan je eerste API-ontwerp
Een generieke tool als ‘update_customer’ geeft een model veel interpretatieruimte en maakt fouten lastig te evalueren. Smalle tools—bijvoorbeeld ‘propose_address_change’ en een apart, menselijk goedgekeurd ‘apply_address_change’—leggen intentie en risico explicieter vast. Gebruik strikte schema’s, server-side validatie en een begrensde output die geen onnodige data terugstuurt.
Ontwerp mutaties idempotent waar mogelijk en voeg een taak- of request-id toe. Zo veroorzaakt een retry niet stilletjes een tweede betaling, e-mail of record. Laat foutmeldingen onderscheid maken tussen tijdelijk, ongeldig, verboden en goedkeuring vereist; een agent kan alleen verantwoord herstellen wanneer het contract de werkelijkheid goed beschrijft.
- Scheid lezen, voorstellen en uitvoeren.
- Valideer rechten opnieuw aan de serverkant.
- Beperk resultaten tot de data die de taak nodig heeft.
- Gebruik expliciete time-outs, paginering en hoeveelheidslimieten.
- Definieer compensatie of rollback voor iedere materiële mutatie.
Toestemming moet op het juiste moment verschijnen
Een algemene toestemming bij onboarding is te breed voor een agent die later een specifieke, impactvolle actie kiest. Vraag goedkeuring zo dicht mogelijk bij de mutatie en toon wat er verandert, waarom, op basis van welke gegevens en hoe het kan worden teruggedraaid. Voorkom approval fatigue door laag-risico reads via beleid toe te staan en alleen betekenisvolle grenzen interactief te maken.
Bescherm ook tegen prompt injection uit toolresultaten en resources. Behandel opgehaalde inhoud als data, niet als instructie. Houd systeembeleid buiten onbeheerde content, markeer herkomst en laat een server nooit meer bevoegdheid erven dan de gebruiker voor de taak heeft.
Bronnen [2]
Test trajecten, niet alleen losse antwoorden
Een MCP-integratie kan op iedere afzonderlijke call slagen en toch als systeem falen: de verkeerde tool wordt gekozen, dezelfde actie wordt herhaald, een fout wordt verkeerd geïnterpreteerd of de agent stopt zonder resultaat. Bouw evaluaties rond representatieve taaktrajecten met normale gevallen, grensgevallen, vijandige inhoud en uitvallende afhankelijkheden.
Koppel productie-incidenten terug aan dezelfde suite. Meet taakvoltooiing, ongeautoriseerde pogingen, onnodige calls, menselijke correctie, herstelduur en kosten per succesvol resultaat. Daarmee wordt ‘agentisch’ geen stijlwoord, maar een systeem waarvan autonomie stap voor stap verdiend en teruggenomen kan worden.