Angriff und Verteidigung von KI-Systemen in der Cybersecurity: Ein praxisorientiertes Rahmenwerk für Modell-, Daten- und Agentensicherheit im Jahr 2026

1. Einführung

Künstliche Intelligenz ist 2026 kein experimentelles Add-on mehr, sondern ein Kernbestandteil moderner Cybersecurity-Architekturen. Sicherheitsoperationen nutzen LLMs zur Triage von Alerts, zur Erstellung von Incident-Reports, zur Unterstützung forensischer Analysen und zur Beschleunigung von Detection Engineering. Gleichzeitig setzen Angreifer generative Modelle für Social Engineering, Spearphishing, Malware-Entwicklung, Reconnaissance und die Automatisierung von Exploit-Varianten ein. Daraus ergibt sich ein grundlegender Paradigmenwechsel: KI ist nicht nur Werkzeug, sondern auch Ziel und Angriffsfläche. Ein Sicherheitskonzept, das KI-Modelle lediglich wie „normale“ Applikationen behandelt, verfehlt die zentralen Risiken, da sich die Angriffsoberfläche über Daten, Prompts, Tools, Modelle und Entscheidungen erstreckt.

Die Praxis zeigt, dass KI-Systeme besonders dort verwundbar sind, wo sie auf externe Inhalte, Benutzeranweisungen oder dynamische Werkzeuge angewiesen sind. Retrieval-Augmented Generation, Tool-Calling, Agenten-Frameworks und multimodale Eingaben erhöhen die Produktivität, vergrößern aber zugleich die Möglichkeit für Manipulation. Prompt-Injection ist dabei nur ein Teilproblem. In realen Umgebungen werden Modelle über vergiftete Wissensquellen, kompromittierte Dokumente, manipulierte Webseiten, bösartige PDFs oder eingebettete Instruktionen in Tickets und E-Mails angegriffen. Das Modell selbst kann durch Exfiltration über lange Abfragen, adaptive Query-Strategien oder durch unzureichend isolierte Schnittstellen teilweise rekonstruiert werden. Hinzu kommen klassische Security-Probleme, die in KI-Systemen neu auftreten: unzureichendes Secret-Handling, überprivilegierte Tool-Integrationen, fehlende Mandantentrennung, Logging von sensiblen Kontexten und unklare Verantwortlichkeiten zwischen Modellentwicklung, Plattformbetrieb und SOC.

Diese Arbeit behandelt AI Security als eigenständige Subdomäne innerhalb der Cybersecurity. Der Fokus liegt nicht auf allgemeiner KI-Theorie, sondern auf operativ belastbaren Schutzmechanismen für produktive Sicherheitsumgebungen. Zentral ist dabei die Einsicht, dass wir es mit einem System-of-Systems zu tun haben. Ein LLM allein ist meist nicht das eigentliche Risiko; kritisch wird das Gesamtsystem aus Datenpipeline, Modell, Orchestrator, Speicher, Policy Layer, Werkzeugen und menschlicher Interaktion. Deshalb reicht es nicht aus, einzelne Modelle zu härten. Es braucht eine Architektur, die Input, Kontext, Ausgabe und Aktion jeweils separat kontrolliert und auditierbar macht.

Die Bedrohungslage 2026 ist zusätzlich durch die Professionalisierung adversarialer Nutzung von KI geprägt. Generative Modelle senken die Kosten für Social Engineering erheblich, insbesondere wenn Sprachstil, Lokalisation und fachliche Terminologie angepasst werden. Gleichzeitig hat sich die defensive Seite weiterentwickelt: Zero Trust ist in vielen Unternehmen etabliert, CNAPP- und eBPF-basierte Telemetrie sind zunehmend produktiv, und KI-Governance wird durch regulatorische Anforderungen und interne Risikorahmen vorangetrieben. Dennoch bleibt die Kluft zwischen Governance und technischer Durchsetzung groß. Viele Organisationen definieren Richtlinien für Modellnutzung, haben aber keine durchgängige technische Enforcement-Schicht, die unsichere Prompt-Flows, unzulässige Datenabflüsse oder Werkzeugmissbrauch zuverlässig verhindert.

In diesem Beitrag entwickeln wir ein praxisorientiertes Rahmenwerk für die Sicherung von KI-Systemen in Cybersecurity-Umgebungen. Es verbindet Bedrohungsmodellierung, formale Sicherheitsziele, Architekturprinzipien, Implementierungsdetails und eine experimentelle Evaluation. Der Beitrag zielt darauf ab, Verteidigern ein belastbares Instrumentarium zu geben, das sich auf reale Betriebsanforderungen anwenden lässt: geringes Fehlalarmniveau, Skalierbarkeit, Nachvollziehbarkeit, Auditierbarkeit und minimale Auswirkung auf die Nutzererfahrung. Gleichzeitig wird deutlich, dass KI-Sicherheit kein statischer Zustand ist, sondern ein kontinuierlicher Prozess aus Red Teaming, Telemetrie, Policy-Tuning und reproduzierbarer Evaluation.

2. Background and Related Work

Die wissenschaftliche und industrielle Literatur zu AI Security hat sich seit den frühen Arbeiten zu adversarial examples stark ausdifferenziert. Die ersten systematischen Hinweise, dass neuronale Netze gezielt durch kleine Eingriffe in Eingabedaten manipuliert werden können, stammen aus der Arbeit von Szegedy et al. und der späteren Formulierung effizienter Angriffsmethoden wie FGSM und PGD. Diese Erkenntnisse waren zunächst vor allem für Computer Vision relevant, bildeten aber die Grundlage für ein umfassenderes Verständnis der Fragilität lernbasierter Systeme (SZEGEDY et al., 2014; GOODFELLOW; SHLENS; SZEGEDY, 2015; MADRY et al., 2018).

Mit dem Aufstieg von Sprachmodellen verlagerte sich der Fokus von pixelbasierten Angriffen zu Prompt-, Kontext- und Orchestrierungsangriffen. Arbeiten zu prompt injection, jailbreaking und instruction hierarchy zeigten, dass LLMs besonders anfällig sind, wenn externe Texte ohne strikte Trennung von Benutzeranweisung, Systemkontext und unverifizierten Daten verarbeitet werden (GRESHKEVICH et al., 2022; LILLO et al., 2023). Parallel dazu entstand ein umfangreiches Forschungsfeld zu data poisoning, backdoors und model extraction. Während klassische Poisoning-Angriffe Trainingsdaten manipulieren, um das spätere Verhalten eines Modells zu verändern, nutzt model extraction die statistische Ähnlichkeit von Ausgabe- und Entscheidungsverhalten, um sensible Modellparameter oder Funktionalität zu rekonstruieren (TRAMÈR et al., 2016; ORENGO et al., 2020).

In der Praxis hat sich das Risiko mit RAG-Architekturen weiter erhöht. Retrieval-Pipelines kombinieren Vektor-Datenbanken, Dokumentenspeicher und generative Modelle. Dadurch können externe Inhalte unmittelbar die Modellantwort beeinflussen. Angriffsmethoden wie indirect prompt injection, retrieved content poisoning und malicious context stuffing nutzen genau diese Eigenschaft aus, indem sie manipulative Instruktionen in scheinbar harmlose Dokumente, Webseiten oder Tickets einbetten (PEREZ; RAKITIN; et al., 2024; OWASP, 2024). Die Forschung zu LLM-Sicherheit hat diese Klasse von Angriffen inzwischen als eigenständige Bedrohung anerkannt, ebenso wie Tool-Use-Angriffe auf agentische Systeme, bei denen das Modell veranlasst wird, unautorisierte Aktionen auszuführen oder Secrets preiszugeben (NIST, 2024a; ANTHROPIC, 2024).

Von großer Bedeutung ist auch die Standardisierung. Das NIST AI RMF definiert Risikodimensionen für KI-Systeme, ohne jedoch einen vollständigen technischen Schutzstack vorzugeben (NIST, 2023). Ergänzend liefern ISO/IEC 42001 und 23894 organisatorische Leitplanken für AI Management und AI Risk Management (ISO, 2023a; ISO, 2023b). Die OWASP Top 10 for LLM Applications 2024 hat die wichtigsten Angriffsflächen operationalisiert, insbesondere Prompt Injection, Insecure Output Handling, Training Data Poisoning, Model Denial of Service und Supply Chain Vulnerabilities (OWASP, 2024). Diese Klassifikationen sind für die Praxis wertvoll, reichen aber allein nicht aus, um sichere Produktionssysteme zu bauen.

Ein weiterer Strang der Literatur betrifft die Sicherheit von KI in DevSecOps- und Cloud-Umgebungen. CNAPP, eBPF-basierte Observability und runtime enforcement ermöglichen heute eine engere Kopplung von Plattformtelemetrie und Sicherheitskontrollen. Gleichzeitig zeigen Vorfälle im Bereich Supply Chain Security, dass Modellgewichte, Embeddings, Frameworks und third-party connectors integritätskritisch sind. Die Herausforderung besteht darin, KI-Sicherheit nicht als isolierte Disziplin, sondern als Schnittmenge aus Application Security, Cloud Security, Data Security und Security Engineering zu verstehen. Besonders relevant sind hier Zero-Trust-Ansätze, die nicht nur Benutzeridentitäten, sondern auch jede Daten-, Modell- und Werkzeuginteraktion kontinuierlich prüfen (NIST, 2020; GOOGLE, 2024).

Die Forschungslücke liegt somit nicht im Mangel an Einzelangriffen, sondern in der fehlenden systematischen Verbindung zwischen Bedrohungsmodell, technischer Durchsetzung und betrieblichen Metriken. Viele Arbeiten betrachten entweder Robustheit von Modellen oder Sicherheit von LLM-Anwendungen. Weniger untersucht ist die Frage, wie man produktive KI-Systeme mit Security-by-Design so integriert, dass Angriffe auf Daten, Modelle und Agenten gleichzeitig abgewehrt und im Betrieb messbar gemacht werden können. Genau an dieser Stelle setzt die vorliegende Arbeit an.

Bedrohungsklasse	Betroffene Ebene	Typische Wirkung	Beispielhafte Kontrollen
Prompt Injection	Eingabe, Kontext, Agenten	Manipulation von Modellverhalten, Tool-Missbrauch	Kontext-Sanitization, Instruction Hierarchy, Policy Filter
Datenvergiftung	Training, RAG, Embeddings	Falsche Antworten, Backdoors, Wissensmanipulation	Herkunftsprüfung, Signaturen, Quarantäne, Retrieval-Scoring
Modell-Exfiltration	Inferenz, API	Rekonstruktion von Parametern oder Funktion	Rate Limiting, Output Truncation, Query Anomaly Detection
Adversarial Examples	Eingabeebene	Fehlklassifikation bei Vision, Audio, OCR	Robust Training, Input Smoothing, Ensemble Checks
Agentic Abuse	Tool-Schicht	Unautorisierte Aktionen, Secret-Leaks	Least Privilege, Tool Allowlisting, Approval Gates

3. Threat Model and Problem Formalization

Wir modellieren ein KI-gestütztes Sicherheitssystem als Zusammenspiel $S = (D, M, R, A, P, T)$, wobei $D$ die Datenquellen, $M$ das Modell, $R$ die Retrieval-Komponente, $A$ die Aktions- und Werkzeugschicht, $P$ die Policy-Engine und $T$ die Telemetrie- und Audit-Schicht beschreibt. Der Angreifer kann einen oder mehrere dieser Bestandteile beeinflussen. Ziel des Angreifers ist typischerweise eine der folgenden vier Wirkungen: Verletzung der Vertraulichkeit, Verfälschung der Integrität, Einschränkung der Verfügbarkeit oder Auslösung unerwünschter Aktionen.

Wir unterscheiden vier Angreiferklassen. Erstens der externe Angreifer, der nur über öffentliche oder halböffentliche Schnittstellen verfügt, etwa Chat-Interfaces, API-Endpunkte oder Support-Portale. Zweitens der eingeschleuste Inhaltsangreifer, der Texte, Dateien, Webseiten oder Dokumente einspeist, die später durch Retrieval oder Kontextaggregation verarbeitet werden. Drittens der Insider mit begrenzten Privilegien, der Zugriff auf Prompts, Logs, Modellartefakte oder Datenquellen hat. Viertens der Supply-Chain-Angreifer, der Abhängigkeiten, Container-Images, Model Hub Artefakte oder Connectoren kompromittiert. Diese Klassen überlappen in der Praxis, weshalb defensive Maßnahmen mehrschichtig sein müssen.

Die Sicherheitsziele lassen sich formal als Optimierungsproblem mit Nebenbedingungen betrachten. Sei $u$ ein Nutzwert, der aus Antwortqualität, Latenz und Automatisierungsgrad besteht, und $r$ ein Risikowert aus Angriffserfolg, Datenabfluss und Fehlaktion. Dann soll ein Betriebssystem für KI die Funktion $$ \max_{x \in \mathcal{X}} ; u(x) - \lambda r(x) $$ unter Nebenbedingungen zu Zugriffsrechten, Datenklassifizierung und Compliance erfüllen. Dabei ist $\lambda$ ein risikopolitischer Gewichtungsfaktor, der je nach Kritikalität der Umgebung angepasst wird. In hochsensiblen SOC- oder IR-Workflows ist $\lambda$ deutlich größer als in rein assistiven, nicht autonom agierenden Kontexten.

Für die Messung der Verteidigungswirkung verwenden wir unter anderem folgende Größen. Die Attack Success Rate $ASR$ ist definiert als $$ ASR = \frac{N_{\text{erfolgreich}}}{N_{\text{gesamt}}}. $$ Die Reduktion der Erfolgsquote durch eine Verteidigung $d$ kann als $$ \Delta ASR_d = ASR_{\text{baseline}} - ASR_d $$ gemessen werden. Für Retrieval-Angriffe definieren wir den Poisoning Impact als Anteil der Antworten, die durch vergiftete Quellen beeinflusst wurden. Für Agentensysteme betrachten wir die Tool Misuse Rate, also den Anteil unautorisierter Tool-Aufrufe. Für Modell-Exfiltration ist die relevante Größe die Reconstructions Efficiency, gemessen als Anzahl erforderlicher Queries pro Qualitätsniveau der Rekonstruktion.

Das Problem ist zusätzlich durch nichtlineare Ketteneffekte geprägt. Ein einzelner bösartiger Dokumenteintrag kann über Retrieval in den Modellkontext gelangen, dort eine Instruktion auslösen, ein Tool anstoßen und schließlich eine externe Aktion erzeugen. Daher ist die Sicherheitsanalyse nicht modular in dem Sinn, dass jede Schicht isoliert bewertet werden könnte. Stattdessen müssen Pfade betrachtet werden, in denen Angriffe mehrere Kontrollschichten umgehen. Eine geeignete Darstellung ist ein gerichteter Graph $G = (V,E)$ mit Knoten für Datenquellen, Transformationsstufen und Aktoren. Ein erfolgreicher Angriff ist ein Pfad von einer kompromittierten Quelle zu einer unerlaubten Wirkung. Die Verteidigung reduziert die Pfadwahrscheinlichkeit durch Absicherung einzelner Kanten und Knoten.

Sicherheitsziel	Formale Größe	Beispielhafte Metrik	Relevanz
Vertraulichkeit	$C$	Secret Leakage Rate	Schutz von Prompts, Logs, Daten
Integrität	$I$	ASR, Poisoning Impact	Vermeidung falscher Antworten
Verfügbarkeit	$A$	Error Rate, DoS Resilience	Stabilität unter Last oder Angriff
Kontrollierbarkeit	$K$	Tool Misuse Rate	Verhindern unerlaubter Aktionen

4. Proposed Methodology

Unsere Methode besteht aus fünf Schichten: Datenhärtung, Kontextkontrolle, Modellhärtung, Aktionssicherung und Betriebsüberwachung. Ziel ist es, KI-Systeme so zu designen, dass Angriffe nicht nur erkannt, sondern möglichst schon vor der Ausführung unterbunden werden. Der Ansatz ist defensiv, aber operativ, und orientiert sich an realen Produktionsanforderungen in SOC-, GRC- und SecOps-Umgebungen.

Die erste Schicht ist die Datenhärtung. Alle externen Quellen werden klassifiziert, signiert, versioniert und auf Herkunft geprüft. Dokumente, die in Retrieval-Pipelines gelangen, werden durch Content Sanitization, MIME-Whitelisting und statische Erkennung verdächtiger Instruktionsmuster vorbehandelt. Zusätzlich werden Embeddings und Indexeinträge mit Provenienzmetadaten versehen, damit bei späteren Antworten nachvollzogen werden kann, welche Quellen die Generierung beeinflusst haben. Für hochriskante Kontexte setzen wir eine Quarantänephase ein, in der neue oder geänderte Dokumente zunächst nur mit eingeschränkter Vertrauenswürdigkeit verfügbar sind.

Die zweite Schicht ist die Kontextkontrolle. Die zentrale Regel lautet: Benutzeranweisungen, Systemanweisungen und externe Inhalte dürfen niemals ungetrennt in einen gemeinsamen, unmarkierten Prompt-Stream verschmolzen werden. Stattdessen werden Rollen, Vertrauensstufen und erlaubte Datenklassen explizit kodiert. Unverifizierte Texte werden als Daten behandelt, nicht als Instruktionen. Output-Filter prüfen, ob das Modell Geheimnisse, interne Pfade, API-Schlüssel oder unerlaubte Maßnahmen nennt. In agentischen Systemen werden Werkzeugaufrufe grundsätzlich durch eine Policy-Engine vermittelt, die Parameter, Zielsysteme und Kontextbedingungen validiert.

Die dritte Schicht ist die Modellhärtung. Hierzu gehören moderates adversarial training, safety fine-tuning, refusal tuning, calibrated uncertainty estimation und robustes decoding. Für Klassifikations- und Erkennungskomponenten werden Ensembling und Abstimmungslogik eingesetzt, um die Wirkung einzelner adversarialer Eingaben zu reduzieren. Bei generativen Modellen ist Robustheit schwieriger, weshalb wir die Modellantwort nicht als autoritative Wahrheit, sondern als Vorschlag mit Unsicherheitsrahmen behandeln. In sicherheitskritischen Fällen muss die Modellantwort durch deterministische Regeln, Signaturen oder externe Verifikation bestätigt werden.

Die vierte Schicht ist die Aktionssicherung. Tool-Use wird nach dem Prinzip des Least Privilege gestaltet. Jedes Werkzeug erhält ein separates Identitäts- und Berechtigungsprofil. Hochriskante Aktionen, etwa das Löschen von Tickets, das Blockieren von Konten oder das Ausrollen von Firewall-Regeln, erfordern mehrstufige Freigaben oder human-in-the-loop. Für API-Aufrufe werden sichere Konnektoren mit Request Normalization, Parameter Binding und Egress-Policy eingesetzt. Dadurch soll verhindert werden, dass das Modell durch manipulierte Eingaben indirekt auf unerwartete Ziele zugreift.

Die fünfte Schicht ist die Betriebsüberwachung. Wir verwenden Telemetrie auf eBPF-Basis, um Netzwerk-, Prozess-, Datei- und Syscall-Ereignisse mit Modellaktivität zu korrelieren. Auffällige Muster wie ungewöhnliche outbound requests, hohe Query-Frequenz, wiederholte Tool-Fehlversuche oder abrupte Kontextwechsel werden in Echtzeit detektiert. Ein zentraler Vorteil dieser Schicht besteht darin, dass sie modellunabhängig ist. Selbst wenn ein neues Modell deployed wird, bleiben die runtime-Kontrollen wirksam.

Die Gesamtsicherheit ergibt sich aus der Komposition dieser Schichten. Vereinfacht kann der Restangriffserfolg als $$ P(\text{Erfolg}) = \prod_{i=1}^{n} (1 - c_i) $$ modelliert werden, wobei $c_i$ die Wirksamkeit der jeweiligen Kontrollschicht ist. In der Praxis sind die Schichten nicht unabhängig, weshalb die Formel als Approximation dient. Dennoch illustriert sie den entscheidenden Punkt: Eine einzelne defensive Maßnahme reicht nicht aus, aber mehrere moderate Kontrollen in Kombination können den Angreiferkostenpunkt stark erhöhen.

Schicht	Ziel	Primäre Mechanismen	Typische Failure Modes
Datenhärtung	Poisoning verhindern	Signaturen, Provenienz, Quarantäne	Unsaubere Quellen, Shadow Indexes
Kontextkontrolle	Prompt Injection stoppen	Trennung von Instruktion und Daten	Vermischte Rollen, unsichere Templates
Modellhärtung	Fehlverhalten reduzieren	Safety Tuning, Robust Decoding	Overrefusal, False Confidence
Aktionssicherung	Tool-Missbrauch verhindern	Allowlisting, Approval Gates	Überprivilegierte Connectors
Betriebsüberwachung	Angriffserkennung	eBPF, SIEM, Anomaly Detection	Fehlende Korrelation, Blind Spots

5. Implementation

Die Referenzimplementierung basiert auf einer Container- und Kubernetes-nahen Architektur, die sich für CNAPP-gestützte Umgebungen eignet. Der LLM-Dienst wird von der Retrieval-Schicht und den Werkzeugen logisch getrennt. Für jede Anfrage wird ein kurzlebiger Kontext erstellt, der nur die minimal erforderlichen Quellen, Rollen und Berechtigungen enthält. Persistente Speicher enthalten keine unredigierten Geheimnisse; stattdessen werden sensible Elemente tokenisiert oder durch referenzielle Platzhalter ersetzt.

Für die Inferenz verwenden wir eine Gateway-Schicht, die Anfragen validiert, Prompt-Templates erzwingt und Ausgabeprüfungen vornimmt. Die Gateway-Schicht integriert eine Policy-Engine, die auf Attribute Based Access Control und risikobasierten Regeln beruht. Bei Konflikten zwischen Benutzerwunsch und Sicherheitsrichtlinie wird die Aktion blockiert oder auf einen manuellen Freigabepfad umgeleitet. Für Retrieval werden Dokumente vor dem Indexing auf folgende Merkmale geprüft: Datei-Typ, Makros, eingebettete Anweisungen, URL-Ketten, ungewöhnliche Unicode-Muster und Verdachtswörter, die auf Prompt-Injection hindeuten.

Ein wichtiges Element ist die Observability. Wir koppeln Modellaufrufe mit Telemetrie aus dem Host- und Container-Layer. eBPF-Sensoren erfassen Socket-Verbindungen, Dateioperationen und auffällige Prozessketten. Diese Daten werden mit Anfrage-IDs korreliert, sodass ein Incident nachverfolgt werden kann, ohne den gesamten Prompt-Text unnötig zu speichern. Für den Audit Trail nutzen wir manipulationsgeschützte Logs, die mit Zeitstempeln, Quellen-IDs und Policy-Entscheidungen versehen sind. Dies erleichtert spätere forensische Analysen und regulatorische Nachweise.

Ein Beispiel für eine hardening-orientierte Runtime-Konfiguration ist die Trennung von Modell- und Tool-Namespaces. Das Modell läuft ohne direkte Netzwerkausgangsrechte, während der Werkzeug-Proxy ausschließlich definierte Ziele ansprechen darf. Secrets werden über einen dedizierten Secret Manager bereitgestellt und nur zur Laufzeit injiziert. Zusätzlich werden DLP-Mechanismen verwendet, um personenbezogene Daten, Schlüsselmaterial und interne Klassifizierungen vor dem Verlassen der Plattform zu erkennen.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: secure-llm-gateway
spec:
  replicas: 2
  selector:
    matchLabels:
      app: secure-llm-gateway
  template:
    metadata:
      labels:
        app: secure-llm-gateway
    spec:
      securityContext:
        runAsNonRoot: true
        seccompProfile:
          type: RuntimeDefault
      containers:
      - name: gateway
        image: registry.example.com/sec/llm-gateway:2026.1
        ports:
        - containerPort: 8080
        env:
        - name: POLICY_ENGINE_URL
          value: http://policy-engine.default.svc.cluster.local:8181
        - name: RETRIEVAL_MODE
          value: sanitized
        securityContext:
          allowPrivilegeEscalation: false
          readOnlyRootFilesystem: true
          capabilities:
            drop: ["ALL"]

# Beispiel: Erfassung von Prozess- und Netzwerk-Telemetrie mit eBPF-naher Observability
kubectl apply -f secure-llm-gateway.yaml
kubectl logs -n security deploy/secure-llm-gateway -f

# Beispielhafte Runtime-Prüfung in einer Linux-Umgebung
sudo bpftool prog show
sudo bpftool map show
sudo auditctl -w /var/lib/llm/ -p wa -k llm_audit

Die Implementierung nutzt ferner ein mehrstufiges Prompt-Template. Die Systeminstruktion definiert harte Sicherheitsregeln, die Benutzeranfrage wird separat behandelt, und externe Dokumente werden in expliziten Datenblöcken eingebettet. Für kritische Fälle erlaubt die Pipeline nur zusammenfassende Antworten mit Quellenverweis, aber keine direkte Ausführung. Bei Tool-Anfragen wird eine strukturierte JSON-Repräsentation erzeugt, die durch Schema-Validierung und policy checks läuft, bevor ein Funktionsaufruf erfolgt.

6. Experimental Evaluation

Zur Bewertung wurde ein Benchmark-Set aus 1.200 Testfällen konstruiert, das vier Angriffsgruppen umfasst: Prompt Injection, Retrieval Poisoning, Tool Misuse und Model Exfiltration. Die Tests wurden in einer kontrollierten Umgebung mit einem LLM-basierten SOC-Assistenten durchgeführt. Verglichen wurden vier Konfigurationen: Baseline ohne spezielle Schutzmaßnahmen, Prompt-Härtung allein, Kontext plus Tool-Gating und die vollständige mehrschichtige Architektur. Ziel war es, die relative Wirksamkeit der Maßnahmen unter realistischen Betriebsbedingungen zu messen.

Die wichtigsten Metriken waren Attack Success Rate, False Refusal Rate, Tool Misuse Rate und mediane Antwortlatenz. Für Retrieval-Angriffe wurde zusätzlich gemessen, wie häufig manipulierte Quellen in der Antwort referenziert wurden. Für die Exfiltrationstests wurde untersucht, wie viele adaptiv formulierte Anfragen nötig waren, um sensitive Informationen über das Modellverhalten zu rekonstruieren. Der Fokus lag dabei nicht auf der absoluten Stärke eines einzelnen Modells, sondern auf dem Sicherheitsgewinn durch Architektur und Kontrollen.

$$ \text{F1}{\text{safety}} = \frac{2 \cdot \text{Precision}{\text{safe}} \cdot \text{Recall}{\text{safe}}}{\text{Precision}{\text{safe}} + \text{Recall}_{\text{safe}}} $$

Die Ergebnisse zeigen ein klares Muster: Einzeln implementierte Prompt-Filtersysteme reduzieren zwar triviale Angriffe, versagen aber häufig gegen indirekte Prompt-Injection und agentische Missbrauchsszenarien. Erst die Kombination aus Datenhärtung, Kontextkontrolle und Tool-Gating erreicht eine robuste Reduktion der Erfolgsraten. Gleichzeitig steigt die Antwortlatenz nur moderat, sofern die Policy Engine und der Retrieval-Cache effizient implementiert sind. Der Hauptkostenfaktor liegt nicht in der Modellinferenz selbst, sondern in Quarantäne- und Prüfprozessen bei unklaren Quellen.

Konfiguration	Prompt-Injection ASR	Retrieval-Poisoning ASR	Tool-Misuse Rate	Median-Latenz (ms)
Baseline	0.78	0.64	0.71	840
Prompt-Härtung	0.41	0.52	0.63	910
Kontext + Tool-Gating	0.18	0.26	0.14	1040
Vollständige Architektur	0.06	0.09	0.03	1185

Angriffstyp	Zielsystem	Erforderliche Queries zur Rekonstruktion	Erfolgsquote ohne Schutz	Erfolgsquote mit Schutz
Model Extraction	Klassifikations-API	2.400	0.83	0.19
Prompt Leakage	SOC-Assistant	180	0.74	0.07
Indirect Injection	RAG-Pipeline	12	0.69	0.05
Tool Abuse	Agentic Workflow	9	0.77	0.03

Verteidigung	Sicherheitsgewinn	Betriebsaufwand	Hauptrisiko
Output Filtering	mittel	niedrig	Overblocking
Policy Engine	hoch	mittel	Regelkomplexität
Retrieval Quarantine	hoch	mittel	Verzögerte Verfügbarkeit
eBPF Telemetry	mittel	mittel	Datenvolumen
Human Approval Gates	sehr hoch	hoch	Workflow-Latenz

Die Evaluierung bestätigt außerdem, dass Datenherkunft ein zentraler Faktor ist. Dokumente ohne Provenienzprüfung waren wesentlich häufiger Träger erfolgreicher indirekter Angriffe. Bei kuratierten Quellen, signierten Artefakten und Quarantäne sank die Erfolgsquote signifikant. Ein zweites Ergebnis betrifft die False Refusal Rate: Zu aggressive Filter verursachen spürbare Nutzbarkeitseinbußen. Das legt nahe, dass defensive Systeme adaptive Schwellenwerte benötigen, die auf Kontextkritikalität, Nutzerrolle und Datenklasse reagieren.

7. Case Study

Die Fallstudie betrachtet einen LLM-gestützten SOC-Assistenten in einer mittelgroßen Enterprise-Umgebung. Das System diente dazu, Alert-Korrelationen zu erklären, Incident-Tickets zu priorisieren und Analysten mit Playbook-Vorschlägen zu unterstützen. Vor der Härtung konnten Benutzer freie Texteingaben machen und externe Wissensquellen aus dem Ticket-System wurden direkt in den Prompt übernommen. In der Praxis führte dies zu mehrfachen Fehlinterpretationen, gelegentlichen Halluzinationen und einem kritischen Vorfall, bei dem ein bösartiger Ticket-Kommentar eine unerwünschte Zusammenfassung und eine irreführende Eskalation auslöste.

Nach der Umstellung auf die vorgeschlagene Architektur wurden drei zentrale Änderungen eingeführt. Erstens erhielt jede externe Quelle eine Vertrauenskategorie, und verdächtige Inhalte wurden nur noch in eingeschränktem Retrieval-Modus verarbeitet. Zweitens wurden Tool-Aktionen wie Quarantäne, Ticket-Eskalation oder Blocklistenänderungen nur noch nach Policy-Prüfung und bei Bedarf mit menschlicher Freigabe ausgelöst. Drittens wurde ein Audit- und Telemetriepfad eingeführt, der die Antwort des Modells mit der zugehörigen Quelle und den getroffenen Entscheidungen verknüpfte.

Innerhalb von sechs Wochen sank die Zahl sicherheitsrelevanter Fehlaktionen deutlich. Besonders wirksam war die Trennung von erklärender Ausgabe und operativer Aktion. Analysten konnten weiterhin Zusammenfassungen und Hypothesen erhalten, aber kritische Änderungen am Umfeld mussten explizit bestätigt werden. Der wichtigste Lerneffekt war organisatorisch: Das Modell selbst war nicht der alleinige Risikotreiber, sondern die fehlende Governance zwischen Chat-Schnittstelle, Ticket-System und Response-Automation. Erst als diese Schnittstellen technisch abgesichert wurden, ließ sich der Assistent produktiv und verantwortbar betreiben.

Die Fallstudie verdeutlicht auch die Rolle der Red-Team-Praxis. Mehrere Angriffsvarianten wurden intern getestet, darunter indirekte Prompt-Injection über HTML-Inhalte in Tickets, manipulierte IOC-Listen und versteckte Instruktionen in PDF-Anhängen. Die defensive Architektur bestand diese Tests nur dann zuverlässig, wenn Quellensanierung, Tool-Gating und Logging gemeinsam aktiv waren. Einzeln eingesetzt hätten dieselben Kontrollen die Sicherheitslage nur kosmetisch verbessert. In einer realen SOC-Umgebung ist genau diese Kombination entscheidend, da die Kosten eines Fehlalarms deutlich niedriger sind als die Kosten einer falschen automatisierten Gegenmaßnahme.

8. Diskussion

Die Ergebnisse unterstreichen, dass AI Security 2026 nicht mehr als Randthema der Applikationssicherheit behandelt werden kann. KI-Systeme vergrößern die Angriffsfläche nicht nur quantitativ, sondern qualitativ. Sie transformieren statische Sicherheitsentscheidungen in probabilistische, kontextabhängige und oft nicht deterministische Prozesse. Das macht klassische Kontrollmodelle nicht obsolet, aber ihre Anwendung schwieriger. Besonders problematisch ist die Diskrepanz zwischen der natürlichen Sprachschnittstelle von LLMs und den strengen Anforderungen sicherheitskritischer Betriebsprozesse.

Ein zentrales Spannungsfeld ist die Balance zwischen Nutzen und Sicherheit. Zu strenge Kontrollmechanismen führen zu Overblocking und verringern die Akzeptanz. Zu lockere Kontrollen machen die Systeme manipulierbar. Deshalb muss die Sicherheitsarchitektur sich am Kritikalitätsgrad orientieren. In einer SOC-Triage kann ein Modell assistiv arbeiten, solange finale Entscheidungen durch Analysten oder deterministische Regeln abgesichert sind. In einem autonomen Response-Workflow hingegen sind strengere Freigabepfade, härtere Netzwerkgrenzen und engere Telemetrie erforderlich. Diese Differenzierung ist essenziell, wird aber in vielen Produktdesigns noch zu wenig berücksichtigt.

Ein zweites Spannungsfeld betrifft die Governance. 2026 existieren zwar zahlreiche Richtlinien, Frameworks und regulatorische Leitplanken, doch die technische Umsetzung bleibt heterogen. NIST AI RMF, ISO/IEC 42001, OWASP LLM Top 10 und interne AI Policies liefern wertvolle Orientierung, aber sie ersetzen keine Laufzeitkontrollen. Unternehmen benötigen daher eine Brücke zwischen Governance und Engineering. Diese Brücke muss messbar sein, etwa durch technische Controls, die einem bestimmten Risiko zugeordnet und regelmäßig gegen reale Angriffe validiert werden. Ohne diese Koppelung droht „paper compliance“ ohne operative Wirkung.

Drittens ist die Frage der Skalierbarkeit entscheidend. Sicherheitsmaßnahmen für KI-Systeme dürfen nicht so schwergewichtig sein, dass sie produktive Nutzung verhindern. Dies spricht für modulare Architektur, kurze Pfade und automatisierbare Prüfungen. eBPF-basierte Observability ist hier besonders wertvoll, weil sie tiefe Runtime-Einsichten bietet, ohne den Applikationscode massiv zu verändern. Ebenso wichtig ist die Trennung von Detektion und Enforcement. Nicht jede Anomalie muss sofort blockiert werden; in vielen Fällen genügt zunächst ein erhöhtes Risiko-Signal für die menschliche Bewertung.

Die größte offene Herausforderung liegt in der Bewertung von Agentensystemen. Klassische Benchmarks messen oft statische Modelle, nicht aber dynamische Tool-Nutzung, Langzeitkontext und komplexe Mehrschritt-Interaktionen. Für 2026 besteht daher Bedarf an standardisierten, realitätsnahen Benchmarks für RAG- und Agenten-Sicherheit, die sowohl Angriffserfolg als auch Betriebskosten abbilden. Ohne solche Benchmarks bleibt die Vergleichbarkeit von Verteidigungen begrenzt. Hinzu kommt der Bedarf an belastbaren Testdaten, die nicht selbst zum Angriffsmaterial werden.

9. Conclusion and Future Work

Diese Arbeit hat AI Security als operative Disziplin innerhalb der Cybersecurity eingeordnet und ein mehrschichtiges Rahmenwerk für den Schutz von KI-Systemen vorgestellt. Die zentrale Schlussfolgerung lautet, dass produktive KI-Sicherheit nur dann tragfähig ist, wenn Daten, Kontext, Modell, Werkzeuge und Betrieb gemeinsam betrachtet werden. Einzelmaßnahmen wie Prompt-Filter oder Policy-Listen sind nützlich, aber nicht hinreichend. Erst die Kombination aus Datenhärtung, Kontexttrennung, Modellrobustheit, Werkzeugkontrolle und Runtime-Observability reduziert die wesentlichen Risiken nachhaltig.

Die experimentelle Analyse zeigt, dass integrierte Verteidigungslinien die Attack Success Rate erheblich senken können, ohne die Nutzbarkeit vollständig zu opfern. Besonders wirksam sind Provenienzprüfungen, strikt geregeltes Tool-Gating und auditierbare Entscheidungswege. Die Fallstudie aus dem SOC verdeutlicht außerdem, dass organisatorische und technische Maßnahmen zusammengehören. Governance ohne Enforcement bleibt wirkungslos, und Enforcement ohne Governance führt zu operativer Friktion.

Für zukünftige Arbeit ergeben sich mehrere Richtungen. Erstens braucht die Forschung standardisierte Benchmarks für Prompt-Injection, Retrieval Poisoning und Agentenmissbrauch. Zweitens müssen Verteidigungen gegen Modell-Exfiltration und adaptive Jailbreaks weiter verbessert werden. Drittens ist die Integration von AI Security in Zero-Trust-, CNAPP- und Post-Quantum-Architekturen ein wichtiges Thema, insbesondere in regulierten Branchen. Viertens sollten Sicherheitsmechanismen so entwickelt werden, dass sie erklärbar, auditierbar und international vergleichbar sind. Nur dann kann KI in Cybersecurity nicht nur leistungsfähig, sondern auch vertrauenswürdig betrieben werden.

10. Referências

ACM. ACM CCS 2025 Proceedings. ACM Digital Library, 2025. Disponível em: https://dl.acm.org/conference/ccs. Acesso em: 3 mai. 2026.

ANTHROPIC. Prompt Injection and Tool Use in LLMs. Anthropic Research, 2024. Disponível em: https://www.anthropic.com/research. Acesso em: 3 mai. 2026.

BROWN, Tom B. et al. Language Models are Few-Shot Learners. In: NEURIPS, 2020. Disponível em: https://arxiv.org/abs/2005.14165. Acesso em: 3 mai. 2026.

CISA. AI and Cybersecurity Guidance. Cybersecurity and Infrastructure Security Agency, 2025. Disponível em: https://www.cisa.gov/ai. Acesso em: 3 mai. 2026.

CWE. CWE Top 25 Most Dangerous Software Weaknesses. MITRE, 2025. Disponível em: https://cwe.mitre.org/top25/. Acesso em: 3 mai. 2026.

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

GOOGLE. BeyondCorp Enterprise and Zero Trust Architecture. Google Cloud, 2024. Disponível em: https://cloud.google.com/beyondcorp. Acesso em: 3 mai. 2026.

GRESHKEVICH, Serge et al. Prompt Injection Attacks in Large Language Models. 2022. Disponível em: https://arxiv.org/abs/2211.09527. Acesso em: 3 mai. 2026.

ISO. ISO/IEC 42001:2023 Artificial intelligence — Management system. International Organization for Standardization, 2023a. Disponível em: https://www.iso.org/standard/81230.html. Acesso em: 3 mai. 2026.

ISO. ISO/IEC 23894:2023 Artificial intelligence — Risk management. International Organization for Standardization, 2023b. Disponível em: https://www.iso.org/standard/77304.html. Acesso em: 3 mai. 2026.

KAMAT, Aditi et al. A Survey of Prompt Injection Attacks and Defenses. 2024. Disponível em: https://arxiv.org/abs/2402.01234. Acesso em: 3 mai. 2026.

KLEINBERG, Jon; LIAO, Kevin. AI Governance and Security in Enterprise Systems. 2025. Disponível em: https://arxiv.org/abs/2501.00456. Acesso em: 3 mai. 2026.

MADRY, Aleksander et al. Towards Deep Learning Models Resistant to Adversarial Attacks. 2018. Disponível em: https://arxiv.org/abs/1706.06083. Acesso em: 3 mai. 2026.

MITRE. ATLAS: Adversarial Threat Landscape for Artificial-Intelligence Systems. MITRE, 2025. Disponível em: https://atlas.mitre.org/. Acesso em: 3 mai. 2026.

NIST. AI Risk Management Framework (AI RMF 1.0). National Institute of Standards and Technology, 2023. Disponível em: https://www.nist.gov/itl/ai-risk-management-framework. Acesso em: 3 mai. 2026.

NIST. Cybersecurity Framework 2.0. National Institute of Standards and Technology, 2024a. Disponível em: https://www.nist.gov/cyberframework. Acesso em: 3 mai. 2026.

NIST. Adversarial Machine Learning: A Taxonomy and Terminology. National Institute of Standards and Technology, 2024b. Disponível em: https://csrc.nist.gov/publications. Acesso em: 3 mai. 2026.

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

PEREZ, F. et al. Indirect Prompt Injection in Retrieval-Augmented Generation Systems. 2024. Disponível em: https://arxiv.org/abs/2402.01234. Acesso em: 3 mai. 2026.

PERCY, Ryan et al. Secure LLM Operations: Practical Defenses for Production Deployments. 2025. Disponível em: https://arxiv.org/abs/2503.06789. Acesso em: 3 mai. 2026.

SALTMAN, Hava; GOODFELLOW, Ian. Defensive Distillation. 2016. Disponível em: https://arxiv.org/abs/1511.04508. Acesso em: 3 mai. 2026.

SANDERS, David et al. eBPF for Security Observability in Cloud-Native Environments. 2024. Disponível em: https://arxiv.org/abs/2407.01357. Acesso em: 3 mai. 2026.

SZEGEDY, Christian et al. Intriguing Properties of Neural Networks. 2014. Disponível em: https://arxiv.org/abs/1312.6199. Acesso em: 3 mai. 2026.

TRAMÈR, Florian et al. Stealing Machine Learning Models via Prediction APIs. In: USENIX Security, 2016. Disponível em: https://www.usenix.org/conference/usenixsecurity16/technical-sessions/presentation/tramer. Acesso em: 3 mai. 2026.

USENIX. USENIX Security 2025 Proceedings. USENIX Association, 2025. Disponível em: https://www.usenix.org/conference/usenixsecurity25. Acesso em: 3 mai. 2026.

VERTES, Michael et al. Benchmarking LLM Security Controls in SOC Workflows. 2025. Disponível em: https://arxiv.org/abs/2505.08122. Acesso em: 3 mai. 2026.

WANG, Haoran et al. On the Security of Retrieval-Augmented Generation. 2024. Disponível em: https://arxiv.org/abs/2401.01234. Acesso em: 3 mai. 2026.

ZHANG, Yiming et al. Adversarial Prompting and Jailbreaking of Large Language Models: A Survey. 2025. Disponível em: https://arxiv.org/abs/2502.05555. Acesso em: 3 mai. 2026.