Identität und Data Governance: Rechte bis zum Datensatz

Ein Aufruf trägt mehrere Identitäten

Ein MCP-Aufruf beginnt beim Menschen, läuft durch Host und Client zum Server und oft weiter zu Datenbank oder SaaS-API. An jeder Grenze existiert eine andere Identität. Der Endnutzer ist der fachliche Auftraggeber. Der Host ist eine Softwareinstanz. Der MCP-Server besitzt eine Dienstidentität. Das Backend kennt vielleicht wiederum Nutzer, Clients oder nur ein technisches Konto. Wer diese Rollen in „der Aufrufer“ zusammenfasst, kann weder Rechte noch Audit korrekt erklären.

Endnutzer

Wessen Aufgabe, Datenrechte und Zustimmung gelten

Host oder OAuth-Client

Welche Anwendung den Request vermittelt

MCP-Server

Welcher Dienst Vertrag und serverseitige Policy durchsetzt

Downstream-Dienst

Welche Zielressource mit welchem Principal angesprochen wird

Zeichne für jedes wirkende Tool eine Identitätskette: authentifizierter Principal am Server, daraus abgeleiteter Tenant, verwendete Downstream-Credential und fachlicher Entscheider. Der Trace korreliert diese Ebenen mit nicht sensiblen Kennungen, ohne Tokens zu speichern. Ein Eintrag „Servicekonto hat gelesen“ reicht nicht, wenn das Produkt später beantworten muss, welcher Nutzer welche Akte zu welchem Zweck anforderte.

Authentifizierung ist noch keine Fachautorisierung

Ein gültiges Token beweist eine Identität und bestimmte kryptografische beziehungsweise ausstellerbezogene Aussagen. Es beweist nicht automatisch, dass employee_42 die Personalakte record_99 lesen darf. Der Server prüft zuerst Tokenziel, Aussteller, Ablauf und relevante Claims; anschließend entscheidet eine Fachpolicy über Ressource, Aktion, Tenant und Kontext. Diese zweite Prüfung gehört möglichst nah an den Datenzugriff.

``text allow = authenticated && token.audience == mcp_server && principal.tenant == record.tenant && policy.allows(principal, "read", record) ``

Der Host kann zusätzlich entscheiden, ob er das Tool im Produkt anbietet oder eine Nutzerfreigabe verlangt. Das ersetzt die Serverprüfung nicht, weil andere Hosts oder direkte Requests dieselbe Schnittstelle erreichen können. Umgekehrt kennt der Server nicht zwingend die gesamte Produktrolle und den aktuellen Arbeitszweck. Beide Schichten beantworten unterschiedliche Fragen. Dokumentiere diese Trennung, damit eine erfolgreiche Hostfreigabe niemals als universelle Backendberechtigung missverstanden wird.

Der verwirrte Stellvertreter nutzt geliehene Macht

Ein Server mit einem weitreichenden Servicekonto kann zum verwirrten Stellvertreter werden: Ein schwächer berechtigter Nutzer veranlasst ihn, Rechte auszuüben, die der Nutzer direkt nicht hätte. Tool-Schema und Promptbeschreibung verhindern das nicht. Die Sicherheitsgrenze muss prüfen, ob die angeforderte Wirkung innerhalb der Rechte des ursprünglichen Principals liegt. Sonst verwandelt jede neue MCP-Integration technische Erreichbarkeit in Rechteerweiterung.

Prüfe besonders Parameter, die Zielkonten, Pfade, Mandanten oder Empfänger wählen. Ein Nutzer darf nicht über frei gesetzte IDs aus seinem erlaubten Bereich ausbrechen. Auch scheinbar lesende Tools können Rechte ausweiten, wenn der Server Suchergebnisse aus einem globalen Index liefert. Negative Tests verwenden gültige Identitäten mit fremden Ressourcenschlüsseln; ein bloßer Test mit ungültigem Token findet diese Klasse nicht.

Delegation erhält Nutzerbezug und Zielbindung

Versteht das Downstream-System Nutzeridentitäten, sollte der MCP-Server im Namen des Nutzers mit einem dafür ausgestellten Token handeln. Ein für den MCP-Server bestimmtes Access Token wird nicht einfach an eine andere API weitergereicht. Audience beziehungsweise Resource-Indikator binden ein Token an sein Ziel. Für Delegation kann eine kontrollierte Token-Exchange-Beziehung ein neues, engeres Token für das Backend ausstellen, das Nutzerbezug und zulässigen Scope erhält.

Delegation ist kein Kopieren von Credentials. Begrenze Audience, Scope, Lebensdauer und erlaubte Austauschbeziehung. Der Server speichert keine Nutzertokens in Tool-Ergebnissen, Modellkontext oder normalen Logs. Schlägt Exchange fehl, fällt er nicht still auf sein mächtigeres Servicekonto zurück; das würde genau die geprüfte Nutzerbindung entfernen. Wo mehrere Backends beteiligt sind, erhält jedes sein eigenes zielgebundenes Token.

Definiere auch den Lebenszyklus delegierter Tokens. Der MCP-Server cached sie höchstens verschlüsselt, kurz und mit einem Schlüssel aus Principal, Zielressource und Scope. Ein Cachetreffer nach Rechteentzug darf die neue Policy nicht dauerhaft umgehen; kurze Laufzeit, Token-Introspection oder ein geeigneter Widerrufspfad begrenzen das Fenster. Erneuerung geschieht über den vorgesehenen Autorisierungsfluss und nicht, indem ein Refresh Token durch Toolargumente oder Modellkontext gereicht wird. Bei einem Wechsel des Downstream-Ziels wird erneut ein passendes Token beschafft. Für Hintergrundjobs muss explizit feststehen, ob delegierte Autorität nach Ende der Nutzerinteraktion weitergelten darf. Andernfalls startet der Server keine stundenlange Aufgabe mit einer Vollmacht, deren Zweck und Dauer niemand festgelegt hat. Telemetrie zeichnet Aussteller, Audience, Scope-Klasse und Validierungsgrund auf, aber niemals den Tokenwert. Teste falsche Audience, abgelaufene Claims, fehlenden Scope und einen Token für denselben Nutzer aus einem nicht vertrauten Issuer. Jede Ablehnung bleibt geschlossen; sie löst keinen stillen Credential-Fallback aus.

Mandanten stammen aus autoritativen Claims

Ein Toolparameter wie tenantId ist Client-Eingabe. Er kann für Navigation oder einen Admin-Use-Case nötig sein, darf aber nicht allein die Datenansicht bestimmen. Für gewöhnliche Nutzer leitet der Server den Tenant aus verifiziertem Principal und autoritativer Zuordnung ab. Enthält ein Request dennoch einen Tenant, vergleicht er ihn mit der erlaubten Menge und verwirft Abweichungen. Dasselbe gilt für Resource-URIs, Cursor und Anwendungshandles.

• Query: Tenantfilter wird serverseitig gesetzt, nicht aus freiem Modelltext übernommen.
• Cache: Schlüssel enthält Principal- oder Tenant-Sicht sowie relevante Policyversion.
• Cursor: Fortsetzung ist an dieselbe autorisierte Sicht gebunden.
• Event: Subscription und Notification bleiben dem anfordernden Principal zugeordnet.
• Telemetry: Korrelation ermöglicht Audit, ohne direkte Identifikatoren unnötig zu vervielfachen.

Defense in Depth setzt die Grenze an mehreren Stellen: Policy im Server, Row-Level- oder Schema-Isolation im Datenspeicher und Tests gegen Cross-Tenant-Zugriff. Eine einzige vergessene WHERE-Klausel soll keinen Vollverlust erzeugen. Prüfe Listen, Exporte, Fehlertexte und Aggregationen ebenso wie Einzelobjekte; Leaks entstehen häufig über Metadaten, Trefferzahlen oder globale Caches statt über den offensichtlichen Lesehandler.

Admin- und Supportrollen verdienen einen eigenen Vertrag. Ein Supportmitarbeiter kann mehreren Tenants zugeordnet sein, doch das macht einen freien Tenantparameter nicht automatisch sicher. Der Server ermittelt die erlaubte Tenantmenge aus Policy, verlangt eine explizite Auswahl, protokolliert Zweck und Wechsel und begrenzt die Sicht weiterhin auf die angeforderte Aufgabe. Vermeide einen globalen „Superuser“-Cache, dessen Einträge später normalen Nutzern dienen. Bei asynchronen Jobs speichert der Auftrag die zum Start geprüfte Sicht und definiert, wie ein Rechteentzug behandelt wird; Ergebnisse werden beim Abruf erneut autorisiert. Aggregationen über mehrere Tenants sind eine eigene privilegierte Capability mit separatem Outputvertrag, nicht ein versteckter Sonderwert wie tenantId: all. Auch Fehler müssen mandantensicher bleiben: „Objekt existiert in anderem Tenant“ verrät mehr als eine einheitliche Nichtverfügbarkeit. So umfasst Tenant-Isolation Entscheidungen, Metadaten und Seiteneffekte, nicht nur Zeilenfilter.

Legacy-Servicekonten verschieben die Sicherheitsgrenze

Manche Altsysteme kennen nur ein technisches Integrationskonto mit Vollzugriff. Dann kann das Backend die Endnutzergrenze nicht selbst durchsetzen. Der Wrapper muss Nutzer authentifizieren, dessen Bereich aus einer autoritativen Quelle ermitteln und jede Backendabfrage auf diese Sicht begrenzen. Aus einem Adapter wird damit eine sicherheitskritische Policy Enforcement Point. Diese Rolle gehört ausdrücklich in Threat Model, Review und Betrieb.

Servicekonto

Minimal mögliche Rechte, zentraler Secret Store, Rotation und getrennte Umgebungen

Wrapper-Policy

Deny by default, objektbezogene Prüfung und serverseitige Tenantprojektion

Backend-Abfrage

Keine frei zusammengesetzten Ziele; Filter und Limits aus geprüfter Policy

Audit

Endnutzer, Entscheidung und Servicekonto-Wirkung manipulationsarm korrelieren

Ein Host-Allowlisting oder eine Toolbeschreibung ist keine Ersatzgrenze. Ebenso wenig sollte der Wrapper bei unklarer Nutzerzuordnung unter dem Servicekonto „best effort“ lesen. Fehler schließen den Zugriff. Langfristig droht Policy-Drift zwischen Wrapper und Fachsystem; automatisierte Berechtigungstests und ein verantwortlicher Owner sind deshalb Teil der Lösung. Ist das Risiko nicht vertretbar, kann Aussetzen dennoch die richtige Produktentscheidung sein — aber bewusst aufgrund des verbleibenden Risikos, nicht weil das Muster technisch unbekannt wäre.

Datensparsamkeit beginnt im Capability-Vertrag

Daten, die ein Tool oder eine Resource ausliefert, können in Modellkontext, Hosthistorie, Providerverarbeitung, Cache und Sicherung gelangen. Darum beginnt Governance nicht erst beim Logfilter. Das Input- und Output-Schema soll nur Felder enthalten, die der konkrete Zweck benötigt. Ein Tool zur Terminbestätigung braucht selten Geburtsdatum, Anschrift und vollständige Kundenakte. Kleinere Verträge reduzieren zugleich Kontextkosten, Fehlinterpretation und Angriffsfläche.

• Weglassen: nicht benötigte Felder gar nicht abfragen oder serialisieren.
• Pseudonymisieren: stabile, begrenzte Referenz statt direkter Identität verwenden.
• Verdichten: Kategorie statt Rohwert liefern, wenn sie den Zweck erfüllt.
• Begrenzen: einzelne Fälle und Seiten statt unbeschränkter Exporte.
• Trennen: besonders sensible Details nur über einen eigenen, stärker kontrollierten Aufruf.

Beschreibungen nennen Zweck und Datenumfang, damit Host und Nutzer eine informierte Entscheidung treffen können. outputSchema macht Felder maschinenlesbar, aber ein Schema beweist keine rechtliche oder fachliche Erforderlichkeit. Diese Entscheidung kommt aus Use Case, Datenklassifikation und zuständiger Governance. Prüfe reale Payloads gegen den Vertrag; optionale Debugfelder und Backendantworten dürfen nicht unbemerkt durchgereicht werden.

Der Datenfluss endet nicht am Tool-Result

Vor Freigabe eines Servers wird der tatsächliche Datenweg inventarisiert: Fachsystem, MCP-Server, Host, Modellanbieter, regionale Verarbeitung, Gesprächshistorie, Cache, Telemetrie, Backup und Supportzugriff. Für jede Station stehen Zweck, Datenkategorie, Principal, Region, Aufbewahrung, Löschweg und verantwortlicher Owner fest. Die Aussage „der Nutzer darf die Akte sehen“ beantwortet nicht, ob sie an all diese Systeme übertragen und dort gespeichert werden darf.

Cache- und Modellanbieterwahl sind Teil dieser Architektur. Ein cacheScope beschreibt Protokoll-Caching, hebt aber keine Governance-Regel auf. Region, Unterauftragnehmer und Trainingsnutzung müssen mit den tatsächlichen Produktbedingungen übereinstimmen. Änderungen am Datenweg werden wie Vertragsänderungen reviewed. Für Auskunft und Löschung braucht das Team einen Index, der betroffene Systeme findet, ohne noch eine weitere Vollkopie der Inhalte anzulegen.

Übersetze das Inventar in technische Kontrollen. Der Host versieht Inhalte mit Datenklasse und Herkunft, bevor sie in einen Modellrequest gelangen. Konversationen erben die strengste relevante Aufbewahrungsregel oder trennen sensible Arbeitsräume vollständig. Caches führen Ablauf und Scope; Exporte und Backups haben dokumentierte Löschfristen. Ein Modellprovider wird nicht nur nach Region bewertet, sondern nach tatsächlicher Speicherung, Supportzugriff, Subprozessoren und vertraglicher Nutzung der Eingaben. Für lokale Modelle gelten dieselben Fragen zu Logs, Snapshots und Betreiberzugriff. Bei einem Löschbegehren kann ein Index anhand pseudonymer Referenzen alle Kopien auffinden und einen überprüfbaren Workflow auslösen. Prüfe regelmäßig mit einem markierten Testdatensatz, ob er nach Ablauf wirklich aus Suche, Cache, Historie und Standardtelemetrie verschwunden ist. Das ist wirksamer als eine Tabelle, deren Systeme nie gegen die reale Produktion abgeglichen werden.

Logs sind eine Datenbank mit anderem Namen

Telemetrie kopiert Daten besonders leicht, weil Frameworks Requestparameter, Header und Antworten bequem automatisch erfassen. Ein zentraler Logdienst hat häufig mehr Leser und längere Aufbewahrung als das Fachsystem. Standardlogs enthalten daher Ereigniszeit, Server- und Tool-ID, pseudonyme Korrelation, Dauer, Ergebnisstatus und Fehlerklasse — nicht Bearer-Token, freien Prompt oder vollständige Akte. Redaction geschieht vor dem Export, nicht erst in der Suchoberfläche.

Standard

Request-ID, pseudonymer Tenant, Methode, Status, Dauer, Größenklasse

Kontrolliert

Zeitlich begrenztes Debug-Sampling mit Genehmigung und zusätzlicher Redaction

Ausgeschlossen

Secrets, Authorization-Header, vollständiger Payload und unnötige Direktidentifikatoren

Fehlertexte sind ebenfalls Payload. Datenbankmeldungen können Tabellen, Suchwerte oder fremde Datensätze enthalten. Übersetze sie in stabile Fehlerklassen und handlungsleitende, autorisierungsgerechte Meldungen. Prüfe Backups, Traces und Dead-Letter-Queues im selben Umfang. Eine kurze Produktionsaufbewahrung hilft wenig, wenn Rohlogs jahrelang in einem Backup bleiben. Tests speisen markierte Secrets und personenbezogene Testwerte ein und suchen sie anschließend in allen Exportzielen.

Governance wird als Invariante betrieben

Ein produktionsreifer Test verwendet zwei Principals aus verschiedenen Tenants, gleich aussehende Objekt-IDs und parallele Requests. Er prüft Einzelzugriff, Listen, Cursor, Caches, Subscription-Events, Fehlertexte und Logs. Danach wechseln Rechte und ein alter Handle wird erneut verwendet. Erwartet wird eine neue Autorisierungsentscheidung, kein Vertrauen in früheren Besitz. Für Servicekonten werden Rotation und Ausfall des Secret Stores geprobt; der Server darf Credentials weder ausgeben noch bei fehlender Policy offen weiterarbeiten.

• Identität erhalten: Auftraggeber, Client, Server und Backend-Prinzipal nicht vermischen.
• Sicht erzwingen: Tenant aus Claims und Policy, nicht aus freier Eingabe.
• Daten minimieren: Vertrag, Kontext, Cache und Telemetrie gemeinsam betrachten.
• Lifecycle schließen: Aufbewahrung, Löschung, Rotation und Incident-Zugriff nachweisen.

Plane auch den Incident-Fall. Ein Break-Glass-Zugriff auf geschützte Payloads ist personengebunden, begründet, zeitlich befristet und nachträglich unabhängig überprüfbar. Er darf keine dauerhafte Debugkonfiguration einschalten, die nach dem Incident weiter Vollinhalte sammelt. Bei vermutetem Tenant-Leak stoppt das Team zuerst den betroffenen Datenpfad, sichert minimale Beweise und bestimmt anhand korrelierter Entscheidungslogs den Wirkungsradius. Tokens und Servicekonto-Secrets werden rotiert, ohne sie zur Analyse in Tickets zu kopieren. Anschließend entstehen Regressionstests für genau die verletzte Sichtgrenze. Übungen sollten diesen Ablauf vor Produktion durchspielen: Wer darf sperren, wer genehmigt Break Glass, wo liegen Redaction-Regeln, und wie wird bestätigt, dass Caches und Streams keine alten Daten mehr ausliefern? Governance ist belastbar, wenn der Ausnahmeweg enger und sichtbarer ist als der Normalbetrieb, nicht wenn im Notfall alle Grenzen verschwinden.