Ihr neuer KI-Agent liest E-Mails, ruft APIs auf, aktualisiert CRM-Datensätze und sendet Nachrichten im Namen Ihres Unternehmens. Genau das macht ihn nützlich — und genau deshalb verdient seine Sicherheitsarchitektur eine kritischere Prüfung als eine Standard-SaaS-Integration.
Klassische Anwendungssicherheit wurde für Systeme konzipiert, die auf authentifizierte Benutzer reagieren. Agentische KI ist anders: Der Agent entscheidet selbstständig, was zu tun ist, welche Tools er aufruft und in welcher Reihenfolge — auf Basis natürlichsprachiger Eingaben von Benutzern, externen Daten und sogar anderen Agenten. Diese Autonomie schafft eine Angriffsfläche, die die meisten IT-Teams noch nicht kartiert haben.
Dieser Artikel behandelt die realen Risiken in agentischen Produktivsystemen — Prompt-Injection, Tool-Missbrauch und Datenexfiltration — sowie die praktischen Gegenmaßnahmen, die IT-Verantwortlichen heute zur Verfügung stehen.
Warum KI-Agenten-Sicherheit ein eigenes Framework braucht
Herkömmliches Threat-Modeling betrachtet Authentifizierung, Autorisierung und Daten während der Übertragung. Diese Kontrollen bleiben wichtig. Aber agentische Systeme bringen drei Eigenschaften mit, die neue Risiken erzeugen:
- Sie verarbeiten nicht vertrauenswürdige Inhalte als Anweisungen. Ein Agent, der eine PDF zusammenfasst, eine eingehende E-Mail verarbeitet oder eine Webseite liest, operiert auf Inhalten, die er nicht selbst erstellt hat. Diese Inhalte können adversarielle Anweisungen enthalten.
- Sie verfügen über Credentials und können Aktionen ausführen. Ein Agent, der mit Ihrem Kalender, Ihrem ERP oder Ihrem File-Store verbunden ist, kann lesen, schreiben und löschen — nicht nur abrufen.
- Ihr Reasoning ist intransparent. Anders als bei einem deterministischen Skript ist der Weg eines Agenten von Eingabe zu Aktion nicht immer vorhersehbar, was Anomalieerkennung erschwert.
Diese drei Eigenschaften kombinieren sich zu Angriffsvektoren, für die es in konventioneller Software keine direkten Entsprechungen gibt.
Die drei zentralen Angriffsvektoren in der agentischen KI-Sicherheit
1. Prompt Injection — der am besten dokumentierte Angriffsvektor
Prompt Injection ist das am besten dokumentierte Risiko in produktiv eingesetzten agentischen Systemen. Das Prinzip: Ein Angreifer bettet adversarielle Anweisungen in Inhalte ein, die der Agent verarbeiten wird — ein Dokument, eine Kundennachricht, eine Webseite. Der Agent, der die eingebettete Anweisung nicht von einer legitimen unterscheiden kann, führt sie aus.
Direkte Injection zielt direkt auf den System-Prompt oder die Benutzeroberfläche ab. Ein Mitarbeiter, der einem internen HR-Agenten eine böswillige Frage stellt, um die Gehaltsdaten eines Kollegen zu extrahieren, ist ein direkter Injection-Versuch.
Indirekte Injection ist subtiler und schwerer abzuwehren. Ein Kunde sendet ein Support-Ticket mit versteckten Anweisungen — vielleicht weißer Text auf weißem Hintergrund in einem Anhang — die den Agenten anweisen, die Gesprächszusammenfassung an eine externe Adresse weiterzuleiten. Der Agent liest das Dokument als Teil seines Workflows und führt den eingebetteten Befehl ohne entsprechende Schutzmaßnahmen aus.
Indirekte Injection-Angriffe wurden an Produktivsystemen demonstriert, die mit E-Mail, Browsern und Document Stores verbunden sind. Bekannte öffentliche Fälle sind EchoLeak (CVE-2025-32711, CVSS 9.3) — eine per E-Mail eingeschleuste indirekte Injection, die in Microsoft 365 Copilot gepatcht wurde — die Datenleck-Schwachstelle in privaten Slack-AI-Kanälen (August 2024) und CVE-2025-53773 für GitHub Copilot. Die grundlegende akademische Taxonomie von Greshake et al. (2023) demonstrierte Angriffe auf E-Mail, Browser und Document Stores.
Praktische Gegenmaßnahmen für dieses Quartal:
- Wenden Sie strenge Eingabe-/Ausgabe-Validierung an jeder Tool-Grenze an — behandeln Sie Daten, die der Agent liest, als nicht vertrauenswürdig und trennen Sie diese von den Anweisungen, die er erhält.
- Verwenden Sie separate System-Prompts, die die erlaubten Aktionen des Agenten explizit einschränken; halten Sie die Anweisungsfläche so schmal wie der Anwendungsfall es erlaubt.
- Implementieren Sie Output-Filtering, um unerwartete Datenmuster zu erkennen (z. B. E-Mail-Adressen oder API-Schlüssel in Agent-Antworten, wo sie nicht hingehören).
2. Tool-Missbrauch — wenn Scope Creep zur Schwachstelle wird
Agenten beziehen ihre Leistungsfähigkeit aus Tools: der Fähigkeit, APIs aufzurufen, Abfragen auszuführen, Dateien zu schreiben, Nachrichten zu senden. Diese Leistungsfähigkeit braucht explizite Scope-Grenzen. Ohne sie kann eine kleine Prompt-Manipulation den Agenten zu Aktionen verleiten, die nie beabsichtigt waren.
Stellen Sie sich einen Agenten vor, der für die Beantwortung interner IT-Helpdesk-Anfragen gebaut wurde. Wenn er auch Schreibzugriff auf das Ticketing-System, das Benutzerverzeichnis und das E-Mail-Relay hat — weil das während der Entwicklung praktisch war — könnte eine präparierte Eingabe ihn anweisen, Admin-Konten zu erstellen, Berechtigungen zu ändern oder Ticket-Daten zu exfiltrieren. Der Agent wird nicht im herkömmlichen Sinne “gehackt”; er erhält einfach eine Anweisung, die er keinen Grund hat abzulehnen.
Das ist weniger ein Modellproblem als ein Designproblem. Die meisten Tool-Missbrauch-Schwachstellen entstehen durch überprivilegierte Agenten.
Praktische Gegenmaßnahmen:
- Wenden Sie Least-Privilege standardmäßig auf Tool-Ebene an. Ein Agent, der Daten liest, braucht selten Schreibzugriff; einer, der schreibt, sollte fast nie Löschberechtigungen haben.
- Definieren Sie explizite Listen erlaubter Aktionen in der Systemkonfiguration Ihres Agenten, anstatt sich auf das Urteilsvermögen des Modells zur Selbstbeschränkung zu verlassen.
- Protokollieren Sie jeden Tool-Aufruf mit vollständigem Kontext — die Eingabe, die ihn ausgelöst hat, das aufgerufene Tool und die zurückgegebene Ausgabe. Was Sie nicht nachverfolgen können, können Sie nicht untersuchen.
- Für hochriskante Tools (Finanzbuchungen, Benutzerverwaltung, externe Kommunikation) verlangen Sie einen menschlichen Bestätigungsschritt vor der Ausführung. Das ist keine Bürokratie; es ist der Unterschied zwischen einem Beinahe-Vorfall und einem Sicherheitsvorfall.
3. Datenexfiltration — das stille Risiko in RAG-Agenten
Agenten mit Zugriff auf interne Knowledge Bases, Datenbanken oder Document Stores führen ein Datenexfiltrations-Risiko ein, das sich von einem Datenbankeinbruch unterscheidet. Es gibt keinen einzelnen Exploit-Punkt — der Agent selbst wird zum Exfiltrationskanal.
Ein Angreifer, der die Eingaben des Agenten beeinflussen kann (per Injection, Social Engineering oder über ein kompromittiertes Benutzerkonto), kann ihn potenziell dazu bringen, sensible Inhalte abzurufen und weiterzuleiten. Da der Agent ein autorisiertes System ist, erscheint der Abruf dem Data Store selbst nicht anomal.
Ein sekundäres Exfiltrationsrisiko entsteht durch Training- und Logging-Pipelines. Wenn Gesprächsprotokolle, abgerufene Dokumente oder Tool-Ausgaben ohne ordnungsgemäße Datenklassifizierung an externe Dienste für Monitoring, Fine-Tuning oder Analytics gesendet werden, können sensible Inhalte über einen völlig anderen Kanal als den überwachten verloren gehen.
Praktische Gegenmaßnahmen:
- Begrenzen Sie Abrufberechtigungen nach Rolle: Ein Agent im Vertriebseinsatz sollte keine HR- oder Finanzdokumente abfragen können, auch wenn der zugrunde liegende Store alle enthält.
- Wenden Sie Datenklassifizierung auf Dokument- oder Datensatzebene an, nicht nur auf Systemebene. Kennzeichnen Sie Inhalte als intern, vertraulich oder eingeschränkt — und setzen Sie diese Kennzeichnungen im Retrieval-Layer des Agenten durch.
- Prüfen Sie, was Ihre Umgebung verlässt. Alle Protokoll- oder Gesprächsdaten, die an einen Drittanbieterdienst (LLM-Anbieter, Monitoring-Plattform) gesendet werden, sollten der gleichen Datenhandhabungsprüfung unterzogen werden, die Sie auf jeden SaaS-Anbieter anwenden.
Eine praktische Sicherheits-Checkliste für produktive Agenten
Bevor Sie ein agentisches System für den Produktiveinsatz freigeben, sollte ein IT-Verantwortlicher jeden dieser Punkte mit Ja beantworten können:
- Operiert jeder Agent mit Least-Privilege-Tool-Zugriff — nur das, was für seine definierte Aufgabe benötigt wird?
- Sind System-Prompts explizit darüber, was der Agent tun darf und was nicht?
- Werden alle Inhalte, die der Agent liest (Dokumente, E-Mails, Webseiten), als nicht vertrauenswürdige Eingabe behandelt, mit angewendeter Output-Validierung?
- Wird jeder Tool-Aufruf mit ausreichend Kontext protokolliert, um zu rekonstruieren, was passiert ist und warum?
- Gibt es menschliche Genehmigungsstufen für irreversible oder weitreichende Aktionen?
- Wurden die durch Agent-Logs und Monitoring-Pipelines fließenden Daten auf sensible Inhalte überprüft?
- Gibt es einen Prozess zur Überprüfung und Aktualisierung von Berechtigungen, wenn sich der Aufgabenbereich des Agenten ändert?
Keiner dieser Punkte erfordert ein neues Sicherheitsprodukt. Die meisten erfordern bewusste Designentscheidungen in der Architektur- und Deployment-Phase — was der richtige Zeitpunkt ist, um sie zu adressieren.
Wen das am meisten betrifft
Sicherheitsrisiken skalieren mit dem Zugriff. Ein Agent mit Nur-Lese-Zugriff auf eine einzelne FAQ-Datenbank trägt minimales Risiko. Ein Agent, der mit Ihrem CRM, Finanzsystem, E-Mail und Kundendaten verbunden ist — wie viele produktive Agenten — trägt ein materielles Risiko, wenn er ohne die oben genannten Kontrollen eingesetzt wird.
Die am stärksten exponierten Organisationen sind typischerweise jene, die schnell vom Prototyp in die Produktion gewechselt sind und den Agenten als eigenständige Anwendung behandelt haben, anstatt als privilegierten Systemakteur. Die Funktionalität funktionierte; die Sicherheitsarchitektur wurde nicht erneut überprüft. Diese Lücke lohnt sich zu schließen, bevor die Agenten-Flotte wächst.
Für einen umfassenderen Überblick, wie Governance, Testing und Sicherheit in einem Agenten-Programm zusammenwirken, lesen Sie unsere Leitfäden zu KI-Agenten-Governance für KMU und Testing von KI-Agenten mit Evals. Wenn Sie prüfen, ob Ihr aktuelles Setup durch die Datenverwaltung von Agenten eine DSGVO-Exposition einführt, behandelt KI-Agenten und DSGVO genau dieses Thema.
Zu verstehen, warum agentische Systeme architektonisch anders sind als einfache Automatisierung, hilft auch, die Sicherheitsanforderungen einzuordnen — Agentic Workflows erklärt ist ein guter Ausgangspunkt, wenn dieser Kontext nützlich ist.
Wie Orange ITS die Sicherheit agentischer KI angeht
Bei Orange ITS werden Sicherheit und Governance von der ersten Designsession an in die Architektur eingebaut — nicht nachträglich nach dem Go-live hinzugefügt. Wenn wir mit einem Kunden den Scope eines Agenten-Projekts definieren, legen wir Tool-Berechtigungen, Datenzugriffsgrenzen, Logging-Anforderungen und menschliche Genehmigungsschwellen fest, bevor eine einzige Zeile Code geschrieben wird.
Das ist Teil einer umfassenderen Engineering-Disziplin, die wir in der gesamten KI-Agenten-Entwicklung anwenden: Das Ziel sind Agenten, die in der Produktion zuverlässig funktionieren — nicht Agenten, die in Demos funktionieren. Für Schweizer und europäische Kunden bedeutet das auch, DSGVO, revDSG und sektorspezifische KI-Act-Pflichten als erstrangige Anforderungen zu behandeln.
Wenn Sie einen Agenten in der Produktion haben — oder kurz davor sind, einen einzusetzen — und eine direkte Bewertung Ihrer aktuellen Sicherheitsarchitektur wünschen, buchen Sie ein 30-minütiges Gespräch mit unserem Team. Wir analysieren Ihre Architektur, identifizieren die konkreten Lücken und geben Ihnen eine priorisierte Liste von Maßnahmen, auf die Sie sofort reagieren können. Nehmen Sie über unsere Kontaktseite Kontakt auf.