# Security

> Prompt Injection, Excessive Agency, Datenschutz und unsichere Output-Verarbeitung — die OWASP-LLM-Risiken, die in Produktion tatsächlich auftreten.

Track: [LLMOps](https://physar.tech/learn/llmops)  
Kanonische Fassung: https://physar.tech/learn/llmops/security  
Stand: 2026-07-22  
Interaktiver Teil: 10 Checks (nur im Browser)

## KI-Security: die Trust-Grenzen eines LLM-Systems

### Die Angriffsfläche eines LLM-Systems

Ein LLM folgt Anweisungen aus **jeder** Eingabe, die in seinen Kontext gelangt — es unterscheidet nicht zuverlässig zwischen „Daten“ und „Befehl“. Im RAG-/Agenten-Setup kommt Eingabe aus mehreren Quellen: dem Nutzer, **retrievten Dokumenten** und **Tool-Ausgaben**.

Nutzer → **Retrievte Docs** → Tool-Ausgaben

Damit verschwimmt die Trust-Grenze. Sicherheit heißt hier nicht „ein Filter“, sondern: klare Vertrauensgrenzen ziehen und an **jeder** Schicht verteidigen.

> **Landkarte:** Die **OWASP Top 10 for LLM Applications (2025)** ordnen diese Risiken — von Prompt Injection über Excessive Agency bis unsicherem Output-Handling. Dieser Pfad geht sie der Reihe nach durch.

### Prompt Injection: direkt, indirekt — und der Prompt als „öffentlich“

**Direkte** Injection: der Nutzer manipuliert den Prompt selbst („ignoriere deine Anweisungen …“). **Indirekte** Injection: die Anweisung steckt in **retrievtem oder externem Inhalt** — die gefährlichere Variante, weil der Angreifer nie direkt mit euch reden muss.

Zentrale Konsequenz: Die **Prompt-Ebene ist keine Sicherheitsgrenze.** Anweisungen lassen sich überschreiben, und der System-Prompt lässt sich oft **extrahieren** (System Prompt Leakage). Entwirf so, dass selbst ein vollständig überschriebener oder ausgelesener Prompt keinen Schaden anrichtet.

> **Grundregel:** **Alles, was nicht aus eurem eigenen, vertrauenswürdigen Code kommt, ist nicht vertrauenswürdige Eingabe** — auch retrievte „Fakten“. Und alles **im** Prompt ist potenziell öffentlich.

### Excessive Agency: Least-Privilege für Tools & Agenten

Injection wird erst **gefährlich**, wenn das kompromittierte Modell **mächtige Tools** hat — DB-Zugriff, E-Mail, Shell. Der Schaden ist so groß wie die Rechte des Agenten.

Antwort: **Least-Privilege.** Jedes Tool nur mit minimalen Rechten, Allowlists statt Blocklists, **Human-in-the-Loop** für irreversible Aktionen. Ein reiner Lese-Job bekommt keine Lösch-Berechtigung.

> **Denk in Blast-Radius:** Was kann im schlimmsten Fall passieren, wenn genau dieses Tool eine feindliche Anweisung ausführt? Danach bemisst sich die nötige Absicherung.

### Ausgabe: Improper Output Handling

LLM-Ausgaben sind **ebenfalls untrusted**. Wer Modell-Output ungefiltert in Shell, SQL, HTML oder einen Downstream-Aufruf gibt, baut die Injection-Lücke am **anderen Ende** wieder ein.

|  |  |
| --- | --- |
| Eingang (retrievt/Nutzer) | untrusted → filtern, Least-Privilege |
| Ausgang (ausführen/rendern) | untrusted → validieren, encodieren, Allowlist |

> **Beide Enden:** Trust-Grenzen gelten **an beiden Enden** eines LLM-Systems — nicht nur am Eingang.

### Datenschutz: PII & besondere Kategorien

Datenschutz ist eine Eigenschaft des **Datenflusses**, nicht der Nutzer: sobald personenbezogene Daten an einen (externen) Verarbeiter gehen, zählen Rechtsgrundlage und **Datenminimierung** — auch bei rein interner Nutzung.

**Besondere Kategorien** (Art. 9 DSGVO, u. a. Gesundheitsdaten) verschärfen das: explizite Rechtsgrundlage, PII vor der Übermittlung redigieren, Logging- und Aufbewahrungsdauer festlegen.

> **Vor & nach dem Modell:** PII-Redaction gehört **vor** die Übermittlung; nachträgliches Filtern der Antwort schützt die bereits gesendeten Daten nicht mehr.

### Daten- & Index-Poisoning

Retrieval **erbt das Vertrauen seiner Quellen.** Indexiert ihr eine nicht kuratierte, editierbare Quelle, kann ein Angreifer präparierte Inhalte einschleusen, die eure Antworten verfälschen (Data/Index Poisoning).

> **Verteidigung:** Nur vertrauenswürdige oder moderierte Quellen indexieren, Änderungen prüfen und **Provenance** (Herkunft) mitführen — Vertrauen entscheidet sich beim Einspeisen, nicht erst bei der Antwort.

### Secrets in Prompts & Logs

Zwei häufige Leak-Kanäle: **Secrets im System-Prompt** (extrahierbar) und **Prompt-/Antwort-Logs**, die PII und Tokens breit einsehbar speichern. Observability darf keine neue Leak-Quelle schaffen.

> **Regel:** Keine Geheimnisse im Modellkontext; Logs behandeln wie Datenverarbeitung — **redigieren, Zugriff minimieren, Aufbewahrung begrenzen.**

### Resource Abuse: Kosten- & Verfügbarkeits-DoS

Ein KI-Endpoint ist eine **kostenverursachende Ressource.** Ohne Grenzen skaliert Missbrauch direkt in explodierende Kosten und Timeouts für legitime Nutzer (Unbounded Consumption).

> **Grenzen an den Endpoint:** **Rate-Limits, Eingabe-/Kontext-Obergrenzen und Budget-Alerts** pro Client/Key — Grenzen gehören an den Endpoint, nicht in einen Haftungsausschluss.

### Supply Chain: Modelle & Plugins

Modelle, Plugins und Abhängigkeiten sind Teil eurer **Lieferkette** — sie können manipuliert sein, exzessive Rechte fordern oder Daten abfließen lassen. „Open Source“ oder „viele Sterne“ ist kein Integritätsbeweis.

> **Verifizieren, nicht unterstellen:** Herkunft & Integrität prüfen, Versionen **pinnen**, Plugin-Berechtigungen minimal halten.

### Defense in Depth — gleich im Check

Kein einzelner Filter ist sicher — Guardrails lassen sich umgehen. Sicherheit entsteht durch **Schichten**: Input-Guardrails, Least-Privilege, Output-Validierung, Datenminimierung, Quellen-Kuratierung, Limits und Monitoring. Keine Schicht vertraut der anderen blind.

> **Gleich im Check:** Du entscheidest jetzt selbst für konkrete Ops-Szenarien — von direkter Injection über Poisoning und Secrets bis Resource Abuse und Supply Chain.

## Quellen

- OWASP Top 10 for LLM Applications (2025) — LLM01 Prompt Injection, LLM02 Sensitive Information Disclosure, LLM03 Supply Chain, LLM04 Data and Model Poisoning, LLM05 Improper Output Handling, LLM06 Excessive Agency, LLM07 System Prompt Leakage, LLM10 Unbounded Consumption
- Verordnung (EU) 2016/679 (DSGVO), Art. 9 — besondere Kategorien personenbezogener Daten
- OWASP Top 10 for LLM Applications (2025) — LLM01: Prompt Injection
- OWASP Top 10 for LLM Applications (2025) — Excessive Agency (LLM06)
- Verordnung (EU) 2016/679 (Datenschutz-Grundverordnung, DSGVO), Art. 9
- OWASP Top 10 for LLM Applications (2025) — Improper Output Handling (LLM05)
- Simon Willison — Serie zu Prompt Injection (Konzept)
- OWASP Top 10 for LLM Applications (2025) — LLM07: System Prompt Leakage
- OWASP Top 10 for LLM Applications (2025) — LLM04: Data and Model Poisoning
- OWASP Top 10 for LLM Applications (2025) — LLM02: Sensitive Information Disclosure
- OWASP Top 10 for LLM Applications (2025) — LLM10: Unbounded Consumption
- OWASP Top 10 for LLM Applications (2025) — LLM03: Supply Chain