Een AI-worker moet een projectserver controleren of een goedgekeurde actie starten. Daarvoor zijn passende hulpmiddelen en rechten nodig. Een bestand met alle API-tokens en privésleutels voor SSH in de projectmap maakt dat gemakkelijk, maar vergroot de mogelijke gevolgen van een fout of gemanipuleerde invoer.
Een gecontroleerde MCP-tussenlaag kan het toegestane handelingsbereik gericht vastleggen. De agent vraagt een omschreven actie aan; de server controleert identiteit, project en bevoegdheid. Waar het proces dat toelaat, gebruikt een beperkte backenddienst de benodigde inloggegevens zonder ze aan het model terug te geven.
MCP biedt hulpmiddelen, geen automatisch veilige rechten
Het Model Context Protocol beschrijft hoe clients hulpmiddelen en andere mogelijkheden van een server gebruiken. De toepassing moet betrouwbaar bepalen of een gebruiker een bepaalde actie op een concreet object mag uitvoeren. Een aangemelde client is niet automatisch voor elk project of hulpmiddel bevoegd.
Voor beveiligde HTTP-verbindingen beschrijft MCP een autorisatieproces op basis van OAuth. De huidige specificatie onderscheidt dat van lokale STDIO-verbindingen. Passende beveiliging hangt af van het werkelijke transport. Een willekeurige sleutel in een URL-parameter of één gedeeld permanent token is niet gelijkwaardig aan gedifferentieerd rechtenbeheer.
Een concreet voorbeeld: project A blijft project A
Een worker krijgt de taak de status van een afgesproken dienst in project A op te vragen. Een daarvoor bedoeld hulpmiddel accepteert een gecontroleerde objectidentificatie en levert alleen het benodigde resultaat. Het biedt geen vrij te gebruiken shell of algemene export van alle geheimen.
Elke aanroep wordt op de server getoetst aan gebruiker, project, hulpmiddel en actie. Ook een door de client gewijzigde projectidentificatie mag geen toegang tot project B opleveren. Doelen worden uit goedgekeurde koppelingen bepaald; een willekeurig door het model aangeleverd adres vormt geen toereikende opdracht. Tenantgrenzen horen bij die controle.
Tokens voor de juiste ontvanger controleren
Bij een beveiligde HTTP-MCP-server moet een toegangstoken voor de bedoelde ontvanger zijn uitgegeven en daar worden gecontroleerd. Audience, toegestane reikwijdte en geldigheid horen bij elkaar. Een korte levensduur beperkt het tijdvenster van een gestolen token; ze vervangt geen objectcontrole op de server of intrekkingsprocedure.
De MCP-beveiligingsdocumentatie verbiedt ongecontroleerd doorgeven van tokens: een server mag tokens voor andere bronnen niet als eigen bevoegdheidsbewijs accepteren en ongewijzigd aan achterliggende API’s doorgeven. De aanmelding van de MCP-client en de bevoegdheid bij een doelsysteem zijn aparte vertrouwensrelaties. Een onduidelijke overgang kan een bevoorrechte tussenpersoon voor andermans doelen laten gebruiken; dit heet het confused deputy-probleem.
Geheimen in de bedoelde backend gebruiken
Een beheerde geheimenbackend kan inloggegevens naar verantwoordelijkheid en doel beschikbaar stellen. De uitvoerende dienst krijgt alleen de noodzakelijke rechten. De beheerinterface regelt goedkeuringen, koppelingen en intrekking; ze wordt geen algemeen leesbare wachtwoordcatalogus voor alle aangesloten workers.
Een beperkt hulpmiddel kan bijvoorbeeld een statuswaarde lezen of een uitdrukkelijk toegestane beheeractie uitvoeren en een opgeschoond resultaat teruggeven. Ruwe gegevens uit de geheimenbackend mogen niet terloops in hulpmiddeluitvoer, foutmeldingen, traces of prompts belanden. Moet een concrete client technisch een geheim ontvangen, dan wordt die openbaarmaking expliciet beoordeeld en beperkt in omvang, duur en ontvanger. Een algemene garantie dat geen geheimen worden gedeeld zou dan onjuist zijn.
| Controlepunt | Gewenste grens | Concrete test |
|---|---|---|
| Gebruiker en project | Elke actie blijft binnen de toegestane projectomvang. | Projectidentificatie wijzigen: onbevoegde toegang weigeren. |
| Hulpmiddel en parameters | Alleen bedoelde acties en doelen zijn bereikbaar. | Een vrij doeladres of de identificatie van een ander object afwijzen. |
| Token en backend | Ontvanger en autorisatieroute zijn eenduidig. | Onjuiste audience, verval en intrekking testen. |
| Geheimen en resultaten | Alleen noodzakelijke resultaten verlaten de backend. | Uitvoer, fouten en logs op ruwe waarden controleren. |
| Goedkeuring en beheer | Wijzigingen met grote gevolgen zijn specifiek goedgekeurd. | Doelbinding, levensduur, limieten en uitvalroute testen. |
Externe inhoud mag geen toestemming geven
Een ticket, website of repository kan tekst bevatten die de agent tot andere acties probeert te bewegen. Ook beschrijvingen en resultaten van hulpmiddelen kunnen gemanipuleerd zijn. Die inhoud is gegevens, geen bevoegdheidsbewijs. Een prompt als “gebruik alleen project A” helpt de taak te omschrijven, maar vervangt geen technisch afgedwongen projectgrens.
Gericht beperkte hulpmiddelen, gecontroleerde parameters, afgebakende doelsystemen en onafhankelijke rechtencontrole verminderen de gevolgen van promptinjectie. Extra goedkeuringen hangen af van de actie: een statusvraag vraagt een ander proces dan een wijziging met grote gevolgen. De goedkeuring wordt gekoppeld aan het concrete doel en de bedoelde wijziging.
Logging en intrekking meenemen
Voor navolgbaar beheer worden gebruikers- of dienstidentiteit, project, hulpmiddel, beslissing, tijdstip en resultaat vastgelegd. Geheime waarden blijven buiten beeld. Bewaartermijnen, logtoegang en benodigde detaillering worden voor de omgeving afgesproken. Eén succeslog vervangt geen controle van wat er werkelijk bij het doel is gebeurd.
Aanroep- en tijdslimieten en een beperkte backendomvang verminderen verder de gevolgen van onverwachte aanroepen. Bij intrekking worden nieuwe aanroepen, al uitgegeven toegangsgegevens en lopende acties apart bekeken. Uitval van de MCP- of geheimendienst vraagt een omschreven fout- en herstelroute.
Begin met een kleine pilot
Een geschikte pilot begint met één project en enkele hulpmiddelen die alleen lezen. Getest worden toegestane en verboden objectidentificaties, ontbrekende rechten, verlopen toegangsgegevens, gemanipuleerde resultaten en backenduitval. Pas daarna worden duidelijk beperkte schrijfacties beoordeeld. De omvang volgt uit risico en bestaand beheer.
DAXS ondersteunt architectuur, integratie en een controleerbare omvang van hulpmiddelen. De themapagina over MCP en interfaces, het artikel over beheerde SSH-toegang en het overzicht van AI-beveiliging verdiepen de samenhang. U kunt een projectgebonden AI-integratie bespreken.
Veelgestelde vragen
Kan een MCP-server alle inloggegevens voor het model verbergen?
Met passend ontworpen serveracties kan het model alleen het opgeschoonde resultaat ontvangen. Of dat voor elke benodigde handeling mogelijk is, moet worden gecontroleerd. Technische overdracht van een geheim aan de client verandert de risicobeoordeling.
Biedt een lang geheim token voldoende bescherming?
Nee. Ook ontvanger, reikwijdte, geldigheid, gebruikers- en projectkoppeling en de concrete actie worden gecontroleerd. Eén breed bevoegd token biedt die scheiding niet vanzelf.
Hoe begint een pilot met meerdere projecten?
Eerst worden toegestane acties voor één project vastgelegd en getest. Een tweede project wordt daarna ook met uitdrukkelijk verboden kruisverwijzingen getest. Pas daadwerkelijk afgedwongen scheiding biedt de basis voor verdere taken.
Bronnen: MCP: autorisatie, versie 28.07.2026 (externe link) · MCP: vertrouwensgrenzen en token passthrough (externe link) · OWASP: autorisatie per aanroep en object (externe link) · OWASP: geheimen beheren (externe link) · OWASP: promptinjectie beperken (externe link)
Concrete functies en beheeromvang worden voor de betreffende omgeving afgesproken.
