MCP-Server sicher entwickeln: KI-Agenten kontrolliert an Tools und Daten anbinden

Ein Entwicklungsteam möchte einen KI-Agenten mit dem internen Ticketsystem, einer Wissensdatenbank und einem Reporting-Service verbinden. Die erste Idee klingt einfach: Der Agent bekommt einen technischen Zugang und ruft bei Bedarf die vorhandenen APIs auf. Genau an dieser Stelle entstehen jedoch die typischen Risiken. Der Agent sieht mehr Daten als nötig, kann unbeabsichtigt schreibende Aktionen auslösen oder wird durch Inhalte aus einem Ticket dazu gebracht, ein sensibles Tool falsch zu verwenden.

Das Model Context Protocol, kurz MCP, schafft eine einheitliche Schnittstelle, über die KI-Anwendungen kontrolliert auf Tools, Ressourcen und Datenquellen zugreifen können. Es löst aber kein Sicherheitsproblem automatisch. Ein MCP-Server ist kein neutraler Adapter, sondern eine Sicherheitsgrenze. Du musst deshalb bewusst festlegen, welche Funktionen ein Agent erhält, in wessen Namen er handelt und wie du jeden relevanten Zugriff nachvollziehbar machst.

Infografik zu MCP-Server sicher entwickeln: KI-Agenten kontrolliert an Tools und Daten anbinden (KI-generiert).

Die Rollen im MCP-Modell sauber trennen

Für eine sichere Architektur hilft es, die beteiligten Komponenten klar voneinander abzugrenzen:

• Der MCP-Host ist die Anwendung, in der ein Mensch oder ein KI-Agent arbeitet.
• Der MCP-Client stellt innerhalb des Hosts die Verbindung zum Server her.
• Der MCP-Server bietet definierte Tools, Ressourcen oder Vorlagen für Prompts an.
• Das angebundene Zielsystem ist etwa ein CRM, eine Datenbank, ein Dateispeicher oder ein ITSM-System.

Der MCP-Server sollte nicht einfach alle Funktionen eines Zielsystems durchreichen. Seine Aufgabe besteht darin, eine kleine, fachlich sinnvolle und abgesicherte Schnittstelle bereitzustellen. Statt einer allgemeinen Datenbankabfrage bietest du beispielsweise ein Tool wie ticket_anzeigen an. Dieses erwartet eine Ticket-ID, prüft die Berechtigung und liefert nur die benötigten Felder zurück.

Damit reduzierst du die Angriffsfläche erheblich. Der Agent muss weder Tabellenstrukturen kennen noch freie Abfragen formulieren. Gleichzeitig kannst du pro Tool präzise festlegen, wer es unter welchen Bedingungen verwenden darf.

Tools so gestalten, dass sie wenig Spielraum lassen

Ein gutes Tool-Design folgt dem Prinzip der minimalen Berechtigung. Ein Tool erfüllt genau eine fachliche Aufgabe und nimmt nur die Parameter an, die dafür notwendig sind. Je allgemeiner eine Schnittstelle formuliert ist, desto schwieriger wird ihre Absicherung.

Diese Gegenüberstellung zeigt den Unterschied:

Ungünstiges Design	Sichereres Design
Freie SQL-Abfrage an eine Produktivdatenbank	kunde_abrufen(kundennummer) mit fest definierter Abfrage
Universeller Dateizugriff auf ein Share	projekt_dokument_liste(projekt_id) mit erlaubten Pfaden
Beliebige HTTP-Anfrage an interne Dienste	Einzelne Tools für freigegebene Geschäftsaktionen
Freitext für eine Löschaktion	Eindeutige Objekt-ID, Bestätigung und zusätzliche Prüfung
Vollständiges Ticketobjekt	Gefilterte Felder passend zum jeweiligen Anwendungsfall

Definiere Eingaben strikt über ein Schema. Typen, erlaubte Werte, Längen und Formate sollten serverseitig geprüft werden. Verlasse dich nicht darauf, dass das Sprachmodell Parameter korrekt erzeugt. Ein Agent kann Werte verwechseln, unvollständig ausgeben oder durch manipulierte Inhalte zu unerwarteten Aufrufen verleitet werden.

Besonders wichtig sind schreibende Tools. Ein Tool wie benutzer_deaktivieren, bestellung_freigeben oder incident_schliessen benötigt stärkere Schutzmechanismen als eine reine Suche. Frage dich bei jeder Aktion: Kann sie rückgängig gemacht werden? Entsteht ein finanzieller, rechtlicher oder operativer Schaden? Muss ein Mensch die Ausführung bestätigen?

Für kritische Vorgänge ist ein zweistufiges Vorgehen sinnvoll. Der Agent bereitet zunächst eine Aktion als Entwurf vor. Erst nach einer sichtbaren Prüfung und ausdrücklichen Freigabe durch den berechtigten Menschen führt der Server sie aus. Der MCP-Server darf eine solche Freigabe nicht nur im Chat annehmen, sondern muss sie technisch an die konkrete Aktion, die Identität und einen kurzen Gültigkeitszeitraum binden.

Identität und Authentifizierung: Der Agent ist nicht der Benutzer

Ein häufiger Fehler besteht darin, dass alle Anfragen eines MCP-Servers mit einem gemeinsamen technischen Konto am Zielsystem ankommen. Das ist zwar bequem, aber problematisch: Du kannst später kaum erkennen, wer eine Aktion veranlasst hat. Zudem erhalten alle Nutzenden indirekt die Rechte dieses Kontos.

Besser ist eine Trennung zwischen drei Identitäten:

• Die Identität des angemeldeten Menschen
• Die Identität der aufrufenden Anwendung oder des Workloads
• Die technische Identität des MCP-Servers gegenüber angebundenen Systemen

Der Server muss erkennen können, für wen eine Anfrage erfolgt und welche Anwendung sie ausgelöst hat. Nutze dafür etablierte Verfahren mit kurzlebigen Zugriffstokens, eindeutigen Zielgruppen und geprüften Ausstellern. Ein Token darf nur für den vorgesehenen Dienst und den vorgesehenen Zweck gültig sein.

Leite ein vorhandenes Benutzer-Token nicht ungeprüft an beliebige Backend-Systeme weiter. Prüfe mindestens Signatur, Ablaufzeit, Aussteller, Zielgruppe und benötigte Berechtigungen. Falls du Tokens austauschst, sollten die neuen Tokens enger begrenzt sein als die ursprüngliche Berechtigung.

Für lokale Entwicklungsumgebungen kann MCP über Standard-Ein- und Ausgabe laufen. Bei vernetzten Deployments ist die Absicherung des Transportwegs besonders wichtig. Erzwinge verschlüsselte Verbindungen, validiere Zertifikate und begrenze, welche Clients den Server erreichen dürfen. Ein offen erreichbarer MCP-Endpunkt ohne starke Anmeldung gehört nicht in ein Unternehmensnetz.

Rechtekonzept: Nicht nur Zugriff, sondern Kontext prüfen

Authentifizierung beantwortet die Frage, wer eine Anfrage stellt. Autorisierung beantwortet die wichtigere Frage, ob diese Identität genau diese Aktion auf genau dieses Objekt ausführen darf.

Implementiere Berechtigungen nicht nur im Prompt oder in einer Tool-Beschreibung. Der MCP-Server und das Zielsystem müssen sie technisch durchsetzen. Ein Hinweis wie „Nutze dieses Tool nur für eigene Tickets“ schützt nicht, wenn der Server jede Ticket-ID akzeptiert.

Ein tragfähiges Rechtekonzept berücksichtigt mehrere Ebenen:

• Welche Rolle hat die Person?
• Darf diese Rolle das konkrete Tool aufrufen?
• Darf sie auf das angefragte Objekt zugreifen?
• Ist die Aktion lesend, ändernd oder administrativ?
• Gibt es zeitliche, organisatorische oder mandantenbezogene Einschränkungen?
• Muss eine zweite Person oder ein definierter Prozess zustimmen?

Beispiel: Ein Teamlead darf möglicherweise Abwesenheiten seines Teams einsehen, aber nicht die aller Mitarbeitenden. Die Berechtigung hängt dann nicht allein von der Rolle „Teamlead“ ab, sondern auch von der Teamzuordnung des angefragten Datensatzes.

Vermeide außerdem das „Confused Deputy“-Problem. Dabei besitzt der MCP-Server selbst weitreichende Rechte und wird von einer weniger berechtigten Person dazu gebracht, diese Rechte auszunutzen. Der Server darf niemals allein deshalb handeln, weil er technisch dazu fähig ist. Er muss die Berechtigung der anfragenden Person bei jedem sensiblen Aufruf mitprüfen.

Prompt Injection als Sicherheitsfall behandeln

MCP verbindet Sprachmodelle mit handlungsfähigen Systemen. Deshalb können unzuverlässige Inhalte aus E-Mails, Dokumenten, Webseiten oder Tickets gefährlich werden. Ein Tickettext könnte etwa Anweisungen enthalten, der Agent solle interne Daten exportieren oder eine Sicherheitsprüfung überspringen.

Solche Inhalte sind Daten, keine vertrauenswürdigen Anweisungen. Diese Trennung muss in deiner Architektur sichtbar sein. Der Agent darf Informationen aus externen oder nutzergenerierten Quellen auswerten, aber sie nicht automatisch als Handlungsauftrag behandeln.

Dazu gehören mehrere Maßnahmen:

• Begrenze die verfügbaren Tools pro Agent und Aufgabe.
• Übergib dem Modell nur die Daten, die es für die aktuelle Entscheidung braucht.
• Kennzeichne fremde Inhalte intern als untrusted content.
• Fordere bei schreibenden oder datenintensiven Aktionen eine explizite Bestätigung.
• Prüfe Tool-Parameter unabhängig vom Modellserverseitig.
• Verwende für besonders kritische Vorgänge regelbasierte Prüfungen zusätzlich zur KI-Entscheidung.

Ein Modell darf Vorschläge machen. Die verbindliche Sicherheitsentscheidung gehört jedoch in überprüfbaren Code und in klar definierte Richtlinien.

Logging und Datenschutz von Anfang an einplanen

Ohne Protokollierung kannst du Vorfälle kaum untersuchen. Gleichzeitig dürfen Logs nicht selbst zur neuen Datenquelle für sensible Informationen werden. Protokolliere deshalb strukturiert und zweckgebunden.

Für relevante Tool-Aufrufe solltest du mindestens festhalten:

• Zeitpunkt und eindeutige Anfrage-ID
• Benutzer-, Client- und Serveridentität
• Name des Tools und Ergebnisstatus
• Berechtigungsentscheidung
• Zielsystem und technische Laufzeit
• Referenzen auf betroffene Objekte, sofern datenschutzgerecht möglich
• Grund für Ablehnung, Zeitüberschreitung oder Fehler

Speichere nicht pauschal vollständige Prompts, Antworten oder Nutzdaten in Logs. Gerade darin können personenbezogene Daten, Zugangsdaten oder interne Geschäftsdetails stehen. Maskiere Geheimnisse, reduziere Inhalte auf notwendige Metadaten und beschränke den Zugriff auf Audit-Protokolle.

Hilfreich sind getrennte Protokolle für Betrieb, Sicherheit und fachliche Nachvollziehbarkeit. So können Entwickler Fehler analysieren, ohne automatisch alle sensiblen Nutzdaten einsehen zu müssen.

Sicher betreiben und Änderungen kontrollieren

Ein sicher entwickelter MCP-Server bleibt nur sicher, wenn du ihn auch kontrolliert betreibst. Versioniere Tool-Schemas und Richtlinien. Teste Änderungen zunächst mit Testdaten und getrennten Zugängen. Prüfe vor jedem Release, ob ein neues Tool unbeabsichtigt bestehende Rechte erweitert.

Diese Checkliste unterstützt dich vor dem produktiven Einsatz:

• Jedes Tool hat einen klaren fachlichen Zweck und ein enges Eingabeschema.
• Lese- und Schreibzugriffe sind getrennt bewertet.
• Benutzeridentität und Workload-Identität sind nachvollziehbar.
• Berechtigungen werden serverseitig und objektbezogen geprüft.
• Tokens sind kurzlebig, zweckgebunden und werden validiert.
• Geheimnisse liegen nicht im Quellcode oder in Prompt-Vorlagen.
• Kritische Aktionen benötigen eine technische Bestätigung.
• Tool-Aufrufe werden datensparsam und revisionsfähig protokolliert.
• Fehlermeldungen verraten keine internen Details oder Zugangsdaten.
• Es gibt Tests für unzulässige Parameter, Rechteverletzungen und manipulierte Inhalte.

MCP entwickelt sich weiter, deshalb solltest du Spezifikationen, eingesetzte Bibliotheken und Sicherheitsfunktionen regelmäßig prüfen. Plane Updates wie bei jeder anderen Integrationskomponente: mit Abhängigkeitspflege, Sicherheitsprüfungen und einem klaren Rückfallplan.

Wenn du MCP-Server oder sichere Schnittstellen für KI-Anwendungen im Team aufbauen möchtest, helfen dir fundierte Kenntnisse zu APIs, Authentifizierung, Cloud-Sicherheit und Softwarearchitektur. Passende Seminare und Termine findest du bei uns auf cmt.de.