Een MCP-server beoordelen voordat uw AI-agent tools krijgt

Behandel een MCP-server als code van derden die handelt met uw inloggegevens, en beoordeel die voordat de agent hem kan aanroepen. De onderstaande controles zijn gebaseerd op de MCP-autorisatiespecificatie (revisie 2025-06-18) en de MCP security best practices (revisie 2025-11-25). De revisies verschillen van elkaar, dus raadpleeg de actuele specificatie voordat u op een eis vertrouwt.

Autorisatie is optioneel, controleer dus of die aanwezig is

Servers op een HTTP-transport horen de autorisatiespecificatie te volgen. Servers op STDIO doen dat niet en halen hun inloggegevens uit de omgeving. Maak voor een lokale STDIO-server een lijst van de omgevingsvariabelen die uw clientconfiguratie aan het proces doorgeeft en vraag u bij elke variabele af of die nodig is.

Stuur bij een HTTP-server een niet-geauthenticeerd verzoek:

curl -i https://mcp.example.com/mcp

U hoort een 401 Unauthorized terug te krijgen, met een WWW-Authenticate-header die de URL van de resource metadata bevat. Haal dat document op en controleer of authorization_servers er met minstens één item in staat. Antwoordt de server in plaats daarvan met data, dan stopt u hier.

Controleer daarna de punten die de specificatie als verplicht aanmerkt:

• De client stuurt bij elk HTTP-verzoek Authorization: Bearer <access-token> mee, en het token staat nooit in de query string van de URI.
• Endpoints van de autorisatieserver gebruiken HTTPS, en redirect-URI's zijn localhost of HTTPS.
• De autorisatieserver vergelijkt redirect-URI's exact met vooraf geregistreerde waarden.
• Clients implementeren PKCE.

Clients horen ook de state-parameter te verifiëren, en autorisatieservers horen kortlevende access tokens uit te geven.

Token audience en scope

De client moet de resource-parameter (RFC 8707) meesturen in zowel autorisatie- als tokenverzoeken, en de server moet valideren dat elk token specifiek voor hem is uitgegeven. Anders werken tokens die voor andere diensten zijn uitgegeven ook tegen deze server.

Token passthrough is erger: de server accepteert een token dat niet voor hem is uitgegeven en stuurt het ongewijzigd door naar downstream-systemen. Maatregelen zoals rate limiting en monitoring kunnen afhangen van de token audience, en downstream-logs kunnen verzoeken aan de verkeerde identiteit toeschrijven, wat onderzoek bemoeilijkt.

Test de audience binding door met een geregistreerde client een token voor een andere resource aan te vragen bij de token_endpoint uit de metadata van de autorisatieserver. Speel dat token af tegen de MCP-server:

curl -i -H "Authorization: Bearer $OTHER_TOKEN" https://mcp.example.com/mcp

Verwacht een 401. Een geldig token zonder de benodigde rechten hoort een 403 te krijgen. Geeft de autorisatieserver zo'n token niet uit, vraag de leverancier dan hoe de MCP-server de audience controleert.

Vraag ook waar de server tokens opslaat. Bij public clients moeten refresh tokens worden geroteerd, en tokens die op de server worden gecachet of gelogd zijn een doelwit voor diefstal.

Proxyservers en consent

Als de MCP-server met één statische client-ID als voorportaal voor een API van een derde fungeert, lees dan het onderdeel over confused deputy in de best practices. De aanval vereist een statische client-ID, dynamic client registration, een consent-cookie van de autorisatieserver van de derde partij en geen consent per client bij de proxy. Het laatste punt kunt u zelf verhelpen: de proxy hoort per gebruiker een register van goedgekeurde client_id-waarden bij te houden en op zijn eigen consentpagina de clientnaam, scopes en redirect-URI te tonen. Die pagina moet iframing blokkeren met frame-ancestors of X-Frame-Options: DENY.

Zet de tools op een allowlist en beperk ze daarna

Vraag de server om zijn lijst met tools en vergelijk die met wat de taak nodig heeft. Alles wat extra is, valt in termen van OWASP LLM06:2025 onder excessive functionality. Verwijder het, of voorkom dat de agent het kan aanroepen.

Bewaar de lijst als baseline en vergelijk die na elke serverupdate, zodat een tool die in een update is toegevoegd wordt beoordeeld voordat de agent hem kan aanroepen. Controleer daarna elke resterende tool:

• Is de tool open-ended, zoals "voer een shell-commando uit" of "haal een URL op"? Vervang hem door een smalle tool. Het voorbeeld van OWASP is een tool om bestanden te schrijven in plaats van shelltoegang.
• Welke identiteit gebruikt de tool downstream? Een tool die data leest, hoort alleen met SELECT te verbinden, niet met UPDATE, INSERT en DELETE.
• Handelt de tool namens één gebruiker? Dan hoort hij via OAuth te authenticeren met de minimale scope, niet via een generiek geprivilegieerd account.

Dwing de beperkingen af in het downstream-systeem. OWASP noemt dit complete mediation: vertrouw er niet op dat het model beslist of een actie is toegestaan.

Menselijke goedkeuring voor schrijfacties

Hallucinaties en prompt injection zijn veelvoorkomende aanleidingen voor schadelijke acties, dus acties met grote impact vragen om een mens in de keten. OWASP beschrijft een mailassistent die binnenkomende berichten samenvat. Een geïnjecteerde e-mail misleidt de assistent om de inbox te doorzoeken op gevoelige informatie en die door te sturen naar de aanvaller.

Een extensie met alleen leesrechten, een OAuth-scope met alleen leesrechten of handmatige controle van elke opgestelde e-mail vóór verzending had die aanval elk afzonderlijk kunnen stoppen. Combineer ze waar dat kan.

Alles wat verwijdert, verstuurt of publiceert hoort op de goedkeuringslijst. Leg de goedkeuring vast in de extensie of in het downstream-systeem. Logging en rate limiting voorkomen excessive agency niet, maar maken ongewenste acties wel makkelijker op te merken.

Als de client server-side draait

Tijdens OAuth discovery haalt de client URL's op die de server aanlevert, waaronder resource_metadata, authorization_servers en token_endpoint. Een kwaadaardige server kan deze laten wijzen naar interne adressen of naar het cloud metadata-endpoint op 169.254.169.254.

Eis HTTPS in productie, blokkeer private en gereserveerde adresbereiken en valideer redirect-doelen of schakel automatische redirects uit. Schrijf IP-validatie niet zelf, want trucs met octale, hexadecimale en IPv4-mapped IPv6-notatie misleiden zelfgeschreven parsers. Overweeg een egress proxy zoals Smokescreen.

Test het daarna. Zet een vijandige testserver op die een 401 teruggeeft waarvan de WWW-Authenticate-header een resource_metadata-URL bevat die naar http://169.254.169.254/ wijst, en herhaal de test met een URL die doorverwijst naar een intern adres. De client hoort beide te weigeren, en een listener op het interne doel mag geen verzoek zien.

Waar u kunt beginnen

1. Maak een lijst van elke MCP-server die uw agents gebruiken, met transport en beheerder. Verwijder elke server die u niet kunt verantwoorden.
2. Voer curl -i uit tegen elke HTTP-server en bevestig de 401 met een WWW-Authenticate-header. Speel daarna een token af dat voor een andere resource is uitgegeven.
3. Beoordeel bij proxyservers met een statische client-ID de consent-flow: register per client, inhoud van de consentpagina en bescherming tegen framing.
4. Leg per server een baseline van de toollijst vast, beperk die tot wat de taak vereist, geef elke tool de identiteit met de minste rechten en eis menselijke goedkeuring voor schrijf- en verwijdertools.
5. Voer bij server-side clients de SSRF-test uit met een vijandige testserver.
6. Herhaal stap 2 tot en met 5 telkens wanneer een server een update krijgt, een tool toevoegt of zijn scopes wijzigt.

Voor een externe beoordeling kunt u terecht bij onze adviesdienst. Onze penetratietestdienst kan de token- en consentcontroles uitvoeren op uw opzet.