In einem früheren Blogbeitrag, habe ich dargelegt, dass bei einem Modell der Mythos-Klasse der Ort, an dem ein Angriff abgefangen wird, wichtiger ist als die Frage, ob er erkannt wird, und dass der Datenverkehrspfad der einzige Kontrollpunkt ist, den ein logisch denkender Angreifer nicht umgehen kann. Dieser Beitrag überträgt diese Argumentation auf das Unternehmensumfeld: Was bewegt sich tatsächlich auf diesem Pfad, sobald ein Unternehmen KI einsetzt, und warum verändert die Antwort darauf die Art und Weise, wie wir Sicherheit gestalten?
Vor einigen Monaten nahm ich an einer Diskussion über den Einsatz von KI in Unternehmen teil, die so begann wie die meisten dieser Gespräche: Welches Modell sollten wir verwenden? Sollten wir es selbst betreiben oder auf ein öffentliches Modell zugreifen? Wie können wir die Genauigkeit erhöhen und Halluzinationen reduzieren? Alles gute Fragen. Doch niemand fragte, was passiert, nachdem das Modell ausgewählt wurde.
Folgendes passiert: Ein Benutzer sendet einen Prompt. Eine Anwendung empfängt ihn, prüft die Identität des Benutzers, ruft Kontext aus einem Dokumentenspeicher oder einer Datenbank ab und spricht einige interne APIs an. Ein Agent entscheidet möglicherweise, dass ein Tool benötigt wird. Die zusammengestellte Anfrage erreicht das Modell, das daraufhin Tokens generiert. Diese Tokens können eine Antwort sein. Sie können aber auch eine Anweisung darstellen, die den nächsten API-Aufruf, den nächsten Workflow oder eine Änderung in einem führenden System auslöst.
So betrachtet ist das Modell nur eine Komponente in einer viel längeren Kette. Mit dieser Kette meine ich den Inferenzpfad, und diesem Beitrag liegt eine einfache Beobachtung zugrunde: Der Inferenzpfad ist der Datenverkehrspfad.
“Herkömmlicher Datenverkehr überträgt Daten. Inferenzverkehr überträgt Absichten, Kontext und Entscheidungen.”
Was der Inferenzpfad tatsächlich ist
Beim Training lernt ein Modell. Inferenz bezeichnet den Moment, in dem das trainierte Modell zum Einsatz kommt. Wenn ein Mitarbeiter einen Unternehmensassistenten bittet, „die neuesten Ergebnisse zusammenzufassen und eine E-Mail für das Führungsteam zu entwerfen“, durchläuft die Anfrage in etwa folgenden Weg:
Benutzer → Anwendung → Identität → Kontext und Abruf → APIs → Agent → Modell → Tools → Modell → Antwort → Benutzer
Jede Station auf diesem Weg erzeugt Netzwerk- und Anwendungsdatenverkehr. Dieser weist Endpunkte, Latenzen und Routing-Entscheidungen auf und ist mit einer Identität verknüpft. Er überträgt Daten, verbraucht Budget und ist zunehmend mit der Befugnis verbunden, Aktionen auszuführen.
Meine Kollegin Lori MacVittie wies Anfang dieses Jahres auf einen ähnlichen Aspekt hin: Inferenz ist Laufzeitverhalten im Produktivbetrieb und verhält sich wie eine Anwendungsschicht – mit Nutzern, Datenverkehrsmustern, Latenzempfindlichkeit, Ausfallszenarien, Kostenbeschränkungen und Sicherheitsrisiken. Kunal Anand, Chief Product Officer von F5, beschreibt denselben Weg als eine neue Wertschöpfungskette: vom Prompt über den Eingang, durch Workflows und Inferenz und zurück zum Nutzer. Sobald man diese Sichtweise akzeptiert, muss sich auch die Sicherheitsdiskussion entsprechend weiterentwickeln. Mani Ganesan, VP of Product Management AI Security bei F5, untersucht in seinem aktuellen Blogbeitrag, was dieser Wandel für die Angriffsfläche bedeutet: „Ihre KI ist jetzt eine Angriffsfläche. Sind Sie bereit, sie abzusichern?“
Vier Annahmen, von denen wir uns verabschieden sollten
Während CISOs die KI-Sicherheit stärken, sollten wir uns alle von vier Annahmen verabschieden:
- „Es dreht sich alles um das Modell.“ Das Modell steht im Mittelpunkt, weil es der sichtbare Teil ist. Doch der Prompt kann sensible Daten enthalten, beim Abruf können vertrauliche Datensätze herangezogen werden, der Agent kann über API-Zugangsdaten verfügen und das von ihm aufgerufene Tool kann möglicherweise in eine Datenbank schreiben. Nur das Modell abzusichern ist so, als würde man eine Datenbank härten und dabei die Anwendung und die APIs außer Acht lassen, die mit ihr kommunizieren. Die Angriffsfläche erstreckt sich über den gesamten Pfad.
- „Der Übergang vom Pilotprojekt zur Produktion ist eine Frage der Skalierung.“ Ein Pilotprojekt umfasst in der Regel ein Modell, eine Handvoll Benutzer, eine Anwendung und manuell genehmigte Zugriffe. In der Produktion sieht das völlig anders aus. F5s Bericht „2026 State of Application Strategy“ ergab, dass Unternehmen im Durchschnitt sieben KI-Modelle koordinieren. Dabei gaben 77 % an, dass inzwischen die Inferenz und nicht das Training ihre vorherrschende KI-Aktivität ist, während 52 % mehrere Modelle miteinander verketten oder orchestrieren. Das ist nicht dieselbe Architektur mit mehr Benutzern, sondern eine andere Architektur – und das Sicherheitsmodell muss sich entsprechend ändern.
- „Geschwindigkeit, Sicherheit und Governance sind separate Ebenen.“ Nehmen wir einen Prompt, der personenbezogene Daten enthält. Auf dem Weg vom Benutzer zum Modell muss diese Anfrage geprüft, gemäß den Richtlinien anonymisiert, an ein zugelassenes Modell weitergeleitet, überwacht und für Auditzwecke protokolliert werden – und das alles während der Übertragung. Derselbe Entscheidungspunkt, der die Frage „Wohin soll diese Anfrage weitergeleitet werden?“ beantwortet, muss nun auch klären: „Darf sie überhaupt dorthin weitergeleitet werden?“ Das ist eine einzige Entscheidung bei der Verarbeitung des Datenverkehrs und nicht drei nachträglich miteinander verknüpfte Funktionen.
- „Wir können Einzellösungen miteinander verknüpfen.“ Ein Unternehmen kann den Stack durchaus selbst zusammenstellen: API-Gateway, WAF, DLP, IAM, KI-Schutzmechanismen, ein Modell-Gateway, Observability, SIEM, Agentensteuerung und MCP-Sicherheit. Keines dieser Tools ist an sich schlecht. Das Problem sind die Schnittstellen zwischen ihnen. Stellen Sie sich vor, eine Anfrage durchläuft sechs Kontrollpunkte, jeder mit einer eigenen Richtlinien-Engine und einem eigenen Identitätskontext. Wer weiß, ob der Benutzer, der den Prompt eingegeben hat, dieselbe Identität ist, die nun das Tool aufruft? Wer kann erkennen, dass der API-Aufruf, der Modellaufruf und der Tool-Aufruf Teil ein und derselben Transaktion sind? Wer kann über den gesamten Ablauf hinweg einheitliche Richtlinien durchsetzen und im Nachhinein belegen, was geschehen ist?
In meinem vorherigen Blogbeitrag habe ich darauf hingewiesen, dass ein strategisch denkender Angreifer zuerst nach Schwachstellen an den Übergängen sucht. Dasselbe gilt für einen gut gemeinten Agenten, der schlicht von den Richtlinien abweicht.
Wenn Datenverkehr beginnt, Absichten zu transportieren
KI erweitert die bekannte Abfolge aus Anfrage, Routing, Richtlinienanwendung und Antwort um neue Phasen: Kontext, Abruf, Orchestrierung und Werkzeugaufruf. Die tiefgreifendere Veränderung betrifft jedoch das, was der Datenverkehr transportiert. Herkömmlicher Datenverkehr transportiert Daten. Inferenz-Datenverkehr transportiert Absichten, Kontext und Entscheidungen.
Das ist vor allem bei Agenten von Bedeutung. Ein Assistent, der eine Frage beantwortet, ist eine Sache. Ein Agent, der Kundendaten lesen, Tickets erstellen, E-Mails versenden, Code ausführen, die Infrastruktur verändern oder eine Zahlungsanweisung erteilen kann, ist etwas völlig anderes. Der Inferenzpfad wird zum Aktionspfad, und die Auswirkungen einer Fehlentscheidung beschränken sich nicht mehr nur auf Informationen.
Die Inferenztransaktion ist die neue Sicherheitseinheit
Traditionelle Sicherheitskonzepte betrachten Benutzer, Geräte, Anwendungen, APIs, Workloads und Daten. Zero Trust hat uns gelehrt, nicht nur zu fragen: „Wer sind Sie?“, sondern auch: „Worauf möchten Sie zugreifen?“ KI-Systeme erfordern eine dritte Frage: „Was soll die KI für Sie tun, mit welchen Daten und über welches Modell – und welche Aktionen könnte diese Interaktion auslösen?“
Um diese Frage zu beantworten, ist Kontext erforderlich, über den keine einzelne bestehende Kontrollinstanz verfügt. Stellen Sie sich einen authentifizierten Benutzer eines Finanz-Copiloten vor, dessen Anfrage vertrauliche Finanzdaten in ein externes Modell überträgt, sie an einen Finanzagenten weiterleitet und schließlich die ERP-API aufruft, um eine Zahlungsanweisung zu erstellen. Die Identität des Benutzers allein reicht als Entscheidungsgrundlage nicht aus. Die gesamte Transaktion muss berücksichtigt werden.
Deshalb wachsen Identitätsmanagement, Anwendungssicherheit, API-Sicherheit, KI-Sicherheit und Traffic-Management zusammen. Der gemeinsame Bezugspunkt ist dabei die Inferenztransaktion: Identität plus Prompt plus Kontext plus Modell plus Daten plus Tools plus Ausgabe plus Aktion. Sie ist ein weitaus komplexeres Objekt als eine HTTP-Anfrage.
Sobald man in Transaktionen denkt, ist Sicherheit kein einzelner Kontrollpunkt mehr, sondern wird zu einem kontinuierlichen Kreislauf. Vor der Inferenz stellen sich die Fragen, wer die Anfrage stellt, welche Daten bereitgestellt werden, ob der Prompt bösartig ist und welches Modell ihn erhalten soll.
Während der Inferenz geht es darum, ob die Anfrage den Richtlinien und Budgetvorgaben entspricht und ob ein Agent versucht, ein Tool aufzurufen, für das er nie autorisiert wurde. Nach der Inferenz stellt sich die Frage, ob die Antwort gefahrlos zurückgegeben werden kann, ob sie eine Aktion ausgelöst hat und was protokolliert werden muss. Jede dieser Entscheidungen muss dort getroffen werden, wo der Datenverkehr fließt, denn nur dort liegt der gesamte Kontext gleichzeitig vor.
Was das für CISOs bedeutet
Dieses Muster haben wir schon früher gesehen. Aus Monolithen wurden verteilte Anwendungen, aus Client-Server-Architekturen wurden APIs und Microservices, und die Perimetersicherheit wich identitäts- und anwendungsbezogenen Kontrollen. Jedes Mal gewann die Infrastruktur, die den Datenverkehr bereitstellte und absicherte, strategisch an Bedeutung. Inferenz ist die nächste Phase dieses Zyklus.
Die Frage an Ihr Architekturteam sollte sich also nicht nur darauf beschränken, wo Ihre Modelle ausgeführt werden. Fragen Sie auch, wohin der Inferenzdatenverkehr fließt, welche Daten er transportiert, worauf er zugreifen kann, welche Entscheidungen er trifft und welche Aktionen er auslösen kann. Stellen Sie dann die schwierigste Frage: Wo können wir für all das Richtlinien durchsetzen, ohne die Anwendung auszubremsen?
Denn im KI-Zeitalter verläuft die wichtigste Sicherheitsgrenze möglicherweise nicht mehr um das Modell herum, sondern auf dem Weg zu ihm und von ihm weg.
Weitere Informationen zum Ansatz von F5 finden Sie auf der Seite F5 AI Gateway. Lesen Sie außerdem unbedingt meinen vorherigen Blogbeitrag „Frontier-KI direkt im Datenverkehr stoppen: Warum Inline-Kontrolle ein entscheidender Vorteil gegenüber Modellen der Mythos-Klasse ist.“
Über den Autor
Ähnliche Blogbeiträge
Vier Gründe, warum Sie den F5 Post-Mythos Security Summit nicht verpassen sollten
Holen Sie sich Expertenrat, um Ihre Apps, APIs und Modelle in der Post-Mythos-Welt zu schützen.
Von einer App zu einer Flotte von KI-Agenten: Ein 90-Tage-Framework für KI-Sicherheit
Vermeiden Sie den kostspieligen Ansatz „Erst bereitstellen, später absichern“ – mit einem umfassenden Framework zum Schutz von KI-Modellen, Anwendungen und autonomen Agenten.
Fünf Stufen antifragiler Cyberresilienz verwandeln Praxis in Ergebnisse
Erfahren Sie, wie fünf Stufen antifragiler Resilienz Störungen in adaptive Verhaltensweisen überführen, die Ausfälle begrenzen und hybride Multicloud-Architekturen stärken.
Warum Ihre KI-Richtlinien, Governance und Leitplanken nicht warten können
KI-Richtlinien und -Governance dürfen nicht länger als reine Formalitäten oder Zukunftsthemen betrachtet werden. Sie müssen durch praktische, durchsetzbare Leitplanken ergänzt werden.
Wenn „privat“ nicht privat ist: Wie ChatGPT-Unterhaltungen öffentlich wurden
KI verändert die Arbeitsabläufe in Unternehmen, doch eine übersehene Einstellung hat bereits Tausende vertraulicher Unterhaltungen öffentlich zugänglich gemacht
KI-Nutzung verstehen: Warum Unternehmen Transparenz brauchen
Anstatt einen zu laxen oder zu strengen Ansatz zu verfolgen, können Unternehmen durch mehr Transparenz bei der KI-Nutzung fundierte und durchsetzbare Entscheidungen treffen.