|Ben @ Grepture

Warum Ihre KI-Agenten Daten leaken (und wie Sie das stoppen)

KI-Agenten rufen autonom dutzende APIs, Tools und Modelle auf — jeder Schritt ist ein potenzieller Datenleck-Vektor. So schützen Sie die Daten in agentischen Workflows.

KI-Agenten rufen nicht nur eine API auf — sie rufen dutzende auf

Single-Shot-LLM-Aufrufe sind die Architektur von gestern. Die KI-Features, die heute gebaut werden, sind agentisch — sie nutzen Tool Calling, Funktionsausführung, mehrstufiges Reasoning und protokollbasierte Integrationen wie MCP, um komplexe Aufgaben autonom zu erledigen.

Ein Kundensupport-Agent generiert nicht einfach eine Antwort. Er ruft das Ticket des Kunden aus dem CRM ab, zieht die Bestellhistorie aus einer Datenbank, prüft den Versandstatus über eine Logistik-API, erstellt eine Antwort mit einem LLM und schreibt eine Zusammenfassung zurück ins CRM. Fünf externe Aufrufe. Eine Nutzernachricht.

Jeder dieser Aufrufe ist ein potenzieller Datenleck-Vektor. Nicht das Modell selbst — die Daten, die durch die Pipeline fließen. Name, E-Mail, Telefonnummer und Bestelldetails des Kunden fließen von System zu System zu System, oft zu verschiedenen Providern, in verschiedenen Jurisdiktionen, mit verschiedenen Aufbewahrungsrichtlinien.

Das Sicherheitsmodell für einzelne LLM-API-Aufrufe deckt das nicht ab. Wenn Ihr Agent autonom entscheidet, ein externes Tool aufzurufen und Konversationskontext dorthin übergibt, brauchen Sie Schutz, der bei jedem Hop greift — nicht nur beim ersten.

Wie agentische Workflows neue Leak-Vektoren schaffen

Traditionelle LLM-Integrationen haben einen einfachen Datenfluss: Ihre App sendet einen Prompt, bekommt eine Antwort. Eine Anfrage, ein Provider. Agenten brechen dieses Modell auf mehrere Arten.

Tool Calling und Funktionsausführung

Wenn ein LLM entscheidet, eine Funktion aufzurufen, übergibt es Argumente, die oft Daten aus früheren Teilen der Konversation enthalten. Das Modell extrahiert, was es für das Tool als nötig erachtet, aus der Nutzernachricht und dem bisherigen Kontext — und es ist nicht zurückhaltend dabei.

Ein Terminplanungs-Agent, der gebeten wird, „Sarah Müllers Termin zu verschieben", ruft möglicherweise Ihre Kalender-API mit dem vollen Namen auf, dann eine E-Mail-API mit Name und E-Mail-Adresse, dann aktualisiert es einen CRM-Eintrag mit all dem zusammen. Der Nutzer hat seinen Namen einmal genannt. Er landete in drei externen Systemen.

Das Risiko multipliziert sich, weil der Entwickler zur Laufzeit nicht bestimmt, was das Modell in Tool-Call-Payloads aufnimmt. Sie definieren das Funktionsschema, aber das Modell entscheidet, welche Werte es übergibt. Sie können nicht jede Kombination zur Entwicklungszeit prüfen.

Mehrstufige Ketten

Agentische Workflows akkumulieren Kontext über Schritte hinweg. Schritt 3 hat Kontext aus Schritten 1 und 2. Schritt 5 hat Kontext aus allen vier vorherigen Schritten. Personenbezogene Daten, die an irgendeinem Punkt eingeführt werden, können sich durch die gesamte Kette verbreiten.

Ein Research-Agent, der mit dem Abrufen eines Kundenprofils (mit PII) beginnt, könnte diesen Kontext durch zehn nachfolgende Tool-Aufrufe tragen — Zusammenfassung, Klassifizierung, Datenbankschreibvorgänge, API-Aufrufe — jeder erhält Daten, die der Nutzer einmal erwähnt hat, Schritte zuvor.

MCP und Tool-Integrationen

Das Model Context Protocol (MCP) standardisiert, wie LLMs sich mit externen Tools und Datenquellen verbinden. Es ist leistungsstark und wächst schnell. Es bedeutet aber auch, dass jedes über MCP verbundene Tool Daten aus dem Konversationskontext empfangen kann — einschließlich Daten, die der Nutzer nie mit diesem spezifischen Tool teilen wollte.

Ein MCP-Server für Dateiverwaltung, der mit demselben Agenten verbunden ist wie ein MCP-Server für E-Mail, bedeutet, dass beide potenziell Kontext voneinander empfangen können. Die Tool-Grenze, die Entwickler annehmen, ist durchlässig.

RAG plus Agenten

Retrieval-Augmented Generation birgt bereits Datenrisiken — Ihre Retrieval-Pipeline zieht Dokumente, die PII aus nicht zusammenhängenden Datensätzen enthalten können. Wenn RAG in einen agentischen Workflow einfließt, fließen diese abgerufenen Dokumente (und die PII darin) durch jeden nachfolgenden Schritt.

Agent ruft 10 Dokumente mit Kundendaten ab → nutzt LLM zur Zusammenfassung → ruft externe API mit Zusammenfassung auf. Die PII aus diesen 10 Dokumenten hat gerade Ihre Infrastruktur verlassen, eingebettet in eine Zusammenfassung.

Memory und Persistenz

Agenten mit Erinnerung über Sessions hinweg — über Vektordatenbanken, Konversationslogs oder dedizierte Memory-Systeme — erzeugen persistente Speicher personenbezogener Daten, die nicht mit DSGVO-Betroffenenrechten im Sinn entworfen wurden. Der Name und die Problembeschreibung eines Nutzers, gespeichert in einer Vektordatenbank für „Kontext", wird zur Verarbeitung personenbezogener Daten, die schwer zu auditieren, schwer zu finden und schwer zu löschen ist.

Ein konkretes Beispiel

Ein Kundensupport-Agent bearbeitet ein eingehendes Ticket:

  1. Ruft Ticket ab von der Helpdesk-API — Ticket enthält Kundenname, E-Mail, Telefonnummer, Kontodaten
  2. Fasst zusammen mit einem LLM — voller Ticket-Inhalt (mit PII) geht an den Modell-Provider
  3. Prüft Bestellung über E-Commerce-API — übergibt Kundenkennung und Kontext
  4. Erstellt Antwort mit einem LLM — PII aus dem Ticket plus Bestelldaten nun im Prompt
  5. Schreibt CRM-Notiz über CRM-API — Zusammenfassung mit PII fließt an ein viertes System

Ein Support-Ticket. Personenbezogene Daten jetzt in fünf Systemen — Ihr Helpdesk, LLM-Provider, E-Commerce-Plattform, erneut LLM-Provider und CRM. Jeweils mit unterschiedlichen Aufbewahrungsrichtlinien, unterschiedlichen AVVs, unterschiedlichen Unterauftragsverarbeiter-Ketten.

Warum traditionelle API-Level-Schutzmaßnahmen für Agenten nicht funktionieren

Die meisten aktuellen Ansätze für LLM-Sicherheit wurden für das Single-Call-Modell entwickelt. Sie greifen bei agentischen Architekturen aus konkreten Gründen zu kurz.

Client-seitige Guardrails schützen nur den ersten Hop. Wenn Sie PII-Erkennung in Ihrem Anwendungscode vor dem LLM-Aufruf hinzufügen, deckt das die initiale Anfrage ab. Aber wenn der Agent anschließend autonom Tool-Aufrufe macht, sind Ihre Anwendungsebenen-Prüfungen nicht involviert. Der Agent entscheidet, was er aufruft und welche Daten er einbezieht.

Modellspezifische SDKs decken Tool-Call-Payloads nicht ab. OpenAIs Moderation-API prüft Chat Completions. Sie scannt nicht, was Ihr Agent an Salesforce, Jira oder Ihre internen APIs via Function Calling sendet. Die Tool-Aufrufe passieren auf der Modellebene, außerhalb Ihres SDK-Wrappers.

Rate Limiting und API-Schlüssel verhindern nicht, dass Daten im Payload sind. Sie können einschränken, welche Tools ein Agent aufrufen kann und wie oft. Aber wenn der Tool-Aufruf autorisiert ist, kümmert sich Rate Limiting nicht darum, dass das Payload eine Sozialversicherungsnummer enthält.

Code-Time-Review skaliert nicht auf Runtime-Entscheidungen. Bei traditionellen API-Integrationen schreibt ein Entwickler das Prompt-Template und ein Reviewer kann prüfen, welche Daten hineinfließen. Bei Agenten konstruiert das Modell Payloads dynamisch zur Laufzeit. Die Kombinationen sind unbegrenzt.

Was Sie brauchen, ist Schutz auf der Netzwerkebene — etwas, das jede ausgehende Anfrage inspiziert, unabhängig davon, was sie ausgelöst hat, welches Tool sie initiiert hat oder an welchen Provider sie geht.

Der Proxy-Ansatz: jede Anfrage, jede Antwort, jeden Tool-Aufruf scannen

Ein Proxy sitzt zwischen Ihrer Infrastruktur und allen externen Endpunkten. Jede ausgehende HTTP-Anfrage passiert ihn — ob diese Anfrage von Ihrem Anwendungscode, einem Tool-Aufruf des LLMs oder einer autonomen Entscheidung des Agenten initiiert wurde.

Das ist die Architektur, die für agentische KI tatsächlich funktioniert:

Jede ausgehende Anfrage wird gescannt. PII-Erkennung läuft auf dem gesamten Traffic — Chat Completions an OpenAI, Tool-Aufrufe an Salesforce, Webhook-Payloads an Slack. Dieselben Erkennungsregeln gelten unabhängig vom Ziel. Eine E-Mail-Adresse ist eine E-Mail-Adresse, ob sie an Anthropics API oder die REST-Schnittstelle Ihres CRMs geht.

Jede Antwort wird ebenfalls gescannt. Daten leaken nicht nur in eine Richtung. LLM-Antworten, Tool-Call-Responses und RAG-Retrieval-Ergebnisse können PII enthalten, die nicht gespeichert, geloggt oder weitergeleitet werden sollten. Bidirektionales Scanning erfasst beide Richtungen.

Mask and Restore bewahrt die Agent-Funktionalität. Der Agent muss funktionieren. Permanentes Redigieren von Daten bricht mehrstufige Workflows, in denen Entitäten über Aufrufe hinweg konsistent sein müssen. Mask and Restore ersetzt PII durch Tokens, die der Agent konsistent verfolgen und verwenden kann, während echte Daten Ihre Infrastruktur nie verlassen.

Erkennung ist einheitlich über Provider hinweg. Sie brauchen keine separate PII-Erkennung für jedes Tool, Modell oder jede API. Ein Regelsatz — Regex-Muster für strukturierte Daten, KI-Modelle für Namen und Orte — deckt alles ab, was durch den Proxy fließt.

Audit-Trail deckt die gesamte Kette ab. Jede Anfrage, jede Erkennung, jede Aktion — an einem Ort protokolliert. Wenn Ihr Compliance-Team fragt „wohin sind die Daten dieses Kunden gegangen?", können Sie die gesamte Agent-Ausführungskette nachverfolgen.

Grepture ist dafür gebaut. Leiten Sie den Traffic Ihres Agenten durch den Proxy und jeder ausgehende Aufruf — an LLM-Provider, Tool-APIs, MCP-Server — wird automatisch gescannt. Siehe den Quickstart-Leitfaden zur Einrichtung oder erfahren Sie, wie Grepture funktioniert.

Praktische Checkliste zur Absicherung agentischer KI

Wenn Sie KI-Agenten bauen oder betreiben, sollten Sie Folgendes tun:

  • Kartieren Sie jede externe API, die Ihre Agenten aufrufen können. Nicht nur LLM-Provider — jedes Tool, jeden MCP-Server, jeden Webhook. Sie können nicht schützen, was Sie nicht sehen.
  • Leiten Sie den gesamten Agent-Traffic durch einen Proxy mit PII-Erkennung. Das ist der einzige Weg, um konsistente Abdeckung über autonome Tool-Aufrufe zu erreichen.
  • Aktivieren Sie Erkennung für Tool-Call-Payloads. Chat Completions sind nur ein Teil des Traffics. Funktionsaufruf-Argumente und -Antworten brauchen dieselbe Prüfung.
  • Überwachen Sie Agent-Memory und Persistenz-Schichten. Vektordatenbanken, Konversationslogs und Session-Speicher können akkumulierte PII enthalten. Auditieren Sie, was gespeichert wird, und setzen Sie Aufbewahrungsrichtlinien.
  • Richten Sie Alerts für unerwartete Datenmuster ein. Agent ruft einen neuen Endpunkt auf, den Sie noch nie gesehen haben? Ungewöhnliche Datenvolumen? Das sind Signale, die es wert sind, untersucht zu werden.
  • Wenden Sie Least-Privilege auf den Tool-Zugang von Agenten an. Nicht jedes Tool braucht Zugang zu jedem Kontextdatum. Beschränken Sie, was Tools sehen können und welche Daten sie erhalten.
  • Audit-Logs: Verfolgen Sie den Datenfluss über die gesamte Ausführungskette. Wenn etwas schiefgeht — und bei Agenten ist der Blast Radius größer — müssen Sie genau nachverfolgen können, welche Daten wohin, wann und warum geflossen sind.

Zu Prompt-Injection-Risiken speziell bei Agenten (wo indirekte Injection durch Tool-Antworten besonders gefährlich ist) siehe unseren Prompt-Injection-Präventionsleitfaden. Für allgemeine Leitlinien zum Schutz von LLM-Traffic beginnen Sie mit Sensible Daten in LLM-API-Aufrufen schützen.

Kernaussagen

Agenten multiplizieren Ihre Datenleck-Oberfläche. Jeder Tool-Aufruf, jede mehrstufige Kette, jede MCP-Verbindung, jeder Memory-Schreibvorgang ist ein potenzieller Leak-Vektor. Und anders als bei Single-Shot-LLM-Aufrufen treffen Agenten diese Entscheidungen autonom zur Laufzeit.

Client-seitige Schutzmaßnahmen decken autonome Agent-Entscheidungen nicht ab. Modellspezifische SDKs scannen keine Tool-Call-Payloads. Code-Time-Review berücksichtigt kein dynamisches Laufzeitverhalten.

Proxy-Level-Scanning ist die Architektur, die funktioniert — ein Inspektionspunkt, der den gesamten Agent-Traffic einheitlich abdeckt, unabhängig davon, welches Tool oder welchen Provider der Agent aufruft. Kombiniert mit Mask and Restore arbeiten Ihre Agenten weiter, während echte Daten in Ihrer Infrastruktur bleiben.

Die Agenten, die Sie heute bauen, sind leistungsfähiger als je zuvor. Stellen Sie sicher, dass die Daten, die durch sie fließen, bei jedem Schritt geschützt sind.

Sehen Sie, wie Grepture KI-Traffic schützt — die Einrichtung dauert unter fünf Minuten.