Die erste produktive MCP-Verbindung sollte wie eine Sicherheitsfreigabe behandelt werden. Sobald ein Agent über das Model Context Protocol auf echte Systeme zugreifen darf, müssen Identität, Berechtigungen, Datenfluss und mögliche Schreibaktionen vorab geprüft und laufend überwacht werden.
Montagmorgen, 8.47 Uhr, ein Besprechungsraum in Berlin-Mitte. In unserem fiktiven Szenario sitzt Mira, Plattformverantwortliche bei einem jungen Softwareanbieter, mit kaltem Kaffee vor ihrem Laptop. Sie will dem internen Agenten Zugriff auf das Ticketsystem geben. Die Verbindung steht, der Test in der Entwicklungsumgebung war unauffällig, die Aufgabe klingt harmlos: offene Supportfälle zusammenfassen und ähnliche Probleme gruppieren.
Dann erscheint der Dialog für den Produktivzugriff. Das angeforderte Konto darf Tickets lesen, interne Notizen sehen, Anhänge öffnen und Einträge verändern. Mira hält inne. Wenn der Agent eine Anweisung aus einem präparierten Anhang übernimmt oder ein Ticket falsch interpretiert, könnte er interne Informationen ausgeben oder einen Vorgang verändern, bevor jemand den Fehler bemerkt.
Die geplante Freigabe um neun Uhr steht plötzlich auf der Kippe. Ohne die Verbindung fällt die Vorführung vor der Geschäftsleitung aus. Mit den vorgesehenen Rechten könnte aus einer Zusammenfassung ein Eingriff in Produktionsdaten werden.
Der Connector erweitert die Sicherheitsgrenze
MCP standardisiert, wie Modelle Werkzeuge und Datenquellen ansprechen. Das erleichtert Integrationen, beseitigt aber keine Sicherheitsfragen. Im Gegenteil: Eine verständliche Schnittstelle kann den Weg von einer Texteingabe zu einer wirksamen Aktion erheblich verkürzen.
Für die Prüfung zählt deshalb weniger, ob die Verbindung technisch funktioniert. Entscheidend ist, welche Folgen ein einzelner Aufruf haben kann.
Kann das Werkzeug nur ausgewählte Felder lesen oder vollständige Datensätze? Erhält der Agent auch vertrauliche Notizen? Darf er schreiben, löschen oder Aktionen auslösen? Werden Zugangsdaten im Connector gespeichert? Lassen sich Aufrufe später einer Person, einem Agentenlauf und einer konkreten Eingabe zuordnen?
Diese Fragen gehören in die Architekturentscheidung, bevor der erste Token für die Produktion ausgestellt wird. Wer sie erst nach einem Vorfall stellt, rekonstruiert womöglich einen Ablauf, der nie ausreichend protokolliert wurde.
Der Markt bewegt sich bereits in diese Richtung. Die Übernahme von Virtue AI durch Fortinet bringt automatisiertes Red-Teaming, Laufzeitschutz und Sicherheitsüberwachung für autonome Agenten, Modelle und MCP-Werkzeuge zusammen. Das ist kein Beleg dafür, dass ein bestimmtes Produkt jede Gefahr abfängt. Es zeigt, welche Kontrollen rund um produktive Agentensysteme relevant werden.
Vier Prüfungen vor der Freigabe
Mira verschiebt den Termin nicht sofort. Gemeinsam mit einem Sicherheitskollegen zerlegt sie die Verbindung in vier prüfbare Fragen.
Erstens: Welche Identität handelt? Ein gemeinsam genutztes Dienstkonto verschleiert, welcher Agentenlauf eine Aktion ausgelöst hat. Eine eigene, eindeutig zugeordnete Identität begrenzt den Zugriff und verbessert die Nachvollziehbarkeit.
Zweitens: Welche Rechte braucht die konkrete Aufgabe? Für Zusammenfassungen genügt ein lesender Zugriff auf ausgewählte Ticketfelder. Änderungsrechte, administrative Funktionen und der Zugriff auf Anhänge gehören nicht automatisch dazu. Das Prinzip der geringsten Rechte muss sich in der tatsächlichen Konfiguration zeigen, nicht in einer Richtlinie auf Papier.
Drittens: Welche Eingaben sind feindlich zu behandeln? Tickettexte, Webseiten, Dokumente und Anhänge können Anweisungen enthalten, die ein Agent für relevant hält. Externe Inhalte brauchen daher eine klare Trennung von Systemvorgaben und Werkzeugrechten. Ein Agent sollte aus einem gelesenen Dokument keine zusätzlichen Berechtigungen ableiten können.
Viertens: Was passiert bei einem Fehlverhalten? Verantwortliche brauchen aussagekräftige Protokolle, begrenzte Sitzungen und einen Weg, Zugangsdaten schnell zu sperren. Schreibende oder irreversible Aktionen benötigen zusätzliche Bestätigungsschritte. Die laufende Kontrolle ist Teil des Betriebs, keine einmalige Abnahme.
Diese Vorbereitung ähnelt der Frage, was vor dem ersten IBM OpenAI Workshop geklärt sein muss: Erst Rollen, Daten und Grenzen festlegen, dann den sichtbaren Anwendungsfall starten.
Der erste Test muss einen Angriff enthalten
Ein erfolgreicher Verbindungscheck beweist lediglich, dass Agent und Werkzeug miteinander sprechen können. Er sagt wenig darüber aus, wie sich das System bei missverständlichen, manipulierten oder unerwarteten Eingaben verhält.
Ein sinnvoller Produktionstest enthält deshalb mindestens einen absichtlich problematischen Datensatz. Darin kann eine eingebettete Anweisung stehen, vertrauliche Informationen aus einem anderen Ticket abzurufen oder eine nicht freigegebene Aktion auszuführen. Das erwartete Ergebnis muss vorher feststehen: Der Agent ignoriert die Anweisung, überschreitet seinen Datenbereich nicht und erzeugt einen überprüfbaren Protokolleintrag.
Auch Ausfälle gehören in den Test. Was geschieht bei einer Zeitüberschreitung, einer unvollständigen Antwort oder einem wiederholten Werkzeugaufruf? Wiederholt das System eine schreibende Aktion, kann aus einem kleinen Verbindungsproblem ein doppelter Vorgang werden.
Diese Tests sollten die tatsächliche Produktionskonfiguration abbilden. Eine Entwicklungsumgebung mit bereinigten Daten, anderen Rollen und folgenlosen Aktionen liefert nur begrenzte Sicherheit.
Produktionszugriff bleibt eine laufende Entscheidung
Um 9.06 Uhr sitzt Mira noch immer im Besprechungsraum. Die große Freigabe ist vom Tisch, die Vorführung jedoch nicht. Der Agent erhält ein eigenes Konto mit lesendem Zugriff auf wenige Felder. Anhänge, interne Notizen und Änderungen bleiben gesperrt. Jeder Werkzeugaufruf landet im Prüfprotokoll.
Auf dem Bildschirm erscheinen die ersten Zusammenfassungen. Neben dem Laptop liegt nun kein allgemeiner Freigabevermerk, sondern eine kurze Liste mit erlaubten Daten, ausgeschlossenen Aktionen, verantwortlicher Person und Abschaltweg.
Das ist der eigentliche Übergang in die Produktion. Die MCP-Verbindung läuft unter Bedingungen, die das Team benennen, testen und widerrufen kann. Neue Werkzeuge, Datenfelder oder Schreibrechte lösen eine neue Prüfung aus. Denn mit jeder zusätzlichen Fähigkeit verändert sich auch die Sicherheitsgrenze.
Kommentare
Noch keine Kommentare.