instellectMCP-autorisatie bepaalt of een client een beschermde server mag gebruiken. Bij HTTP-gebaseerde verbindingen beschrijft de MCP-specificatie een OAuth-gebaseerde aanpak. Daarna blijft controle nodig op de concrete tool, gegevens en bevoegdheden van de aanvrager.
Maak de vertrouwensrelaties zichtbaar
Teken de client, MCP-server, autorisatieserver en achterliggende API. Noteer voor elke verbinding welk token of welke identiteit gebruikt wordt. De toegang tot de MCP-server en de toegang tot het bronsysteem zijn afzonderlijke relaties. Een server kan technisch een broncredential bezitten zonder dat iedere ingelogde gebruiker alle mogelijkheden daarvan mag benutten.
Valideer meer dan de aanwezigheid van een token
Controleer volgens het gekozen autorisatiemodel onder meer de geldigheid, uitgever, doelgroep en benodigde bevoegdheden. Een token voor een andere service mag niet alleen vanwege een geldige handtekening worden geaccepteerd. Stuur inkomende tokens niet blind door naar downstream-diensten. Gebruik de actuele documentatie van de gebruikte client, server en identityprovider om het exacte protocol te implementeren.
Test dezelfde actie met verschillende rechten
Maak testidentiteiten die bewust verschillen in toegestane klanten of tools. Probeer met beide een normale aanvraag en daarna een verboden object. Controleer ook verlopen en ingetrokken toegang. Een scope zoals “read” vertelt nog niet welke records gelezen mogen worden. Werk die objectgrens uit in datarechten voor agents.
Een compacte negatieve testset voor je MCP-server
Dit fictieve testontwerp gebruikt twee administraties, Noord en Zuid, en één gebruiker met alleen leesrechten in Noord. Maak aparte testrecords aan. Een geldig token voor de juiste MCP-server mag het toegestane record in Noord lezen. Hetzelfde token mag geen record in Zuid lezen en geen record in Noord wijzigen. Een administratienummer in een toolargument is invoer, geen bewijs van bevoegdheid.
Herhaal de leesactie met een verlopen token en met een token dat voor een andere ontvanger is uitgegeven. Beide verzoeken moeten vóór brongebruik worden geweigerd. Test daarna hetzelfde directe serveradres buiten het portaal. De toegangsgrens moet daar nog steeds gelden. Registreer per geval de identiteit, aangevraagde actie, beleidsbeslissing en het waargenomen broneffect, zonder volledige tokens of gevoelige recordinhoud in het log te bewaren.
Test ingetrokken rechten en herhaalde opdrachten
Trek het leesrecht in Noord in en voer het verzoek opnieuw uit binnen de actualisatietermijn die je zelf hebt vastgelegd. Controleer niet alleen de foutmelding: ook caches, gevonden fragmenten en eerdere context mogen geen verboden gegevens opnieuw aanbieden. Zet naast ieder testgeval de verwachte uitkomst, eigenaar en bewijsplaats. Een geslaagde OAuth-login bewijst alleen dat een aanmeldroute werkt, niet dat deze objectcontroles kloppen.
De Exact Online MCP-verdieping helpt de stap naar administraties en bronacties uit te werken. Combineer de autorisatietests met MCP-servertests voor ongeldige invoer en bronfouten. Herhaalde schrijfopdrachten vragen daarnaast een eigen ontwerp voor idempotentie; toegang verlenen voorkomt op zichzelf geen dubbel effect. Deze testset is een startpunt en moet worden aangepast aan jouw client, transport, bron en risicoprofiel.
Drie afzonderlijke autorisatievragen
| Laag | Controle | Voorbeeld van weigering |
|---|---|---|
| Servertoegang | Token hoort bij deze server | Geldig token met verkeerde doelgroep |
| Toolbevoegdheid | Identiteit mag deze actie gebruiken | Leesrol vraagt een wijziging |
| Objecttoegang | Record valt binnen toegestane scope | Klantrecord van een ander team |
Een portal toont een CRM-tool
Een medewerker ziet de CRM-server in een portal en logt in. Bij een concrete toolcall vraagt de agent per ongeluk om een dossier buiten het toegewezen team. De MCP-server of het bronsysteem weigert die handeling. De zichtbaarheid van de server in de catalogus verandert de dossiergrens niet. In de audittrail blijft onderscheid tussen login en geweigerde objecttoegang zichtbaar.
Neem mee naar je team.
- Documenteer de identiteit op beide zijden van de MCP-server.
- Test verkeerde doelgroep, verlopen toegang en verboden objecten.
- Bewaar geen bearer tokens in modelcontext of algemene logs.
Met ruimte voor je besluit, eigenaar en testbewijs. Geen e-mailadres nodig.
Bronnen & verantwoording
Technische achtergrond bij dit onderwerp. De keuzetabel, checklist en fictieve voorbeelden zijn een eigen redactionele uitwerking van Instellect. De beschreven patronen zijn geen overzicht van reeds beschikbare productfuncties.
Geraadpleegd op 11 oktober 2026. Een correctie doorgeven? Mail Instellect.