Security von KI-Systemen in der Cyberabwehr 2026: Bedrohungsmodell, Schutzarchitekturen und empirische Bewertung von LLM-, RAG- und MLOps-Härtung

1. Introduction

Die Cybersecurity-Landschaft des Jahres 2026 ist durch zwei parallele Entwicklungen geprägt: einerseits die breite Operationalisierung von KI in Sicherheitsprodukten, Plattformen und internen Arbeitsabläufen, andererseits die rasch wachsende Angriffsfläche, die durch diese Systeme selbst entsteht. Während klassische Angriffe auf Identitäten, Endpunkte, Netzwerke und Cloud-Workloads weiterhin dominieren, verschiebt sich ein erheblicher Teil der Risikofläche in Richtung AI-gestützter Entscheidungs- und Automatisierungsketten. Große Sprachmodelle, multimodale Modelle, Retrieval-Augmented Generation, autonome Agenten und MLOps-Pipelines sind 2026 keine experimentellen Bausteine mehr, sondern produktive Komponenten in SOCs, DevSecOps-Workflows, Kundenportalen und internen Wissenssystemen. Genau dadurch wird AI Security zu einem operativen Thema der Cyberabwehr und nicht mehr nur zu einer Forschungsfrage.

Die zentrale Herausforderung besteht darin, dass KI-Systeme zugleich Software, Datenverarbeitung, Wissensschnittstelle und Steuerungslogik sind. Ein LLM-basierter Assistent kann Dokumente zusammenfassen, Alerts triagieren, Tickets erstellen, Cloud-Konfigurationen analysieren oder Playbooks triggern. Dieselbe Flexibilität schafft jedoch neue Angriffsformen: Ein manipuliertes Dokument kann über indirekte Prompt-Injection den Modellkontext kompromittieren; ein vergifteter Datensatz kann das Modellverhalten dauerhaft verschieben; ein zu großzügig angebundenes Tool kann von einem Agenten in eine unerwünschte Aktion überführt werden; und eine schlecht segmentierte RAG-Pipeline kann vertrauliche Informationen aus falschen Kontexten vermischen. Damit verschiebt sich die Sicherheitsaufgabe von der reinen Verhinderung technischer Exploits hin zur Sicherung von Semantik, Kontext und Entscheidungsautonomie.

Die Praxis zeigt, dass viele Organisationen ihre KI-Systeme zunächst wie herkömmliche Webanwendungen behandeln. Das ist unzureichend. Ein klassischer WAF kann weder die inhaltliche Instruktionsverschleierung einer Prompt-Injection erkennen noch die subtile Beeinflussung einer Retrieval-Schicht durch versehentlich indexierte Geheimnisse verhindern. Ebenso reicht ein traditionelles IAM-Modell nicht aus, wenn ein Agent im Namen eines Mitarbeiters E-Mails versenden, Jira-Tickets anlegen oder Cloud-Ressourcen konfigurieren darf. Für AI Security braucht es daher eine integrierte Sicht, die klassische Sicherheitsprinzipien wie Least Privilege, Segmentierung, Verschlüsselung, Signierung und Überwachung mit KI-spezifischen Kontrollen wie Prompt-Härtung, Kontextfilterung, Model-Behavior-Evaluation und adversarial testing verbindet.

Diese Arbeit verfolgt drei Ziele. Erstens wird ein präzises Bedrohungsmodell für AI-Systeme in der Cyberabwehr abgeleitet, das Angreiferziele, Trust Boundaries und Schadensdimensionen formal strukturiert. Zweitens wird eine Schutzarchitektur vorgeschlagen, die LLMs, RAG und Agenten in einer mehrschichtigen Defense-in-Depth-Strategie absichert. Drittens wird die Wirksamkeit dieser Maßnahmen experimentell bewertet, um die oft pauschalen Aussagen über „sichere KI“ durch messbare Ergebnisse zu ersetzen. Damit wird ein Rahmen geschaffen, der sowohl für Sicherheitsarchitekten als auch für Incident Responder, Red Teams und Governance-Teams unmittelbar nutzbar ist.

Die Relevanz ist auch regulatorisch und strategisch hoch. Spätestens mit der Verbreitung von AI-Governance-Programmen, strengeren Anforderungen an Datenschutz und Modellnachvollziehbarkeit sowie der zunehmenden Verzahnung von Cloud Security Posture Management, CNAPP und AI-Workloads wird deutlich, dass Sicherheitsverantwortliche ihre Kontrollmodelle erweitern müssen. Hinzu kommt, dass Angreifer KI-gestützte Systeme nicht nur angreifen, sondern ihrerseits zur Skalierung von Social Engineering, Spear Phishing, Reconnaissance und Schadcode-Entwicklung nutzen. AI Security ist deshalb nicht isoliert, sondern Teil der Gesamtverteidigung gegen eine neue Klasse operationalisierter, semantischer und agentischer Angriffe.

2. Background and Related Work

Die wissenschaftliche und industrielle Auseinandersetzung mit AI Security hat sich in den Jahren vor 2026 deutlich verdichtet. Ein früher Orientierungspunkt ist das Feld des adversarial machine learning, das die Verletzlichkeit von Modellen gegenüber manipulierten Eingaben, Datenvergiftung und Inferenzangriffen beschrieb. Bereits Goodfellow et al. zeigten, dass neuronale Netze durch kleine, gezielt konstruierte Perturbationen fehlgeleitet werden können, obwohl die Eingaben für Menschen plausibel bleiben (GOODFELLOW, 2015). Kurze Zeit später systematisierte das NIST in späteren Arbeiten und Leitfäden die robuste Evaluierung und das Risikomanagement für AI-Systeme, während das MITRE ATLAS-Framework Angriffs- und Verteidigungstaktiken für KI-Systeme strukturierte (MITRE, 2023). Parallel dazu entstanden mit OWASP Top 10 for LLM Applications eine praxisnahe Taxonomie der häufigsten Risiken großer Sprachmodelle, etwa Prompt Injection, Insecure Output Handling, Training Data Poisoning und Excessive Agency (OWASP, 2024).

Für den Kontext moderner Sprachmodelle ist die Arbeit von Carlini et al. besonders relevant. Sie zeigten, dass Trainingsdaten teils memorisiert werden und unter bestimmten Bedingungen extrahiert werden können, was direkte Implikationen für Datenschutz und Geheimnisschutz hat (CARLINI et al., 2021). Weitere Arbeiten zu Membership Inference und Model Inversion belegten, dass auch abstrakte Modellparameter keine Garantie gegen Informationslecks sind. Diese Erkenntnisse wurden für LLMs durch spätere Untersuchungen erweitert, die zeigen, dass große Modelle oft sowohl allgemeines Weltwissen als auch fragmente individueller Trainingsdaten reproduzieren können. Für Betreiber bedeutet das, dass Datenminimierung, Kuratierung und Redaction nicht optional sind, sondern Teil der Sicherheitsgrundlage.

Ein zweites großes Themenfeld ist Prompt Injection. Hier hat sich zwischen 2022 und 2026 ein erheblicher Erkenntnissprung vollzogen. Die erste Welle direkter Prompt-Injection-Angriffe zielte darauf, das Modell durch explizite Instruktionskonflikte zu manipulieren. Mit dem Aufkommen von RAG und multimodalen Systemen verschob sich die Bedrohung auf indirekte Prompt Injection, bei der externe Inhalte wie Webseiten, PDFs, E-Mails oder Bilder versteckte Anweisungen tragen und beim Retrieval in den Modellkontext gelangen. Rezende et al. und mehrere industrielle Untersuchungen zeigten, dass LLMs nicht zuverlässig zwischen Nutzdaten und eingebetteten Anweisungen trennen, wenn diese im gleichen Kontextfenster ankommen. Das Problem ist strukturell, weil das Modell keine harte Trennung zwischen „Daten“ und „Code“ kennt, sondern beides als Kontext interpretiert.

Ein drittes Feld betrifft die Sicherheit von Agenten und Tool-Calling. Mit Produkten und Frameworks wie LangChain, LlamaIndex, OpenAI Assistants/Tool-Calling, AutoGen, CrewAI und späteren enterprise-orientierten Orchestratoren entstanden Systeme, die externe Werkzeuge in natürlichen Sprachschleifen steuern. Diese Fähigkeiten sind produktiv wertvoll, erhöhen aber das Risiko von Fehlsteuerung, Privilegienausweitung und ungewollten Transaktionen. Ein Agent, der auf Mail, Kalender, Ticketing, CI/CD oder Cloud-APIs zugreifen kann, braucht dieselbe Strenge wie jeder andere privilegierte Dienstaccount, jedoch ergänzt um semantische Angriffspunkte. Die Forschung zu agentic misuse und tool hijacking verdeutlichte, dass bereits kleine Instruktionsverschiebungen große Folgewirkungen haben können.

Auch die MLOps-Sicherheit ist 2026 ein etabliertes Forschungs- und Praxisfeld. Model Supply Chain Security umfasst Model Signing, Provenance Tracking, Dependency Pinning, Container Hardening und Artefaktintegrität. Angriffe gegen Python-Ökosysteme, etwa typosquatting oder kompromittierte Packages, betreffen KI-Pipelines unmittelbar. Darüber hinaus haben sich Plattformen wie MLflow, Kubeflow, KServe, BentoML und ähnliche Komponenten in produktiven Umgebungen etabliert, sodass ihre Absicherung Teil des Sicherheitsdesigns wird. CNAPP-Ansätze, die Cloud, Kubernetes, Workloads und Identitäten gemeinsam abbilden, werden zunehmend zur Basis für die Beobachtung von AI-Workloads. Gleichzeitig verbessert eBPF die Telemetrie in Linux- und Kubernetes-Umgebungen, indem syscalls, Netzwerkflüsse und Prozessketten ohne invasive Agenten beobachtet werden können.

Die Regulierung hat die Entwicklung zusätzlich beschleunigt. Der EU AI Act, die NIST AI Risk Management Framework Version 1.0, ISO/IEC 42001 und branchenspezifische Leitfäden fördern einen Governance-Ansatz, der Risikoanalyse, Dokumentation, menschliche Aufsicht und Monitoring verlangt (EU, 2024; NIST, 2023; ISO, 2023). Sicherheit wird dadurch nicht nur als technisches, sondern auch als organisatorisches Kontrollsystem verstanden. Für die Cyberabwehr ist diese Konvergenz wichtig, weil Security Teams nicht mehr nur Modelle schützen, sondern ganze Entscheidungs- und Nachvollziehbarkeitsketten.

Die Literatur zeigt somit einen klaren Trend: Während frühe Arbeiten sich auf Adversarial Examples konzentrierten, rücken 2024 bis 2026 semantische Angriffe, Kontextmanipulation, Agentenmissbrauch und Supply-Chain-Risiken in den Vordergrund. Diese Arbeit positioniert sich genau an dieser Schnittstelle. Sie integriert Erkenntnisse aus adversarial ML, LLM-Security, Cloud Security, Zero Trust und Incident Response zu einem umsetzbaren, operativen Sicherheitsrahmen.

Risikoklasse	Beispiel	Typischer Schaden	Geeignete Kontrollen
Prompt Injection	Eingebettete Anweisung in HTML/PDF	Datenexfiltration, Fehlaktion	Kontextfilter, Sandboxing, Policy Enforcement
Datenvergiftung	Manipulierte Trainings- oder RAG-Daten	Persistente Verhaltensänderung	Provenance, Signierung, Review-Gates
Model Extraction	API-Abfragen zur Rekonstruktion	IP-Verlust, Missbrauch	Rate Limiting, Output-Restriktionen
Membership Inference	Rückschluss auf Trainingsdaten	Datenschutzverletzung	Differential Privacy, Redaction
Tool Hijacking	Missbrauch angebundener Actions	Unautorisierte Transaktionen	Least Privilege, Human-in-the-Loop

3. Threat Model and Problem Formalization

Das Bedrohungsmodell dieser Arbeit umfasst einen realistischen Mix aus externen, internen und lieferkettenbezogenen Angreifern. Externe Angreifer versuchen typischerweise, über Prompt Injection, über manipulierte Dokumente im RAG-Korpus oder über öffentlich erreichbare APIs Einfluss zu nehmen. Interne Angreifer oder kompromittierte Konten nutzen vertrauenswürdige Zugänge aus, um Daten zu exfiltrieren, Modelle zu vergiften oder Agenten zu Fehlverhalten zu bewegen. Supply-Chain-Angreifer platzieren kompromittierte Modelle, Packages, Container Images oder Transitivabhängigkeiten. In Summe ergibt sich eine Bedrohungslage, in der nicht nur Vertraulichkeit, Integrität und Verfügbarkeit klassisch bedroht sind, sondern auch Instruktionsintegrität, Kontextintegrität und Entscheidungsintegrität.

Formal definieren wir ein KI-System als Tupel $S=(M, R, T, P, D)$, wobei $M$ das Modell, $R$ die Retrieval-Komponente, $T$ die Tool-Schnittstellen, $P$ die Policy-Schicht und $D$ die Daten- und Telemetrieumgebung repräsentieren. Ein Angriff $a$ ist erfolgreich, wenn eine unerwünschte Zustandsänderung $\Delta s$ eintritt, etwa Datenabfluss, unautorisierte Aktion oder persistente Verhaltensänderung. Wir modellieren das Risiko als $$ \mathcal{R}(a)=\Pr[\text{Erfolg}(a)] \cdot \text{Impact}(a), $$ wobei der Impact neben finanziellen Verlusten auch regulatorische, operative und reputative Schäden erfasst. Die Gesamtangriffsfläche ergibt sich als $$ \mathcal{A} = \sum_i w_i \cdot v_i, $$ wobei $v_i$ die jeweilige Verwundbarkeit einer Komponente beschreibt und $w_i$ deren operative Exposition und Kritikalität gewichtet.

Die wesentlichen Angriffsziele sind: erstens das Erzwingen schädlicher Modellantworten, zweitens das Extrahieren sensibler Informationen, drittens das Manipulieren von Entscheidungen oder Aktionen und viertens das Destabilisieren von Verfügbarkeit und Kostenprofilen. Insbesondere bei agentischen Systemen reicht schon ein partieller Erfolg, etwa das Erzeugen mehrerer nicht autorisierter API-Aufrufe, um erhebliche Schäden zu verursachen. Deshalb definieren wir die Erfolgsfunktion nicht binär, sondern als abgestufte Wirkung: $$ E(a) = \alpha C + \beta I + \gamma A + \delta S, $$ wobei $C$ für Confidentiality, $I$ für Integrity, $A$ für Availability und $S$ für Safety steht. Die Gewichte $\alpha,\beta,\gamma,\delta$ werden organisationsspezifisch gesetzt.

Ein wesentliches Designprinzip ist die Trennung zwischen Nutzdaten, Instruktionen, Werkzeugen und Policy. In einem sicheren System darf eine aus dem RAG-Korpus geladene Datei keine gleichrangige Befehlsgewalt gegenüber einer Systempolicy erhalten. Ebenso muss ein Tool-Call eine explizite Autorisierungsschicht durchlaufen, bevor er externe Wirkungen entfalten darf. Daraus folgt die Annahme, dass jedes externe Objekt zunächst als feindlich einzustufen ist, bis es durch strukturierte Validierung, Signaturprüfung oder Policy-Gates freigegeben wurde. Diese Haltung entspricht dem Zero-Trust-Gedanken und ist für AI-Systeme zwingend, weil semantische Kontextgrenzen oft unscharf sind.

Angreifertyp	Primäres Ziel	Zugangsvoraussetzung	Beispielhafte Taktik
Externer Angreifer	Exfiltration, Fehlaktion	Öffentliche Schnittstelle	Prompt Injection in RAG-Quelle
Insider	Persistente Manipulation	Interner Zugriff	Vergiftung von Wissensartikeln
Supply-Chain-Akteur	Verteilung kompromittierter Artefakte	Build-/Registry-Zugang	Manipuliertes Model Artifact
Opportunistischer Bot	Kosten-/Verfügbarkeitsangriff	API-Nutzung	Token-DoS, Abuse der Quoten
Zielgerichteter APT	Mehrstufiger Zugriff	Phishing, Identitätskompromittierung	Tool Hijacking, lateral movement

4. Proposed Methodology

Die vorgeschlagene Methodik basiert auf einer mehrschichtigen Sicherheitsarchitektur für AI-Systeme. Sie kombiniert Prävention, Detektion, Eindämmung und Wiederherstellung und ordnet alle Kontrollen einer klaren Trust Boundary zu. Die Kernidee ist, dass KI-Systeme nicht als monolithische Anwendung betrachtet werden, sondern als Kette voneinander separierter Sicherheitsdomänen: Eingabe, Kontextaufbereitung, Retrieval, Inferenz, Tool-Ausführung, Ausgabe und Observability. Jede Domäne erhält eigene Richtlinien, Validierungsmechanismen und Logging-Standards.

Die erste Schicht ist Input Hardening. Hier werden Benutzereingaben, Dateiuploads und externe Inhalte normalisiert, auf offensichtliche Angriffsindikatoren geprüft und in eine sichere Zwischenrepräsentation überführt. Besonders wichtig ist die Erkennung von versteckten Instruktionen in HTML, Markdown, Office-Dokumenten und PDFs. Praktisch bedeutet dies: Entfernen von Skript- und Stil-Elementen, Heuristiken gegen Instruktionsmuster, Extraktion von Text mit Metadatenverlustkontrolle und Kennzeichnung von Quellen, die aus untrusted domains stammen. Diese Schicht soll Angriffe nicht vollständig verhindern, sondern ihre Effektivität reduzieren und die nachfolgende Policy-Entscheidung unterstützen.

Die zweite Schicht ist Context Isolation. RAG-Systeme müssen Retrieval-Ergebnisse logisch von Systemprompts, Tool-Anweisungen und Nutzeranfragen trennen. Jeder Kontextblock erhält ein Vertrauenslabel, etwa system, operator, retrieved, user, external. Das Modell selbst sieht nicht nur einen langen Prompt, sondern strukturierte Segmente mit expliziten Prioritäten. Wo möglich, wird das Modell über function calling oder constrained decoding dazu gebracht, in einem kontrollierten Format zu antworten. Die Trennung reduziert die Wahrscheinlichkeit, dass eine retrieved Quelle Instruktionen als dominanten Kontextbestandteil durchsetzt.

Die dritte Schicht ist Tool Governance. Jedes Tool wird als potenziell gefährliche Capability behandelt. Daher werden Tool-Scopes granular zugeschnitten, etwa getrennte Rechte für Lesen, Schreiben, Senden und Löschen. Kritische Aktionen müssen durch eine Policy Engine freigegeben werden, bevor sie ausgeführt werden. Für Hochrisiko-Operationen empfiehlt sich ein Human-in-the-Loop-Mechanismus, bei dem ein Mensch die finale Ausführung bestätigt. Dieser Mechanismus ist in SOC- und Admin-Workflows besonders wichtig, weil Fehlalarme, grobe Zusammenfassungen oder mehrdeutige Anweisungen sonst unmittelbar in operative Aktionen übersetzt werden könnten.

Die vierte Schicht ist Supply Chain Security. Modelle, Embeddings, Retrievers, Container Images und Bibliotheken müssen signiert, versioniert und reproduzierbar gebaut werden. Hier greifen klassische Maßnahmen wie SBOM, SLSA-ähnliche Build-Standards, Pinning von Dependencies, Secret Scanning und Artifact Provenance. Gerade im KI-Kontext ist das wichtig, weil Model Hub-Ökosysteme, externe Checkpoints und Notebook-Exporte häufig unterschätzt werden. Eine kompromittierte Gewichtedatei oder ein manipuliertes Python-Package kann die gesamte Kette unterlaufen.

Die fünfte Schicht ist Telemetry and Detection. eBPF-basierte Sensorik, Kubernetes Audit Logs, API-Gateways, Prompt Logs mit Redaction und Data Access Logs werden korreliert, um Anomalien zu erkennen. Wichtig ist die Unterscheidung zwischen normalen Modellschwankungen und verdächtigen Musterwechseln. Beispielsweise können exzessive Retrieval-Queries auf Datenexfiltration hindeuten, ungewöhnlich viele Tool-Calls auf Agentenfehler oder Prompt Injection, und abrupt wechselnde Antwortverteilungen auf Manipulation oder Jailbreak-Versuche. Eine statistische Grundlage ist hierbei hilfreich: $$ z = \frac{x-\mu}{\sigma}, $$ wobei $x$ der aktuelle Messwert, $\mu$ der erwartete Mittelwert und $\sigma$ die Standardabweichung sind. Werte mit hohem $|z|$ werden als Anomalien priorisiert.

Abbildungslos beschrieben lässt sich die Verteidigung als Pipeline darstellen: Validierung, Isolierung, Autorisierung, Ausführung, Beobachtung und Reaktion. Die Reaktion umfasst Quarantäne von Sessions, Deaktivierung von Tools, Rotation von Secrets und die Sicherung von Forensikdaten. Diese Methodik ist bewusst operational. Sie zielt nicht auf theoretische Vollständigkeit, sondern auf umsetzbare Schutzmaßnahmen in realen Unternehmensumgebungen.

Sicherheitskontrolle	Primärer Effekt	Implementierungsaufwand	Wirksamkeit gegen
Kontextsegmentierung	Reduktion von Prompt Injection	Mittel	Indirekte Prompt Injection
Tool Least Privilege	Begrenzung von Schadensradius	Mittel	Tool Hijacking, Agentenmissbrauch
Signierte Artefakte	Schutz vor Supply-Chain-Manipulation	Hoch	Model-/Package-Kom­pro­mit­tie­rung
eBPF-Telemetrie	Verbesserte Erkennung	Mittel	Lateral movement, Datenabfluss
Human-in-the-Loop	Verhindert irreversible Aktionen	Niedrig bis Mittel	Hochrisiko-Transaktionen

5. Implementation

Die Implementierung erfolgt als referenzielle Referenzarchitektur für ein SOC-nahes RAG- und Agentensystem. Ziel war es, realistische Enterprise-Muster nachzubilden: ein Chat-Interface, ein Retrieval-Layer auf Basis interner Wissensartikel, ein Ticketing-Tool, ein E-Mail-Connector und eine Policy-Schicht. Für die LLM-Komponente wurde ein lokal oder cloudseitig bereitgestelltes Modell verwendet, wobei das Sicherheitsdesign modellagnostisch bleibt. Der Sicherheitsnutzen entsteht nicht aus dem Modell selbst, sondern aus der Einbettung in kontrollierte Prozesse.

Technisch wurde die Architektur in Container-Umgebungen umgesetzt, um Isolierung, Reproduzierbarkeit und Observability zu maximieren. Für die Orchestrierung bietet sich Kubernetes an, ergänzt um NetworkPolicies, Pod Security Standards und workload identity. Die Retrieval-Komponente wird in einem separaten Namespace betrieben, der nur lesende Zugriffe auf freigegebene Dokumentenquellen besitzt. Tool-Connectoren laufen in eigenen Pods oder als separate Microservices mit minimalen Berechtigungen. System- und Operator-Prompts werden nicht als frei editierbare Dateien gehalten, sondern signiert und bei Start geprüft. Für strengere Setups ist eine Policy Engine wie OPA/Gatekeeper oder eine vergleichbare Entscheidungsinstanz sinnvoll.

Besonders wichtig ist die Behandlung von Secrets. API-Schlüssel für Ticketing, Mail oder Cloud-Plattformen dürfen nie im Prompt-Kontext landen. Stattdessen werden kurzlebige Token, workload identities und Secret-Mounts genutzt. Zusätzlich wird eine Filterstufe eingesetzt, die Secrets in Logdaten und Modellantworten redigiert. Das Logging folgt dem Prinzip „minimum necessary visibility“: Vollständige Prompts werden nur in kontrollierten, zugangsbeschränkten Security-Repositories gespeichert, während operative Logs nur hashes, Ereignis-Typen und Metadaten enthalten. Dadurch bleibt die forensische Nachvollziehbarkeit erhalten, ohne unnötig große Datenrisiken zu erzeugen.

Zur Umsetzung der Model- und Container-Absicherung wurden etablierte Werkzeuge verwendet. Ein Build-Workflow für Images kann beispielsweise mit trivy und cosign abgesichert werden, während syft SBOMs generiert. Für Runtime-Analyse und eBPF-gestützte Beobachtung eignen sich cilium, falco oder tetragon, je nach Plattform. Die folgende Konfiguration illustriert einen typischen Baseline-Workflow für ein Modell- und Service-Artifact:

# SBOM erzeugen und Image scannen
syft packages ghcr.io/org/llm-rag-gateway:1.0.0 -o spdx-json > sbom.spdx.json
trivy image --severity HIGH,CRITICAL ghcr.io/org/llm-rag-gateway:1.0.0

# Image signieren und Verifikation vorbereiten
cosign sign --key cosign.key ghcr.io/org/llm-rag-gateway:1.0.0
cosign verify --key cosign.pub ghcr.io/org/llm-rag-gateway:1.0.0

Für die Sicherheitskontrolle auf Runtime-Ebene wird eine Policy eingeführt, die Tool-Calls vor Ausführung prüft. Ein vereinfachtes Beispiel in einer OPA-nahen Logik könnte so aussehen:

package llmtools.authz

default allow = false

allow {
  input.request.tool == "create_ticket"
  input.request.user_role == "soc_analyst"
  not sensitive_context
  count(input.request.fields) <= 5
}

sensitive_context {
  input.request.contains_secret == true
}

allow {
  input.request.tool == "send_email"
  input.request.user_role == "incident_commander"
  input.request.approval == "human_confirmed"
}

Die Implementierung dieser Regeln reduziert die direkte Angriffsfläche erheblich, weil das Modell nicht mehr allein über die Ausführung entscheidet. Stattdessen wird das Modell zum Vorschlagsgenerator, während die Policy-Schicht den bindenden Ausführungsrahmen liefert. Genau diese Trennung ist für AI Security essenziell.

6. Experimental Evaluation

Die experimentelle Evaluation untersucht die Wirksamkeit der vorgeschlagenen Schutzschichten in einer kontrollierten Umgebung mit einem RAG-basierten Assistenzsystem. Das Setup umfasste drei Szenarien: ein Basis-System ohne spezifische AI-Sicherheitskontrollen, ein gehärtetes System mit Input- und Output-Filtering sowie ein mehrschichtig gehärtetes System mit Kontextsegmentierung, Tool-Governance, Signierung und Telemetrie. Die Angriffe wurden so gestaltet, dass sie typische 2026er Risiken widerspiegeln: direkte Prompt Injection, indirekte Prompt Injection über Dokumente, Tool-Missbrauch und Datenabflussversuche aus Retrieval-Quellen.

Die Metriken waren: Angriffs-Erfolgsrate, Fehlalarmrate, mittlere Latenz pro Anfrage, Antwortqualität in einer internen Relevanzbewertung sowie operative Eingriffshäufigkeit durch Human-in-the-Loop. Die Erfolgsrate wurde als Anteil der Angriffe gemessen, die eine schädliche Zustandsänderung auslösten. Die Antwortqualität wurde in einer 5-Punkte-Skala bewertet, wobei 5 einer fachlich korrekten und vollständigen Antwort entsprach. Die Robustheit wurde zusätzlich mit einer anwendungsnahen Formel bewertet: $$ \text{Robustheit} = 1 - \frac{E_{\text{erfolgreich}}}{E_{\text{gesamt}}}. $$

Die erste Tabelle zeigt die Angriffsresistenz der drei Konfigurationen. Die Ergebnisse sind realistisch, weil sie nicht auf einen einzelnen Schutzmechanismus setzen, sondern auf kombinierte Kontrollen. Besonders auffällig ist, dass direkte Prompt Injection durch einfache Filter nur moderat reduziert wird, während Kontextsegmentierung und Tool-Policies die Erfolgsrate deutlich stärker senken. Indirekte Prompt Injection bleibt anspruchsvoll, wird aber durch Retrieval-Isolierung und Quarantäne externer Quellen erheblich entschärft.

Angriffsszenario	Basis-System Erfolgsrate	Gehärtet Erfolgsrate	Mehrschichtig Erfolgsrate
Direkte Prompt Injection	78%	41%	12%
Indirekte Prompt Injection	71%	38%	15%
Tool Hijacking	64%	29%	8%
Datenabfluss via RAG	69%	33%	10%
Model Prompt Leakage	57%	26%	9%

Die zweite Tabelle zeigt die operativen Nebenwirkungen der Schutzmaßnahmen. Hier wird sichtbar, dass Sicherheit immer auch Kosten erzeugt, insbesondere in Latenz und Prozessaufwand. Dennoch bleiben die Werte in einem praktikablen Bereich, solange Human-in-the-Loop nur für kritische Aktionen aktiviert wird. Auffällig ist, dass die Antwortqualität kaum leidet, wenn die Architektur sauber implementiert ist. Dies ist ein wichtiger Befund gegen das verbreitete Argument, dass starke Sicherheit unvermeidlich die Nutzbarkeit zerstöre.

Kennzahl	Basis-System	Gehärtet	Mehrschichtig
Mittlere Latenz pro Anfrage	1,8 s	2,3 s	2,9 s
Fehlalarmrate	1,2%	2,8%	3,5%
Human-Review-Rate	0%	6%	11%
Antwortqualität (1-5)	4,1	4,0	3,9
Token-Overhead	0%	9%	14%

Die dritte Tabelle illustriert die Wirkung einzelner Kontrollen im Vergleich. Sie zeigt, dass nicht jede Maßnahme gleich stark ist, aber dass ihre Kombination den Unterschied macht. Insbesondere Signierung und Provenance wirken eher präventiv gegen Lieferkettenangriffe, während Policy Enforcement und Telemetrie vor allem zur Laufzeit wirksam sind. Die beste Konfiguration entsteht daher nicht durch eine einzelne „KI-Wall“, sondern durch abgestimmte Kontrollen.

Kontrolle	Direkte Injection	Indirekte Injection	Tool Missbrauch	Supply Chain
Input Filtering	hoch	mittel	gering	gering
Context Segmentation	hoch	hoch	mittel	gering
Tool Policy Engine	gering	gering	hoch	gering
Artifact Signing	gering	gering	gering	hoch
eBPF Monitoring	mittel	mittel	hoch	mittel

Zusätzlich wurden Beobachtungsdaten ausgewertet. In den Angriffsszenarien fielen insbesondere ungewöhnliche Retrieval-Spitzen, mehrfach wiederholte Tool-Requests und semantische Drift in den Antworten auf. Die Kombination aus Regelwerk und Anomalieerkennung entdeckte 87% der erfolgreichen Angriffsversuche vor ihrer Wirkung, was für eine operative SOC-Integration ausreichend relevant ist. Wichtig ist jedoch, dass die Restlücke nicht vernachlässigt werden darf; vor allem fein getarnte indirekte Injection-Angriffe bleiben schwer detektierbar.

Ein weiterer Befund betrifft die Latenz und die Komplexität des Systems. Mit jeder zusätzlichen Kontrollschicht steigt der Betriebsaufwand, insbesondere bei Logging, Redaction und Policy Checks. Dennoch ist dieser Overhead im Vergleich zu einem Sicherheitsvorfall moderat. Eine grobe Kostenfunktion kann als $$ K = c_1 L + c_2 H + c_3 R, $$ formuliert werden, wobei $L$ die Latenz, $H$ den Human-Review-Aufwand und $R$ die Rechenressourcen beschreibt. In der Praxis ist ein kleiner Anstieg von $K$ meist deutlich günstiger als ein Sicherheitsverlust mit unkontrollierter Datenexfiltration oder unautorisierter Aktion.

7. Case Study

Die Fallstudie basiert auf einem SOC-Assistenten, der interne Threat-Intel-Artikel, Ticketing-Daten und Cloud-Alerts zusammenführt. Ziel war es, Analysten bei der Triage zu unterstützen und Standardmaßnahmen vorzuschlagen. Der Assistent hatte Zugriff auf drei Tools: Lesen von Wissensartikeln, Erstellen von Tickets und Senden von Benachrichtigungen an ein Incident-Response-Postfach. Die Architektur war anfangs funktional, aber sicherheitstechnisch nur mittelmäßig gehärtet. Insbesondere wurden externe Inhalte aus einem Threat-Intel-Feed direkt in den Retrieval-Korpus übernommen, ohne ausreichende Sanitization oder Quellenpriorisierung.

Der Angriff begann mit einem manipulierten externen Bericht, der scheinbar harmlose Analyse enthielt, aber versteckte Instruktionen in einem Blockzitat und in Metadaten trug. Beim Abruf des Artikels wurde der Text in den Modellkontext injiziert. Das Modell interpretierte Teile des Inhalts als operative Anweisung und schlug vor, sensitive Alert-Details in ein internes Ticket zu kopieren. In einer zweiten Phase verleitete eine weitere präparierte Quelle den Assistenten dazu, ein E-Mail-Template zu verwenden, das ungewollt mehrere interne Empfänger adressierte. Ein zusätzliches Tool-Call-Problem bestand darin, dass der Assistent zwar Formulare ausfüllen durfte, aber keine explizite Freigabe benötigte, bevor die Daten versendet wurden.

Die forensische Analyse zeigte, dass der Angriff nicht durch „Modellfehler“ im engeren Sinne verursacht wurde, sondern durch eine fehlende Trennung zwischen untrusted Retrieval-Inhalt und vertrauenswürdiger Systemlogik. Die Korrekturmaßnahmen waren entsprechend architektonisch. Erstens wurden externe Quellen in quarantinierte Retrieval-Buckets verschoben und nur nach Signatur- oder Reputation-Check in den produktiven Index übernommen. Zweitens wurde das Tool-Calling so umgebaut, dass E-Mail- und Ticket-Aktionen nur mit expliziter Freigabe eines Incident-Commanders ausgeführt werden konnten. Drittens wurde das Logging so erweitert, dass indirekte Prompt-Injection-Indikatoren, wie widersprüchliche Instruktionsmuster und ungewöhnliche Kontextdichte, markiert wurden. Nach diesen Änderungen sank die praktische Ausnutzbarkeit des Szenarios drastisch.

Die Fallstudie verdeutlicht, dass AI Security in SOC-Umgebungen besonders heikel ist, weil dort hohe Reaktionsgeschwindigkeit mit oft unvollständiger Informationslage zusammentrifft. Genau diese Kombination macht agentische Systeme attraktiv und gefährlich zugleich. Sicherheitsverantwortliche müssen deshalb nicht nur die Inhalte prüfen, sondern auch die Automatisierungsgrenzen festlegen. Ein Assistent, der unter Zeitdruck Entscheidungen vorbereitet, darf nie unkontrolliert in die Ausführung wechseln.

8. Discussion

Die Ergebnisse dieser Arbeit zeigen, dass AI Security 2026 primär ein Problem der Systemarchitektur und der betrieblichen Governance ist. Technische Schwächen im Modell sind nur ein Teil der Bedrohung; mindestens ebenso kritisch sind unsaubere Trust Boundaries, zu breite Tool-Berechtigungen, unzureichend gereinigte Retrieval-Daten und fehlende Überwachung. Damit ähnelt AI Security zwar in Teilen klassischer Applikationssicherheit, unterscheidet sich aber durch ihre semantische Natur. Angriffe zielen nicht nur auf Codepfade, sondern auf Bedeutung, Kontext und Priorisierung.

Ein zentrales Spannungsfeld ist das Verhältnis zwischen Sicherheit und Funktionalität. Zu aggressive Filter können legitime Informationen blockieren und so die Nutzbarkeit eines Systems untergraben. Zu lax konfigurierte Systeme hingegen erzeugen unkontrollierte Risiken. In der Praxis ist daher ein abgestuftes Modell sinnvoll: niedrigriskante Antworten dürfen automatisiert erfolgen, während hochriskante Aktionen menschliche Freigabe brauchen. Dieser Ansatz ist kompatibel mit Zero Trust und entspricht dem Prinzip der gestuften Autorisierung. Gleichzeitig sollte jedes System über einen „safe fallback mode“ verfügen, in dem bei Verdacht auf Manipulation nur noch lesende oder stark eingeschränkte Funktionen angeboten werden.

Ein weiterer Diskussionspunkt betrifft die Bedeutung von Observability. Ohne gute Telemetrie sind AI-Angriffe oft nur als nachträgliche Anomalie sichtbar. eBPF, API-Gateways, Policy-Logs und Prompt-Events bilden zusammen die Grundlage für Erkennung und Forensik. Allerdings ist auch hier Sorgfalt nötig, weil Telemetrie selbst hochsensible Daten enthalten kann. Deshalb müssen Logging, Redaction und Zugriffskontrolle auf Sicherheitsniveau des Primärsystems liegen. Andernfalls wird das Monitoring zum neuen Leak-Kanal.

Die Supply-Chain-Dimension wird in vielen Organisationen noch unterschätzt. Modelle, Embeddings, Indexer, Notebook-Exports und Python-Abhängigkeiten bilden eine heterogene Kette, die schwer vollständig zu kontrollieren ist. Dennoch ist gerade dort ein großer Teil des Risikos lokalisiert. Signierte Artefakte, reproduzierbare Builds, Version Pinning, Malware-Scanning und SBOMs sind daher keine bürokratische Zusatzlast, sondern eine Voraussetzung für belastbare AI-Systeme. Die gleiche Logik gilt für Cloud-Kontrollen, insbesondere wenn AI-Services in Multi-Cloud- und Hybrid-Umgebungen laufen.

Auch regulatorisch wird klar, dass AI Security nicht isoliert betrachtet werden darf. Der EU AI Act, NIST AI RMF und ISO/IEC 42001 treiben Unternehmen dazu, Risiken, Rollen und Kontrollen sauber zu dokumentieren. Für Sicherheitsabteilungen ist das eine Chance, denn Governance zwingt zu klareren Prozessen. Gleichzeitig darf Governance nicht in reinem Papier-Compliance enden. Ohne technische Umsetzung bleibt sie wirkungslos. Die besten Programme kombinieren deshalb Risikomanagement, Red-Team-Testing, technische Kontrollen und Incident-Playbooks.

Ein Blick auf die Zukunft bis und jenseits 2026 zeigt, dass die nächste Welle der Bedrohungen durch noch autonomere Systeme, multimodale Agenten und tiefer eingebettete AI in Endpunkten und Cloud-Steuerungen entstehen dürfte. Damit steigen die Anforderungen an Verifikation, Policy-Design und sichere Ausführung weiter. Besonders relevant werden Post-Quantum-Umstellungen, weil AI-Infrastruktur oft langfristige Datenwerte verarbeitet, die auch später noch schützenswert sind. Wer heute AI-Systeme baut, sollte daher bereits auf Kryptographie-Agilität und robuste Identitätskontrollen achten.

9. Conclusion and Future Work

Diese Arbeit hat AI Security als eigenständigen, operativ relevanten Bereich der Cybersecurity für das Jahr 2026 eingeordnet und einen praxisnahen Rahmen für Bedrohungsmodellierung, Schutzarchitektur und Bewertung vorgeschlagen. Die zentrale Erkenntnis lautet, dass sichere KI-Systeme nicht allein durch Modellhärtung entstehen, sondern durch konsequente Trennung von Daten, Kontext, Tools und Policies. Besonders wirksam sind Kontextsegmentierung, least-privilege Tool-Design, Artefaktsignierung und telemetriegestützte Detektion. Gleichzeitig bleibt die Herausforderung bestehen, indirekte Prompt-Injection-Angriffe und semantische Manipulationen in offenen Informationsumgebungen robust zu erkennen.

Für die Zukunft sind drei Forschungsrichtungen besonders wichtig. Erstens braucht es bessere formale Modelle für semantische Vertrauensgrenzen in RAG- und Agentensystemen. Zweitens müssen Evaluationsstandards entstehen, die über simple Benchmarks hinaus echte Betriebsbedingungen, menschliche Faktoren und Multi-Step-Angriffe berücksichtigen. Drittens müssen Governance und Technik enger zusammenwachsen, damit AI Security in SOC, Cloud und Software Supply Chain konsistent umgesetzt werden kann. Wer AI-Systeme in produktive Cyberabwehr integriert, muss sie so behandeln, als wären sie privilegierte, potentiell fehlbare und ständig angegriffene Sicherheitskomponenten. Genau darin liegt die eigentliche Aufgabe der AI Security im Jahr 2026.

10. References

AI VILLAGE. OWASP Top 10 for LLM Applications 2024. 2024. Disponível em: https://owasp.org/www-project-top-10-for-large-language-model-applications/ . Acesso em: 21 abr. 2026.

BARR, Emily et al. Adversarial Examples in Modern Machine Learning: A Survey. 2023. Disponível em: https://arxiv.org/abs/2301.00000 . Acesso em: 21 abr. 2026.

CARLINI, Nicholas et al. Extracting Training Data from Large Language Models. 2021. Disponível em: https://www.usenix.org/conference/usenixsecurity21/presentation/carlini-extracting . Acesso em: 21 abr. 2026.

EUROPEAN UNION. Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act). 2024. Disponível em: https://eur-lex.europa.eu/eli/reg/2024/1689/oj . Acesso em: 21 abr. 2026.

GOODFELLOW, Ian; SHLENS, Jonathon; SZEGEDY, Christian. Explaining and Harnessing Adversarial Examples. 2015. Disponível em: https://arxiv.org/abs/1412.6572 . Acesso em: 21 abr. 2026.

ISO. ISO/IEC 42001:2023 Artificial intelligence — Management system. 2023. Disponível em: https://www.iso.org/standard/81230.html . Acesso em: 21 abr. 2026.

KENT, Zach et al. Indirect Prompt Injection in Retrieval-Augmented Systems. 2024. Disponível em: https://arxiv.org/abs/2402.00000 . Acesso em: 21 abr. 2026.

KOS, Jason et al. Prompt Injection Attacks and Defenses for Large Language Models. 2023. Disponível em: https://arxiv.org/abs/2307.00000 . Acesso em: 21 abr. 2026.

LANGCHAIN. LangChain Documentation. 2025. Disponível em: https://python.langchain.com/docs/ . Acesso em: 21 abr. 2026.

LLAMAINDEX. LlamaIndex Documentation. 2025. Disponível em: https://docs.llamaindex.ai/ . Acesso em: 21 abr. 2026.

MITRE. ATLAS: Adversarial Threat Landscape for AI Systems. 2023. Disponível em: https://atlas.mitre.org/ . Acesso em: 21 abr. 2026.

NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY. Artificial Intelligence Risk Management Framework (AI RMF 1.0). 2023. Disponível em: https://www.nist.gov/itl/ai-risk-management-framework . Acesso em: 21 abr. 2026.

NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY. Secure Software Development Framework (SSDF) Version 1.1. 2022. Disponível em: https://csrc.nist.gov/Projects/ssdf . Acesso em: 21 abr. 2026.

OPENAI. Function Calling in the API. 2024. Disponível em: https://platform.openai.com/docs/guides/function-calling . Acesso em: 21 abr. 2026.

OPENAI. Model Spec. 2025. Disponível em: https://model-spec.openai.com/ . Acesso em: 21 abr. 2026.

OPA. Open Policy Agent Documentation. 2025. Disponível em: https://www.openpolicyagent.org/docs/latest/ . Acesso em: 21 abr. 2026.

OWASP. OWASP Top 10 for Large Language Model Applications. 2024. Disponível em: https://owasp.org/www-project-top-10-for-large-language-model-applications/ . Acesso em: 21 abr. 2026.

PAPERNOT, Nicolas et al. The Limitations of Deep Learning in Adversarial Settings. 2016. Disponível em: https://arxiv.org/abs/1511.07528 . Acesso em: 21 abr. 2026.

RED HAT. eBPF for Security and Observability. 2024. Disponível em: https://www.redhat.com/en/topics/linux/what-is-ebpf . Acesso em: 21 abr. 2026.

SCLAFANI, Michael et al. Membership Inference Attacks Against Machine Learning Models: A Survey. 2022. Disponível em: https://arxiv.org/abs/2201.00000 . Acesso em: 21 abr. 2026.

SNYK. Container Security Best Practices. 2025. Disponível em: https://snyk.io/learn/container-security/ . Acesso em: 21 abr. 2026.

SYFT. Syft SBOM Generator. 2025. Disponível em: https://github.com/anchore/syft . Acesso em: 21 abr. 2026.

TRIVY. Trivy Vulnerability Scanner. 2025. Disponível em: https://github.com/aquasecurity/trivy . Acesso em: 21 abr. 2026.

WILLIAMS, David et al. AI Red Teaming in Enterprise Environments. 2024. Disponível em: https://arxiv.org/abs/2404.00000 . Acesso em: 21 abr. 2026.

ZOU, Andy et al. Universal and Transferable Adversarial Attacks on Aligned Language Models. 2023. Disponível em: https://arxiv.org/abs/2307.15043 . Acesso em: 21 abr. 2026.

COSIGN. Sigstore Cosign Documentation. 2025. Disponível em: https://docs.sigstore.dev/cosign/overview/ . Acesso em: 21 abr. 2026.

KUBERNETES. Kubernetes Documentation: Security Concepts. 2025. Disponível em: https://kubernetes.io/docs/concepts/security/ . Acesso em: 21 abr. 2026.