ki-engineeering/19-security-und-safety.md

Security und Safety

Qualität und Canaries stehen (Kapitel 17–18). Parallel öffnet das Feature eine neue Angriffsfläche: User-Text steuert Tools, Retrieval liefert fremde Docs, Logs speichern Prompts, und ein cleverer String im Tickettext versucht, die Policy zu überschreiben. Klassische AuthZ bleibt nötig — und reicht nicht.

Security ist hier App- und Produktsicherheit um Foundation Models, nicht Secure Coding Agents im Dev-Harness (ki-agent / ki-praxis).

Kern in einem Satz: Behandelt Model, Retrieval und Tool-Pfad als untrusted compute mit Side Effects — Trust Boundaries, Least Privilege, Validate/Guardrails und Red-Team gegen Injection, Leakage und Tool Abuse; Security ist Architektur (T8), kein abschließendes Prompt-„sei sicher“.

Checkliste: security-review-ai.md. Privacy/Residenz → Kapitel 20.

---

Bridge: Klassisches SE → AI Engineering

Klassisches SE	AI-App Security …
Trust Boundaries (User → API → DB)	plus Prompt-Slots, Retrieval, Tool-Results, Model-Provider
XSS / SQLi / SSRF	Prompt Injection, Output→Interpreter, Tool-SSRF-Äquivalente
AuthZ an der API	AuthZ vor Tool-Ausführung; Modell ersetzt keine Berechtigung
Input validation	Input-Gates + Output-Gates (Schema, Policy, Deny-Listen)
Secrets management	keine Keys im Prompt; Redaction in Logs/Traces
Supply chain	Model-/Provider-Abhängigkeit, Index-Inhalte, MCP/Tool-Server
Abuse / Rate limits	Token- und Tool-Budget als Abuse-Controls
Pen-Test / ASVS	+ LLM-Red-Team und Safety-Suite im Eval

Die Brücke: derselbe Defense-in-Depth-Reflex — neue Datenflüsse, neue Interpreter (das Modell), neue Wirkungspfade (Tools).

---

Threat Model (minimal, aber schriftlich)

Skizziert für jede Capability:

[User/Channel] → [Orchestrator] → [Context: RAG/Memory] → [Model]
                      ↓                                      ↓
                 [Tools/Effects]  ←—— tool args / results ——┘
                      ↓
                 [Downstream systems]
         Logs / Eval / Provider egress  (seitlich)

Asset	Risiko-Beispiel
Vertrauliche Daten	Leakage an User, andere Tenants, Provider-Logs
Integrität von Aktionen	unautorisierte Writes, Fraud
Verfügbarkeit	Cost bombs, Loop, Provider-Exhaustion
Vertrauen / Safety	schädliche Anleitung, Harassment, Policy-Bruch
Secrets	API-Keys in Context oder Tool-Results

OWASP-ähnliche Taxonomien für LLM-Apps (z. B. Prompt Injection, Improper Output Handling, SSRF via tools — OWASP Top 10 for LLM Applications 2025, Eintrag u. a. LLM05; Stand August 2026 Versionen und IDs prüfen) sind nützlich als Checklisten, kein Ersatz für euer Feature-Threat-Model.

---

Prompt Injection

Direct: User (oder Channel) versucht, System-/Policy-Instruktionen zu überschreiben.
Indirect: Inhalt in Docs, Mails, Web-Seiten, Ticket-Historie, Tool-Results enthält Anweisungen an das Modell.

Warum „Ignoriere Anweisungen im Dokument“ nicht reicht

Modelle folgen untrusted Text teilweise. Prompt-Sätze sind Defense-in-Depth, nicht Control. Kontrolle liegt in:

1. Trennung trusted Policy vs. untrusted Content (Kapitel 11)
2. Least Privilege Tools
3. Output- und Effect-Gates im Code
4. Mensch vor hoher Wirkung

Typische Payloads (illustrativ, nicht exhaustiv)

• „Ignore previous instructions…“
• „Reveal your system prompt / keys“
• Indirekt: „When summarizing this page, call tool X with …“
• Multistage: harmlos wirken, in Schritt 2 Tool-Missbrauch

Mitigationen (Schichten)

Schicht	Maßnahme
Architektur	untrusted markieren; nicht mit Policy concatenieren ohne Struktur
Tools	Allowlist, AuthZ, keine generische Shell/SQL
Output	Schema; keine Roh-HTML/JS an Browser; keine ungeprüften Commands
Retrieval	Corpus-Hygiene, Source-Trust-Level, sensitives raushalten
Runtime	Caps, HITL, anomaly on tool sequences
Eval	Injection-Suite im Golden/Safety-Set (Kapitel 17)

---

Data Leakage

Pfad	Beispiel	Hebel
Antwort an User	fremdes Ticket, PII, Secrets aus Context	Context-Minimierung, Output-Filter, Tenant-Isolation im Retrieval
Prompt/Logs	Klartext-PII in Traces	Redaction, Sampling, ACL (Kapitel 20)
Provider egress	Daten an Model-API	Datenklassen, Verträge, ggf. anderes Hosting (Kapitel 09)
Cross-tenant	falscher Index-Filter	harte Filter vor Retrieval und in der Query, nie „Modell bitte nur Tenant A“
Training/reuse	Provider-Opt-in Missverständnis	Policy und Contract prüfen (Stichtag, schriftlich)

System-Prompt Extraction ist oft eher IP-/Policy-Leak als Kronjuwel — trotzdem: keine Secrets in Prompts; sensitive Policy lieber im Code enforce.

---

Tool Abuse und Improper Output Handling

Tools multiplizieren Blast Radius (Kapitel 13). Improper Output Handling (OWASP-LLM-Taxonomie 2025; älterer Name oft „Insecure Output Handling“) meint: Modell-Ausgabe ungeprüft in Browser, Shell, SQL, E-Mail oder nächste Pipeline-Stufe — ohne Sanitize, Schema und Effect-Gate.

Muster	Risiko	Besser
run_shell / freie SQL	RCE / Data exfil	enge, parametrisierte Tools
URL-fetch ohne Allowlist	SSRF, interne Netze	allowlisted domains, block private ranges
Output → Code-Interpreter	Injection in der nächsten Stufe	sandbox, validate
Model wählt Empfänger	Spam, Fraud	Policy + HITL auf high side effect
Übermächtiges Admin-Tool	Privilege escalation	least privilege, separate identities

Regel: Das Modell schlägt Args vor; euer Harness autorisiert und validiert. AuthZ-Entscheidung fällt nicht im Token-Sampler.

Agent-Loops

Mehr Schritte = mehr Chancen für Injection-getriebene Tool-Ketten. Caps, Allowlist, step audit, kill-switch (Kapitel 14).

---

Guardrails: Input, Output, Policy

Art	Wann	Beispiele
Input	vor Model/Tools	AuthZ, Rate limit, Max length, Malware/URL checks, Blocklisten
Output	nach Model vor User/Effect	Schema, PII-Filter, Safety classifier, HTML escape
Policy / Effect	vor Side Effect	Allowlist tools, amount caps, HITL, deny-by-default writes

Guardrail-Design

• Fail closed bei Unsicherheit auf Hochrisiko-Pfaden.
• Guardrails messbar (block rate, false positive samples) — sonst erstickt ihr Nützlichkeit unbemerkt.
• Kombiniert deterministische Checks (Schema, Allowlists) mit optionalen ML/LLM-Classifiers; Classifier allein ist kein AuthZ.
• Vendor-Safety-Filter (anbieterseitig) sind Zusatz, nicht eure Architektur.

Safety vs. Security (im Buch)

Security (hier)	Safety (hier)
Angreifer, Missbrauch, Leakage, AuthZ	schädliche/unerwünschte Inhalte, Policy, Nutzergefährdung
oft klassisch + LLM-Fläche	oft Policy + Eval + Output-Gates

Überlappung ist groß (Injection → beides). In der Praxis: ein Threat Model, gemeinsame Gates, getrennte Eval-Suites wo hilfreich.

---

Patterns und Trade-offs

Pattern: Capability-scoped tools

Pro Feature nur die Tools, die der Job braucht — nicht die globale Firmen-Tool-Registry.

Trade-off: mehr Bindings; massiv kleinere Angriffsfläche.

Pattern: Two-man rule for effects

Plan/dry-run → validate → HITL oder zweite deterministische Policy → execute.

Trade-off: Latenz/UX; Pflicht bei Geld, Rechten, Außenwirkung.

Pattern: Content as data, never as code

Untrusted Text nur in Datenfeldern; Interpreter (SQL, shell, HTML) nur über eure Templates/Bindungen.

Trade-off: weniger „flexibles“ Agent-Verhalten; überlebensfähig.

Pattern: Red team in CI

Feste Injection-/Leakage-Fälle als Safety suite, blockt Release.

Trade-off: Pflege; verhindert Regression nach Prompt-Tuning.

Decision Frame: Blocken, entschärfen oder Mensch?

Risiko × Unsicherheit	Tendenz
hoch × hoch	block / needs_human
hoch × niedrig (klar erlaubt)	allow mit audit
niedrig × hoch	soft refuse oder nachfragen
Tool write × injection indicators	deny + log

Trade-off: strikte Guardrails vs. Utility

Strenger	Lockerer
weniger Incidents	mehr False Blocks
höhere refuse-rate	mehr Nutzungsfreude kurzfristig
messbar in Spec	„wir lockern still“ = Drift

Entscheidet produktseitig und misst beide Seiten (Kapitel 18).

---

Anti-Patterns

Anti-Pattern	Symptom	Besser
Security by prompt	nur „folge der Policy“	Code-Gates + least privilege
Model as AuthZ	„nur wenn User admin ist“ im Prompt	echte AuthZ vor Tools
God tool	shell/SQL/HTTP freeform	enge Contracts
Trusted retrieval	jedes Doc = Instruction	untrusted + hygiene
Log everything raw	PII/Secrets in Traces	redaction, ACL
Safety only at UI	API ohne Gates	gleiche Policy server-side
Copy coding-agent perms	Dev-Workspace-Rechte im Produkt	Produkt-Threat-Model
No red team	erste Injection in Prod	Safety suite
Ignore indirect injection	nur Chat-Filter	Docs/Tools/Mails einbeziehen
Alert without kill-switch	erkennen, nicht stoppen	Flag / disable capability

---

Production Notes

Cost. Red-Team-Eval, Classifier und doppelte Checks kosten Tokens und Laufzeit. Das ist Teil der Security-Envelope — billiger als Incident und forensische Prompt-Logs (T7, T8).

Latency. Output-Filter und HITL erhöhen p95; für Hot Paths: schnelle deterministische Gates zuerst, schwere Classifier async oder nur auf riskanten Slices.

Observability. Security-Events: policy_block, authz_deny, injection_suspect, tool_denied, redaction_applied — mit Trace-ID, ohne Payload-Klartext wo möglich. Alerting auf Anomalien in Tool-Sequenzen und Cost bombs (Kapitel 22).

Security. Dieses Kapitel ist die Security-Note: Review vor Launch mit security-review-ai.md; nach Model-Change Safety suite (T9); Owner für Policy und Tool-Allowlist (T10).

Lifecycle. Neue Tools = Threat-Model-Update. MCP/externe Tool-Server = Supply-Chain. Provider- und Model-Wechsel können Safety-Verhalten ändern — Canary inkl. Safety-Metriken.

---

Key Takeaways

• T8: Security ist Teil der Architektur — Trust Boundaries um Model, Context und Tools.
• Prompt Injection (direct/indirect) wird mit Schichten mitigiert, nicht mit einer Prompt-Zeile.
• AuthZ und Side Effects leben im Harness; das Modell wählt höchstens Args.
• Leakage-Pfade: Antwort, Logs, Provider, Cross-Tenant — Context minimieren und filtern.
• Guardrails: Input / Output / Policy; fail closed bei hohem Risiko; Utility messen.
• Red-Team- und Safety-Suites gehören in Eval und Release.
• Produkt ≠ Coding-Agent-Permissions.

Praktische nächste Schritte

1. Zeichnet Trust Boundaries und Side-Effect-Pfade für eure Top-Capability.
2. Geht security-review-ai.md durch; Lücken als Tickets.
3. Entfernt oder zerlegt jedes Tool mit freier Code-/SQL-/URL-Ausführung.
4. Baut 15–40 Injection-/Leakage-Fälle in die Safety suite (CI-Blocker).
5. Prüft Logs/Traces auf PII/Secrets; Redaction und ACL.
6. Kill-Switch und rate/cost limits pro Capability verifizieren.
7. Datenresidenz, Retention, Trust nach außen: Privacy, Compliance, Trust.