Skip to content
KI & Innovation, Cyber-Resilienz & Datensicherheit

Die vier Angriffsvektoren, auf die Ihr KI-Sicherheitskonzept nicht ausgelegt ist

Ihr Sicherheitskonzept wurde wahrscheinlich für eine andere Art von KI entwickelt.


Die wichtigsten Erkenntnisse

  • Agentenbasierte KI birgt neue Sicherheitsrisiken, da sie systemübergreifend plant, sich Dinge merkt und handelt, anstatt nach einem einzigen Prompt-Antwort-Zyklus aufzuhören.
  • Manipulierte Trainingsdaten können das Modellverhalten in großem Umfang unbemerkt beeinflussen, selbst wenn das Modell bei Standardtests noch eine normale Leistung zu erbringen scheint.
  • Kompromittierte Vektordatenbanken können die Entscheidungen von Agenten beeinflussen, indem sie den Kontext verfälschen, auf den sich das Modell stützt, wodurch unerwünschtes Verhalten als legitim erscheint.
  • Die Identität unkontrollierter Agenten führt zu einem Problem bei der Zugriffskontrolle in Maschinen-Geschwindigkeit, für dessen Bewältigung herkömmliche, auf den Menschen ausgerichtete Identitätssysteme nicht ausgelegt sind.
  • Auf fehlerhaften Zuständen basierende, aufeinander aufbauende Entscheidungen können zu Fehlern bei mehreren Agenten und Arbeitsabläufen führen, was ein Zurücksetzen und die Wiederherstellung erheblich erschwert.

Die Tools, Kontrollmechanismen und Governance-Richtlinien, über die die meisten Unternehmen verfügen, wurden für Systeme entwickelt, die Fragen beantworten – Abfrage-Tools, Copiloten, generative Assistenten. Systeme, die auf eine Eingabe reagieren und dann aufhören. Wenn etwas schiefging, war der Fehler isoliert. Man korrigierte die Eingabe, passte die Konfiguration an und machte weiter.

Agentenbasierte KI funktioniert nicht auf diese Weise. Diese Systeme planen, merken sich und führen unternehmensweit Aufgaben aus, ohne schrittweise Anweisungen von Menschen zu benötigen. Sie behalten den Systemzustand bei. Sie koordinieren sich mit anderen Agenten. Sie agieren in Produktionssystemen – schreiben in Datenbanken, lösen Workflows aus, treffen Entscheidungen mit maschineller Geschwindigkeit. Dieser architektonische Wandel bringt vier Bedrohungsvektoren mit sich, auf deren Abwehr bestehende Sicherheitskonzepte nie ausgelegt waren. Wenn Ihre KI-Governance-Strategie diese nicht berücksichtigt, bestehen bei Ihnen wahrscheinlich Sicherheitslücken, die Sie möglicherweise gar nicht erkennen.

1. Verfälschte Trainingsdaten

Ein KI-System ist nur so vertrauenswürdig wie die Daten, mit denen es trainiert wurde. Diese Aussage galt schon immer. Was sich geändert hat, ist die Angriffsfläche.

Bei agentenbasierten KI-Implementierungen sind die Trainingspipelines umfangreicher, komplexer und setzen sich häufig aus mehreren Quellen zusammen – interne Daten, Feeds von Drittanbietern, von Anbietern bereitgestellte Datensätze. Jede Abhängigkeit in dieser Kette ist ein potenzieller Einbruchspunkt. Ein böswilliger Akteur, der Trainingsdaten beeinflussen kann – durch Kompromittierung der Lieferkette, Insiderzugriff oder Verunreinigung einer gemeinsam genutzten Datenquelle –, kann das Modellverhalten in großem Maßstab steuern. Was dies besonders gefährlich macht, ist die Tatsache, dass manipulierte Modelle bei Standard-Benchmarks oft normale Ergebnisse liefern. Die Manipulation kann äußerst präzise sein: Sie zielt darauf ab, in bestimmten Kontexten bestimmte Ergebnisse zu erzeugen, während sich das Modell ansonsten korrekt verhält.

Wenn der Effekt erst in der Produktion zutage tritt, ist das Modell bereits seit Wochen oder Monaten im Einsatz, und um die Verunreinigung bis zu ihrer Quelle zurückzuverfolgen, bedarf es genau jener relationalen Datenherkunftsdaten, über die die meisten Unternehmen nicht verfügen. Die Frage, die man sich stellen muss: Können Sie eine vollständige, überprüfbare Aufzeichnung darüber vorlegen, mit welchen Daten Ihre Modelle zu einem bestimmten Zeitpunkt trainiert wurden?

2. Kompromittierte Vektordatenbanken

Vektordatenbanken bilden die Speicherebene agentenbasierter Systeme. Bevor ein Agent handelt, fragt er einen Vektorspeicher ab, um relevante Kontextinformationen – vergangene Interaktionen, Fachwissen, Referenzdaten – abzurufen, die sein weiteres Vorgehen bestimmen. Die meisten Sicherheitsteams betrachten Vektordatenbanken nicht auf dieselbe Weise wie andere Speicherorte für sensible Daten. Das sollten sie aber tun. Eine kompromittierte Vektordatenbank liefert nicht nur falsche Antworten. Sie beeinflusst auch die darauf folgenden Entscheidungen. Eingeschleuste Embeddings – bösartige Inhalte, die in den Vektorspeicher eingefügt wurden – können das Verhalten des Agenten so umleiten, dass es von außen betrachtet völlig legitim erscheint.

Ein Agent, der aufgefordert wird, eine Transaktion zu genehmigen, ruft Kontext ab, der die Genehmigungskriterien subtil umdeutet. Ein Agent, der die Kundenkommunikation verwaltet, ruft Kontext ab, der die Antworten in die vom Angreifer bevorzugte Richtung lenkt. Die Aktion sieht korrekt aus. Die Argumentation wirkt stichhaltig. Aber der zugrunde liegende Kontext wurde manipuliert.

Dieser Angriffsvektor ist besonders schwer zu erkennen, da er unterhalb der Modellebene abläuft. Eine standardmäßige Modellüberwachung kann ihn nicht aufdecken. Das Modell verhält sich genau so, wie es trainiert wurde – nur der Kontext, auf dessen Grundlage es seine Schlussfolgerungen zieht, wurde verfälscht. Die Frage, die Sie sich stellen sollten: Wird Ihre Vektordatenbank als sensible, regulierte Datenressource behandelt – mit Zugriffskontrollen, Integritätsüberwachung und Protokollierung von Prüfungen, die mit denen Ihrer wichtigsten Produktionsdatenbanken vergleichbar sind?

3. Identität eines nicht regulierten Akteurs

In einer Multi-Agenten-Architektur interagieren Agenten nicht nur mit Daten – sie interagieren auch miteinander. Sie erzeugen Unteragenten, delegieren Aufgaben, fordern Ergebnisse an und führen Ergebnisse von Agenten zusammen, mit denen sie nie explizit verbunden waren. Dazu authentifizieren sie sich, legen Berechtigungsnachweise vor und bauen Vertrauen auf.

Die Agentenidentität ist die Zugriffskontrollschicht für das autonome Unternehmen – und sie stellt eine Lücke dar, die Anbieter von Identitätssicherheit und Identitätsanbieter (IDPs) nicht schließen. Ihre Governance-Rahmenwerke sind auf die Identität von Menschen ausgelegt.

Agentenidentitäten, die im Rahmen derselben Regeln erstellt wurden, erscheinen völlig legitim: Sie wurden korrekt bereitgestellt und entsprechen den Richtlinien. Der IDP versagt nicht – ihm fehlt lediglich ein Rahmenwerk, um festzustellen, ob ein Agent außerhalb des Kontexts handelt, für den er erstellt wurde, ob seine Berechtigungen unbemerkt erweitert wurden oder ob er sich an Stellen einmischt, an denen er nichts zu suchen hat.

Diese Sicherheitslücke unterscheidet sich qualitativ von herkömmlichen Angriffen auf Anmeldedaten. Wenn die Anmeldedaten eines menschlichen Nutzers gestohlen werden, agiert der Angreifer im Rahmen der Berechtigungen dieses Nutzers und in menschlichem Tempo. Wird die Identität eines Agenten kompromittiert, erhält der Angreifer Zugriff auf die autonome Entscheidungsebene – die Fähigkeit, Arbeitsabläufe auszulösen, Aktionen zu genehmigen, sich mit anderen Agenten abzustimmen und Daten mit maschineller Geschwindigkeit und in großem Umfang über Kanäle zu exfiltrieren, die völlig normal erscheinen.

Ausfälle auf der Identitätsebene gehören zudem zu denjenigen, die im Nachhinein am schwersten zu erkennen sind. Aktionen eines Agenten, die unter einer kompromittierten Identität ausgeführt werden, wirken nicht anomal – sie sehen aus wie legitimes Agentenverhalten. Und da sie von einem System und nicht von einem Menschen generiert werden, kann das Ausmaß enorm sein, bevor es jemand bemerkt.

Die Recovery verschärft das Problem noch. Die meisten KI-Recovery-Szenarien konzentrieren sich auf die Wiederherstellung von Daten: Trainingsdatensätze, Modellgewichte, Pipeline-Konfigurationen. Die Identität steht selten auf der Liste. Ein System, das mit sauberen Daten, aber falsch ausgerichteten Identitätskonfigurationen wiederhergestellt wird, ist eigentlich nicht wiederhergestellt. Es handelt sich um ein sauberes System mit einer kompromittierten Zugriffsebene. Die Frage, die man sich stellen muss, lautet: Wird die Identität von Agenten mit derselben Sorgfalt verwaltet wie die Identität von Menschen – mit Lebenszyklusmanagement, Zugriff nach dem Prinzip der geringsten Berechtigungen und Einbeziehung in Wiederherstellungsszenarien?

4. Kaskadierende Entscheidungen, die auf einer falschen Zustandsangabe beruhen

Die ersten drei Angriffsvektoren sind punktuell. Dieser hier ist systemisch – und in vielerlei Hinsicht möglicherweise am schwierigsten einzudämmen. Multi-Agenten-Architekturen sind auf Koordination ausgelegt. Agenten teilen den Kontext, geben Ergebnisse untereinander weiter und bauen auf der Arbeit der anderen auf. Diese Koordination macht sie so leistungsfähig. Sie ist aber auch der Grund dafür, dass sich Fehler ausbreiten.

Ein Agent, der mit beschädigtem Speicher arbeitet, fällt nicht sauber aus. Er erzeugt Ergebnisse – Entscheidungen, Aktionen, Daten –, die von anderen Agenten verarbeitet werden. Diese Agenten erzeugen wiederum ihre eigenen Ergebnisse. Bis die ursprüngliche Beschädigung als etwas Beobachtbares zutage tritt, hat der fehlerhafte Zustand möglicherweise bereits Dutzende nachgelagerter Prozesse über mehrere Agenten hinweg beeinflusst, ohne dass es einen sauberen Rollback-Pfad gibt.

Genau das macht die Kontextlücke so bedeutsam. Zu jedem beliebigen Zeitpunkt besteht Ihr KI-System aus einer Modellversion, einem Satz von Trainingsdaten, einem Artefakt-Speicher, einer Pipeline-Konfiguration und einer Reihe aktiver Agenteninteraktionen – all diese Komponenten müssen denselben Betriebszustand widerspiegeln, um ein vertrauenswürdiges, wiederherstellbares System zu bilden. Ist dies nicht der Fall, liegt nicht einfach nur ein Fehler vor. Sie haben ein System, das in seinen Einzelteilen kohärent, als Ganzes jedoch inkohärent ist. Einzelne Tools können jeweils ihren eigenen Ausschnitt überprüfen. Keines kann jedoch bestätigen, dass die einzelnen Teile zusammenpassen. Das ist kein Überwachungsproblem, das sich durch das Hinzufügen eines weiteren Tools lösen lässt. Es handelt sich um eine strukturelle Lücke – und die einzige Möglichkeit, diese zu schließen, ist ein System, das den Zustand der KI relational erfasst: Was lief, mit welchen Daten, in welcher Konfiguration und zu welchem Zeitpunkt?

Die Frage, die Sie sich stellen sollten: Wenn Ihre KI-Infrastruktur heute kompromittiert würde, könnten Sie dann genau feststellen, in welchem Zustand sich jede Komponente vor dem Vorfall befand – und dies auch nachweisen?

Was dies für Ihre Sicherheitsstrategie bedeutet

Jeder dieser vier Vektoren erfordert eine andere defensive Reaktion. Sie haben jedoch eine gemeinsame Konsequenz: Die für die bisherige Ära der KI konzipierten Rahmenbedingungen für Governance und Resilienz decken die Fehlermodi der agentischen Ära nicht ab. Um eine agentische KI zu gewährleisten, muss Ihr Framework in drei Richtungen erweitert werden:

  • Tiefer, in die Daten- und Identitätsschichten, die unterhalb des Modells liegen.
  • Umfassender, um Interaktionen zwischen Agenten abzudecken, die von den bestehenden Überwachungsmaßnahmen nicht erfasst werden.
  • In relationaler Hinsicht geht es darum, nicht nur den Zustand einzelner Komponenten zu erfassen, sondern auch, wie diese zu jedem beliebigen Zeitpunkt zusammenwirken.

Diese letzte Anforderung ist diejenige, mit der sich die meisten Organisationen noch nicht auseinandergesetzt haben. Und genau sie entscheidet darüber, ob Sie – wenn etwas schiefgeht – über ein wiederherstellbares System verfügen oder nur über eine Sammlung von auf den ersten Blick korrekten Berichten, die etwas beschreiben, das nicht mehr existiert. Lesen Sie den Artikel „The Agentic Blind Spot: Why AI Resilience Demands a System of Record“, um zu erfahren, warum Sie ein SOR benötigen, um die Konsistenz und Genauigkeit Ihrer KI-Daten zu gewährleisten.

FAQs

F: Warum sind agentenbasierte KI-Systeme riskanter als herkömmliche generative KI-Tools?

A: Agentenbasierte Systeme können mehr als nur auf Eingabeaufforderungen reagieren. Sie verwalten den Systemzustand, koordinieren sich mit anderen Agenten und führen Aktionen in Produktionsumgebungen durch, wodurch sich die Angriffsfläche weit über die einfache Manipulation von Eingabeaufforderungen hinaus erweitert.

F: Warum sind „vergiftete“ Trainingsdaten so schwer zu erkennen?

A: Die Manipulation kann sehr gezielt erfolgen und nur bestimmte Situationen betreffen, während normale Referenzwerte unberührt bleiben. Das bedeutet, dass ein Modell auf den ersten Blick einwandfrei erscheint, bis das manipulierte Verhalten im tatsächlichen Einsatz zutage tritt.

F: Inwiefern kann eine Vektordatenbank zu einem Sicherheitsproblem werden?

A: Eine Vektordatenbank prägt den Kontext, auf den sich ein Agent stützt, bevor er handelt. Wird dieser Kontext verändert, trifft der Agent möglicherweise Entscheidungen, die auf den ersten Blick vernünftig erscheinen, in Wirklichkeit jedoch von böswilligen Daten geleitet werden.

F: Warum unterscheidet sich die Identität eines Agenten von der Identität eines Menschen?

A: Die Identität eines Agenten ist untrennbar mit autonomen Handlungen, der Delegation von Aufgaben und der Ausführung in Maschinen-Geschwindigkeit verbunden. Herkömmliche Identitätsverwaltung ist auf Menschen ausgelegt, sodass oft übersehen wird, ob ein Agent außerhalb seines vorgesehenen Kontexts handelt.

F: Warum ist die Ausbreitung von Fehlzuständen in Multi-Agenten-Systemen ein so ernstes Problem?

A: Sobald ein Agent fehlerhafte Daten verarbeitet, kann sich dieser Fehler auf nachgelagerte Agenten und Arbeitsabläufe ausbreiten. Die Folge ist nicht nur eine einzelne Fehlentscheidung, sondern eine Kette miteinander verbundener Fehler.

F: Wie können Unternehmen die Sicherheit im Bereich der KI verbessern?

A: Die Governance tiefer in die Daten- und Identitätsschichten ausweiten, die Interaktionen zwischen den Agenten überwachen und den Zustand der KI relational nachverfolgen, damit im Falle eines Vorfalls rekonstruiert werden kann, was genau geschehen ist.

Michael Thelander ist Senior Director für Produktmarketing bei Commvault.

Verwandte Blogbeiträge

Weitere Beiträge zum Thema


Thumbnail_Blog-Data-Access-Governance-2026

Sicherheit für KI durch einheitliche Datenzugriffs-Governance

Erfahren Sie mehr über „Sicherheit für KI durch einheitliche Datenzugriffs-Governance“
Thumbnail_Blog-Environmental-Footprint-AI-2026

Intelligentere Daten, umweltfreundlichere KI

Lesen Sie mehr über „Intelligentere Daten, umweltfreundlichere KI“
Thumbnail_Blog-Anthropic-Project-ResOps-2026

Das Projekt „Glasswing“ von Anthropic spricht für ResOps

Lesen Sie mehr über „Anthropics Projekt Glasswing spricht für ResOps“
Thumbnail_Blog-Data-Rooms-2025-Linkedin

Data Activate: Das Potenzial vertrauenswürdiger Daten für KI-Innovationen erschließen

Lesen Sie mehr über „Data Activate: Das Potenzial vertrauenswürdiger Daten für KI-Innovationen erschließen“
Thumbnail_Blog-AI-Agents-2026

KI-Agenten sind überall. Wissen Sie, was sie tun?

Erfahren Sie mehr über „KI-Agenten sind überall. Wissen Sie, was sie tun?“
Thumbnail_Blog-Building-AI-Agents-2026

Vom Experiment zum Einsatz: Entwicklung von KI-Agenten, denen man wirklich vertrauen kann

Lesen Sie mehr über „Vom Experiment zum Einsatz: KI-Agenten entwickeln, denen man wirklich vertrauen kann“