Was ist AI Application Security? Vom Code bis zur Runtime

Was ist AI Application Security?

AI Application Security schützt Anwendungen mit KI-Modellen, Agenten und Daten-Pipelines vor Bedrohungen in Code, Cloud-Infrastruktur und Runtime-Verhalten. Das ist wichtig, weil KI-Anwendungen neue Angriffsflächen mitbringen, etwa Prompt Injection, Training Data Poisoning und den Missbrauch autonomer Agenten. Für solche Risiken wurden klassische AppSec-Tools nie entwickelt.

Wichtig ist die Abgrenzung: Dieser Artikel behandelt die Absicherung KI-gestützter Anwendungen selbst. Davon zu unterscheiden ist KI, die bestehende Sicherheits-Workflows verbessert, etwa beim Code-Scanning oder bei der automatisierten Alarm-Triage. Beides ist sinnvoll, löst aber unterschiedliche Probleme.

Was unterscheidet eine KI-Anwendung von einer klassischen? Neben dem Anwendungscode umfasst sie trainierte Modelle, Inferenz-Endpunkte (APIs, die Modellvorhersagen ausliefern) und Vektordatenbanken (Speicher für Embedding-basierte Suche). Dazu kommen RAG-Pipelines, bei denen Modelle per Retrieval-Augmented Generation Kontext aus externen Wissensdatenbanken abrufen.

Hinzu kommen Ebenen für die Agenten-Orchestrierung und Anbindungen an externe Tools. Diese Komponenten erweitern die Angriffsfläche grundlegend, denn Code, Daten, Infrastruktur und Verhalten sind gleichzeitig betroffen.

Warum AI Application Security jetzt wichtig ist

Unternehmen führen KI schneller ein, als sich Sicherheitsprogramme anpassen können. Laut dem Report Wiz State of AI in the Cloud 2025 nutzt die große Mehrheit der Unternehmen inzwischen KI-Services oder -Tools in ihren Cloud-Umgebungen.

KI-Anwendungen gehen zudem schneller live als klassische Software. Treiber sind KI-gestütztes Programmieren, Managed AI Services ohne Sicherheitsfreigabe und die schnelle Integration von Modellen externer Anbieter.

Aus diesem Tempo entsteht ein wachsendes Problem: Shadow AI. Entwicklungsteams nutzen Managed Services wie Amazon SageMaker, Google Vertex AI oder Azure OpenAI Service ohne zentrale Kontrolle. Laut dem Work Trend Index von Microsoft bringen 78 % der KI-Nutzenden eigene Tools zur Arbeit mit, was Datenrisiken außerhalb offizieller Kontrollen verstärkt.

Was Sicherheitsteams nicht sehen, können sie nicht schützen. Automatische Agentless-Erkennung ist daher die Grundlage.

Ein typisches Szenario: Ein Data-Science-Team startet ein Vertex-AI-Notebook mit öffentlicher IP und weitreichenden IAM-Berechtigungen, um ein per Fine-Tuning angepasstes Modell zu testen. Ohne zentrale Transparenz weiß das Sicherheitsteam nichts von diesem Endpunkt. Noch weniger ahnt es, dass darüber sensible Trainingsdaten offen im Internet liegen.

Auch die Regulierung zieht nach. Die OWASP Top 10 for LLM Applications, das NIST AI Risk Management Framework und der EU AI Act legen fest, wie Unternehmen KI-Systeme absichern sollen.

Wer KI-Sicherheit erst nachträglich angeht, schafft technische und regulatorische Risiken. Für Verstöße gegen verbotene Praktiken sieht der EU AI Act Bußgelder von bis zu 35 Mio. € vor.

Unterschiede zwischen AI Application Security und klassischer AppSec

Klassische Anwendungssicherheit konzentriert sich auf bekannte Muster: Schwachstellen im Code, fehlerhafte Abhängigkeiten, Fehlkonfigurationen und Injection-Angriffe mit deterministischen Ein- und Ausgaben. KI-Anwendungen hebeln diese Annahmen grundlegend aus.

Der entscheidende Unterschied: In der klassischen AppSec ist der Code die Anwendung. Bei AI Application Security gehören auch das Modell, seine Trainingsdaten und die aufrufbaren Tools dazu.

Hinzu kommen die Identität, unter der das Modell läuft, und die Cloud-Services, von denen es abhängt. Sicherheit muss all diese Ebenen gemeinsam betrachten.

Typische Sicherheitsrisiken in KI-Anwendungen

KI-Anwendungen bringen Risiken auf vier Ebenen mit: im Modell selbst, in der Daten-Pipeline, in der Anwendungslogik einschließlich Agenten und in der Cloud-Infrastruktur. Am kritischsten wird es, wenn Schwächen auf mehreren Ebenen zusammentreffen.

Prompt Injection und Eingabemanipulation

Bei einer Prompt Injection formuliert jemand Eingaben so, dass das Modell seine Anweisungen umgeht, System-Prompts preisgibt oder nicht vorgesehene Aktionen ausführt. Eine direkte Prompt Injection erreicht das Modell über die Nutzereingabe. Die indirekte Variante ist subtiler: Angreifer verstecken Anweisungen in einem Dokument oder einer Datenquelle, die ein RAG-basierter Assistent abruft und befolgt.

Ein Beispiel: Ein Angreifer platziert schädliche Anweisungen in einem PDF in der Wissensdatenbank eines Unternehmens. Ruft ein interner Assistent dieses Dokument für eine Antwort ab, folgt er den versteckten Anweisungen und schleust Daten aus dem angebundenen Vektor-Datastore aus.

Statische Codeanalyse erkennt solche Angriffe nicht, weil sie vollständig von Eingaben zur Runtime abhängen. Deshalb sind Guardrails gegen Prompt Injection und Runtime-Monitoring unverzichtbar.

Training Data Poisoning und Offenlegung von Daten

Kompromittierte oder offengelegte Trainingsdaten untergraben die Integrität eines Modells auf zwei Wegen. Beim Data Poisoning schleusen Angreifer manipulierte Beispiele in Trainings-Datasets ein, sodass das Modell falsches oder schädliches Verhalten lernt. Bei Datenlecks merkt sich das Modell sensible Informationen aus dem Training, etwa PII oder Zugangsdaten, und gibt sie in seinen Outputs wieder.

Wer auf die Datastores hinter KI-Pipelines zugreifen oder sie manipulieren kann, macht jeden Output des Modells unzuverlässig. Ein gutes Beispiel ist die von Wiz Research entdeckte, offen zugängliche DeepSeek-Datenbank mit Chatverläufen und Betriebsdaten. Sie zeigt, wie schnell ein falsch konfigurierter Datastore einen kompletten KI-Betrieb offenlegen kann.

Schwachstellen in der KI-Lieferkette

Die KI-Lieferkette reicht über klassische Bibliotheken und Pakete hinaus. Dazu gehören Modelldateien mit möglicherweise serialisiertem Schadcode, KI-SDKs wie LangChain und Hugging Face Transformers, vortrainierte Gewichte aus externen Quellen und Prompt-Templates. Zusammen bilden sie die Lieferkette von KI-Anwendungen.

Anders als klassische Abhängigkeiten lassen sich Modellgewichte und Datenartefakte mit Standard-Tools für SAST oder SCA kaum prüfen. Eine manipulierte Modelldatei, die per Pickle-Deserialisierung in Python geladen wird, führt sofort beliebigen Code auf dem Host aus.

Missbrauch von Agenten und Tools

Agentische KI bringt eine grundlegend neue Risikokategorie mit. Gemeint sind Systeme, in denen Modelle selbst entscheiden, welche Tools sie aufrufen, auf welche Daten sie zugreifen und welchen Code sie ausführen. MCP-Server (Model Context Protocol) legen fest, welche Tools und Datenquellen ein Agent erreicht.

Sind Tool-Definitionen zu großzügig, wächst der Schadensradius eines kompromittierten Agenten erheblich. Er kann dann in Datenbanken schreiben, Shell-Befehle ausführen oder externe APIs aufrufen.

Die meisten Sicherheitsprogramme konzentrieren sich auf das Modellverhalten und übersehen die Berechtigungen und Fähigkeiten der Agenten, die diese Modelle umgeben. Genau hier wächst die Lücke in der KI-Sicherheit derzeit am schnellsten.

Fehlkonfigurationen von KI-Services in der Cloud-Infrastruktur

Managed AI Services wie SageMaker-Endpunkte, Vertex-AI-Notebooks und Azure-ML-Workspaces sind Cloud-Ressourcen. Für sie gelten dieselben Fehlkonfigurationsrisiken wie für jede andere Infrastruktur: öffentliche Erreichbarkeit, unverschlüsselte Endpunkte, zu weit gefasste IAM-Rollen und fehlende Netzwerkkontrollen.

Ein SageMaker-Endpunkt ohne Verschlüsselung, dessen IAM-Rolle breiten Zugriff auf einen S3-Bucket mit sensiblen Trainingsdaten gewährt, ist eine ernsthafte Angriffsfläche. Das gilt unabhängig davon, wie gut das Modell selbst abgesichert ist. KI-Sicherheit lässt sich deshalb nicht vom Management des Cloud-Sicherheitsstatus trennen.

AI Application Security vom Code über die Cloud bis zur Runtime

Sicherheit für KI-Anwendungen greift in drei Phasen des Lebenszyklus. Jede Phase deckt andere Risikokategorien ab. Wirksamer Schutz entsteht aber erst, wenn Teams die Signale aus allen drei Phasen verknüpfen.

KI-Sicherheit in der Entwicklung

In der Entwicklungsphase fangen Teams unsichere KI-Muster ab, bevor sie in Produktion gelangen. Dafür scannen sie Code-Repositories und CI/CD-Pipelines auf Probleme, die speziell KI-Workloads betreffen:

• Eingebettete Secrets: API-Schlüssel für OpenAI, Anthropic oder KI-Services in der Cloud stehen hartcodiert in Quelldateien.

• Verwundbare KI-Bibliotheken: Veraltete Versionen von LangChain, Hugging Face Transformers oder anderen KI-SDKs enthalten bekannte CVEs.

• Unsicheres Laden von Modellen: Deserialisierungsmuster können Schadcode aus nicht vertrauenswürdigen Modelldateien ausführen.

• Zu großzügige Agenten-Definitionen: Tool-Konfigurationen geben Agenten uneingeschränkten Schreibzugriff auf Datenbanken oder erlauben Shell-Befehle.

KI-Sicherheit in der Cloud-Infrastruktur

Nach dem Deployment übernimmt das Management des Sicherheitsstatus. Teams erfassen alle KI-Services in der Umgebung einschließlich Shadow AI und prüfen deren Konfigurationen gegen Sicherheits-Baselines. Außerdem ordnen sie jedem Workload seine Identitätsberechtigungen zu.

Eine AI Bill of Materials (AI-BOM) inventarisiert Modelle, SDKs, Agenten-Konfigurationen und Datenabhängigkeiten in der gesamten Umgebung. So erhalten Teams ein vollständiges Bild ihrer KI-Lieferkette in der Cloud. Wo KI-Services ständig starten und wieder verschwinden, erfasst API-basiertes Agentless-Scanning nach Cloud-Native-Prinzip alles ohne Abdeckungslücken.

KI-Sicherheit zur Runtime

Runtime-Monitoring erkennt Bedrohungen, die erst im realen Einsatz auftreten. Dazu zählen Prompt-Injection-Versuche, die statische Analysen umgehen, und Agenten, die ihre vorgesehenen Grenzen verlassen. Hinzu kommen Datenabfluss über Modell-Outputs und unerwartete Tool-Aufrufe.

Weil KI-Verhalten nicht deterministisch ist, gehört Runtime-Monitoring zur Pflicht. Nur so lassen sich Bedrohungen erkennen, die entstehen, wenn reale Eingaben in Produktion auf Modelle und Agenten treffen.

Ein Szenario aus der Praxis: Ein Agent soll interne Dokumente zusammenfassen. Plötzlich ruft er eine externe API auf, für die er nie explizit konfiguriert wurde. Auslöser ist eine gezielt formulierte indirekte Prompt Injection in einem abgerufenen Dokument.

Mehrwert von verknüpftem Kontext

Der eigentliche Mehrwert entsteht, wenn Signale aus Entwicklung, Infrastruktur und Runtime zusammenfließen. Eine verwundbare KI-Bibliothek im Code-Scan ist zunächst ein einzelner Schwachstellen-Fund.

Nun läuft dieselbe Bibliothek in einem öffentlich erreichbaren Container. Der zugehörige Service-Account hat Lese- und Schreibrechte auf einen S3-Bucket mit PII-haltigen Trainingsdaten, und eine Netzwerksegmentierung fehlt. Damit entsteht ein kritischer, ausnutzbarer Angriffspfad.

Erst diese Verbindung über Ebenen hinweg macht aus einer Liste von Funden ein priorisiertes Bild des tatsächlichen Risikos.

Vorteile von AI Application Security

Der Wert von AI Application Security zeigt sich in messbaren Ergebnissen statt in Funktions-Checklisten.

Keine blinden Flecken bei KI-Workloads

Kontinuierliche Erkennung und Inventarisierung zeigen Sicherheitsteams, welche KI läuft, wo sie bereitgestellt ist und worauf sie zugreifen kann. Ohne diese Grundlage arbeiten alle anderen Sicherheitskontrollen mit unvollständigen Informationen.

Weniger Risiko durch Fokus auf ausnutzbare KI-Bedrohungen

Durch verknüpfte Signale aus Code, Cloud und Runtime erkennen Teams, welche KI-Probleme tatsächlich erreichbar und folgenreich sind. Sie müssen dann nicht mehr tausende theoretische Funde im kontinuierlichen Schwachstellenmanagement sichten. Kontext bestimmt die Priorität.

Sicherheit im Tempo der KI-Entwicklung

KI-Anwendungen erreichen die Produktion schneller als klassische Software. Sicherheitspraktiken, die sich in bestehende Entwickler-Workflows und CI/CD-Pipelines einfügen, halten Schritt, ohne zum Engpass zu werden. Das Team von Genpact hat mit AI-SPM das Deployment von KI-Anwendungen beschleunigt, dabei Best Practices für Sicherheit angewendet und Anwendungen nach dem Prinzip Secure by Design bereitgestellt.

Stärkerer Compliance-Status für KI-Systeme

Kontinuierliche Bewertung des Sicherheitsstatus und auditfähige Berichte helfen, neue Anforderungen aus dem EU AI Act, dem NIST AI RMF und den OWASP Top 10 for LLM Applications zu erfüllen. Mit kontinuierlicher Transparenz lässt sich Compliance jederzeit belegen, auch wenn das nächste Audit kurzfristig ansteht.

Typische Stolperfallen in Programmen für AI Application Security

Lücken in KI-Sicherheitsprogrammen entstehen selten durch fehlende Tools. Meist liegen sie an Fehlern in Architektur und Betrieb. Die folgenden Muster bringen selbst erfahrene Sicherheitsorganisationen ins Straucheln.

• KI-Sicherheit als reines Modellproblem behandeln: Teams beobachten das Modell, übersehen aber Cloud-Infrastruktur, Identitätsebene und Daten-Pipeline, die den Schadensradius jedes Exploits auf Modellebene bestimmen. Eine Prompt Injection allein ist lästig, auf einem Agenten mit Schreibzugriff auf Datenbanken ohne Netzwerksegmentierung wird sie zum Sicherheitsvorfall.

• Agentenbasierte Ansätze für kurzlebige KI-Workloads nutzen: KI-Services und Container starten und verschwinden in schnellem Wechsel. Tools, die auf jedem Workload einen Agenten brauchen, hinterlassen Lücken in den dynamischsten Teilen der Umgebung.

• Code und Cloud getrennt scannen: Wie dringend eine Schwachstelle in einem KI-SDK ist, hängt von der Internet-Erreichbarkeit des Workloads und den Datenrechten seines Service-Accounts ab. Ohne domänenübergreifende Korrelation können Teams kritische Probleme nicht vom Alarmrauschen unterscheiden.

• Die agentische Ebene ignorieren: Wer Modelle und Infrastruktur absichert, aber Tool-Berechtigungen von Agenten, MCP-Server-Konfigurationen und autonome Entscheidungsgrenzen nicht prüft, lässt die leistungsfähigsten KI-Komponenten unkontrolliert.

Worauf es bei Lösungen für AI Application Security ankommt

Nicht alle KI-Sicherheitstools decken dasselbe ab. Die passende Lösung verbindet die Ebenen des KI-Risikos, statt sie isoliert zu betrachten.

• Abdeckung des gesamten Lebenszyklus vom Code bis zur Runtime: Die Lösung deckt Entwicklung, Cloud-Infrastruktur und Runtime ab statt nur einer Phase.

• Agentless-Erkennung und Inventarisierung: Die Lösung schafft schnell breite Transparenz über KI-Services, Modelle und Datenabhängigkeiten, ohne Agenten auf jedem Workload.

• Cloud-Kontext und Angriffspfadanalyse: Funde werden anhand realer Deployment-Bedingungen wie Netzwerkerreichbarkeit, Identitätsberechtigungen und Datenzugriff bewertet, nicht allein nach Schweregrad.

• Erkennung KI-spezifischer Risiken: Die Plattform erkennt KI-native Bedrohungen wie Prompt Injection, offengelegte Trainingsdaten und Agentenmissbrauch statt nur umetikettierter klassischer Schwachstellen.

• AI Bill of Materials (AI-BOM): Eine AI-BOM inventarisiert KI-Komponenten als Artefakte der Lieferkette und führt Code und Cloud in einer gemeinsamen Ansicht zusammen.

• Integration in bestehende Workflows: Funde landen in den Tools, die Teams bereits nutzen, etwa JIRA, Slack, ServiceNow oder CI/CD-Pipelines.

Der Wiz-Ansatz für AI Application Security

Die Wiz AI Application Protection Platform (AI-APP) verbindet den gesamten KI-Stack von der Entwicklung über die Cloud-Infrastruktur bis zur Runtime in einem einzigen Sicherheitsmodell. Wiz behandelt KI-Sicherheit dabei nicht als eigene Disziplin. Stattdessen fließt sie direkt in bestehende Workflows für Sicherheitsstatus, Schwachstellenmanagement, Identitäten und Datensicherheit in der Cloud ein.

So sichert die Plattform jede Phase des KI-Lebenszyklus ab:

• Entwicklung (Wiz Code): Scannt Repositories und CI/CD-Pipelines und findet unsichere KI-Muster, verwundbare KI-SDKs und eingebettete Secrets.

• Deployment (Wiz Cloud & AI-SPM): Erkennt alle KI-Services einschließlich Shadow AI, bildet die vollständige AI-BOM ab und prüft Konfigurationen gegen strenge Sicherheits-Baselines.

• Runtime (Wiz Defend): Überwacht KI-Traffic in Produktion und erkennt aktiv Prompt Injection, aus dem Ruder laufende Agenten und Datenabfluss.

• Kontextbasierte Priorisierung (Wiz Security Graph): Der Security Graph verknüpft KI-spezifische Risiken mit dem übergreifenden Cloud-Kontext aus Identitätsberechtigungen, Netzwerkerreichbarkeit und Datenklassifizierung. Statt einer Flut isolierter Alarme markiert er toxische Kombinationen, etwa einen öffentlich erreichbaren Agenten, der mit überprivilegierten Cloud-Zugangsdaten auf sensible Trainingsdaten zugreift.

Erfahren Sie, wie Wiz Sicherheitssignale aus Entwicklung, Cloud und Runtime zusammenführt, um Risiken in KI-Anwendungen im Kontext zu bewerten. Wiz in Aktion erleben

Häufig gestellte Fragen