Datensicherheit von KI-Agenten: Was passiert, wenn Agenten sich mit Systemen verbinden?

KI entwickelt sich von der reinen Generierung von Antworten hin zur Ausführung von Aktionen in realen Systemen. Dieser Wandel ändert die zentrale Sicherheitsfrage. Es reicht nicht mehr zu fragen, ob das Modell genau oder vertrauenswürdig ist. Wir müssen auch prüfen, wie sich das umgebende System verhält, wenn das Modell eine Anweisung missversteht, auf schädliche Eingaben stößt oder mehr Befugnisse erhält, als die Aufgabe erfordert. Protokolle wie MCP erleichtern den Aufbau von Verbindungen zwischen Agent und System; sie machen es gleichzeitig unmöglich, das Design dieser Verbindungen zu ignorieren.

Die Anbindung eines KI-Agenten an ein Geschäftssystem kann verschiedene Datenkategorien für unterschiedliche Komponenten offenlegen, etwa den KI-Host, den Tool-Server, den Identity-Provider und die nachgelagerte Anwendung. MCP definiert, wie Teile dieser Verbindung kommunizieren, legt aber nicht fest, welche Daten eine konkrete Implementierung speichert, preisgibt oder aufbewahrt.

Von Antworten zu Konsequenzen

Die Anbindung eines Agenten schafft nicht nur eine Vertrauensgrenze, sondern eine Kette davon: Der KI-Host interpretiert die Anfrage, ein Protokoll-Client wählt eine Funktion aus, ein Tool-Server validiert und übersetzt den Aufruf, ein Identity-Provider stellt fest, wer handelt, und das nachgelagerte System setzt Berechtigungen durch und protokolliert das Ergebnis. MCP standardisiert einen Teil dieser Kommunikation, macht die gesamte Kette aber nicht automatisch sicher. Sicherheit hängt von den Entscheidungen auf jeder Ebene ab.

Die erste Generation weit verbreiteter generativer KI lieferte meist Ausgaben zur menschlichen Überprüfung: Texte, Bilder, Zusammenfassungen und Code. Agenten bedienen zunehmend Tools. Sie versenden Nachrichten, ändern Datensätze, lösen Workflows aus, überweisen Geld und steuern physische Prozesse. Eine plausible, aber falsche Antwort ist ärgerlich; eine plausible, aber falsche Aktion kann sofortige Folgen haben.

Standards wie MCP machen Tools über strukturierte Schnittstellen auffindbar und aufrufbar. Das ist eine wichtige Verbesserung gegenüber Screen Scraping oder improvisierten Integrationen, doch Struktur allein ist keine Sicherheitsrichtlinie. Die Entwickelnden des Tools entscheiden weiterhin, welche Aktionen existieren, welche Eingaben akzeptiert werden, wessen Identität genutzt wird und welche Nachweise zurückgegeben werden.

Auf diesen Unterschied stießen wir beim Aufbau von ezeeps MCP-Server. Druckvorgänge machen das Problem greifbar, weil eine Entscheidung eines Agenten innerhalb von Sekunden zu physischer Ausgabe werden kann. Die Lektion gilt jedoch für jedes operative System.

Wohin die Daten tatsächlich fließen

„Das Modell sieht dein Passwort nie“ ist eine nützliche Aussage, aber sie beschreibt den Datenfluss nicht vollständig. Eine typische Agenten-Verbindung umfasst mehrere Informationskategorien: Anmeldeinformationen, die von einer Authentifizierungsschicht gehandhabt werden; Tool-Argumente, die aus der Anfrage der Nutzenden gebildet werden; operative Ergebnisse, die an das Modell zurückgegeben werden; Geschäftsdaten (Payloads), die an den nachgelagerten Dienst übertragen werden; und Protokolle, die von einer oder mehreren Komponenten aufbewahrt werden. Das Modell erhält in der Regel die Unterhaltung, Beschreibungen verfügbarer Tools, die für den Aufruf eines gewählten Tools nötigen Argumente sowie das von diesem Tool zurückgegebene Ergebnis.

Diese Kategorien folgen nicht zwangsläufig demselben Pfad. OAuth kann Passwörter und Bearer-Token außerhalb des Kontexts des Modells halten, während das Ergebnis des Tools dennoch Kundennamen, Gerätestandorte, Finanzdaten oder interne Systemmetadaten offenlegt. Ein Dokument kann direkt zwischen Diensten übertragen werden, während sein Dateiname, Ziel und Status in der Unterhaltung erscheinen. KI-Host, Tool-Server, Identity-Provider und Zielsystem können außerdem unterschiedliche Protokollierungs- und Aufbewahrungsrichtlinien haben.

Es gibt daher keine verantwortungsvolle, allgemeingültige Behauptung, dass „die KI die Daten nicht sieht“. Die relevanten Fragen lauten: Welche Daten empfängt jede Schicht, warum benötigt sie diese, wie lange werden sie aufbewahrt und ob die Nutzenden diese Grenze verstehen. Unsere eigene MCP-Implementierung liefert konkrete Beispiele für diese Unterschiede, doch das Designproblem betrifft jedes an einen Agenten angeschlossene System.

Die Identität bestimmt den „Blast-Radius“

Ein Agent sollte nicht über eigene Autorität verfügen. Er kann über eine geteilte Dienstidentität handeln oder im Namen eines einzelnen Nutzenden agieren. Keines der Modelle ist grundsätzlich für alle Fälle richtig. Eine geteilte Identität eignet sich für unbeaufsichtigte Workflows, aber jede Aktion übernimmt die Reichweite dieses Kontos. Eine individuelle Autorisierung bietet engeren Zugriff und klarere Zuordnung, verlangt jedoch, dass sich alle Nutzenden authentifizieren und die Anwendung einzelne Sitzungen korrekt verwaltet. Die Interpretation einer Anfrage durch den Agenten darf niemals die vom Zielsystem durchgesetzte Autorisierung ersetzen.

Die entscheidende technische Frage ist nicht, welches Modell abstrakt sicherer klingt. Entscheidend ist, ob die Identität zum Workflow passt und ob ihre Berechtigungen enger gefasst sind als die Konsequenzen eines Fehlers. Bei unserer Arbeit am ezeep MCP unterstützen wir beide Modelle, weil ein automatisierter Lagerdienst und Mitarbeitende, die interaktiv drucken, tatsächlich unterschiedliche Anforderungen an die Identität haben.

Wer trägt die Verantwortung, wenn ein KI-Agent eine Aktion ausführt?

Das ist ein Problem des Systemdesigns, nicht bloß eine Frage des Vertrauens in das Modell. Eine sicherere Architektur kombiniert mehrere Kontrollmechanismen: Identitäten mit minimalen Rechten, eng gefasste und typisierte Fähigkeiten, Validierung im nachgelagerten System, Bestätigung bei folgenschweren Aktionen, Trennung zwischen vertrauenswürdigen Anweisungen und nicht vertrauenswürdigen Inhalten sowie einen Audit-Trail, der zeigt, was tatsächlich passiert ist. Eingrenzung begrenzt den potenziellen Schaden; Beobachtbarkeit und Zurechenbarkeit stellen die Verantwortlichkeit her, nachdem eine Aktion stattgefunden hat.

Design für Umkehrbarkeit

Ein nützlicher Test für jede Fähigkeit eines Agenten ist nicht nur, ob die Aktion erlaubt ist, sondern was passiert, wenn sie falsch ist. Leseoperationen, wiederherstellbare Änderungen, finanzielle Verpflichtungen, externe Kommunikation und destruktive administrative Eingriffe verdienen unterschiedliche Kontrollmechanismen. Manche Aktionen sollten eine Bestätigung erfordern. Manche sollten einen Rollback unterstützen. Andere sollten dem Agenten gar nicht erst zugänglich gemacht werden.

Beim Aufbau des MCP-Servers von ezeep haben wir uns entschieden, das Löschen von Nutzenden, Gruppen oder Druckern nicht zugänglich zu machen, obwohl entsprechende REST-APIs existieren. Das macht die verbleibenden Werkzeuge nicht harmlos – beim Drucken entsteht physischer Output und administrative Werkzeuge können den Zugriff ändern –, aber es schließt eine Klasse irreversibler Fehler aus. Das Prinzip geht über das Drucken hinaus: Das Design von Fähigkeiten sollte die Konsequenzen widerspiegeln, nicht nur die technische Verfügbarkeit.

Kann Prompt Injection einen KI-Agenten dazu bringen, eine falsche Aktion auszuführen?

Ja. Ein Agent kann auf Anweisungen stoßen, die in Dokumenten, Webseiten, E‑Mails, Support-Tickets oder Tool-Ergebnissen versteckt sind. Das nennt man üblicherweise indirekte Prompt Injection: Inhalte, die eigentlich als Daten hätten behandelt werden sollen, versuchen stattdessen zu beeinflussen, was der Agent als Nächstes tut.

Dieses Risiko lässt sich nicht lösen, indem man das Modell bittet, „vorsichtig zu sein“. Nicht vertrauenswürdige Inhalte sollten keine Berechtigungen erteilen, das Ziel des Nutzenden ändern, eine höher privilegierte Identität auswählen oder eine Bestätigung umgehen können. Tool-Eingaben erfordern eine deterministische Validierung, folgenschwere Aktionen benötigen Richtlinienprüfungen außerhalb des Modells, und sensible Workflows sollten vertrauenswürdige Anweisungen klar von nicht vertrauenswürdigem Material trennen.

Auch die Tool-Supply-Chain spielt eine Rolle. Tool-Beschreibungen beeinflussen das Verhalten des Modells, daher ist die Anbindung eines neuen Servers selbst eine Sicherheitsentscheidung – nicht nur eine Komforteinstellung.

Sicherheit wird auf jeder Ebene entschieden

Die Anbindung eines Agenten an ein reales System ist eine Designentscheidung, die auf jeder Ebene getroffen wird: welche Aktionen existieren, wessen Identität sie verwenden, welche Daten jede Komponente sieht, was rückgängig gemacht werden kann und was protokolliert wird. MCP standardisiert einen Teil dieser Überlegungen. Den Rest entscheiden die Personen, die die Verbindung aufbauen. Beim MCP-Server von ezeep bedeutete das, sowohl Service- als auch nutzerbezogene Identitäten zu unterstützen und das Löschen von Nutzenden, Gruppen oder Druckern nicht zugänglich zu machen. Jeder Agent wird irgendwann einmal falsch liegen, daher muss die Verbindung für diesen Moment ausgelegt sein — und genau so haben wir den MCP-Server von ezeep gebaut.

Möchtest du ezeep MCP nutzen?

Verbinde unseren MCP noch heute mit deinen Agenten.

Kostenlos Testen