Pseudonymisierung über MCP integrieren: den Schutzschritt verbindlich machen

Der bestätigte Zugang zum KIShieldGuard MCP-Dienst

Der eigenständige Dienst ist unter mcp.kishieldguard.de erreichbar. Der MCP-Endpunkt lautet https://mcp.kishieldguard.de/mcp. Er ist vom REST-Angebot der Hauptanwendung getrennt; Zugang und Tarif werden über den MCP-Dienst eingerichtet.

Die öffentliche Metadatenadresse https://mcp.kishieldguard.de/.well-known/oauth-protected-resource/mcp beschreibt die geschützte Ressource. Bei der Prüfung am 17. Oktober 2026 antwortete sie mit HTTP 200 und verwies auf den Autorisierungsserver https://mcp.kishieldguard.de/auth/realms/mcp. Als unterstützter Scope war mcp:use angegeben. Ein nicht autorisierter Aufruf des MCP-Endpunkts erhielt HTTP 401.

Die MCP-Spezifikation zur Autorisierung beschreibt für HTTP den OAuth-basierten Zugang und die Ermittlung der geschützten Ressource. Verwenden Sie einen Client, der den Autorisierungsablauf des Dienstes unterstützt. Lassen Sie ihn die Metadaten auswerten, statt Tokenadressen oder Clientregistrierung aus fremden Beispielen zu übernehmen.

Werkzeuge und Schema nach der Anmeldung ermitteln

Die Schutzwerkzeuge heißen pseudonymize und reidentify. Fragen Sie nach erfolgreicher Autorisierung mit dem MCP-Verfahren tools/list die tatsächlich angebotenen Werkzeuge und deren Eingabeschema ab. Binden Sie diese Definitionen in Ihren Adapter ein und prüfen Sie Werkzeugfehler und Antwortformat.

Dieser Leitfaden legt bewusst keine angeblichen JSON-Feldnamen für die Werkzeugantwort fest: Sie müssen zum Schema des angemeldeten Dienstes passen. Halten Sie die konkret eingesetzte Clientversion und das geprüfte Schema in Ihrer Integrationsdokumentation fest.

Der Datenfluss in fünf Schritten

1. Original begrenzen: Die Anwendung wählt den benötigten Text aus und entfernt unnötige Inhalte.
2. Schutzwerkzeug aufrufen: Der Adapter ruft pseudonymize auf und prüft den Erfolg. Er trennt freigegebenen Text und den für die Rückzuordnung benötigten Kontext.
3. Modell anfragen: Ausschließlich der freigegebene Text wird als Nutzinhalt an das Modell übermittelt. Der Zuordnungskontext gehört nicht in den Prompt.
4. Antwort zurückübersetzen: Der Adapter verwendet reidentify entsprechend dem ermittelten Schema und dem passenden Kontext.
5. Ergebnis prüfen: Die Anwendung gibt die Antwort erst im vorgesehenen Berechtigungskontext aus. Eine fachliche Abnahme bleibt Teil des Prozesses.

Ein minimales Adaptermuster für Ihre Anwendung

Der folgende Python-Code zeigt ausschließlich die Reihenfolge in Ihrer Anwendung. Er ist kein MCP-SDK-Beispiel und enthält keine implementierten Netzwerkaufrufe. Die Funktionen protect und restore werden von Ihnen an den tatsächlich autorisierten Dienst angebunden.

Der lokale Adaptervertrag lautet: protect liefert nach erfolgreicher Schema- und Fehlerprüfung ein Tupel aus freigegebenem Text und Zuordnungskontext. model verarbeitet nur diesen Text. restore erhält Antwort und Kontext. Ausnahmen werden weitergegeben, damit die aufrufende Anwendung den Vorgang anhält.

def run_guarded(original, protect, model, restore):
    # Adaptervertrag, kein direkter Aufruf eines MCP-SDKs.
    protected_text, context = protect(original)
    if not isinstance(protected_text, str) or not protected_text.strip():
        raise ValueError("Keine freigegebene Eingabe")
    answer = model(protected_text)
    if not isinstance(answer, str):
        raise TypeError("Unerwartete Modellantwort")
    return restore(answer, context)

Für dieses veröffentlichte Ablaufmuster wurden Erfolg, leere Schutzausgabe, Schutzfehler, unerwartete Modellantwort und Fehler bei der Rückübersetzung mit isolierten Testfunktionen geprüft. Das prüft die Kontrolllogik des Beispiels; Ihre tatsächlichen MCP- und Modelladapter benötigen zusätzlich einen Integrationstest.

Was der Integrationstest nachweisen muss

• Autorisierung: Nicht angemeldete Zugriffe werden abgewiesen. Zugangsdaten erscheinen weder in Prompt noch in Protokollen.
• Schutzausfall: Bei einer abgelehnten Werkzeugantwort, einem Timeout oder einem Formatfehler erfolgt kein Modellaufruf.
• Datenminimierung: Der Modelladapter erhält genau die freigegebene Textfassung. Rohtext und Zuordnung werden nicht als zusätzlicher Kontext mitgesendet.
• Kontexttrennung: Zwei parallele Vorgänge verwenden ihre jeweils eigene Zuordnung. Kontext aus einem Vorgang wird nicht im anderen eingesetzt.
• Rückübersetzung: Ein Fehler wird als Fehler behandelt. Die Anwendung baut keine scheinbar vollständige Ausgabe aus fremdem oder fehlendem Kontext.
• Nachweis: Nur erfundene Testdaten verwenden und Version, Erwartung sowie beobachteten Datenfluss festhalten.

Protokolle, Wiederholungen und Berechtigungen

Protokollieren Sie technische Zustände und eine interne Vorgangskennung, soweit erforderlich. Übernehmen Sie nicht automatisch Originaltexte, Werkzeugantworten oder Zuordnungen in Debug-Logs. Prüfen Sie das auch für Fehlerberichte und externe Überwachungsdienste.

Definieren Sie für Wiederholungen, ob ein Vorgang erneut aufgebaut werden muss oder im bestehenden Kontext fortgesetzt werden darf. Eine Wiederholung ist erst dann sinnvoll, wenn die Zuordnung eindeutig bleibt. Beschränken Sie Zugriffe auf die Personen und Systeme, die sie für den jeweiligen Schritt benötigen.

Wann MCP der passende Weg ist

MCP passt zu kompatiblen Clients und Agentenumgebungen, in denen Sie Werkzeugaufrufe und Ablaufsteuerung kontrollieren können. Für klassische HTTP-Anwendungen kann die REST API der direktere Weg sein. Für Beschäftigte an bestehenden KI-Oberflächen kommt die Browser-Erweiterung infrage.

Der Architekturvergleich ordnet diese Wege ein. Welche Daten Sie vor dem Modellaufruf entfernen oder ersetzen sollten, zeigt das vollständige Pseudonymisierungsbeispiel.

Allgemeine Fachinformation. Die rechtliche und fachliche Bewertung richtet sich nach dem konkreten Einsatz.