Die Sicherheitsdiskussion über KI-Systeme dreht sich in den meisten Unternehmen um die eigene Anwendung. Geprüft wird, was intern gebaut wurde, abgesichert wird, was in der eigenen Umgebung läuft. Diese Sicht ist notwendig und mittlerweile in vielen Organisationen etabliert. Sie greift allerdings zu kurz, weil der überwiegende Teil eines produktiven KI-Systems gar nicht selbst gebaut ist. Das Modell stammt von einem Anbieter, die Vektordatenbank von einem zweiten, die Werkzeuganbindung von einem dritten, und der Konnektor, über den der Agent auf das CRM zugreift, wurde von einem Dienstleister beigesteuert. Die Angriffsfläche beginnt damit lange vor der eigenen Systemgrenze, das Risiko endet aber vollständig im eigenen Haus.
Die Angriffsfläche endet nicht an der Systemgrenze
Ein produktiver Agent hat in aller Regel vier Zulieferungen, die unabhängig voneinander kompromittiert werden können. Das Modell selbst, dessen Verhalten sich mit jedem Anbieterupdate verschiebt, ohne dass das Unternehmen davon erfährt. Die Werkzeuge und Konnektoren, über die der Agent handelt, häufig als Open-Source-Komponente eingebunden und selten mit derselben Sorgfalt geprüft wie eine klassische Bibliothek. Die Wissensbasis, in die Inhalte aus Quellen einfließen, über die niemand vollständig Kontrolle hat. Und die Betriebsplattform, auf der das alles läuft und deren Protokollierung darüber entscheidet, ob ein Vorfall überhaupt rekonstruierbar ist.
Der Unterschied zur klassischen Softwarelieferkette ist die Wirkungsweise. Eine kompromittierte Bibliothek führt Code aus. Eine kompromittierte Wissensquelle oder ein manipuliertes Werkzeugschema führt Sprache ein, und Sprache ist in einem Agentensystem eine Anweisung. Es braucht keinen Exploit im technischen Sinn, es genügt ein Text an der richtigen Stelle. Genau deshalb versagen Prüfmuster, die auf bekannte Schwachstellenklassen ausgerichtet sind, an dieser Stelle vollständig. Sie suchen nach Code, während das Risiko im Inhalt liegt.
Warum Standardprüfungen für Lieferanten hier nicht greifen
In fast jedem Konzern existiert ein etablierter Prozess für die Lieferantenprüfung. Er fragt nach Zertifizierungen, nach Standort der Datenverarbeitung, nach Auftragsverarbeitungsverträgen und nach der Finanzstabilität des Anbieters. Diese Fragen sind richtig und bleiben es. Sie beantworten allerdings keine einzige der Fragen, die bei einem Modell- oder Werkzeuganbieter tatsächlich über das Risiko entscheiden. Eine ISO-Zertifizierung sagt nichts darüber aus, ob Eingaben als Trainingsmaterial verwendet werden. Ein Serverstandort in der Europäischen Union sagt nichts darüber aus, ob das Modell nach einem Update anders auf dieselbe Eingabe reagiert.
Hinzu kommt ein struktureller Unterschied im Verhältnis. Bei klassischer Software ist die eingekaufte Version stabil, bis das Unternehmen ein Update einspielt. Bei einem Modell über eine Schnittstelle verändert sich das Produkt, ohne dass der Kunde eingreift oder informiert wird. Ein Verhalten, das gestern von der eigenen Prüfung abgedeckt war, kann heute abweichen. Damit verliert die einmalige Freigabe ihren Sinn, denn sie bezieht sich auf einen Zustand, der nicht fortbesteht. Wer diesen Punkt nicht adressiert, dokumentiert eine Prüfung, die zum Zeitpunkt des Vorfalls längst überholt ist.
Fünf Nachweise, die vor Vertragsschluss vorliegen müssen
Aus dieser Lage folgen fünf Anforderungen, die sich konkret in eine Beschaffung übersetzen lassen. Erstens eine vertragliche Zusage zur Datennutzung, die ausdrücklich regelt, ob Eingaben und Ausgaben für Training, Auswertung oder Qualitätssicherung verwendet werden und wie lange sie gespeichert bleiben. Zweitens eine Verpflichtung zur Vorabinformation bei Modellwechseln und wesentlichen Verhaltensänderungen, verbunden mit einer Frist, die eine eigene Nachprüfung erlaubt. Drittens ein Zugang zu Protokolldaten in einer Tiefe, die eine Rekonstruktion im Vorfall zulässt, denn ohne diesen Zugang bleibt jede Aufklärung eine Vermutung.
Viertens ein Nachweis über die Herkunft der Komponenten, die der Anbieter selbst zuliefert, in Form einer Stückliste, die auch Modelle, Werkzeugschemata und Prompt-Vorlagen umfasst und nicht nur Bibliotheken. Fünftens das Recht, eigene adversariale Tests gegen die bezogene Leistung durchzuführen, ausdrücklich vertraglich zugesichert. Dieser fünfte Punkt scheitert in Verhandlungen am häufigsten und ist zugleich der wertvollste, weil ohne ihn jede Prüfung an der Anbietergrenze endet. Wer ihn nicht durchsetzen kann, sollte diese Einschränkung wenigstens dokumentieren und in der Risikobewertung sichtbar machen.
Red Teaming über die Anbietergrenze hinweg
Prüfen lässt sich in dieser Konstellation nicht der Anbieter, sondern das zusammengesetzte System unter realistischen Annahmen. Das verändert den Zuschnitt eines Red Teaming Engagements. Statt zu fragen, ob das Modell einem Jailbreak standhält, wird gefragt, was geschieht, wenn eine zugelieferte Wissensquelle manipulierte Inhalte enthält, wenn ein Werkzeugschema mehr Rechte beschreibt als vorgesehen, oder wenn ein Konnektor Antworten liefert, die der Agent als Anweisung liest. Diese Szenarien sind nicht hypothetisch, sondern beschreiben genau die Wege, über die zugekaufte Bestandteile in der Praxis zum Einfallstor werden.
Für die Steuerung folgt daraus eine zweite Kadenz neben der internen. Jede neue Zulieferung durchläuft vor der Freigabe eine Prüfung gegen diese Szenarien. Bei jeder gemeldeten Modell- oder Schnittstellenänderung erfolgt ein gezielter Nachtest der betroffenen Pfade. Und mindestens einmal im Jahr wird geprüft, ob die vertraglichen Zusagen des Anbieters noch dem entsprechen, was tatsächlich gilt, denn Nutzungsbedingungen werden häufiger geändert als Verträge neu verhandelt. Diese zweite Kadenz ist der Teil, der in den meisten Sicherheitsprogrammen bislang fehlt.
Fazit und Empfehlung
Ein KI-System ist zum größeren Teil eingekauft, und die Sicherheitsarbeit muss dieser Tatsache folgen. Für die nächsten neunzig Tage empfehlen wir drei Schritte. Erstens eine Bestandsaufnahme aller externen Bestandteile produktiver KI-Anwendungen, ausdrücklich einschließlich Werkzeugen, Konnektoren und Wissensquellen, weil diese Ebene in bestehenden Verzeichnissen fast nie erfasst ist. Zweitens die fünf Nachweise in den Standardfragebogen der Beschaffung aufnehmen, damit sie nicht von der Verhandlungsstärke des Einzelfalls abhängen. Drittens ein Prüfszenario für zugelieferte Bestandteile definieren und es an einem produktiven System einmal vollständig durchspielen.
ECODYNAMICS prüft im Rahmen von AI Security und Red Teaming genau diese zusammengesetzten Systeme und begleitet Unternehmen dabei, die Anforderungen an Anbieter so zu formulieren, dass sie in der Beschaffung durchsetzbar bleiben. Wir bringen die Angreiferperspektive ein, dokumentieren die Befunde prüfungsfest und übersetzen sie in Vorgaben, mit denen Einkauf und Sicherheitsfunktion tatsächlich arbeiten können. Wenn bei Ihnen gerade Modelle, Agentenplattformen oder Konnektoren beschafft werden, sprechen Sie mit uns, bevor unterschrieben wird.