Wenn Sie Entwickler haben, die AI-Anwendungen ausliefern, haben Sie wahrscheinlich von MCP gehört — dem Model Context Protocol. Möglicherweise haben Sie noch nicht durchdacht, was es für Ihre Sicherheitslage bedeutet.
Dieser Beitrag erklärt MCP in einfacher Sprache, beschreibt die Risiken, die es einführt, und skizziert, wie Governance für Teams aussieht, die es sicher nutzen wollen.
Was MCP ist, in einem Absatz
MCP ist ein offenes Protokoll, das AI-Modellen erlaubt, externe Tools aufzurufen. Anstatt Tool-Integrationen in jede AI-Anwendung fest einzucodieren, stellen Entwickler Fähigkeiten über MCP-Server bereit — standardisierte Endpunkte, die ein kompatibler AI-Client entdecken und aufrufen kann. Ein einzelner MCP-Server könnte Tools bereitstellen, um ein Dateisystem zu lesen, eine Datenbank abzufragen, eine E-Mail zu senden oder eine Drittanbieter-API aufzurufen. Das AI-Modell fragt; der MCP-Server handelt.
Das ist wirklich nützlich. Es macht AI-Anwendungen kompositionsfähiger und einfacher zu bauen. Es erweitert aber auch drastisch die Aktionsfläche, die nun davon geregelt wird, was auch immer das AI-Modell zu tun beschließt.
Warum MCP ein Sicherheitsrisiko einführt
Das Risiko liegt nicht im Protokoll selbst. MCP ist gut spezifiziert und auf entwicklerfreundliche Ergonomie ausgelegt. Das Risiko liegt darin, wie es bereitgestellt wird — und welche Governance, falls überhaupt, zwischen dem Modell und den Tools existiert, die es aufrufen kann.
Drei spezifische Risiken:
1. Ungeregelter Tool-Zugriff
MCP-Server stellen Tools bereit. Ein AI-Client, der sich mit einem MCP-Server verbindet, kann standardmäßig jedes Tool aufrufen, das dieser Server bereitstellt. Wenn der Server 40 Tools bereitstellt — darunter einige, die Datensätze ändern, Nachrichten senden oder auf sensible Daten zugreifen — hat der verbundene AI-Client Zugriff auf alle 40.
Die meisten AI-Deployments regeln nicht, welche Tools eine bestimmte Agenten- oder Nutzersitzung aufrufen darf. Sie stellen den Server bereit, verbinden den Client und gehen davon aus, dass das Modell gutes Urteilsvermögen einsetzt. Gutes Urteilsvermögen ist keine Zugriffskontrollrichtlinie.
Die Governance-Anforderung: Tool-Level-Zugriffskontrolle. Jeder Agent oder jede Sitzung sollte nur die spezifischen Tools aufrufen können, die er benötigt — nicht jedes Tool, das jeder registrierte Server bereitstellt.
2. Langlebiges direktes Client-Vertrauen
Viele MCP-Deployments gewähren Clients langlebiges Vertrauen. Sobald sich ein Client bei einem MCP-Server authentifiziert hat, bleibt er für die Sitzung authentifiziert — und manchmal weit darüber hinaus. Wenn dieser Client kompromittiert wird oder das AI-Modell dazu manipuliert wird, Aufrufe zu tätigen, die es nicht tätigen sollte, bedeutet langlebiges Vertrauen, dass der Wirkungsradius groß ist.
Die sicherere Architektur stellt kurzlebige Sitzungs-Tokens aus, die am Ende der Agenten-Aufgabe ablaufen. Kein langlebiges direktes Vertrauen. Kein dauerhafter Zugriff, der im Nachhinein ausgenutzt werden kann.
Die Governance-Anforderung: Sitzungsgebundene Anmeldedaten. MCP-Zugriff sollte für die Dauer einer Agenten-Aufgabe bereitgestellt werden, nicht für die Lebensdauer einer Verbindung.
3. Kein Audit-Trail für Tool-Calls
Wenn ein Nutzer eine Nachricht an ein AI-Modell sendet, protokollieren Sie vielleicht die Konversation. Wenn das AI-Modell ein MCP-Tool aufruft, werden der Aufruf, seine Argumente und sein Ergebnis oft nicht auf strukturierte, prüfbare Weise protokolliert.
Das ist in der Praxis von Bedeutung. Wenn ein AI-Agent einen Datensatz ändert, eine Nachricht sendet oder sensible Daten über einen MCP-Tool-Call abruft — und Sie kein strukturiertes Protokoll dieser Aktion haben — können Sie während eines Audits nicht rekonstruieren, was passiert ist. Sie können die Frage nicht beantworten: „Worauf hat dieser Agent zugegriffen und wann?"
Die Governance-Anforderung: Strukturierte, trace-verknüpfte Audit-Aufzeichnungen für jeden MCP-Tool-Call — einschließlich des Tool-Namens, des Argument-Fingerprints, des Agenten, der ihn ausgelöst hat, des Sitzungskontexts und ob eine menschliche Freigabe eingeholt wurde.
Wie MCP-Governance in der Praxis aussieht
Für Teams, die MCP-verbundene AI-Anwendungen bereitstellen, hat Governance drei Schichten:
Schicht 1: Server-Registrierung und Tool-Inventar
Jeder MCP-Server, der in Ihrer AI-Umgebung verwendet wird, sollte registriert sein. Diese Registrierung sollte umfassen:
- Welcher MCP-Server für die Nutzung freigegeben ist
- Welche Tools dieser Server bereitstellt
- Welche Agenten oder Rollen welche Tools aufrufen dürfen
Dies ist ein Standardkonzept im Software-Betrieb — Anwendungsregistrierung, Service-Allowlisting, API-Inventar — angewendet auf MCP.
Schicht 2: Sitzungsgebundene Zugriffsbereitstellung
Wenn eine Agenten-Sitzung startet, erhält sie ein geregeltes Anmeldedatum, das Zugriff auf die spezifischen Tools gewährt, die sie für diese Aufgabe benötigt. Wenn die Sitzung endet, läuft das Anmeldedatum ab. Kein dauerhafter Zugriff. Kein langlebiges Client-Vertrauen.
Dies ist der Unterschied zwischen einem Gebäude-Ausweis für einen Dienstleister, der an bestimmten Tagen für die Dauer des Projekts funktioniert, und einer dauerhaften Zugangskarte.
Schicht 3: Freigabe vor der Ausführung bei risikoreichen Aufrufen
Manche Tool-Calls sollten nicht ohne menschliche Überprüfung ausgeführt werden. Eine externe Nachricht senden, einen Produktiv-Datensatz ändern, Daten löschen — das sind Aufrufe, die einen Pausier-und-Bestätigen-Schritt vor der Ausführung rechtfertigen.
Eine Governance-Schicht, die einen MCP-Tool-Call abfangen, ihn einem Prüfer in geschwärzter Form vorlegen und basierend auf dieser Entscheidung entweder fortfahren oder abbrechen kann, ist das Äquivalent eines Change-Management-Freigabe-Workflows — angewendet auf der AI-Runtime-Schicht.
Fragen, die Sie Ihrem AI-Plattform-Team stellen sollten
Wenn Ihre Organisation MCP-verbundene AI-Anwendungen nutzt oder zu nutzen plant, sind dies die Governance-Fragen, die es wert sind, gestellt zu werden:
- Welche MCP-Server sind in unserer Umgebung registriert? Können Sie eine vollständige Liste erstellen?
- Welche Tools stellt jeder Server bereit? Haben Sie sie inventarisiert?
- Welche Agenten oder Nutzer können welche Tools aufrufen? Ist dieser Zugriff zugriffskontrolliert, oder steht er jedem verbundenen Client offen?
- Werden Tool-Calls protokolliert? Können Sie eine Audit-Aufzeichnung für einen beliebigen Tool-Aufruf erstellen?
- Sind risikoreiche Tool-Calls an eine menschliche Freigabe gebunden? Oder werden sie automatisch ausgeführt?
- Wie sind Client-Anmeldedaten geregelt? Sind sie sitzungsgebunden und ablaufend, oder langlebig?
Wenn die Antworten nicht ohne Weiteres verfügbar sind, läuft Ihr MCP-Deployment ohne eine Governance-Schicht.
Warum dies jetzt wichtig ist
Die MCP-Adoption beschleunigt sich. Große AI-Plattformen unterstützen es. Entwickler bauen dagegen. Das Tooling-Ökosystem wächst rasant.
Die Governance-Lücke ist nicht hypothetisch — sie ist der Standardzustand der meisten frühen MCP-Deployments, aus demselben Grund, aus dem die Governance-Lücke bei der LLM-Nutzung im Allgemeinen Standard ist: Die Entwickler bewegten sich schnell, das Sicherheits-Tooling holt auf, und das Käufergespräch hat die technische Realität noch nicht eingeholt.
Für regulierte Branchen — Finanzdienstleistungen, Recht, Gesundheitswesen — lautet die Frage nicht, ob MCP-Governance erforderlich ist. Sie lautet, ob Sie ihr zuvorkommen, bevor ein Audit oder ein Vorfall das Gespräch erzwingt.
Wie Qadar AI MCP regelt
Shield Control von Qadar AI umfasst MCP-Governance-Fähigkeiten:
- Server-Registrierung — definieren Sie, welche MCP-Server für die Nutzung in Ihrer Umgebung freigegeben sind
- Tool-Inventar — erfassen Sie die Tools, die jeder Server bereitstellt, sowie die zulässigen Aufrufer
- Sitzungsgebundener Zugriff — geben Sie kurzlebige Runtime-Sitzungen pro Agenten-Aufgabe aus; kein langlebiges direktes Client-Vertrauen
- Freigabe-Gates vor der Ausführung — fangen Sie risikoreiche Tool-Calls vor der Ausführung ab und leiten Sie sie an einen menschlichen Prüfer weiter
- Trace-verknüpfter Audit-Trail — jeder MCP-Tool-Call wird mit Akteur, Sitzungskontext, Argument-Fingerprint und Freigabe-Referenz protokolliert
Möchten Sie sehen, wie ein geregeltes MCP-Deployment aussieht? Buchen Sie eine Demo
