Initial import: Secure Coding Agents with Flue

Fachbuch-Projekt mit vollständiger Manuskriptfassung (Prolog, Kap. 1–11, Epilog, Backmatter), Cover- und Part-Page-Assets, Pandoc/LuaLaTeX-Pipeline (portiert von ki-hinterm-vorhang), Klappentext, Exposé und Lektorat Runde 1.
2026-07-24 11:43:43 +02:00
commit 0ca5293559
@@ -0,0 +1,24 @@
+# Build intermediates (reproducible via just assemble / just pdf)
+build/
+dist/*.aux
+dist/*.log
+dist/*.out
+dist/*.toc
+dist/*.tex
+
+# OS / editor
+.DS_Store
+.idea/
+.vscode/
+*.swp
+*~
+
+# Python
+__pycache__/
+*.py[cod]
+.venv/
+venv/
+
+# Local scratch
+*.tmp
+/tmp/
@@ -0,0 +1,85 @@
+# Secure Coding Agents with Flue
+
+Enterprise-ready Data Protection, Logging & Compliance Patterns  
+**Martin Richardt** (2026)
+
+Fachbuch-Projekt: sichere Coding-Agents auf Basis des Flue Frameworks
+(TypeScript Agent-Harness) — DLP, LLM-Datenkontrolle, Audit, Sandbox.
+
+## Cover bauen
+
+```bash
+just cover
+# oder:
+python3 scripts/build_cover.py
+```
+
+Voraussetzung: Python 3 + Pillow (`pip install pillow`), macOS-Systemfonts
+(Baskerville, Avenir Next).
+
+| Datei | Größe | Zweck |
+|-------|-------|--------|
+| `assets/cover/cover-art.jpg` | 1600×2400 | Textfreie Art-Base |
+| `assets/cover/cover.jpg` | 1600×2400 | Finales Cover (PDF/E-Book) |
+| `assets/cover/cover-hires.png` | 1600×2400 | Druck/Export |
+| `assets/cover/cover-web.jpg` | 800×1200 | Vorschau / Web |
+
+Design-Notizen: [`design/cover-entscheidungen.md`](design/cover-entscheidungen.md)  
+Klappentext: [`design/klappentext.md`](design/klappentext.md)  
+Exposé: [`expose.md`](expose.md)  
+Lektorat: [`design/lektorat-2026-07-24.md`](design/lektorat-2026-07-24.md)
+
+## PDF bauen
+
+Voraussetzungen: Pandoc, LuaLaTeX (TeX Live), Charter/DejaVu-Fonts.
+
+```bash
+just cover          # Cover neu rendern (optional)
+just assemble       # manuskript/* → build/book.md
+just pdf            # volles PDF → dist/secure-coding-agents-flue.pdf
+just pdf-sample     # nur Prolog + Kap. 1–2
+just clean
+```
+
+## Manuskript
+
+17 Quellen unter `manuskript/` (Prolog, 11 Kapitel, Epilog, Glossar, …).
+Gliederung und Konventionen: [`manuskript/README.md`](manuskript/README.md).
+
+**Teile**
+
+1. Grundlagen (Kap. 1–3)
+2. Datenschutz und DLP (Kap. 4–6)
+3. Isolation und Runtime (Kap. 7–8)
+4. Compliance und Betrieb (Kap. 9–11)
+
+## PDF-Pipeline
+
+Portiert von `../ki-hinterm-vorhang` (Pandoc + LuaLaTeX + KOMA):
+
+```
+pdf/
+  metadata.yaml
+  styles/secure-agents-colors.tex
+  templates/secure-agents-book.tex
+  templates/secure-agents-preamble.tex
+  filters/boxes.lua
+  front/impressum.tex
+```
+
+Cover-Einbindung: `\ProjectCover` → `assets/cover/cover.jpg`.
+
+## Projektstruktur
+
+```
+assets/cover/     Cover-Assets
+assets/parts/     Teiltrenner (teil-01 … teil-04)
+design/           Cover, Parts, Klappentext, Lektorat
+manuskript/       Kapitelquellen
+pdf/              LaTeX/Pandoc-Vorlage
+scripts/          assemble_book.py, build_cover.py
+justfile          cover | assemble | pdf | pdf-sample | clean
+dist/             PDF-Ausgabe
+```
+
+Part-Pages: [`design/parts.md`](design/parts.md)
@@ -0,0 +1,66 @@
+# Cover-Design: Secure Coding Agents with Flue
+
+## Zielgruppe (visuell)
+
+Ernsthafte Entwickler und Security-Verantwortliche in Unternehmen.
+Das Cover soll „Enterprise-ready / Security Engineering“ signalisieren — nicht
+Hobby-Tooling und nicht generisches AI-Hype-Sci-Fi.
+
+## Visuelle Metapher
+
+| Element | Bedeutung im Buchkontext |
+|--------|---------------------------|
+| Geschichtete, transparente Platten (Harness-Node) | Coding-Agent / AI-Harness als kontrollierte Schichtarchitektur |
+| Leuchtender Cyan-/Emerald-Filter | Data-Loss-Prevention: Datenstrom wird geprüft, bevor er an LLMs geht |
+| Stilisierte Schlüssel & Fragment-Glyphs | Sensitive Daten (Secrets, PII, Credentials), die herausgefiltert werden |
+| Circuit-Linien → Sandbox-Rechtecke | Sandbox-/Container-Strategien und Kontrollgrenzen |
+| Telemetrie-Linien am unteren Rand | Observability, Logging, Audit-Spuren — dezent, nicht Dashboard-Hype |
+
+## Farbschema
+
+- **Hintergrund:** Tiefes Navy/Schwarz (`#0B1220`-Nähe) — seriös, hoher Kontrast für Typo
+- **Akzent Cyan** (`#00D4FF`): Schutz/Filter, Kicker, Divider
+- **Akzent Emerald** (`#2A9D8F`): Compliance/„safe“, dezente Unterlinien
+- Bewusst kein Neon-Regenbogen, kein Purple-AI-Klischee
+
+## Typografie (separat vom Art-Base)
+
+Text wird **nicht** im Bildmodell erzeugt, sondern per `scripts/build_cover.py`
+(Pillow) über die textfreie Art-Base gelegt — scharfe, editierbare Titelzeilen.
+
+| Block | Inhalt | Rolle |
+|-------|--------|--------|
+| Kicker | SECURITY ENGINEERING | Genre/Positionierung |
+| Titel | Secure Coding Agents / with Flue | Primärbotschaft |
+| Untertitel | Enterprise-ready Data Protection, Logging & Compliance Patterns | Scope |
+| Tags | DLP · Sandbox · Audit | Drei Kernpfeiler |
+| Autor / Jahr | Martin Richardt · 2026 | Attribution |
+
+Fonts (macOS): Baskerville (Titel), Avenir Next (Rest) — technisch lesbar, nicht verspielt.
+
+## Layout-Prinzipien
+
+1. **Dunkler Freiraum oben** — Titelblock bleibt lesbar.
+2. **Visueller Fokus unten/mitte** — Metapher trägt, ohne Text zu stören.
+3. **Soft-Veil** hinter Titel und Autor — Kontrast ohne harte Box.
+4. **Keine Logos** — weder Flue noch Drittanbieter.
+
+## Pipeline
+
+```
+cover-art.jpg  (textfrei, 1600×2400)
+      ↓
+build_cover.py
+      ↓
+cover.jpg / cover-hires.png / cover-web.jpg
+```
+
+PDF-Einbindung vorbereitet in `pdf/templates/secure-agents-preamble.tex`
+(`\ProjectCover` → `assets/cover/cover.jpg`).
+
+## Bewusst weggelassen
+
+- Markenlogos und Framework-Branding-Icons
+- Figürliche Roboter/Humanoiden
+- Überladene Code-Wände oder Terminal-Screenshots
+- Marketing-Slogans auf dem Cover
@@ -0,0 +1,75 @@
+# Klappentext — Secure Coding Agents with Flue
+
+Varianten für Rückseite, Shop-Beschreibung und Pressematerial.  
+Ton: nüchtern, enterprise, ohne Marketing-Superative.
+
+---
+
+## Kurz (ca. 90 Wörter) — Shop / Softcover-Rücken
+
+Coding-Agents lesen Repositories, rufen Tools auf und senden Kontext an
+Sprachmodelle – oft schneller als jeder Review. Ohne klare Datengrenzen,
+Filter und Audit wird Produktivität zum stillen Risikotransfer.
+
+Dieses Fachbuch zeigt, wie sich Agents auf Basis eines Agent-Harnesses
+(exemplarisch Flue) freigabefähig absichern lassen: Datenfluss zum LLM, DLP
+und Entropie-Filter, Sandbox und Tool-Permissions, Logging ohne Secret-Leck,
+Enterprise-Patterns und Playbooks für den Betrieb.
+
+Für Entwickler, Security und Plattform-Teams, die Agents verantworten – nicht
+nur demonstrieren.
+
+---
+
+## Standard (ca. 160 Wörter) — Klappe / Produktseite
+
+Ein Coding-Agent in der IDE holt sich Dateien, schreibt Patches und hängt
+Kontext an ein Modell – manchmal inklusive Secrets aus `.env` und Logs. Das
+ist kein Randfall, sondern der Normalzustand unkontrollierter Adoption.
+
+*Secure Coding Agents with Flue* behandelt den Harness als Kontrollfläche:
+Was darf das Modell sehen? Was darf der Agent tun? Wie belegen Sie beides im
+Audit?
+
+Das Buch liefert praxistaugliche Patterns statt Prompt-Appelle:
+
+- Trust-Grenze und Datenfluss zum LLM  
+- DLP mit Pattern Matching und Entropie-Filtern  
+- Sandbox-Strategien und Least Privilege für Tools  
+- Audit-Events, die Kontrolle nachweisen, ohne Klartext zu speichern  
+- Enterprise-Anschluss (Gateway, Residenz, Rollen, Change)  
+- Playbooks für Secret-Verdacht, False Positives und Kill-Switch  
+
+Flue dient als TypeScript-Bezugspunkt; die Muster gelten harness-übergreifend.
+Zielgruppe sind ernsthafte Entwickler und Security-Verantwortliche in
+Unternehmen – nicht Hobby-Bots und Demo-Folien.
+
+**Martin Richardt** schreibt an der Schnittstelle von Softwarearchitektur,
+KI-Systemen und nachvollziehbarer Technik.
+
+---
+
+## Sehr kurz (ca. 40 Wörter) — Social / Meta-Description
+
+Wie man Coding-Agents enterprise-ready absichert: Datenkontrolle zum LLM, DLP,
+Sandbox, Permissions, Audit und Playbooks – am Harness, nicht im System-Prompt.
+
+---
+
+## Englisch kurz (ca. 80 words) — internationale Listings
+
+Coding agents read repos, call tools, and send context to models—often including
+secrets no one meant to share. This book treats the agent harness as the control
+plane: data flow to the LLM, DLP and entropy filters, sandboxes and least-
+privilege tools, audit without logging secrets, plus enterprise patterns and
+incident playbooks. Flue is the TypeScript reference point; the patterns apply
+beyond any single framework. For engineers and security owners who need
+shippable controls, not demos.
+
+---
+
+## Drei Sätze (Zitatblock / Einband innen)
+
+1. Was das Modell nicht sehen muss, darf es nicht sehen.  
+2. Was der Agent nicht tun muss, darf er nicht können.  
+3. Was Sie im Audit nicht zeigen können, gilt als nicht kontrolliert.
@@ -0,0 +1,80 @@
+# Lektorat — Secure Coding Agents with Flue
+
+**Datum:** 2026-07-24  
+**Scope:** Gesamtes Manuskript (Prolog, Kap. 1–11, Epilog, Backmatter)  
+**Methode:** Checkpoints Ton, Terminologie, Wiederholung, Verständlichkeit,
+Querverweise (angelehnt an Lektorats-Skill des Schwesterprojekts)
+
+## Ergebnis
+
+Erste Lektoratsrunde **durchgeführt und eingearbeitet**. PDF neu gebaut.
+
+## P0 — behoben
+
+| Fund | Maßnahme |
+|------|----------|
+| Kap. 4 Zusammenfassung: unklare Formulierung „skaliert Nutzen ohne Risiko … mitzuskalieren“ | Neu formuliert (Nutzen skalieren, ohne Datenrisiko proportional mitwachsen zu lassen) |
+| Gemischte Terminologie Allow-Listen / Deny-Listen / Allowlist | Vereinheitlicht auf **Allowlist(s)** / **Denylist(s)** (wie Glossar) |
+| Kap. 9 „Entscheidung-Metadaten“ | → **Entscheidungs-Metadaten** |
+
+## P1 — behoben
+
+| Fund | Maßnahme |
+|------|----------|
+| Doppelte Schlussformel „wenig unnötiges Wissen, wenig unnötige Macht“ (Kap. 7 + 8) | Kap. 7 und 8 differenziert; Epilog behält die drei Leitsätze |
+| „Enterprise-ready heißt“ als Schluss in Kap. 1, 10, 11 | Kap. 10 und 11 variiert |
+| „Theaterkulisse“ / „Theater“ für schwache Sandbox | Kap. 1 entschärft; Kap. 7 behält „Theater“ einmal |
+| Kap. 2 Schluss leicht lehrbuchhaft | Gestrafft, Mapping betont |
+| „Default-deny“ vs. „Deny by default“ (Kap. 7) | Prosa auf **Deny by default** |
+| Kap. 7 „ephemeral workspace“ mitten im DE-Text | → **ephemerer Workspace** |
+| Kap. 6/Epilog/Prolog: kleinere Stilglättungen | eingearbeitet |
+
+## P2 — bewusst belassen oder später
+
+| Fund | Entscheidung |
+|------|----------------|
+| Wiederkehrende Brücken „Kapitel X hat … Dieses Kapitel …“ | Gewollt für lineare Leser; nicht streichen |
+| „System-Prompt ist keine Policy“ an mehreren Stellen | Kernbotschaft; an Ersteinführung (Kap. 1/2) und Vertiefung (Kap. 8) ok |
+| Checklisten am Kapitelende ähnlich aufgebaut | Konvention des Buchs |
+| Literatur: Arbeitsbibliografie, nicht alle DOI | im Text so deklariert; Vertiefung bei Bedarf |
+| Part-Pages ohne Grafik | Infrastruktur, kein Lektoratstext |
+| Kein zweites Augenpaar / Fachreview Security | empfohlen als nächster Schritt |
+
+## Terminologie (kanonisch nach Runde 1)
+
+| Begriff | Form |
+|---------|------|
+| Positiv-/Negativlisten | Allowlist / Denylist |
+| Policy-Default | Deny by default |
+| Steuerungsschicht | Harness / Agent-Harness |
+| Modellzugang | Model Gateway / Gateway |
+| Risikoklassen Tools | R0–R4 |
+| Aufbewahrung Logs | Retention-Tier T0–T3 |
+| Buchtitel EN | Secure Coding Agents with Flue |
+
+## Querverweise
+
+Stichprobe der Kapitelverweise (2→3→4→…→11, Prolog-Lesepfade, Epilog-Schichtentabelle):
+**stimmig**. Keine offensichtlichen „siehe Kapitel N“-Fehler gefunden.
+
+## Ton
+
+- Nüchtern, enterprise/security, wenig Hype — **ok**
+- Keine AGI-Prophezeiungen — **ok**
+- Wiederkehrende Metapher „Vertrauensgrenze / Kontrolle als Produkt“ — kohärent
+
+## Statistik (Runde 1)
+
+| Kategorie | Geschätzt vor Fix | Nach Fix |
+|-----------|-------------------|----------|
+| P0 Sprache/Klarheit | 1 | 0 offen |
+| P0 Terminologie | 1 Cluster | vereinheitlicht |
+| P1 Redundanz Schlussformeln | 3 | entschärft |
+| P2 strukturelle Wiederholung | bewusst | belassen |
+
+## Empfohlene Runde 2 (nicht in diesem Durchlauf)
+
+1. Kapitelweise Lautlesen (Prolog + Kap. 4–6 priorisieren)  
+2. Fachreview: DLP-Schwellen, Sandbox-Stufen, DSGVO/AI-Act-Formulierungen mit Legal  
+3. Box-Filter optisch im PDF prüfen (`Kern in einem Satz` / `Zusammenfassung`)  
+4. Klappentext aus Prolog + Epilog-Leitsätzen ableiten  
@@ -0,0 +1,27 @@
+# Part-Page-Grafiken
+
+Textfreie Trenner-Illustrationen für `\ProjectPartPage` (Titel setzt LaTeX).
+
+| Datei | Teil | Titel (assemble) | Motiv |
+|-------|------|------------------|--------|
+| `assets/parts/teil-01.png` | 1 | Grundlagen | Geschichtete Architektur-Panels, Gitter, Circuit-Netz |
+| `assets/parts/teil-02.png` | 2 | Datenschutz und DLP | Filter-Membran, Datenpartikel, stilisierte Keys |
+| `assets/parts/teil-03.png` | 3 | Isolation und Runtime | Sandbox-Würfel auf Plattform, Isolationsringe |
+| `assets/parts/teil-04.png` | 4 | Compliance und Betrieb | Audit-Timeline, Wellen/Telemetrie, abstrakte Marker |
+
+## Stil
+
+- Bezug: Cover-Art (`assets/cover/cover-art.jpg`) per Image-Edit
+- Palette: Navy / Cyan / Emerald
+- Format: 1600×2400 px (2:3), PNG, RGB
+- **Kein Text, keine Logos** (Teilnummer und Titel kommen aus dem Template)
+
+## Einbindung
+
+`scripts/assemble_book.py` → `PART_BEFORE` injiziert:
+
+```latex
+\ProjectPartPage{n}{Titel}{assets/parts/teil-0n.png}
+```
+
+Neu erzeugen: Bilder ersetzen unter `assets/parts/`, dann `just pdf`.
@@ -0,0 +1,119 @@
+# Exposé
+
+**Titel:** *Secure Coding Agents with Flue*  
+**Untertitel:** *Enterprise-ready Data Protection, Logging & Compliance Patterns*  
+**Autor:** Martin Richardt  
+**Genre:** Fachbuch / Security Engineering für Software- und Plattform-Teams  
+**Sprache:** Deutsch (Titel und Untertitel Englisch)  
+**Umfang (Stand 2026-07):** ca. 73 PDF-Seiten · ~14.000 Wörter (erste durchgehende Fassung)  
+**Status:** Manuskript Vollfassung Kap. 1–11 + Front/Backmatter; Lektorat Runde 1
+
+---
+
+## Worum geht es?
+
+Coding-Agents erweitern die Angriffsfläche von „Code vorschlagen“ auf „Kontext
+beschaffen, Tools ausführen, Daten an LLMs senden“. Produktivität ist real;
+ohne Harness-Kontrollen wächst das Risiko still mit.
+
+Dieses Buch erklärt, wie man Agents **freigabefähig** macht – technisch und
+betrieblich:
+
+- Datenfluss und Trust-Grenze zum Modell  
+- DLP (Pattern Matching) und Entropie-Filter  
+- Sandbox und Tool-Permissions (Least Privilege)  
+- Logging/Audit ohne Secret-Klartext  
+- Enterprise-Patterns (Gateway, Residenz, Rollen, Change, Evidence)  
+- Playbooks für Incident, False Positives, Break-glass  
+
+**Flue** (TypeScript Agent-Harness) ist Bezugspunkt, kein Produktmarketing. Die
+Patterns zielen auf die *Stelle* im System (Context Builder, Gateway, Tool
+Runtime, Policy, Observability), nicht auf ein Logo.
+
+---
+
+## Zielgruppe
+
+| Primär | Bedarf |
+|--------|--------|
+| Entwickler:innen, die Agents bauen/betreiben | Konkrete Hooks und Anti-Pattern |
+| Security / Compliance | Nachweisbare Controls, keine Folien |
+| Plattform-Teams | Standard-Harness, Profile, Self-Service mit Leitplanken |
+
+**Nicht primär:** Prompt-Engineering-Einsteiger, reine Modell-Benchmarks,
+Hobby-Bot-Tutorials, Rechtsberatung.
+
+---
+
+## Ton und Alleinstellung
+
+- nüchtern, praxisnah, enterprise/security  
+- Patterns, Tabellen, Checklisten, Playbooks  
+- keine Hype- oder Untergangsretorik  
+- „System-Prompt ist keine Policy“ als Leitdifferenz  
+
+**Marktlücke:** Viel Material zu Agents ist Demo, Framework-Doku oder
+abstrakte AI-Governance. Wenig verbindet **Harness-Engineering** (DLP,
+Sandbox, Permissions, Audit) mit **Betriebsreife** (Playbooks, SLOs,
+Freigabemodell).
+
+**Kernversprechen:** Nach der Lektüre können Teams benennen, was nie ins Modell
+darf und was der Agent nie tun darf – und die entsprechende Kontrollkette im
+Harness entwerfen, messen und im Incident abarbeiten.
+
+---
+
+## Aufbau
+
+| Teil | Kapitel | Inhalt |
+|------|---------|--------|
+| Front | Prolog | Szene, Scope, Lesepfade |
+| 1 Grundlagen | 1–3 | Warum Security, Harness-Architektur, Bedrohungsmodell |
+| 2 Datenschutz | 4–6 | Datenfluss, DLP, Entropie |
+| 3 Isolation | 7–8 | Sandbox, Tool-Permissions |
+| 4 Compliance | 9–11 | Logging/Audit, Enterprise-Patterns, Playbooks |
+| Back | Epilog, Glossar, Literatur, Autor, Kolophon | |
+
+Drei Leitfragen durchgängig:
+
+1. Welche Daten verlassen den Vertrauensbereich – und warum?  
+2. Welche Kontrolle greift vor/nach dem LLM-Call – und was darf der Agent tun?  
+3. Wie beweisen wir Kontrolle im Audit und Incident?
+
+---
+
+## Vergleichbare Positionierung
+
+| Näher an | Ferner von |
+|----------|------------|
+| OWASP-LLM-Denken + Secure SDLC | Prompt-Kochbücher |
+| Plattform-/Security-Engineering | Business-Buzzword-AI |
+| Runbooks und Policy-as-Code | Reine Governance-Essays ohne Technik |
+
+Komplementär zu allgemeinen LLM-Sachbüchern (z. B. Schwesterprojekt *Die KI
+hinter dem Vorhang*): hier **Security- und Betriebsfokus** auf Coding-Agents.
+
+---
+
+## Lieferumfang / Herstellung
+
+- Markdown-Manuskript, Pandoc/LuaLaTeX-Pipeline (KOMA)  
+- Cover 1600×2400 (Art + Typografie-Overlay)  
+- PDF-Build: `just pdf` → `dist/secure-coding-agents-flue.pdf`  
+- Klappentext-Varianten: `design/klappentext.md`  
+
+---
+
+## Nächste Arbeitspakete (nach Exposé)
+
+1. Lektorat Runde 2 / Fachreview (optional Legal zu DSGVO/AI-Act-Formulierungen)  
+2. Part-Page-Grafiken (Teil 1–4)  
+3. Klappentext final für Einband wählen  
+4. Publikationsweg (Selbstverlag / Verlag) und ISBN  
+
+---
+
+## Autor
+
+Martin Richardt – Softwarearchitektur, KI-Systeme, Technikvermittlung.
+Schwesterprojekt u. a. *Die KI hinter dem Vorhang*.
@@ -0,0 +1,50 @@
+# Justfile — Build orchestration for Secure Coding Agents with Flue
+#
+# Portiert von ../ki-hinterm-vorhang. TeX/LaTeX bleibt Host-seitig (TeX Live).
+
+default: pdf
+
+# Art base + precise typography → assets/cover/cover.jpg
+cover:
+    @python3 scripts/build_cover.py
+
+assemble:
+    @python3 scripts/assemble_book.py
+
+pdf-styled: assemble
+    @mkdir -p dist
+    pandoc build/book.md \
+        --pdf-engine=lualatex \
+        --template=pdf/templates/secure-agents-book.tex \
+        -H pdf/styles/secure-agents-colors.tex \
+        --metadata-file=pdf/metadata.yaml \
+        --lua-filter=pdf/filters/boxes.lua \
+        --resource-path=.:manuskript:assets \
+        -V lang=de-DE -V papersize=a4 -V colorlinks \
+        --toc -o dist/secure-coding-agents-flue.pdf
+
+pdf: pdf-styled
+
+# Schnelle Vorschau: Prolog + Kap. 1–2
+pdf-sample:
+    @mkdir -p dist
+    pandoc \
+        manuskript/prolog.md \
+        manuskript/kapitel-01-warum-sichere-agents.md \
+        manuskript/kapitel-02-flue-architektur.md \
+        --pdf-engine=lualatex \
+        --template=pdf/templates/secure-agents-book.tex \
+        -H pdf/styles/secure-agents-colors.tex \
+        --metadata-file=pdf/metadata.yaml \
+        --lua-filter=pdf/filters/boxes.lua \
+        --resource-path=.:manuskript:assets \
+        -V lang=de-DE \
+        -V papersize=a4 \
+        -V colorlinks \
+        --toc \
+        -o dist/secure-coding-agents-sample.pdf
+
+clean:
+    @rm -f assets/cover/cover.jpg assets/cover/cover-hires.png assets/cover/cover-web.jpg
+    @rm -rf build dist
+    @echo "cleaned cover outputs, build/, dist/"
@@ -0,0 +1,45 @@
+[Du bist ein erfahrener technischer Autor und Security-Architekt.
+Basierend auf folgender detaillierter E-Book-Konzeption erstelle [hier gewünschtes Ergebnis einfügen, z. B. „den vollständigen Klappentext“, „Kapitel 7 als ausführlichen Entwurf“, „eine erweiterte Gliederung mit Unterkapiteln“ etc.]:
+
+Erstelle eine professionelle, moderne und hochwertige E-Book-Cover-Gestaltung (Hochformat, 1600×2400 px, 2:3) für folgendes Fachbuch:
+
+Titel: „Secure Coding Agents with Flue“
+Untertitel: „Enterprise-ready Data Protection, Logging & Compliance Patterns“
+Autor: [Platzhalter für Autorennamen]
+
+Design-Anforderungen:
+- Stil: Clean, technisch, modern, seriös – orientiert an hochwertigen Tech-/Security-Fachbüchern (ähnlich O’Reilly, Manning oder Apress, aber zeitgemäßer und dunkler).
+- Farbschema: Dunkler Hintergrund (tiefes Navy/Schwarz mit leichten Blau- und Cyan-Akzenten). Akzentfarben in elektrischem Cyan und gedämpftem Emerald-Grün.
+- Visuelle Elemente:
+  - Abstrakte, stilisierte Darstellung eines Coding-Agents / AI-Harness.
+  - Dezente visuelle Metapher für „Datenfilterung“ und „Sicherheit“: z. B. ein abstrakter Datenstrom, der durch einen leuchtenden Filter/Schutzschild fließt, während sensitive Daten (stilisierte Schlüssel, Code-Snippets) herausgefiltert werden.
+  - Subtile Code-Linien oder Circuit-Muster im Hintergrund, die in Sandbox-/Container-Formen übergehen.
+  - Sehr dezente Andeutung von Observability/Logging (kleine Telemetrie-Linien oder Graphen).
+- Typografie:
+  - Titel groß, klar, modern (sans-serif, technisch, aber gut lesbar).
+  - Untertitel kleiner und etwas leichter.
+  - Kein überladenes Design – viel Weißraum (bzw. Dunkelraum), hohe Lesbarkeit.
+- Stimmung: Vertrauenswürdig, professionell, zukunftsorientiert, „Enterprise-ready“, nicht verspielt oder zu sci-fi.
+- Keine Logos von Flue oder anderen Marken.
+- Text muss scharf und gut lesbar sein.
+
+Zusätzlicher Kontext für die Bildgestaltung (damit die visuelle Sprache stimmt):
+Das Buch behandelt den Aufbau sicherer Coding-Agents auf Basis des Flue Frameworks (TypeScript Agent-Harness). Schwerpunkt liegt auf:
+- Data-Loss-Prevention (Pattern Matching + Entropy-Filter)
+- Kontrolle übertragener Daten an LLMs
+- Protokollierung & Audit
+- Sandbox-Strategien und Enterprise-Anforderungen
+
+Das Cover soll sofort signalisieren: „Dieses Buch ist für ernsthafte Entwickler und Security-Verantwortliche in Unternehmen, nicht für Hobby-Projekte.“
+
+Erzeuge das Cover in hoher Qualität und beschreibe zusätzlich kurz die Design-Entscheidungen.
+
+Anforderungen an die Ausgabe:
+- Professioneller, klarer, praxisnaher Schreibstil (deutsch, sofern nicht anders gewünscht)
+- Technische Genauigkeit und Realismus
+- Betonung der Enterprise-/Security-Perspektive
+- Keine übertriebenen Marketing-Floskeln
+
+
+Für die PDF-Pipeline verwende die Vorlage aus dem Projekt ../ki-hinterm-vorhang
+Arbeite möglichst parallel
@@ -0,0 +1,30 @@
+# Manuskript — Secure Coding Agents with Flue
+
+Quellen für den PDF-Build. Reihenfolge steuert `scripts/assemble_book.py`.
+
+| Datei | Teil | Status |
+|-------|------|--------|
+| `prolog.md` | Front | **Vollfassung** |
+| `kapitel-01-warum-sichere-agents.md` | 1 Grundlagen | **Vollfassung** |
+| `kapitel-02-flue-architektur.md` | 1 | **Vollfassung** |
+| `kapitel-03-bedrohungsmodell.md` | 1 | **Vollfassung** |
+| `kapitel-04-datenfluss-llm.md` | 2 Datenschutz | **Vollfassung** |
+| `kapitel-05-dlp-pattern-matching.md` | 2 | **Vollfassung** |
+| `kapitel-06-entropie-filter.md` | 2 | **Vollfassung** |
+| `kapitel-07-sandbox-strategien.md` | 3 Isolation | **Vollfassung** |
+| `kapitel-08-tool-permissions.md` | 3 | **Vollfassung** |
+| `kapitel-09-logging-audit.md` | 4 Compliance | **Vollfassung** |
+| `kapitel-10-enterprise-patterns.md` | 4 | **Vollfassung** |
+| `kapitel-11-betrieb-playbooks.md` | 4 | **Vollfassung** |
+| `epilog.md` | Back | **Vollfassung** |
+| `glossar.md` | Back | **Vollfassung** |
+| `literatur.md` | Back | **Vollfassung** |
+| `ueber-den-autor.md` | Back | **Vollfassung** |
+| `kolophon.md` | Back | **Vollfassung** |
+
+**Konventionen**
+
+- Eine H1 pro Datei (`# Titel`)
+- Sprache: Deutsch (Buchtitel/Untertitel Englisch)
+- Boxen (später via `boxes.lua`): Abschnitte mit „Kern in einem Satz“, „Zusammenfassung“, „Überblick“
+- Keine Flue-Markenlogos in Abbildungen; Framework-Begriffe im Text sind ok
@@ -0,0 +1,64 @@
+# Epilog
+
+## Kontrolle ist das Produkt
+
+Coding-Agents werden bleiben. Sie werden besser planen, mehr Tools bedienen und
+tiefer in Repositories greifen. Die strategische Frage für Unternehmen ist
+deshalb nicht, *ob* man sie nutzt, sondern ob man die Vertrauensgrenze zum
+Modell und zu den Werkzeugen **gestaltet** – oder sie dem Zufall, der Demo und
+dem nächsten System-Prompt überlässt.
+
+Dieses Buch hat argumentiert: Die produktive Einheit ist nicht „das LLM“,
+sondern der **Harness** – Context, Policy, Gateway, Sandbox, Permissions,
+Audit. Flue und vergleichbare Frameworks geben dafür Nähte und Hooks. Die
+Sicherheit entsteht, wenn Sie diese Nähte schließen und betreiben.
+
+## Was zusammengehört
+
+| Schicht | Aufgabe in einem Satz |
+|---------|------------------------|
+| Bedrohungsmodell | wissen, was nie gesehen und nie getan werden darf |
+| Datenfluss | Trust-Grenze zum Modell zeichnen und budgetieren |
+| DLP + Entropie | Bekanntes und „sieht aus wie Secret“ filtern |
+| Sandbox | Ausführung vom Host- und Geheimnisraum trennen |
+| Permissions | Least Privilege deterministisch erzwingen |
+| Logging | Entscheidungen belegen, Payloads arm halten |
+| Enterprise-Patterns | Verträge, Rollen, Change, Evidence |
+| Playbooks | im Ernstfall dieselbe Reihenfolge fahren |
+
+Einzelne Maßnahmen ohne die anderen erzeugen Lücken: Filter ohne Sandbox,
+Sandbox ohne Permissions, alles ohne Audit, Audit ohne Playbooks.
+
+## Drei Sätze zum Mitnehmen
+
+1. **Was das Modell nicht sehen muss, darf es nicht sehen.**  
+2. **Was der Agent nicht tun muss, darf er nicht können.**  
+3. **Was Sie im Audit nicht zeigen können, gilt als nicht kontrolliert.**
+
+Bauen und betreiben Sie entlang dieser Sätze. Alles andere – beeindruckende
+Demos, maximale Autonomie, „der Prompt verbietet das schon“ – darf Prototyp
+bleiben, bis die drei Sätze grün sind.
+
+## Ein pragmatischer Start
+
+Wenn Sie morgen beginnen:
+
+1. Model-Calls nur noch über ein Gateway mit Allowlist  
+2. Deny für offensichtliche Secret-Pfade + Basis-DLP  
+3. Keine freie Shell als Default-Tool  
+4. Session-Audit mit `policy_version`  
+5. Kill-Switch und ein Playbook „Session kill / Key rotate“  
+
+Danach kalibrieren, nicht eskalieren: Entropie, strengere Sandbox, Residenz,
+Evidence-Paket. Perfektion ist kein Launch-Kriterium – **messbare Kontrolle**
+schon.
+
+## Schluss
+
+Agents skalieren Können und Risiko zugleich. Wer nur das Können skaliert,
+exportiert das Risiko an Vendor, Log-Pipeline und den unaufmerksamsten
+Commit der Woche. Wer Kontrolle als Produkt baut, kann Freigaben argumentieren,
+Incidents abarbeiten und den Nutzen behalten.
+
+Bauen Sie den Harness so, dass Security „Ja – unter diesen Grenzen“ sagen kann,
+statt dauerhaft nur „Nein, bis die Demo abgeschaltet ist“.
@@ -0,0 +1,139 @@
+# Glossar
+
+Die Einträge folgen der Terminologie dieses Buchs. Wo englische Fachbegriffe
+im Alltag dominieren, steht die gebräuchliche Form voran.
+
+**Agent (Coding-Agent)**
+: System, das ein LLM mit Tools, Kontextbeschaffung und oft einer
+  Mehrschritt-Schleife kombiniert, um Softwareaufgaben auszuführen – nicht nur
+  Text vorzuschlagen.
+
+**Agent-Harness**
+: Laufzeit- und Orchestrierungsschicht um ein LLM: Context Builder, Policy,
+  Gateway, Tool-Router, Sandbox-Anbindung und Observability. Zentraler Ort für
+  Security-Controls (Kapitel 2).
+
+**Allowlist / Denylist**
+: Explizite Positiv- bzw. Negativliste (Pfade, Hosts, Binaries, Modelle). Deny
+  by default plus Allowlist ist der Standard dieses Buchs.
+
+**Approval Gate**
+: Menschliche oder ticketgebundene Freigabe vor riskanten Tool-Calls (typisch
+  Risk-Klasse R3/R4).
+
+**Audit-Trail**
+: Nachvollziehbare Ereigniskette zu Entscheidungen und Nebenwirkungen
+  (Policy, Tools, Approvals, Model-Calls) – payload-arm, metadaten-reich
+  (Kapitel 9).
+
+**Blast Radius**
+: Maximaler Schaden bei Fehlverhalten, Kompromittierung oder Fehlbedienung
+  einer Session bzw. eines Profils.
+
+**Break-glass**
+: Zeitlich eng begrenzte Notfall-Erweiterung von Rechten; immer mit Audit und
+  TTL (Kapitel 11).
+
+**Context Builder**
+: Harness-Komponente, die Quellen selektiert, Chunks bildet und den
+  Modell-Kontext unter Budget zusammenstellt (Kapitel 4).
+
+**Datenklassifikation**
+: Einordnung von Repos/Inhalten (z. B. öffentlich, intern, vertraulich,
+  reguliert); steuert Agent-Profile und Gateway-Zonen (Kapitel 10).
+
+**DLP (Data Loss Prevention)**
+: Maßnahmen gegen unerwünschten Abfluss sensibler Daten; hier vor allem
+  vor dem Model-Call und auf Tool-Outputs (Kapitel 5–6).
+
+**Entropie-Filter**
+: Detektion hochzufälliger Zeichenketten als Secret-Kandidaten, ergänzend zu
+  Pattern Matching (Kapitel 6).
+
+**Fingerprint**
+: Nicht umkehrbarer Hash/Identifier eines Treffers für Logs und Korrelation –
+  ohne Secret-Klartext.
+
+**Flue**
+: TypeScript Agent-Harness, der in diesem Buch als architektonischer
+  Bezugspunkt dient (ohne Marken- oder API-Handbuchanspruch).
+
+**Least Privilege**
+: Minimale Rechte für Zweck und Dauer einer Aufgabe bzw. Session (Kapitel 8).
+
+**Model Gateway**
+: Kontrollierter Zugang zu LLM-Anbietern: Endpoint-Allowlist, Auth, Residenz,
+  Retention-Flags (Kapitel 4, 10).
+
+**Output-Scan**
+: Filterung der Modellantwort bzw. von Tool-Ergebnissen auf Secrets und
+  Policy-Verstöße vor Weitergabe oder Persistenz.
+
+**Policy-as-Code**
+: Versionierte, getestete und reviewte Regeln (Scopes, DLP, Pfade) als
+  Artefakt – nicht als System-Prompt-Text.
+
+**Policy-Version**
+: Explizite Versionskennung der geltenden Regeln; Pflichtfeld in Audit-Events.
+
+**Prompt Injection**
+: Manipulation des Agent-Verhaltens über eingeschleusten Text in
+  Nutzer- oder Kontextquellen (direkt oder indirekt).
+
+**Quarantine**
+: Aktion, bei der Material nicht in den Prompt geht, sondern in einen
+  Review-Pfad (Ticket/Security-Queue).
+
+**Redaction**
+: Ersetzen oder Maskieren sensibler Passagen (z. B. durch Platzhalter mit
+  Klasse und Fingerprint) vor dem Weitergeben.
+
+**Residenz-Zone**
+: Policy-gesteuerte Zuordnung von Workloads zu Regionen/Anbietern
+  (z. B. `eu-prod`, `us-exp`).
+
+**Retention-Tier**
+: Getrennte Aufbewahrungsklassen für Metrics, Audit, Debug und optional
+  Prompt-Archive (Kapitel 9–10).
+
+**Risk-Klasse (R0–R4)**
+: Einordnung von Tool-Operationen nach Wirkung: Lesen, Workspace-Write,
+  Ausführung, externe Seiteneffekte, Secrets/IAM (Kapitel 8).
+
+**Sandbox**
+: Isolierte Ausführungsumgebung für Agent-Tools und -Aktionen; Stufen von
+  Process-Isolation bis Remote Execution (Kapitel 7).
+
+**Schattenmodus**
+: Betrieb von Filtern mit Log/Observe ohne Enforce; zur Kalibrierung vor dem
+  harten Block (Kapitel 5–6).
+
+**Scope**
+: Grobe Fähigkeitsberechtigung einer Session (z. B. `fs:read`, `shell:test`).
+
+**Session**
+: Gebundener Agent-Lauf mit Identity, Scopes, Policy-Version und Trace-ID.
+
+**Shannon-Entropie**
+: Maß für die mittlere Informationsdichte/Zufälligkeit in einem
+  Zeichenfenster; Basis vieler Entropie-Heuristiken (Kapitel 6).
+
+**Source-ID**
+: Stabile Kennung einer Kontextquelle (Datei, Tool-Output, Suche) für Audit
+  und Redaction-Nachvollziehbarkeit.
+
+**STRIDE**
+: Klassisches Threat-Modeling-Schema (Spoofing, Tampering, Repudiation,
+  Information Disclosure, Denial of Service, Elevation of Privilege);
+  in Kapitel 3 agent-spezifisch ausgeprägt.
+
+**Tool Permission**
+: Explizite Berechtigung und Argumentbeschränkung für Agent-Werkzeuge im
+  Harness (Kapitel 8).
+
+**Trust-Zone**
+: Abstrakte Vertrauensgrenze im Datenfluss (z. B. Workspace, Harness, Model,
+  Nebenkanäle) – Kapitel 4.
+
+**TTL (Time to Live)**
+: Ablaufzeit für Ausnahmen, Allowlist-Einträge und Break-glass-Rechte.
@@ -0,0 +1,144 @@
+# 1 Warum sichere Coding-Agents?
+
+## Kern in einem Satz
+
+Coding-Agents erweitern die Angriffsfläche von „Code schreiben“ auf „Code,
+Kontext und Aktionen steuern“ – ohne Security-by-Design wird Produktivität zum
+Risikotransfer an das LLM.
+
+## Überblick
+
+Ein klassischer Autocomplete-Vorschlag riskiert vor allem schlechten Code. Ein
+Coding-Agent riskiert **Datenabfluss, unerwünschte Aktionen und fehlende
+Nachweise**. Er liest Repositories, führt Tools aus, schreibt Patches und
+sendet Kontext an Modelle – oft in einer Schleife, die schneller ist als der
+menschliche Review.
+
+Dieses Kapitel begründet, warum Security hier nicht „später“ kommt, was
+„Enterprise-ready“ operational bedeutet und welche Fehlannahmen Teams in
+Pilotprojekten systematisch in die Irre führen.
+
+## Vom Assistenten zum Akteur
+
+| Eigenschaft | Chat-Assistent | Coding-Agent |
+|-------------|----------------|--------------|
+| Kontext | Nutzer fügt ein | Agent holt sich Dateien, Diffs, Logs |
+| Wirkung | Textvorschlag | Tool-Calls, Writes, Builds, ggf. Tickets |
+| Geschwindigkeit | eine Antwort | viele Schritte pro Minute |
+| Fehlerbild | falsche Antwort | falsche Antwort *plus* Seiteneffekt |
+| Audit-Bedarf | oft gering | hoch (wer hat was ausgelöst?) |
+
+Die Sicherheitsfrage verschiebt sich von „Halluziniert das Modell?“ zu:
+
+- Was hat es **gesehen**?
+- Was hat es **getan**?
+- Können wir beides **belegen und begrenzen**?
+
+## Die neue Angriffs- und Fehlerfläche
+
+### Datenkanäle
+
+- Quellcode und interne Specs
+- Secrets in Env, Config, CI-Ausgabe, Kommentaren
+- PII in Fixtures, Logs, Seed-Daten
+- Drittinhalte (Dependencies, Issues, READMEs) mit Injection-Potenzial
+
+### Aktionskanäle
+
+- Dateisystem und Git
+- Shell und Package-Manager
+- interne und externe APIs
+- ggf. Deploy- und Ticket-Systeme
+
+### Vertrauensgrenzen
+
+- IDE/Laptop ↔ Agent-Harness
+- Harness ↔ Model-Anbieter
+- Harness ↔ Sandbox/Tool-Runtime
+- Logs/Telemetrie als stiller vierter Kanal
+
+Jeder Kanal, der ohne Policy wächst, skaliert Risiko mit der Adoption.
+
+## Was „Enterprise-ready“ hier bedeutet
+
+Nicht: „läuft in Kubernetes“ oder „hat ein SOC2-Logo auf der Vendor-Website“.
+Sondern operationalisierbare Eigenschaften:
+
+| Eigenschaft | Konkret |
+|-------------|---------|
+| **Datenminimierung** | nur task-relevanter Kontext ans Modell |
+| **Abflusskontrolle** | DLP/Entropie, Deny-Pfade, Output-Scan |
+| **Least Privilege** | Scopes, Schemas, Approvals |
+| **Begrenzter Blast Radius** | Sandbox-Stufen, Timeouts, Kill-Switch |
+| **Nachvollziehbarkeit** | Audit-Events mit Policy-Version |
+| **Anschlussfähigkeit** | IAM, SIEM, Change, Incident, Verträge |
+| **Betrieb** | Playbooks, SLOs, Exception mit TTL |
+
+Ein Agent, der beeindruckende Demos liefert, aber keine dieser Eigenschaften
+testbar erfüllt, ist ein **Schattenkanal** – auch wenn er in der offiziellen
+IDE-Sidebar wohnt.
+
+## Warum „später absichern“ scheitert
+
+1. **Gewohnheit schlägt Policy.** Läuft der Agent drei Monate ohne Filter,
+   gelten Filter als Regression.
+2. **Kontext-Caches und Prompts** speichern Vergangenheit; späte Filter fangen
+   nicht, was schon draußen war.
+3. **Schatten-Workarounds** (private Keys, Consumer-Chat) entstehen, sobald die
+   offizielle Strecke zu spät kommt und zu weh tut.
+4. **Audit fragt nach operating effectiveness** – Design-Absicht ohne History
+   reicht nicht.
+
+Security-by-Design heißt hier: Harness-Hooks und Default-Deny *bevor*
+flächendeckendes Rollout.
+
+## Typische Fehlannahmen
+
+| Annahme | Realität |
+|---------|----------|
+| „Das Repo ist intern, also darf alles in den Prompt.“ | Intern ≠ freigegeben für Drittanbieter-Inferenz; Fixtures und Logs sind oft prod-nah. |
+| „Der Vendor speichert nichts – Compliance erledigt.“ | Vertrag ≠ technische Enforce; Missbrauchsfilter, Support, Retries existieren. |
+| „Logging der Antworten reicht als Audit.“ | Entscheidungen liegen in Tool-Calls, Denies, Approvals – nicht nur in der Prosa. |
+| „Sandbox = Docker, fertig.“ | Socket-Mounts, Secret-Env und offenes Netz entwerten die Isolation. |
+| „Der System-Prompt verbietet Gefährliches.“ | Probabilistisch, injizierbar, nicht audit-tauglich als Control. |
+| „Nur böse Angreifer sind relevant.“ | Unachtsamkeit und Fehlkonfiguration dominieren den Alltag. |
+
+Die späteren Kapitel ersetzen jede Zeile durch prüfbare Patterns.
+
+## Wer profitiert – und wer bremst
+
+**Profitieren:** Teams mit klaren Profilen, schnellerem Review unkritischer
+Änderungen, weniger Copy-Paste in unkontrollierte Chat-UIs, besseren Argumenten
+gegenüber Security.
+
+**Bremsen (berechtigt):** Datenschutz, Revision, Betreiber kritischer Systeme –
+solange Nachweise fehlen. Das Buch liefert die technische Seite dieser
+Nachweise; die organisatorische Einbettung steht in Kapitel 10–11.
+
+## Lesepfad in den Rest des Buchs
+
+```
+Kap. 2  Harness-Schichten (wo Controls sitzen)
+Kap. 3  Bedrohungsmodell (was wir schützen)
+Kap. 4–6  Datenpfad zum Modell
+Kap. 7–8  Aktionspfad (Sandbox, Permissions)
+Kap. 9–11 Nachweis und Betrieb
+```
+
+## Checkliste: Brauchen wir dieses Buch *jetzt*?
+
+- [ ] Agents lesen mehr als der Nutzer explizit einfügt
+- [ ] Tools können schreiben oder Shell ausführen
+- [ ] Kontext geht an Modelle außerhalb des reinen Intranet-Trusts
+- [ ] Security oder Compliance hat Freigabe noch nicht erteilt – oder unter Vorbehalt
+- [ ] Es gibt keine versionierte Policy und kein Session-Audit
+- [ ] Ausnahmen existieren „mündlich“ ohne TTL
+
+Je mehr Haken, desto teurer wird Warten.
+
+## Zusammenfassung
+
+Coding-Agents sind Akteure mit Daten- und Aktionskanälen. Produktivität ohne
+Security-by-Design ist Risikotransfer an Modelle, Vendor und Zufall.
+Enterprise-ready heißt: minimieren, begrenzen, nachweisen, betreiben – testbar,
+nicht deklamatorisch. Kapitel 2 verortet diese Anforderungen im Harness.
@@ -0,0 +1,199 @@
+# 2 Flue-Architektur: der Agent-Harness
+
+## Kern in einem Satz
+
+Der Harness orchestriert Tools, Kontext, Policies und Laufzeit – und ist damit
+der natürliche Ort für Security-Kontrollen, nicht der System-Prompt.
+
+## Überblick
+
+Ein Agent-Harness sitzt zwischen Nutzer, Tools und LLM. Er entscheidet, welcher
+Kontext aufgebaut wird, welche Werkzeuge existieren, wie Ergebnisse
+zurückfließen und welche Telemetrie entsteht. **Flue** dient in diesem Buch als
+TypeScript-Bezugspunkt für genau diese Schicht: benannt, aber nicht als
+Produkthandbuch.
+
+Wer den Harness kontrolliert, kontrolliert den Daten- und Aktionsraum. Wer nur
+das Modell „promptet“, verwaltet Symptome.
+
+## Harness vs. Modell vs. IDE
+
+| Komponente | Aufgabe | Determinismus |
+|------------|---------|----------------|
+| **IDE / UI** | UX, Anzeige, lokale Shortcuts | n/a |
+| **Harness** | Orchestrierung, Policy, Tools, Context | hoch (Ihrer Implementierung) |
+| **Modell** | Token-Vorhersage / Planung in Sprache | probabilistisch |
+| **Gateway** | Zugang zum Modell (Vertrag, Region) | hoch, wenn Allowlist |
+| **Sandbox** | Ausführungsumgebung der Tools | hoch, wenn isoliert |
+
+Security-Controls, die auditierbar sein sollen, gehören in Harness, Gateway und
+Sandbox. Das Modell darf Vorschläge machen – es darf nicht die Policy *sein*.
+
+## Schichtenmodell
+
+```
+┌─────────────────────────────────────────┐
+│  Session / Identity / IAM                 │
+├─────────────────────────────────────────┤
+│  Orchestrator (Loop, Budgets, Stop)       │
+├─────────────────────────────────────────┤
+│  Context Builder  │  Policy Engine        │
+│  (Retrieval)      │  (Scopes, DLP hooks)  │
+├─────────────────────────────────────────┤
+│  Model Gateway          │  Tool Router    │
+├─────────────────────────────────────────┤
+│  Tool Runtime / Sandbox                   │
+├─────────────────────────────────────────┤
+│  Observability (Audit, Metrics)           │
+└─────────────────────────────────────────┘
+```
+
+### Session / Identity
+
+- Wer startet den Agent? Mensch, CI-Bot, Service-Account?
+- Welche Rolle und welches Repo-Label gelten?
+- Session-ID für den gesamten Loop (Kapitel 9)
+
+Ohne Identity keine Attribution und keine rollenbasierten Default-Scopes
+(Kapitel 8 und 10).
+
+### Orchestrator
+
+- Agent-Loop: Modellvorschlag → Tool → Observation → erneut
+- Begrenzungen: max. Schritte, Token-Budget, Wanduhr-Timeout
+- Kill-Switch und Loop-Detection (Kapitel 11)
+
+Der Orchestrator ist der Ort für **Stop-Bedingungen**, die nicht vom Modell
+„ausverhandelt“ werden.
+
+### Context Builder
+
+- holt Dateien, Diffs, Suchtreffer, Tool-Outputs
+- vergibt Source-IDs
+- übergibt Chunks an Policy Gate und DLP (Kapitel 4–6)
+- baut die Message-Liste unter Budget
+
+Hier entscheidet sich, ob „hilfsbereit“ zu „datenhungrig“ wird.
+
+### Policy Engine
+
+- Pfad- und Tool-Regeln
+- Risk-Klassen und Approvals
+- versionierte `policy_version`
+
+Idealerweise ein Modul, das **Unit-Tests** kennt – kein verstreutes `if` in
+zehn Adaptern.
+
+### Model Gateway
+
+- nur freigegebene Endpoints und Modelle
+- Auth als Workload-Identity
+- Residenz- und Retention-Flags
+- kein Seiteneinstieg aus Tools heraus (Kapitel 4, 10)
+
+### Tool Router und Runtime
+
+- Schema-Validierung der Argumente
+- Permission-Check
+- Ausführung in Sandbox-Profil der Risk-Klasse (Kapitel 7–8)
+- Output zurück durch DLP in den Context Builder
+
+### Observability
+
+- strukturierte Events, keine Secret-Klartexte
+- Metriken für DX und Security (Kapitel 9)
+
+## Daten- und Kontrollfluss (Happy Path)
+
+```
+1. User-Auftrag + Session-Policy
+2. Context Builder selektiert Quellen
+3. Policy Gate + DLP/Entropie
+4. Komposition → Gateway → Modell
+5. Tool-Vorschlag → Permission → Sandbox
+6. Tool-Output → DLP → Context
+7. ggf. weitere Iterationen bis Stop
+8. Ergebnis an UI; Audit-Events parallel
+```
+
+Abbrüche an 3 oder 5 sind **Erfolge der Kontrolle**, keine bloßen Fehler –
+sofern die UX den Grund verständlich macht.
+
+## Warum nicht „nur das Modell“?
+
+Modelle:
+
+- halten Policy nicht verlässlich ein,
+- sind anfällig für Injection in Kontextquellen,
+- liefern keine revisionssicheren Entscheidungslogs im Sinne Ihrer Governance.
+
+Deterministische Schichten:
+
+- Filter und Allowlists,
+- Schema-Validatoren,
+- Sandboxes und Net-Policies,
+- signierte oder zumindest versionierte Policy-Artefakte,
+
+sind die Controls, die Sie in einem Audit *zeigen* können.
+
+## Flue als Bezugspunkt (ohne Feature-Katalog)
+
+In einem TypeScript-Harness wie Flue erwarten Sie typischerweise:
+
+- typisierte Tool-Definitionen (Eingabe-Schemas),
+- erweiterbare Middleware/Hooks um Context und Tool-Calls,
+- eine zentrale Loop-Implementierung,
+- austauschbare Model-Clients.
+
+Dieses Buch setzt genau dort an: **Hooks vor dem Model-Call, vor dem Tool-Call
+und nach dem Tool-Output**. Konkrete API-Namen ändern sich – die Nahtstellen
+bleiben.
+
+Wenn Sie einen anderen Harness nutzen, mappen Sie:
+
+| Dieses Buch | Ihre Codebase |
+|-------------|----------------|
+| Context Builder | retrieval / prompt assembler |
+| Policy Engine | authz / rules module |
+| Gateway | LLM client wrapper |
+| Tool Runtime | executor / worker |
+| Observability | logger / tracer |
+
+## Integrationsflächen
+
+| Integration | Risiko ohne Kontrolle |
+|-------------|----------------------|
+| IDE-Plugin | lokaler Secret-Zugriff, unklare Identity |
+| CI | hohe Rechte, Secrets in Env, parallele Jobs |
+| Chat-UI intern | Prompt-Archive, Schattenkopien |
+| Ticket-Bot | Seiteneffekte nach außen (R3) |
+
+Dieselbe Harness-Policy sollte Profile pro Fläche liefern, nicht fünf
+Implementierungen mit fünf Lücken.
+
+## Anti-Pattern in der Architektur
+
+1. **SDK-Calls am Harness vorbei** aus Utility-Skripten  
+2. **Policy nur im IDE-Client**, Server vertraut blind  
+3. **Ein God-Object-Loop** ohne testbare Policy-Module  
+4. **Gemeinsame Credentials** für Gateway und Tool-Cloud  
+5. **Logs im selben Bucket wie Prompt-Volltext und Metrics**  
+
+## Checkliste: Harness security-ready?
+
+- [ ] Eine Session-ID über den gesamten Loop
+- [ ] Kein Model-Call außerhalb des Gateways
+- [ ] Context-Chunks passieren Gate + DLP
+- [ ] Tool-Calls passieren Schema + Permission + Sandbox
+- [ ] Tool-Outputs erneut durch DLP
+- [ ] `policy_version` und `agent_version` in Telemetrie
+- [ ] Stop-Bedingungen unabhängig vom Modell
+- [ ] Profile für IDE vs. CI getrennt konfigurierbar
+
+## Zusammenfassung
+
+Der Agent-Harness ist die Kontrollfläche: Identity, Context, Policy, Gateway,
+Tools, Sandbox, Audit. Flue ist ein TypeScript-Beispiel für genau diese Schicht;
+die Patterns lassen sich auf andere Harnesses mappen. Kapitel 3 ergänzt die
+Architektur um ein explizites Bedrohungsmodell – damit die Hooks an den
+richtigen Risiken ansetzen.
@@ -0,0 +1,170 @@
+# 3 Bedrohungsmodell für Coding-Agents
+
+## Kern in einem Satz
+
+Ohne explizites Bedrohungsmodell werden Filter und Sandboxes zur Kosmetik:
+zuerst Assets und Angreiferpfade, dann Controls.
+
+## Überblick
+
+Kapitel 2 hat die Harness-Schichten benannt. Dieses Kapitel beantwortet, *wogegen*
+sie arbeiten: welche Assets schützenswert sind, wer oder was sie gefährdet, und
+welche Kontrollziele die späteren Kapitel bedienen.
+
+Ein brauchbares Agent-Security-Design beginnt nicht mit dem schönsten Prompt,
+sondern mit zwei Sätzen:
+
+1. Was darf **niemals** ins Modell?  
+2. Was darf der Agent **niemals** tun?
+
+## Scope des Modells
+
+**In scope:** Coding-Agents mit Repo-Zugriff, Tool-Ausführung und LLM-Gateway
+in Unternehmenskontexten (IDE und CI).
+
+**Out of scope (hier):** physische Sicherheit, klassische Web-App-OWASP im
+Detail, vollständige Lieferkettenanalyse aller Dependencies – außer wo sie den
+Agent-Pfad kreuzen.
+
+Annahmen (anpassen, nicht ignorieren):
+
+- Entwickler sind keine Angreifer, aber **fehlbar** und unter Zeitdruck.
+- Das Modell ist **unzuverlässig** bzgl. Policy und kann injiziert werden.
+- Der Model-Anbieter liegt **außerhalb** des Repo-Trusts, auch mit DPA.
+- Tools sind **APIs mit Seiteneffekten**, nicht „Funktionen ohne Risiko“.
+
+## Assets
+
+| Asset | Warum wertvoll | Typische Agent-Berührung |
+|-------|----------------|---------------------------|
+| Quellcode & Specs | IP, Angriffsfläche, Roadmap | Retrieval, Diffs |
+| Secrets | Account-Übernahme, Cloud-Kosten | `.env`, Logs, Config |
+| PII / Kundendaten | Regulierung, Vertrauen | Fixtures, Dumps, Tickets |
+| Interne Infrastruktur-Infos | Lateral Movement | Hostnamen, Runbooks |
+| Tool-Fähigkeiten | Wirkung in Repo und Netz | Shell, APIs |
+| Prompt-/Response-Inhalte | Vertrag, Leak, Training | Gateway, Logs |
+| CI- und Cloud-Identitäten | hohe Privilegien | Agent in Pipeline |
+| Vertrauenswürdigkeit des Builds | Supply Chain | install/build tools |
+
+Priorisieren Sie Assets **pro Repo und Datenklasse** – nicht jede Sandbox-Stufe
+für jedes Hobby-Skript.
+
+## Akteure und Fehlermodi
+
+| Akteur / Modus | Beispiel | Primäres Asset |
+|----------------|----------|----------------|
+| Unachtsamer Insider | Agent liest Secrets „hilfsweise“ | Secrets, PII |
+| Malicious Insider | gezielte Exfil über Agent-Kontext | IP, Secrets |
+| Prompt Injection (indirekt) | Anweisung in README/Issue/Dependency | Tools, Daten |
+| Externe Angreifer auf Supply Chain | kompromittiertes Postinstall | Runtime, Credentials |
+| Fehlkonfiguration | zu breite Scopes, offenes Netz | alles |
+| Vendor-/Gateway-Seite | Retention, Support, Breach | Prompt-Inhalte |
+| Automatischer Loop | Kosten, Spam, Selbstverstärkung | Verfügbarkeit, Geld |
+
+Der häufigste produktive Fall in vielen Organisationen ist die **Kombination
+aus Unachtsamkeit und Fehlkonfiguration**, nicht der Film-Angreifer. Das Modell
+muss trotzdem Injection und Privilege-Expansion abdecken.
+
+## STRIDE für Coding-Agents
+
+| STRIDE | Agent-spezifische Ausprägung | Control-Schwerpunkt |
+|--------|------------------------------|---------------------|
+| **S**poofing | fremde Session, gestohlene IDE-Tokens, CI-Identity missbraucht | IAM, Session-Bindung (Kap. 2, 8, 10) |
+| **T**ampering | manipulierte Tool-Outputs als „Wahrheit“, vergifteter Kontext | Schema, Sandbox, untrusted-Markierung (Kap. 4, 7, 8) |
+| **R**epudiation | „wer hat deployed / geleakt?“ unbeantwortbar | Audit-Events (Kap. 9) |
+| **I**nformation Disclosure | Secrets/PII/IP an Modell oder Log | DLP, Entropie, Gateway, Logging-Hygiene (Kap. 4–6, 9) |
+| **D**enial of Service | Token-Burn, Tool-Loops, Platte voll | Budgets, Rate-Limits, Kill-Switch (Kap. 2, 11) |
+| **E**levation of Privilege | Agent > Nutzer-Rechte, Sandbox-Escape, Prod-API | Permissions, Sandbox, Approvals (Kap. 7–8) |
+
+## Angriffspfade (skizziert)
+
+### Pfad D1 — Secret in den Prompt
+
+```
+Datei/Log mit Secret → Context Builder ohne Gate
+  → kein/ schwaches DLP → Gateway → Anbieter
+```
+
+**Mitigation:** Deny-Pfade, Pattern+Entropie, Output-Scan, kein Secret-Env in
+der Tool-Runtime (Kap. 4–7).
+
+### Pfad D2 — Prompt Injection zu Tool-Missbrauch
+
+```
+Untrusted Datei → Modell folgt Anweisung
+  → mächtiges Tool (shell/net) → Exfil oder Zerstörung
+```
+
+**Mitigation:** enge Tools, Argument-Schemas, Default-deny Netz, Approvals,
+untrusted Source-Flag (Kap. 7–8).
+
+### Pfad D3 — Log als zweites Leck
+
+```
+DLP blockt Prompt → Debug-Log schreibt Match-Klartext
+  → breiter Ops-Zugriff
+```
+
+**Mitigation:** Fingerprint-only, Retention-Tiers (Kap. 9).
+
+### Pfad D4 — Privilege über CI
+
+```
+Agent in Pipeline mit Deploy-Rolle → Injection oder Bug
+  → Produktion
+```
+
+**Mitigation:** getrennte Identitäten, R3 nur mit Approval, remote starke
+Sandbox (Kap. 8, 10).
+
+## Kontrollziele (Mapping auf das Buch)
+
+| Kontrollziel | Kapitel |
+|--------------|---------|
+| Datenminimierung und Trust-Grenze Modell | 4 |
+| Erkennung bekannter Secret-/PII-Formate | 5 |
+| Erkennung unbekannter high-entropy Secrets | 6 |
+| Begrenzung der Ausführungsumgebung | 7 |
+| Least Privilege und Approvals | 8 |
+| Nachweis und forensische Korrelation | 9 |
+| Governance, Vendor, Rollen | 10 |
+| Incident- und Betriebsreaktion | 11 |
+
+Wenn ein späteres Pattern kein Ziel aus dieser Liste trifft, ist es
+Dekoration – oder Ihr Modell ist unvollständig und muss erweitert werden.
+
+## Bedrohungsmodell pflegen
+
+- **Trigger:** neues Tool, neues Gateway, neues Repo-Label, Incident, Vendor-Wechsel
+- **Output:** aktualisierte Asset-Liste, Top-Pfade, explizite Non-Goals
+- **Owner:** Platform + Security gemeinsam
+- **Artefakt:** kurze Living Doc, nicht 80 Seiten, die niemand liest
+
+Ein Modell, das nur zur initialen Freigabe existiert, veraltet mit dem ersten
+zusätzlichen `curl`-Tool.
+
+## Anti-Pattern
+
+1. **STRIDE als ausgefülltes Formular ohne technische Folge**  
+2. **Nur externe Angreifer modellieren, Insider-Fehler ignorieren**  
+3. **Assets = „die Cloud“** ohne Secrets/PII/Tools zu trennen  
+4. **Threat Model copy-pasten** von Chatbots ohne Repo-Realität  
+5. **Controls sammeln**, die kein Ziel adressieren  
+
+## Checkliste: Modell sessionstauglich?
+
+- [ ] Assets priorisiert (Top 5 reichen für den Start)
+- [ ] Mindestens Pfade D1–D3 bewertet
+- [ ] STRIDE-Zeilen mit Control-Verweis
+- [ ] Annahmen dokumentiert (Vendor-Trust, IDE vs. CI)
+- [ ] Non-Goals benannt
+- [ ] Review-Termin oder Trigger definiert
+- [ ] Mapping auf Kapitel/Implementierungs-Backlog
+
+## Zusammenfassung
+
+Bedrohungsmodellierung für Coding-Agents macht aus Bauchgefühl eine
+priorisierte Kontroll-Landkarte: Assets, Akteure, STRIDE, konkrete Pfade.
+Die Antwort auf „Was darf nie ins Modell / nie als Aktion?“ steuert den Rest
+des Buchs. Ab Kapitel 4 wird der Datenpfad zum LLM entlang dieser Ziele
+technisch ausgebaut.
@@ -0,0 +1,235 @@
+# 4 Datenfluss zum LLM steuern
+
+## Kern in einem Satz
+
+Jeder Token, der den Vertrauensbereich verlässt, ist eine bewusste Entscheidung –
+oder ein Leck.
+
+## Überblick
+
+Zwischen dem Lesen einer Datei und dem Absenden an ein Sprachmodell liegt der
+kritische Pfad eines Coding-Agents. Hier entscheiden Selektion, Redaction,
+Budget und Gateway-Policy darüber, ob der Agent hilfreich *und* freigabefähig
+ist.
+
+Kapitel 3 hat Assets und Angreiferpfade skizziert. Dieses Kapitel zeichnet die
+**Vertrauensgrenze zum Modell** als Architektur: welche Stufen der Datenfluss
+hat, welche Prinzipien gelten und wo DLP (Kapitel 5–6), Sandbox und Permissions
+(Kapitel 7–8) andocken.
+
+## Warum der Model-Call eine Vertrauensgrenze ist
+
+Ein LLM-Anbieter – intern oder extern – ist aus Sicht Ihrer Organisation oft:
+
+- ein **Auftragsverarbeiter** mit eigenem Retention- und Trainingsregime,
+- ein **Netzwerkziel** außerhalb des Repo-Trusts,
+- ein System, das Eingaben in Logs, Caches oder Support-Workflows spiegeln kann.
+
+Selbst bei „zero retention“-Verträgen bleiben Prompt-Inhalte für die Dauer der
+Inferenz und oft in Fehler- und Missbrauchssystemen sichtbar. Technisch und
+vertraglich gilt: **was den Gateway passiert, ist potenziell außerhalb Ihrer
+direkten Kontrolle**.
+
+Deshalb ist „alles Relevante in den Kontext“ keine Neutralität, sondern eine
+Risikoentscheidung – und sie gehört in den Harness, nicht in den System-Prompt.
+
+## Referenzdatenfluss
+
+```
+1. Nutzerauftrag / Systemziele
+2. Retrieval (Dateien, Diffs, Tool-Ergebnisse, Suche)
+3. Policy Gate (Allow/Deny, Klassifikation, Zweck)
+4. DLP / Entropie-Filter          ← Kapitel 5–6
+5. Kontext-Komposition + Token-Budget
+6. Model Gateway (Anbieter, Region, Retention)
+7. Antwort-Ingress (Output-Filter, Secret-Scan)
+8. Persistenz nur erlaubter Artefakte
+```
+
+Die Reihenfolge ist Absicht: **Policy und Filter vor Komposition**, nicht
+danach. Wer erst einen 200-k-Token-Kontext baut und dann scannen will, zahlt
+Latenz und erhöht die Chance, dass Zwischenspeicher und Debug-Logs bereits
+sensible Fragmente halten.
+
+### Stufe 1–2: Auftrag und Retrieval
+
+Der Agent soll nicht „das Repo“ laden, sondern **task-gebunden** selektieren:
+
+- explizite Pfade aus dem Nutzerauftrag
+- Suchtreffer mit Rank und Limit
+- Diffs gegen einen definierten Base-Branch
+- Tool-Outputs nur der aktuellen Session
+
+Jede Retrieval-Quelle bekommt eine **Source-ID** (für Audit und spätere
+Redaction-Nachvollziehbarkeit).
+
+### Stufe 3: Policy Gate
+
+Bevor Text in den Filter-Stack geht:
+
+| Prüfung | Beispiel |
+|---------|----------|
+| Pfad-Allow/Deny | `.env`, `**/*.pem`, Vault-Injects |
+| Dateityp / Größe | Binaries, Minified Bundles, Riesen-Logs |
+| Datenklassifikation | intern / vertraulich / reguliert |
+| Zweckbindung | Task-Typ erlaubt diese Quelle? |
+| Tenant-/Repo-Grenze | kein Cross-Repo ohne Policy |
+
+Deny by default für unbekannte oder hochsensible Klassen; Allowlists
+versionieren.
+
+### Stufe 4: DLP und Entropie
+
+Siehe Kapitel 5 und 6. An dieser Naht gilt:
+
+- Aktionen `block`, `redact`, `quarantine` sind **Harness-Entscheidungen**
+- Klartext von Treffern gehört nicht in Telemetrie
+- blockierte Chunks erzeugen maschinenlesbare Fehler für den Agent-Loop
+  (ohne Secret-Inhalt)
+
+### Stufe 5: Kontext-Komposition und Budget
+
+Nach dem Filtern:
+
+- Nachrichtenrollen (system / developer / user / tool) klar trennen
+- **Budget** pro Quelle und gesamt (Tokens, nicht nur Zeichen)
+- Priorisierung: Auftrag und aktuelle Fehler > historische Tool-Spuren
+- Redacted Platzhalter beibehalten – stilles Weglassen erschwert Debugging
+  und verleitet zu Riskante „nochmal alles laden“-Schleifen
+
+Budget ist Security: unbegrenzter Kontext belohnt Datenhunger und macht
+Injection-Oberflächen größer.
+
+### Stufe 6: Model Gateway
+
+Der Gateway ist mehr als eine HTTP-URL:
+
+| Kontrolle | Frage |
+|-----------|--------|
+| Anbieter / Endpoint | Welcher Vertrag, welche Region? |
+| Modell-ID | Freigegebene Modelle only? |
+| Auth | Service-Identität, nicht Entwickler-PAT im Klartext |
+| Retention-Flags | wo API es hergibt, explizit setzen und loggen |
+| Timeout / Retry | keine unkontrollierten Doppel-Sends mit Secrets |
+| Kill-Switch | globales Stoppen bei Incident |
+
+Mehrere Gateways (EU-Prod, US-Experiment, lokales Modell) sind normal –
+Routing gehört in Policy, nicht in Ad-hoc-ENV auf Laptops.
+
+### Stufe 7–8: Antwort und Persistenz
+
+- Output auf Secret-Echo und Policy-Verstöße scannen
+- Antworten nicht automatisch in ungeschützte Ticket-/Chat-Systeme spiegeln
+- Persistenz: Diffs und Zusammenfassungen ja; Roh-Prompts oft nein oder
+  strengere Retention (Kapitel 9)
+
+## Trust-Zonen (Arbeitsmodell)
+
+| Zone | Beispiele | Typische Regel |
+|------|-----------|----------------|
+| Z0 Gerät / IDE | lokaler Editor, ungescannte Zwischenablage | Nutzerverantwortung; Agent nicht blind füttern |
+| Z1 Workspace | Checkout, Build-Artefakte im Jail | Lesen/Schreiben laut Tool-Policy |
+| Z2 Harness | Context Builder, DLP, Orchestrator | Enforcement-Punkt |
+| Z3 Model | Anbieter-Inferenz | nur gefilterte, freigegebene Inhalte |
+| Z4 Nebenkanäle | SIEM, Tickets, Metrics | redigierte Events, getrennte Retention |
+
+Daten fließen idealerweise **Z1 → Z2 → (Filter) → Z3** und zurück über Z2.
+Direkte Sprünge Z0/Z1 → Z3 (Copy-Paste in Consumer-Chat) sind der Schattenpfad,
+den Plattform-Teams mit gutem DX und klaren Limits bekämpfen – nicht nur mit
+Verboten.
+
+## Designprinzipien
+
+### Deny by default
+
+Unbekannte Pfade, neue Tool-Output-Typen und „mal schnell die ganze monorepo
+history“ starten bei Deny oder bei stark gekürzten Summaries – nicht bei Full
+Dump.
+
+### Zweckbindung
+
+Kontext nur für den **aktuellen Task**. Ein Agent, der gestern eine DB-Migration
+angefaßt hat, darf den gestrigen Schema-Dump nicht still in den heutigen
+UI-Bugfix mitnehmen, sofern die Session-Policy das nicht erlaubt.
+
+### Sichtbare Redaction
+
+Platzhalter wie `[REDACTED:aws_access_key_id#a1b2]` sind besser als unsichtbare
+Löschung:
+
+- Entwickler verstehen, warum der Agent „blind“ ist
+- Security kann Klasse und Regel-ID korrelieren
+- das Modell wird nicht zu riskanten Rekonstruktionsversuchen an unvollständigen
+  Diffs ohne Hinweis verleitet (kein Allheilmittel, aber ehrlicher)
+
+### Minimale Weitergabe
+
+Lieber drei gezielte Dateien als „grep -r und alles anhängen“. Retrieval-Qualität
+ist hier eine Security-Kontrolle.
+
+### Separates Logging
+
+Prompt-Volltext, Filter-Metadaten und Tool-Traces haben oft **unterschiedliche**
+Rechts- und Retention-Profile. Ein Log-Kanal für alles ist ein Compliance-
+Antipattern.
+
+## Anti-Pattern
+
+1. **„Das Modell sieht eh nur Code, keine Prod-Daten“**  
+   Fixtures, Logs und Configs *sind* oft Prod-ähnlich.
+
+2. **Filter nur auf User-Prompt, nicht auf Tool-Output**  
+   Die gefährlichsten Chunks kommen aus `cat`, Test-Logs und Exception-Dumps.
+
+3. **Debug-Modus mit abgeschaltetem Gateway in Staging-Daten**  
+   Staging leakt genauso; Debug-Flags bleiben haften.
+
+4. **Ein globaler System-Prompt als Policy**  
+   „Du darfst keine Secrets senden“ ist keine Kontrolle.
+
+5. **Kontext-Caches ohne Policy-Version**  
+   Alte, unfiltered Chunks überleben Filter-Updates.
+
+## Einbau in den Flue-Harness (konzeptionell)
+
+Unabhängig von konkreten API-Namen:
+
+1. **Context Builder** ruft nur freigegebene Retriever auf
+2. Jeder Chunk passiert `policyGate` → `dlpPipeline` → `budgetAccount`
+3. **Model Client** akzeptiert ausschließlich Builder-Output (kein Seiteneinstieg)
+4. Jeder Call trägt `session_id`, `policy_version`, `gateway_id`
+5. Responses laufen durch `outputScan`, bevor sie in History oder Tools gehen
+
+Seiteneinstiege (direkter SDK-Call aus einem Tool) sind zu verbieten oder
+gleich streng zu wrappen – sonst ist der Harness Dekoration.
+
+## Messgrößen
+
+| Metrik | Aussage |
+|--------|---------|
+| Anteil blockierter/redigierter Chunks | Filter greifen / zu laut |
+| Tokens pro Task nach Quelle | Datenhunger |
+| Calls ohne policy_version | Implementierungslücken |
+| Gateway-Verteilung | Residenz- und Vertragskonformität |
+| Cache-Hits mit veralteter Policy | Invertierungsrisiko |
+
+## Checkliste
+
+- [ ] Datenfluss-Diagramm Z1–Z3 im Architektur-Repo
+- [ ] Policy Gate vor DLP, DLP vor Komposition
+- [ ] Denylists für Secret-Pfade und heikle Typen
+- [ ] Token-Budgets pro Task-Klasse
+- [ ] Nur freigegebene Gateways / Modelle
+- [ ] Output-Scan aktiv
+- [ ] Kein Prompt-Volltext in Standard-Logs (oder strikte Sonder-Retention)
+- [ ] Cache-Invalidierung bei Policy-Wechsel
+- [ ] Kein ungewrappter Modell-SDK-Call neben dem Harness
+
+## Zusammenfassung
+
+Der Model-Call ist eine Vertrauensgrenze. Wer sie im Harness zeichnet – mit
+Policy Gate, Filtern, Budget und Gateway-Disziplin – kann Nutzen skalieren,
+ohne das Datenrisiko im gleichen Maße mitwachsen zu lassen. Die folgenden
+Kapitel füllen die Filter- und Aktionsseiten dieser Grenze: zuerst was
+*erkannt* wird (DLP, Entropie), später was der Agent *tun* darf (Sandbox,
+Permissions).
@@ -0,0 +1,253 @@
+# 5 DLP mit Pattern Matching
+
+## Kern in einem Satz
+
+Deterministische Muster (Regex, Detektoren, Allowlists und Denylists) fangen den
+großen Teil bekannter Secret- und PII-Formate ab – schnell, erklärbar,
+auditierbar.
+
+## Überblick
+
+Pattern-basierte Data Loss Prevention ist die erste Verteidigungslinie vor dem
+LLM-Kontext. Sie ersetzt weder Entropie-Analyse noch organisatorische Regeln,
+liefert aber etwas, das Security und Compliance sofort brauchen: **vorhersehbare
+Treffer mit nachvollziehbarer Begründung**.
+
+In Kapitel 4 lag der Fokus auf dem Datenfluss. Hier wird die erste konkrete
+Kontrollschicht ausgearbeitet: Was erkannt wird, welche Aktion folgt, wie man
+Regeln versioniert und testet – und warum „ein großer Regex im Harness“ in der
+Praxis scheitert.
+
+## Warum Pattern-DLP im Agent-Harness Pflicht ist
+
+Coding-Agents lesen Dateien, Diffs, Terminal-Ausgaben und oft auch
+Konfigurationsfragmente. Viele Secrets folgen stabilen Formaten:
+
+- Präfixe wie `AKIA…` (AWS), `sk-…` / `sk-proj-…` (API-Keys gängiger Anbieter)
+- PEM-Blöcke (`BEGIN … PRIVATE KEY`)
+- JWT-artige Drei-Segmente-Strukturen
+- Connection Strings mit `password=` / `Password=`
+- Bekannte PII-Formate (E-Mail, IBAN – mit landesspezifischen Varianten)
+
+Ein Musterdetektor braucht keine Modell-Inferenz. Er ist:
+
+1. **schnell** genug für große Diffs und Log-Ausschnitte,
+2. **deterministisch** (gleicher Input → gleicher Befund),
+3. **auditierbar** (Regel-ID, Version, Match-Offset).
+
+Genau diese drei Eigenschaften fehlen probabilistischen „LLM-als-Scanner“-Ansätzen.
+Modelle können helfen, Pattern-Vorschläge zu entwerfen – im Hot Path vor dem
+Model-Call gehören sie nicht als alleinige Enforcement-Instanz.
+
+## Detektorklassen
+
+Organisieren Sie Detektoren nach *Asset-Klasse*, nicht nach Dateiendung. Dieselbe
+AWS-Key-Regel gilt in `.env`, in einem Stack-Trace und in einem Kommentar.
+
+| Klasse | Beispiele | Typische Aktion |
+|--------|-----------|-----------------|
+| Cloud-/API-Keys | Präfix + Zeichensatz + Mindestlänge | block oder redact |
+| Asymmetrische Secrets | PEM, PKCS#8, SSH private key | block |
+| Credentials in URLs/DSNs | `user:pass@host`, JDBC/ODBC | redact |
+| Session-Material | JWT, opaque Bearer-Token (formatbasiert) | redact / quarantine |
+| PII (jurisdiktionsabhängig) | E-Mail, Telefon, IBAN, nationale IDs | redact oder deny-path |
+| Interne Marker | Hostnamen, Ticket-IDs, interne URL-Schemata | policy-gesteuert |
+
+**PII** ist politisch und rechtlich heikler als API-Keys: False Positives treffen
+Alltagstext, und die „richtige“ Aktion hängt von Zweckbindung und
+Verarbeitungsvertrag ab. Starten Sie eng (klar definierte Formate) und erweitern
+Sie mit Fachbereichen – nicht mit einer maximalen Regex-Sammlung am Tag eins.
+
+## Die Pipeline im Harness
+
+```
+Rohkontext
+  → Normalisierung
+  → Matcher-Kette (priorisiert)
+  → Aktion (block | redact | quarantine | allow-with-ticket)
+  → Telemetrie (ohne Secret-Klartext)
+  → (bei allow) weiter zur Kontext-Komposition
+```
+
+### Normalisierung
+
+Vor dem Match:
+
+- Unicode-Normalform (mindestens NFC), damit Homoglyphen und kompatible Zeichen
+  nicht durchrutschen
+- optional Zeilenenden vereinheitlichen
+- **keine** aggressive Lowercase-Konvertierung global – viele Keys sind
+  case-sensitiv, und `BEGIN PRIVATE KEY` soll treffsicher bleiben
+- Base64-/URL-Decoding nur in **kontrollierten, begrenzten** Pfaden (sonst
+  DoS und Doppeldeutigkeit)
+
+### Matcher-Kette
+
+Reihenfolge ist Security-Design:
+
+1. **Hochvertrauens-Blocker** (Private Keys, bekannte Cloud-Key-Formate)
+2. **Redact-Muster** (E-Mails in erlaubten Code-Kontexten, Connection-Passwörter)
+3. **Kontextabhängige Regeln** (nur in bestimmten Pfaden oder MIME-Typen)
+4. **Info-only / score** (für Schattenbetrieb und Kalibrierung)
+
+Früher Abbruch bei `block` spart Arbeit und verhindert, dass nachgelagerte
+Regeln den Befund „aufweichen“.
+
+### Aktionen im Detail
+
+**block**  
+Der betreffende Kontextbaustein (Datei, Chunk, Tool-Output) geht nicht an das
+Modell. Der Agent erhält eine maschinenlesbare Ablehnung inkl. Regel-ID – nicht
+den Secret-Inhalt. Geeignet für klar verbotene Klassen.
+
+**redact**  
+Treffer werden durch stabile Platzhalter ersetzt, z. B.
+`[REDACTED:aws_access_key_id#a1b2]`. Der Platzhalter sollte:
+
+- die *Klasse* nennen (damit der Agent und der Mensch den Kontext verstehen),
+- einen *nicht umkehrbaren* Fingerprint tragen (Korrelation in Logs),
+- **nicht** den Klartext rekonstruierbar machen.
+
+**quarantine**  
+Material landet in einem isolierten Review-Pfad (Ticket, Security-Queue), nicht
+im Prompt. Sinnvoll bei unklaren, aber riskanten Treffern in Onboarding-Phasen.
+
+**allow-with-ticket**  
+Ausnahme mit Change- oder Security-Ticket und TTL. Ohne Ablaufdatum wird daraus
+eine permanente Policy-Lücke.
+
+## Regelwerk als Code
+
+Behandeln Sie DLP-Regeln wie Produktionscode:
+
+- Versionierung im selben Repo wie der Harness (oder als versioniertes Package)
+- Code-Review und CI vor Merge
+- SemVer oder Policy-Epoch in jedem Audit-Event
+- Unit-Tests mit **positiven und negativen** Fixtures
+- Snapshot- oder Contract-Tests gegen bekannte Leak-Korpora (synthetisch!)
+
+### Test-Fixtures – und was nie ins Repo gehört
+
+Fixtures müssen *aussehen* wie Secrets, dürfen aber keine echten sein.
+Bewährte Praxis:
+
+- offiziell dokumentierte Beispiel-Keys der Cloud-Anbieter
+- klar markierte Fake-Strings (`EXAMPLEKEY…`, `dummy_…`)
+- generierte Zufallsstrings, die dem Muster genügen, aber nirgends gültig sind
+
+Echte Incident-Artefakte gehören in ein getrenntes, zugriffsbeschränktes
+Archiv – nicht in die Test-Suite des Open- oder Firmenrepos.
+
+### Beispiel: Regelbeschreibung (konzeptionell)
+
+Statt eines undurchsichtigen Super-Regex pro Zeile lohnt eine strukturierte
+Regel:
+
+| Feld | Inhalt |
+|------|--------|
+| `id` | `sec.aws.access_key_id.v3` |
+| `class` | `cloud_credential` |
+| `pattern` | Präfix + Zeichensatz + Länge |
+| `action` | `block` |
+| `confidence` | `high` |
+| `owners` | Security Platform |
+| `tests` | 12 pos / 40 neg |
+
+So bleibt der Audit-Trail sprechend: nicht „Regex 7 hat getroffen“, sondern
+eine benannte Kontroll-ID.
+
+## Pfad- und Kontextpolitik
+
+Muster allein sind blind für *wo* etwas liegt. Kombinieren Sie sie mit
+Pfad-Policies:
+
+| Pfad / Quelle | Empfehlung |
+|---------------|------------|
+| `.env`, `.env.*`, `*.pem`, `id_rsa*` | oft: gar nicht erst einlesen |
+| `**/secrets/**`, Vault-Agent-Injects | deny by default |
+| `package-lock.json` / Checksummen | allow; High-Entropy separat behandeln (Kap. 6) |
+| CI-Logs, Stack-Traces | scannen, aggressive Redaction |
+| User-Prompt | scannen – Social Engineering und Copy-Paste-Leaks |
+
+**Deny-by-path** vor dem teuren Full-Text-Scan ist oft die beste DLP-Maßnahme:
+Was nie im Context Builder landet, muss nicht redigiert werden.
+
+## Performance und Skalierung
+
+Agent-Sessions hängen Diffs und Tool-Ausgaben an. Ein naiver
+„gesamten Workspace scannen“-Ansatz bricht Latenz und Kosten.
+
+Praktische Grenzen:
+
+- nur **neu hinzugefügte** Chunks scannen (inkrementell)
+- Maximalgröße pro Chunk; darüber: ablehnen oder stubben
+- Multi-line-Muster (PEM) brauchen begrenzte Fenster, kein unbegrenztes
+  Backtracking
+- Regex-Engines: catastrophisches Backtracking vermeiden (ReDoS); lieber
+  lineare oder klar beschränkte Ausdrücke
+
+Messen Sie p95-Latenz der DLP-Stufe getrennt vom Model-Call. Wenn Entwickler
+den Agent meiden, weil „jeder Lauf 20 Sekunden filtert“, gewinnen Sie keine
+Sicherheit – Sie erzeugen Schatten-IT.
+
+## False Positives und Adoption
+
+Eine zu aggressive Policy ohne Feedback-Kanal führt zu:
+
+1. Entwickler deaktivieren den Filter lokal,
+2. oder sie packen Secrets in Formate, die „durchrutschen“,
+3. oder sie nutzen den Agent gar nicht und kopieren Code unkontrolliert in
+   Chat-UIs.
+
+Gegenmittel:
+
+- klare Trefferbegründung in der UI/CLI
+- schneller Exception-Prozess mit TTL und Owner
+- Telemetrie: Top-Regeln nach False-Positive-Verdacht
+- Schattenmodus vor Enforce: erst loggen, dann blocken
+
+## Was Pattern-DLP nicht leistet
+
+- neuartige Token ohne bekanntes Format → Kapitel 6 (Entropie)
+- Daten, die syntaktisch harmlos, semantisch aber sensibel sind
+  (Kundenlisten als CSV mit „normalen“ Spalten)
+- Output-Leaks *nach* dem Modell (Modell halluziniert oder wiederholt Secrets)
+  → Output-Scan und Session-Hygiene
+- organisatorische Freigaben und Verträge → Kapitel 10
+
+## Einbau in den Flue-Harness (konzeptionell)
+
+Unabhängig von konkreten API-Namen gilt dieselbe Hook-Reihenfolge:
+
+1. **vor** dem Zusammenbau der Model-Messages: Chunk-Level-Scan
+2. **nach** Tool-Ergebnissen, **bevor** sie in den Kontext zurückfließen
+3. optional **nach** der Modellantwort (Secret-Echo)
+
+Jeder Hook schreibt:
+
+- `policy_version`
+- `rule_ids[]`
+- `action`
+- `chunk_id` / Quelle
+- **keinen** Klartext des Matches
+
+Damit bleibt DLP im Hot Path und im Audit-Pfad konsistent.
+
+## Checkliste für den ersten Produktionsstand
+
+- [ ] Top-10 Secret-Klassen mit high-confidence block/redact
+- [ ] Denylists für offensichtliche Secret-Pfade
+- [ ] Redaction-Platzhalter mit Klasse + Fingerprint
+- [ ] Fixture-Tests in CI, keine echten Secrets
+- [ ] Telemetrie ohne Klartext
+- [ ] Exception-Prozess mit TTL
+- [ ] p95-Latenz-Budget definiert und gemessen
+- [ ] Schattenmodus-Phase vor hartem Enforce dokumentiert
+
+## Zusammenfassung
+
+Pattern-DLP ist das Pflichtprogramm im Agent-Harness: versioniert, getestet,
+mit klarer Aktion und ohne Secret-Klartext in den Logs. Sie fängt den Großteil
+bekannter Formate ab und schafft die erklärbare Grundlage, auf der Entropie-
+Filter und Sandbox aufbauen. Wer hier „später“ sagt, skaliert Datenabfluss mit
+jeder erfolgreichen Agent-Demo.
@@ -0,0 +1,266 @@
+# 6 Entropie-Filter und unbekannte Secrets
+
+## Kern in einem Satz
+
+Hohe Zufälligkeit in kurzen Token-Fenstern ist ein starkes Signal für Secrets –
+auch wenn kein Regex greift.
+
+## Überblick
+
+Pattern Matching kennt nur, was jemand in eine Regel gegossen hat. Viele
+produktive Lecks sehen anders aus: frisch generierte Tokens ohne öffentliches
+Präfix, interne Session-IDs, Base64-Blöcke aus einem Debug-Dump, „temporäre“
+Schlüssel in einem Kommentar von 2019.
+
+Entropie-basierte Filter bewerten, *wie zufällig* eine Zeichenkette wirkt. Sie
+schließen die Lücke zwischen „bekanntes Secret-Format“ und „sieht aus wie ein
+Schlüssel“. Richtig kalibriert sind sie eine starke zweite Linie – falsch
+kalibriert erzeugen sie Lärm und Frust.
+
+Dieses Kapitel erklärt das Signal, die Pipeline, Kalibrierung, Allowlists und
+das Zusammenspiel mit Kapitel 5.
+
+## Was „Entropie“ hier meint
+
+In der Praxis genügt oft die **Shannon-Entropie** über ein Fenster von Zeichen
+aus einem Alphabet (z. B. alphanumerisch + wenige Symbole):
+
+```
+H = - Σ p_i · log2(p_i)
+```
+
+Dabei ist `p_i` die relative Häufigkeit des Zeichens *i* im Fenster. Ein
+zufällig wirkender API-Token aus 32 Zeichen aus einem 64-Zeichen-Alphabet liegt
+nahe an der theoretischen Obergrenze; ein englischer Satz weit darunter.
+
+Wichtige Klarstellungen:
+
+1. Entropie misst **statistische Unvorhersagbarkeit im Fenster**, nicht
+   kryptographische Sicherheit im strengen Sinn.
+2. Ein **kurzes** Fenster auf einem Commit-Hash kann „high entropy“ sein, ohne
+   dass ein Secret vorliegt.
+3. **Niedrige** Entropie schließt Secrets nicht aus (Passwort `Summer2024!` ist
+   schwach und oft pattern- oder dictionary-basiert besser zu fangen).
+
+Deshalb ist Entropie ein **Score-Signal**, selten ein alleiniger
+Block-Entscheider.
+
+## Wann Entropie greift – und wann nicht
+
+### Starke Einsatzfälle
+
+- neu generierte API-Tokens ohne stabiles öffentliches Präfix
+- opake Session-Cookies und Bearer-Material
+- Base64-/Hex-Blöcke in Configs und Env-Snippets
+- Schlüsselmaterial in „nicht standard“-Containern (Custom JSON-Felder)
+- Dump-Auszüge aus Debuggers und fehlerhaften Exception-Messages
+
+### Schwache oder irreführende Fälle
+
+| Artefakt | Problem |
+|----------|---------|
+| Git-Commit-Hashes | hohe Entropie, meist legitim |
+| UUIDs / ULIDs | formatbekannt, oft allowlisten |
+| Minifizierte Bundles | lange high-entropy-ähnliche Sequenzen |
+| Lockfile-Integrities (`sha512-…`) | erwartet, erlaubt |
+| Komprimierte/binary-ish Textspuren | Rauschen |
+| Natürliche Sprache mit Umlauten | niedrige Entropie, aber PII möglich |
+
+PII mit Prüfziffern und Wörterbuchanteil (Namen, Adressen) gehört **nicht** in
+einen reinen Entropie-Blocker.
+
+## Sliding-Window-Pipeline
+
+```
+Textchunk
+  → Tokenisierung / Kandidatenextraktion
+  → Sliding Window (Länge L, Schritt S)
+  → Score H (und optional Zusatzfeatures)
+  → Schwellwert + Kontextregeln
+  → Aktion / Score an Policy
+  → Telemetrie
+```
+
+### Kandidatenextraktion
+
+Effizienter als „jedes Byte“: zuerst Segmente, die *überhaupt* wie Secrets
+aussehen können:
+
+- zusammenhängende Läufe aus `[A-Za-z0-9+/=_\-]` ab Mindestlänge *n*
+- Zuweisungen `key = value`, JSON-String-Werte, YAML-Skalarwerte
+- Zeilen ohne Whitespace mit hoher Symbol-Dichte
+
+So reduzieren Sie Kosten und False Positives aus Fließtext.
+
+### Fensterparameter
+
+| Parameter | Typische Startwerte (Richtwert) | Kommentar |
+|-----------|----------------------------------|-----------|
+| L (Fenster) | 16–40 Zeichen | zu klein → Rauschen; zu groß → Mittelung |
+| S (Schritt) | 4–8 | Überlappung fängt versetzte Secrets |
+| Alphabet | ASCII-druckbar oder Base64-Set | an Kandidaten anpassen |
+| Schwelle H_min | kalibrieren, nicht raten | pro Quelle/Dateityp |
+
+**Eine globale Schwelle für alles** ist der häufigste Fehler. `.ts`-Quellcode,
+CI-Logs und `.env` brauchen unterschiedliche Profile.
+
+### Zusatzfeatures (empfohlen)
+
+Entropie allein ist dünn. Kombinieren Sie Scores:
+
+- Länge des Kandidaten
+- Anteil Ziffern vs. Buchstaben vs. Symbole
+- Abstand zu Keywords (`password`, `token`, `secret`, `api_key`, `bearer`)
+- Dateipfad-Risiko (aus Kapitel 5)
+- ob ein Pattern-Detektor *in der Nähe* bereits schwach getroffen hat
+
+Ein einfaches Policy-Modell:
+
+```
+if pattern_high_confidence: action = block/redact
+else if entropy_high and keyword_near: action = redact
+else if entropy_high and path_risky: action = quarantine
+else if entropy_high: action = score_only | redact_soft
+else: allow (subject to path policy)
+```
+
+## Kalibrierung ohne Drama
+
+### Schattenmodus
+
+1. Entropie-Filter **nur loggen** (action = observe)
+2. Stichprobe der Top-Scores manuell labeln (secret / not secret)
+3. Precision/Recall schätzen – auch mit kleinen Stichproben ehrlich sein
+4. Schwellen und Allowlists justieren
+5. Enforce schrittweise: erst redact, dann block für klare Bänder
+
+### Metriken, die zählen
+
+| Metrik | Nutzen |
+|--------|--------|
+| Treffer pro 1000 Chunks | Last und Lärm |
+| Anteil mit Keyword-Nähe | Signalqualität |
+| Exception-Rate | ob Teams den Filter umgehen |
+| Zeit bis Regel-Fix nach FP-Welle | Betriebsreife |
+
+Optimieren Sie nicht auf „null False Positives“. Optimieren Sie auf **tragbare
+False Positives bei akzeptablem Recall** für Ihre Secret-Klassen.
+
+## Allowlists – bewusst und befristet
+
+Allowlists sind notwendig und gefährlich.
+
+**Erlaubt (typisch):**
+
+- Commit-SHA in erlaubten Kontexten (Git-Log-Auszüge, die der Agent sowieso
+  braucht)
+- Package-Integrities in Lockfiles
+- bekannte Test-Vektoren mit `EXAMPLE`/`dummy`-Markern
+- kurze UUIDs in Trace-IDs, wenn das Format strikt validiert wird
+
+**Regeln für Allowlists:**
+
+- immer mit `id`, Owner, Begründung, **TTL**
+- so eng wie möglich (Pfad + Format, nicht „alles Base64“)
+- Telemetrie: wie oft greift der Allow-Eintrag?
+- Review-Zyklus (z. B. quartalsweise)
+
+Eine Allowlist ohne TTL ist eine Policy-Schuld mit Zinseszins.
+
+## Zusammenspiel mit Pattern Matching
+
+| Signal | Vertrauensstufe | Typische Aktion |
+|--------|-----------------|-----------------|
+| Pattern match (high) | hoch | block / redact |
+| Pattern weak + high entropy | hoch | redact |
+| High entropy + Keyword/Pfad | mittel–hoch | redact / quarantine |
+| Nur high entropy | mittel | score, soft-redact, oder observe |
+| Kein Signal | — | allow im Rahmen der Pfad-Policy |
+
+**Reihenfolge im Harness:** Pattern zuerst (billig, erklärbar), dann Entropie auf
+verbleibenden Kandidaten. So vermeiden Sie doppelte Arbeit und nutzen
+Pattern-Treffer als harte Gates.
+
+## Output-Seite nicht vergessen
+
+Modelle können Secrets aus dem Prompt **wiederholen** oder aus Trainings-/
+Kontextfragmenten ergänzen. Derselbe Entropie-/Pattern-Stack sollte optional
+auf die **Modellantwort** laufen, bevor sie:
+
+- in Logs landet,
+- in Tickets geschrieben wird,
+- oder an nachgelagerte Tools geht.
+
+Das ist keine Garantie gegen alle Leaks – aber ein günstiger zweiter Riegel.
+
+## Missverständnisse
+
+1. **„Entropie ersetzt Vault.“**  
+   Nein. Sie erkennt *Verdacht* im Textstrom. Geheimnisse gehören in ein
+   Secret-Management, nicht in Repos und nicht in Prompts.
+
+2. **„Höhere Schwelle = sicherer.“**  
+   Zu hoch → Secrets rutschen durch. Zu niedrig → Alert-Müdigkeit.
+
+3. **„ML-Klassierer statt Entropie.“**  
+   Lernende Detektoren können helfen, brauchen aber Trainingsdaten, Drift-
+   Kontrolle und Erklärbarkeit. Viele Teams fahren mit Entropie + Patterns +
+   Keywords lange stabiler.
+
+4. **„Einmal kalibriert, fertig.“**  
+   Neue Stacks (andere Lockfiles, andere Token-Formate) verschieben die
+   Verteilung. Kalibrierung ist Betrieb, kein Projektende.
+
+## Minimaler Implementierungsrahmen (TypeScript-Skizze)
+
+Konzeptionell – keine Framework-Werbung, nur die Nähte im Harness:
+
+```typescript
+type EntropyHit = {
+  start: number;
+  end: number;
+  score: number;
+  previewFingerprint: string; // hash, nie Klartext loggen
+};
+
+function scanChunk(text: string, profile: EntropyProfile): EntropyHit[] {
+  const candidates = extractCandidates(text, profile);
+  const hits: EntropyHit[] = [];
+  for (const c of candidates) {
+    for (const window of slide(c, profile.window, profile.step)) {
+      const h = shannon(window.value);
+      if (h >= profile.threshold) {
+        hits.push({
+          start: window.start,
+          end: window.end,
+          score: h,
+          previewFingerprint: fingerprint(window.value),
+        });
+      }
+    }
+  }
+  return hits;
+}
+```
+
+Wichtig: Klartext der Fenster **nicht** in strukturierte Logs schreiben. Nur
+Fingerprint, Score, Chunk-ID, Policy-Version.
+
+## Checkliste
+
+- [ ] Profile pro Quelle (Code, Env, Log, Lockfile)
+- [ ] Pattern-Pipeline läuft *vor* Entropie
+- [ ] Schattenmodus mit gelabelter Stichprobe
+- [ ] Allowlists mit Owner und TTL
+- [ ] Telemetrie ohne Secret-Klartext
+- [ ] Optionaler Output-Scan
+- [ ] Review-Zyklus für Schwellen dokumentiert
+
+## Zusammenfassung
+
+Entropie-Filter schließen die Lücke, die feste Muster lassen: unbekannte, aber
+offensichtlich geheime Token. Sie sind Score-Lieferanten in einer Policy, keine
+magische Orakel. Kalibrierung, Allowlists mit TTL und das Zusammenspiel mit
+Pattern-DLP entscheiden darüber, ob der Filter schützt – oder nur nervt.
+Das nächste Kapitel wechselt die Ebene: von „was das Modell sieht“ zu „was der
+Agent *tun* darf“.
@@ -0,0 +1,236 @@
+# 7 Sandbox-Strategien
+
+## Kern in einem Satz
+
+Die Sandbox begrenzt, was ein Agent *tun* kann, wenn Prompt oder Tool-Output
+unzuverlässig sind – Datenfilter allein reichen nicht.
+
+## Überblick
+
+Kapitel 5 und 6 schützen den **Datenpfad zum Modell**. Dieses Kapitel schützt
+den **Aktionspfad**: Dateisystem, Shell, Netzwerk, Cloud-APIs. Coding-Agents
+sind nützlich, weil sie handeln. Genau deshalb brauchen sie Isolation.
+
+Prompt Injection, fehlerhafte Tool-Auswahl und schlichte Fehlbedienung enden
+sonst nicht in einer peinlichen Antwort, sondern in gelöschten Dateien,
+exfiltrierten Secrets über `curl` oder in einer Dependency, die im Hintergrund
+nachlädt.
+
+Sandboxing ist kein einzelner Schalter („Docker an“). Es ist eine
+**Strategie** aus Isolationsstufen, passend zu Bedrohungsmodell, Datenklasse
+und Entwicklerfluss.
+
+## Was die Sandbox leisten soll – und was nicht
+
+### Soll
+
+- Blast Radius begrenzen, wenn der Agent falsche oder injizierte Anweisungen
+  befolgt
+- Host-Geheimnisse und Prod-Zugänge vom Tool-Runtime trennen
+- Seiteneffekte auf einen definierten Workspace beschränken
+- Nachvollziehbare Grenzen für Security-Reviews und Audits schaffen
+
+### Soll nicht (allein)
+
+- DLP ersetzen (Kontext kann vor der Ausführung bereits geleakt sein)
+- Authentizität von Modellausgaben garantieren
+- soziales Vertrauen in freigegebene High-Privilege-Tools ersetzen
+
+Sandbox und DLP sind komplementär: Filter begrenzen *Wissen*, Sandbox begrenzt
+*Handlung*.
+
+## Angriffs- und Fehlermodi mit Aktionsbezug
+
+| Szenario | Ohne Sandbox | Mit passender Sandbox |
+|----------|--------------|------------------------|
+| Injizierter Befehl in README | Shell auf Entwicklermaschine | Shell nur in Jail, kein Secret-Mount |
+| `rm -rf` im Workspace | Host-Schaden möglich | Ephemeral FS, Snapshot/rollback |
+| `curl` Exfil an Angreifer | offenes Netz | Default-deny Egress |
+| Paket-Postinstall-Skript | gleiche Rechte wie User | User-Namespace, read-only Root |
+| Agent liest `~/.aws` | Credentials im Prozess | Secrets gar nicht gemountet |
+
+## Strategiestufen
+
+Die Stufen bauen aufeinander auf. Springen Sie nicht zu „microVM für alles“,
+wenn Process-Isolation und FS-Jail den Risk-Case schon decken – und bleiben
+Sie nicht bei „npm test lokal“, wenn untrusted Code im Spiel ist.
+
+### Stufe 1 – Process isolation
+
+- eigener OS-User oder streng reduzierte Privilegien
+- Resource-Limits (CPU, RAM, Prozesse) gegen Fork-Bombs und Kostenexplosion
+- keine Vererbung unnötiger Environment-Secrets
+- harte Timeouts pro Tool-Call
+
+**Geeignet für:** interne Repos, vertrauenswürdige Entwickler, lesende Tools.
+
+### Stufe 2 – Filesystem jail / Workspace-Bindung
+
+- Agent sieht nur einen **dedizierten Worktree** oder Checkout
+- Host-Home, SSH-Keys, Browser-Profile: nicht gemountet
+- sensible Pfade read-only oder abwesend
+- Writes nur unter `workspace/`; Artifacts explizit exportieren
+
+**Pattern:** ephemerer Workspace pro Session, am Ende löschen oder archivieren.
+
+### Stufe 3 – Network policy
+
+Deny by default für Egress, dann Allowlist:
+
+| Ziel | oft erlaubt | oft verboten |
+|------|-------------|--------------|
+| interner Package-Proxy | ja | direktes Internet |
+| Model Gateway | ja (festes Endpoint-Set) | beliebige IP/DNS |
+| Git-Internal | ja | ungeprüfte Fremdhosts |
+| Metadaten-Dienste (Cloud) | nein | — |
+
+„Netz offen, weil sonst `npm install` scheitert“ ist ein Architekturgeruch:
+lösen Sie es mit Proxy und gespiegelten Registries, nicht mit offenem Egress.
+
+### Stufe 4 – Containerisierte Ephemerals
+
+- Container (oder gleichwertig) pro Task/Session
+- frisches Dateisystem, definierte Image-Baseline
+- TTL und automatisches Tear-down
+- keine Docker-Socket-Mounts auf den Host
+- Secrets via kurzlebiger Injects, nicht via `~/.config`
+
+**Geeignet für:** gemischte Trust-Level, CI-ähnliche Agent-Läufe, Multi-Tenant-
+Plattformen.
+
+### Stufe 5 – Stärkere Isolation / Remote execution
+
+- microVM, gVisor-ähnliche Runtimes, oder dedizierte Build-Agents
+- Ausführung **nicht** auf dem Laptop mit Prod-VPN
+- getrennte Konten und Netzsegmente
+- Ausgabe nur als Review-Artefakt zurück zum Entwickler
+
+**Geeignet für:** regulierte Daten, untrusted Contributions, hohe
+Integritätsanforderungen.
+
+## Referenzarchitektur im Harness
+
+```
+User / IDE
+   → Agent-Orchestrator (Policy, DLP, Approvals)
+        → Tool-API (schema-validiert)
+             → Sandbox Runtime
+                  → FS / Shell / Netz (begrenzt)
+        → Model Gateway (separater Trust-Pfad)
+```
+
+Wichtige Trennung: **Model Gateway** und **Tool Runtime** sind verschiedene
+Vertrauens- und Datenpfade. Ein kompromittierter Tool-Container darf keine
+beliebigen Prompts an Prod-Modelle mit erweiterten Rechten schicken – und
+umgekehrt sollen Model-Credentials nicht in der Tool-Sandbox liegen.
+
+## Auswahlmatrix
+
+| Kontext | Mindeststufe | Kommentar |
+|---------|--------------|-----------|
+| Nur Lese-Tools, internes Repo | 1–2 | trotzdem kein Secret-Env erben |
+| Write + Tests im eigenen Branch | 2–3 | Netz für Registry kontrollieren |
+| Dependencies installieren | 3–4 | Postinstall = Code-Ausführung |
+| Untrusted Fork / Vendor-Code | 4–5 | Remote bevorzugen |
+| Prod-nahe Daten / PII | 5 + DLP | oft: gar kein lokaler Agent |
+
+## Anti-Pattern (häufig in Demos)
+
+1. **Docker mit `$HOME` und Docker-Socket**  
+   Das ist eine Privilegienverlängerung, keine Sandbox.
+
+2. **Gleiche Cloud-Credentials wie der Host**  
+   Isolation der Compute-Schicht ohne Secret-Trennung ist Theater.
+
+3. **Privileged containers „nur kurz“**  
+   Bleiben länger als geplant und werden kopiert.
+
+4. **Sandbox nur für Shell, nicht für „hilfreiche“ File-Tools**  
+   Ein `write_file` außerhalb des Workspaces ist ein Shell-Äquivalent.
+
+5. **Kein Timeout, kein Output-Cap**  
+   Agent-Loops füllen Platten und Rechnungen.
+
+## Zusammenspiel mit Tool-Permissions
+
+Sandbox ohne Permission-Modell (Kapitel 8) bleibt grob: entweder zu eng (Agent
+nutzlos) oder zu weit (eine erlaubte Shell frisst die Isolation).
+
+Empfohlene Kette:
+
+1. Tool darf laut Policy existieren (Allowlist)
+2. Argumente validieren (Pfade, Hosts, Flags)
+3. Ausführung nur in der Sandbox-Stufe der Risk-Klasse
+4. Ergebnis zurück durch DLP, bevor es in den Modellkontext geht
+
+Der letzte Punkt schließt die Schleife: selbst erfolgreiche, erlaubte Befehle
+können Secrets in stdout drucken.
+
+## Testbarkeit und Nachweis
+
+Sandbox-Strategien gehören in automatisierte Tests:
+
+| Test | Absicht |
+|------|---------|
+| Secret-path unreachable | `~/.aws` / Env nicht lesbar |
+| Egress deny | Verbindung zu Nicht-Allowlist schlägt fehl |
+| Workspace escape | `../` und Symlink-Tricks scheitern |
+| TTL | Container/Workspace nach Limit weg |
+| Resource limit | CPU/RAM-Exhaustion stoppt sauber |
+
+Für Audits speichern Sie:
+
+- Sandbox-Profil-ID und Version
+- Image-Digest (falls containerisiert)
+- Netz-Policy-Version
+- Session-ID und Tear-down-Status
+
+## Betriebsaspekte
+
+### Entwicklererfahrung
+
+Zu langsame oder undurchsichtige Sandboxes erzeugen Umgehungen. Investieren Sie
+in:
+
+- warme Image-Caches für erlaubte Baselines
+- klare Fehlermeldungen („Netz zu registry.npmjs.org verweigert – nutze Proxy X“)
+- lokale Profile, die *strenger* oder gleich streng wie CI sind (nicht lockerer)
+
+### Kosten
+
+Ephemeral Environments kosten CPU und Wartezeit. Gegenstrategien: Pooling
+gleicher Profile, Snapshot-FS, gestaffelte Stufen (leichte Sandbox für Read,
+schwere nur für Install/Build).
+
+### Incident
+
+Wenn die Sandbox greift (Block, Kill), ist das oft ein **Erfolg**. Playbooks
+(Kapitel 11) sollten „Agent sandbox kill“ als Signal führen, nicht nur als
+Störungsticket.
+
+## Entscheidungshilfe in einem Absatz
+
+Starten Sie mit **Workspace-Bindung + kein Secret-Env + Timeouts**. Sobald der
+Agent Dependencies installiert oder untrusted Input verarbeitet, erzwingen Sie
+**Default-deny Netz und containerisierte Ephemerals**. Für regulierte oder
+fremde Codebasen verlagern Sie die Ausführung **remote** und lassen lokal nur
+Review-Artefakte zu. DLP bleibt davor und danach auf dem Datenpfad aktiv.
+
+## Checkliste
+
+- [ ] Sandbox-Stufe pro Risk-Klasse dokumentiert
+- [ ] Keine Host-Secret-Mounts in Tool-Runtimes
+- [ ] Egress-Policy: Deny by default mit begründeter Allowlist
+- [ ] Timeouts, Output- und Größenlimits
+- [ ] Tool-Ergebnisse laufen durch DLP zurück in den Kontext
+- [ ] Escape- und Egress-Tests in CI
+- [ ] Profil-Version in Audit-Logs
+- [ ] DX: Fehlermeldungen und Proxy-Pfade dokumentiert
+
+## Zusammenfassung
+
+Sandbox-Strategie ist Architektur, kein Demo-Haken. Sie begrenzt den
+Handlungsspielraum des Agents, wenn Filter und Prompts versagen – und sie muss
+zum Trust-Level der Aufgabe passen. Zusammen mit DLP (Kapitel 5–6) und
+Tool-Permissions (Kapitel 8) begrenzt sie Wissen *und* Handlung – die
+Voraussetzung für nachvollziehbare Freigaben.
@@ -0,0 +1,266 @@
+# 8 Tool-Permissions und Least Privilege
+
+## Kern in einem Satz
+
+Jedes Tool ist eine API mit Seitenwirkungen – Berechtigungen gehören an den
+Harness, nicht in den System-Prompt.
+
+## Überblick
+
+Kapitel 7 hat Isolation beschrieben: *wo* Code und Befehle laufen. Dieses
+Kapitel regelt *was* der Agent überhaupt anstoßen darf. Least Privilege für
+Coding-Agents heißt:
+
+- minimale Tool-Menge pro Session und Rolle,
+- enge Argument-Schemas,
+- explizite Freigaben für riskante Operationen,
+- Trennung von Lese- und Schreibpfaden,
+- Policy-as-Code statt Prompt-Appelle.
+
+Prompt Injection und Bedienfehler zielen oft genau auf zu mächtige Tools.
+Eine Sandbox ohne Permission-Modell ist ein Käfig mit offener Werkzeugkiste
+voller Brechstangen.
+
+## Warum der System-Prompt keine Policy ist
+
+Formulierungen wie „Lösche niemals Dateien außerhalb des Projekts“ oder
+„Rufe keine Produktions-APIs auf“ sind Hinweise an ein probabilistisches
+Modell. Sie sind:
+
+- **nicht durchsetzbar**, wenn das Modell sie ignoriert oder injizierter Text
+  sie überschreibt,
+- **nicht auditierbar** als Kontrollnachweis,
+- **nicht versionssicher** im Sinne von Change Management.
+
+Policy gehört in den Harness: deterministisch, testbar, mit Deny als Default.
+
+## Risk-Klassen
+
+Klassifizieren Sie Tools und Operationen nach Wirkung – nicht nach
+Marketing-Namen der Features.
+
+| Klasse | Beispiele | Default |
+|--------|-----------|---------|
+| **R0 Lesen** | Datei lesen, Suche, Git-Log (read-only) | allow + DLP |
+| **R1 Schreiben im Workspace** | Patch, neue Datei unter Workspace-Root | allow + audit |
+| **R2 Ausführung** | Tests, Build, Linter, Format | sandbox Pflicht |
+| **R3 Seiteneffekte außen** | Deploy, Ticket, Mail, Cloud-API, Paket-Publish | deny / approval |
+| **R4 Geheimnisse / IAM** | Secret lesen, Rollen anpassen, Prod-DB | deny; break-glass only |
+
+Dieselbe „Shell“ kann R0 (`cat README`) oder R3 (`curl | bash`) sein.
+Deshalb zählen **Tool-Name + validierte Argumente + Zielkontext**, nicht der
+Tool-Name allein.
+
+## Permission-Modell
+
+### Scopes
+
+Scopes sind grobe Fähigkeiten, die eine Session halten darf:
+
+```
+fs:read
+fs:write
+git:read
+git:write
+shell:test          # nur freigegebene Test-Runner
+shell:build
+net:allowlisted
+tickets:create
+secrets:never       # explizite Negation als Dokumentationsanker
+```
+
+Vergabe:
+
+- über Rolle (Developer, CI-Bot, Auditor),
+- über Task-Typ (Refactor vs. Incident),
+- über Repo-Label (öffentlich / intern / reguliert).
+
+### Argument-Constraints
+
+Scopes allein sind zu grob. Jeder Tool-Call braucht Schema-Validierung:
+
+| Dimension | Beispiele |
+|-----------|-----------|
+| Pfade | nur unter `workspace/`; Deny für `..`, Symlinks nach draußen |
+| Hosts | nur Allowlist-DNS für `net:*` |
+| Befehle | Allowlist von Binaries (`pytest`, `npm test`); Deny `sudo`, `ssh`, `curl` default |
+| Flags | keine `--privileged`, kein Docker-Socket |
+| Größe | max. Bytes lesen/schreiben; max. Output-Capture |
+| Rate | Calls pro Minute gegen Loops |
+
+Validierung **vor** der Sandbox-Ausführung; bei Verletzung: deny + Telemetrie,
+kein „Modell nochmal fragen, ob es ernst ist“.
+
+### Session Binding
+
+Rechte gelten für:
+
+- eine **Session-ID** (oder Task-ID),
+- eine **Policy-Version**,
+- optional ein **Ablaufzeitpunkt**.
+
+Ein Agent, der gestern Deploy-Rechte für Hotfix hatte, erbt sie nicht still in
+die morgige Docs-Session.
+
+### Approval Gates
+
+Human-in-the-loop für R3/R4 und für Abweichungen:
+
+| Ereignis | Gate |
+|----------|------|
+| erstes `fs:write` außerhalb erlaubter Globs | approve oder deny |
+| Shell-Befehl nicht auf Allowlist | deny (kein freies „trotzdem“) |
+| Deploy / Prod-API | zwei Personen oder Change-Ticket |
+| Exception von DLP-block | Security-Owner + TTL |
+
+Approvals loggen: wer, wann, was, welche Policy-Version, welcher Diff-Hash.
+Ein Klick „Allow all for 24h“ ohne Scope-Begrenzung ist ein Anti-Pattern.
+
+## Policy-Entscheidungsablauf
+
+```
+eingehender Tool-Call
+  → Schema valid?
+  → Scope in Session?
+  → Argument-Constraints ok?
+  → Risk-Klasse → Sandbox-Profil (Kap. 7)
+  → Approval nötig und erteilt?
+  → ausführen
+  → Output-Cap + DLP (Kap. 5–6)
+  → Ergebnis zurück in Agent-Loop
+```
+
+Jeder Schritt kann mit stabilen Fehlercodes abbrechen
+(`POLICY_DENY_SCOPE`, `POLICY_DENY_PATH`, `POLICY_NEEDS_APPROVAL`, …), damit
+UI und Tests deterministisch reagieren.
+
+## Trennung Lesen / Schreiben / Ausführen
+
+Häufiger Fehler: ein mächtiges `run_terminal` für alles.
+
+Besser:
+
+| Fähigkeit | Eigenes Tool / enger Wrapper |
+|-----------|------------------------------|
+| Lesen | `read_file`, `search` |
+| Patchen | `apply_patch` mit Diff-Format und Root-Bindung |
+| Tests | `run_tests` mit festem Runner und Args |
+| Build | `run_build` analog |
+| Freie Shell | nur Break-glass, R3+, stark geloggt |
+
+Je enger das Tool, desto kleiner die Injectionsfläche: ein
+`apply_patch`-Schema lässt sich härter validieren als freie Shell-Strings.
+
+## Prompt Injection und Permissions
+
+Injizierter Text in README, Issues oder Abhängigkeitsdateien versucht typischerweise:
+
+1. mächtige Tools zu aktivieren („run this command to continue“),
+2. Daten exfiltrieren (`curl` mit Repo-Inhalt),
+3. Policy-Text zu überschreiben („ignore previous instructions“).
+
+Harte Permissions machen (1) und (2) **unabhängig vom Modellverhalten**
+schwer. (3) ist ohnehin wirkungslos, wenn Policy nicht im Prompt lebt.
+
+Ergänzend:
+
+- untrusted Inhalte als **Daten** markieren (nicht als Instruction-Channel),
+- Tool-Hinweise aus untrusted Quellen nicht als erlaubte Call-Vorschläge
+  übernehmen,
+- erhöhte Risk-Klasse, wenn der auslösende Chunk aus untrusted Source-ID stammt
+  (Kapitel 4).
+
+## Policy-as-Code
+
+### Artefakte
+
+- Policy-Dateien im Repo oder als versioniertes Package
+- `policy_version` in jedem Audit-Event
+- Unit-Tests: erlaubte und verbotene Call-Beispiele
+- Contract-Tests gegen den realen Tool-Router des Harness
+
+### Beispielstruktur (konzeptionell)
+
+```yaml
+# policy excerpt – illustrativ
+version: 2026.04.1
+session_defaults:
+  scopes: [fs:read, git:read]
+profiles:
+  dev_workspace:
+    scopes: [fs:read, fs:write, shell:test]
+    path_root: workspace/
+    network: deny
+  release:
+    scopes: [fs:read, git:read]
+    approvals_required: [shell:build, deploy]
+```
+
+### CI
+
+Jeder Policy-Merge:
+
+1. Schema-Check
+2. Test-Suite grün
+3. Diff-Review durch Platform/Security
+4. Canary auf Nicht-Prod-Agenten
+
+## Mapping auf Sandbox-Stufen
+
+| Risk-Klasse | Mindest-Sandbox (Kap. 7) |
+|-------------|---------------------------|
+| R0 | Process / FS-Jail |
+| R1 | FS-Jail, Writes nur Workspace |
+| R2 | Container oder strenges Process+Netz-Deny |
+| R3 | Ephemeral + net allowlist + approval |
+| R4 | Remote / break-glass, separate Identität |
+
+Permissions ohne Sandbox-Mapping erzeugen Scheinsicherheit: deny in der UI,
+execute trotzdem auf dem Host.
+
+## Anti-Pattern
+
+1. **Voll-Shell als Default-Tool**  
+2. **„Allow once“ wird zu „Allow session forever“**  
+3. **Permissions nur clientseitig in der IDE** (Server/Harness muss enforce)  
+4. **Prod-Credentials in der gleichen Session wie Experimente**  
+5. **Tests der Policy mit dem Modell** statt mit deterministischen Fixtures  
+6. **Ein Admin-Bypass ohne Audit**  
+
+## Betriebs- und DX-Aspekte
+
+Zu enge Permissions ohne erklärende Fehler erzeugen Schatten-Tools und
+Copy-Paste in unkontrollierte Chats. Gute Deny-Meldungen nennen:
+
+- welche Regel greift (`policy_version` + rule id),
+- was erlaubt wäre (z. B. „nutze `run_tests`, nicht `shell`“),
+- wie man eine Ausnahme beantragt (TTL, Owner).
+
+Metriken:
+
+| Metrik | Nutzen |
+|--------|--------|
+| Deny-Rate nach Regel | Schärfe vs. Reibung |
+| Approval-Wartezeit | ob Gates im Alltag funktionieren |
+| Anteil Sessions mit R3-Scopes | Privilegien-Ausbreitung |
+| Break-glass-Häufigkeit | Prozess- oder Policy-Problem |
+
+## Checkliste
+
+- [ ] Tools nach Risk-Klasse R0–R4 inventarisiert
+- [ ] Default-Scopes minimal; keine freie Shell als Standard
+- [ ] Argument-Validierung serverseitig im Harness
+- [ ] Approvals für R3/R4 mit Audit-Feldern
+- [ ] Policy versioniert und in CI getestet
+- [ ] Mapping Risk-Klasse → Sandbox-Profil
+- [ ] Tool-Output läuft durch DLP zurück in den Kontext
+- [ ] Deny-Meldungen actionable für Entwickler
+- [ ] Break-glass dokumentiert, geloggt, TTL-begrenzt
+
+## Zusammenfassung
+
+Least Privilege für Agents ist Harness-Arbeit: Scopes, Schemas, Approvals und
+Session-Bindung – nicht Appelle im System-Prompt. Die Sandbox (Kapitel 7)
+begrenzt *wo* etwas läuft; Permissions begrenzen *was* angestoßen werden darf.
+Kapitel 9 wendet sich dem Nachweis zu: Logging und Audit, ohne Secrets in die
+Logs zu schreiben.
@@ -0,0 +1,185 @@
+# 9 Logging und Audit
+
+## Kern in einem Satz
+
+Audit heißt: Entscheidungen und Nebenwirkungen belegen – nicht jeden Prompt
+ewig speichern.
+
+## Überblick
+
+Die Kapitel 4–8 haben Kontrollen beschrieben: Datenfluss, DLP, Entropie,
+Sandbox, Permissions. Ohne Nachweis bleiben sie Behauptungen. Dieses Kapitel
+definiert, was ein Coding-Agent-Harness protokollieren muss, was er
+*nicht* protokollieren darf, und wie sich die Events an SIEM, Audit und
+Incident Response anschließen.
+
+Observability für Agents ist mehr als „Debug-Logs an“. Sie umfasst strukturierte
+Traces von Policy-Entscheidungen, Tool-Calls, Filter-Ergebnissen und Approvals –
+bei strikter Trennung von Secret-Klartext und Prompt-Volltext.
+
+## Zwei Ziele, die sich beißen – und wie man sie trennt
+
+| Ziel | Braucht | Risiko bei Naivität |
+|------|---------|---------------------|
+| **Security-Nachweis** | wer, was, welche Policy, welches Ergebnis | zu wenig Detail → Audit scheitert |
+| **Datenschutz / Secret-Hygiene** | keine Keys, keine PII im Log | zu viel Detail → Log wird zweites Leck |
+
+Die Auflösung: **Metadaten und Fingerprints reich, Payloads arm.**  
+Regel-ID und Aktion ja; Secret-String nein. Session-ID ja; vollständiger Prompt
+nur in gesonderten, streng regulierten Speichern – oder gar nicht.
+
+## Event-Modell (Mindestumfang)
+
+Jedes sicherheitsrelevante Ereignis sollte maschinenlesbar sein (JSON o. Ä.) und
+mindestens tragen:
+
+| Feld | Zweck |
+|------|--------|
+| `ts` | Zeit (UTC, monoton soweit möglich) |
+| `session_id` / `task_id` | Korrelation |
+| `actor_id` | Mensch oder Service-Principal |
+| `agent_version` | Build/Release des Harness |
+| `policy_version` | welche Regeln galten |
+| `event_type` | z. B. `dlp.hit`, `tool.call`, `tool.deny`, `approval`, `model.call` |
+| `outcome` | allow / deny / redact / error / approved |
+| `resource` | redigierte Kurzform (Tool-Name, Chunk-Source-ID, Gateway-ID) |
+| `trace_id` | Ende-zu-Ende über Orchestrator → Tool → Gateway |
+
+### Pflicht-Events
+
+1. **Session start/end** – Identität, Profil, Scopes
+2. **Policy-Entscheidung** – Deny/Allow mit Regel- oder Scope-ID
+3. **DLP-/Entropie-Treffer** – `rule_id`, Aktion, Fingerprint, *kein* Klartext
+4. **Tool-Call** – Name, validierte Argument-Zusammenfassung, Risk-Klasse,
+   Sandbox-Profil, Exit-Status, Dauer
+5. **Approval** – Anforderer, Entscheider, Bezug, TTL
+6. **Model-Call** – Gateway, Region/Anbieter-Klasse, Modell-ID, Token-Zähler,
+   Fehlercode; Prompt-Hash optional, Prompt-Text separat oder nie
+7. **Kill-Switch / Break-glass** – immer high-severity
+
+### Argument-Zusammenfassung statt Full Dump
+
+Statt `command: "cat /etc/passwd"` im Klartext (wenn überhaupt ausgeführt):
+
+- erlaubte, bereits validierte Felder in kanonischer Form,
+- Pfade normalisiert und ggf. gekürzt,
+- Längen und Hashes statt Riesenstrings,
+- Deny-Gründe als Codes (`POLICY_DENY_PATH`).
+
+Was nie ausgeführt wurde, braucht keinen Secret-haltigen Payload im Log.
+
+## Schutzzonen und Retention-Tiers
+
+| Tier | Inhalt | Retention (Richtwert) | Zugriff |
+|------|--------|------------------------|---------|
+| **T0 Metrics** | Zähler, Latenz, Deny-Raten | 90 Tage – 1 Jahr | breit (Ops) |
+| **T1 Audit trail** | Policy, Tool, Approval, Model-Meta | 1–7 Jahre je Regulierung | Security/Audit |
+| **T2 Debug detail** | erweiterte Traces, redigierte Snippets | Tage bis Wochen | on-call, break-glass |
+| **T3 Prompt archive** | Volltext Prompt/Response | oft: aus oder sehr eng | Legal/Security only |
+
+Zahlen sind Platzhalter für Ihre Policy – wichtig ist die **Trennung**. Ein
+Bucket für alles endet als unkontrolliertes Geheimnisarchiv.
+
+### Secret-Treffer im Log
+
+```
+{
+  "event_type": "dlp.hit",
+  "rule_id": "sec.aws.access_key_id.v3",
+  "action": "block",
+  "fingerprint": "sha256:…",
+  "chunk_source_id": "file:src/config.ts",
+  "policy_version": "2026.04.1"
+}
+```
+
+Nicht: `"match": "AKIA…"`.
+
+## Korrelation und Forensik
+
+Für Incidents brauchen Sie Ketten, keine Einzelzeilen:
+
+```
+session → tool.calls[] → dlp.hits[] → model.calls[] → approvals[]
+```
+
+Praktisch:
+
+- eine `trace_id` durch den gesamten Loop,
+- stabile `chunk_source_id` aus Kapitel 4,
+- Verknüpfung zu Change-Ticket und Incident-ID in Approvals und Kill-Events.
+
+Zielbild einer typischen Frage:  
+*„Welche Sessions haben Regel X in den letzten 24 h geblockt, und folgte ein
+Approval?“* – beantwortbar ohne Prompt-Volltext.
+
+## SIEM und Enterprise-Anschluss
+
+- strukturierte Events (JSON), keine reinen Freitext-Stacktraces als einzige Spur
+- Feldnamen und Severity an bestehende Pipelines anbinden
+- Unveränderlichkeit wo gefordert (WORM, signierte Batches, separates Audit-Konto)
+- Alerting auf: Break-glass-Spikes, Deny-Anomalien, Gateway-Wechsel,
+  Policy-Deploy ohne Canary, massenhafte DLP-Hits einer Regel (FP oder Angriff)
+
+## Was absichtlich *nicht* geloggt wird
+
+- Secret-Klartext und private Keys
+- vollständige `.env`-Inhalte
+- ungefilterte Tool-Stdout-Ströme mit Verdacht auf Credentials
+- personenbezogene Daten aus Fixtures über das nötige Maß hinaus
+- „zur Sicherheit alles“-Prompts in T0/T1
+
+Wenn Produkt oder Support Prompt-Inhalte braucht: **eigenes Produkt mit eigenem
+DPA, eigener Freigabe, eigener Retention** – nicht der Ops-Default.
+
+## Integrität und Schutz der Logs selbst
+
+Logs, die Zugriffe belegen, sind selbst ein Asset:
+
+- Schreibzugriff nur für den Harness-Service, nicht für jeden Entwickler
+- Trennung von Rollen: Operator sieht T0/T1 aggregiert, Klartext-T3 nur
+  break-glass
+- Manipulation erschweren (append-only, externe Senke)
+- Backup und Löschkonzept (Recht auf Löschung vs. Audit-Pflicht klären)
+
+## Anti-Pattern
+
+1. **Debug-Logging von Request-Bodies an den Model-Vendor in Prod**  
+2. **Ein ELK-Index mit Prompts, Secrets und Metriken**  
+3. **Nur Client-seitige Telemetrie** (IDE) ohne Server-Harness-Truth  
+4. **Policy-Version fehlt** – nicht rekonstruierbar, was galt  
+5. **Alerts ohne Runbook** (→ Kapitel 11)  
+6. **Fingerprint mit truncated Klartext** („sicherheitshalber die ersten 4 Zeichen
+   des Secrets“) – oft genug für Missbrauch
+
+## Mindest-Dashboard (Ops)
+
+| Kachel | Signal |
+|--------|--------|
+| Sessions / h | Last |
+| DLP block/redact Rate | Filterwirkung |
+| Top rule_ids | FP oder echte Funde |
+| Tool deny by scope | Permission-Reibung |
+| p95 DLP + Tool Latenz | DX |
+| Break-glass count | Ausnahme-Druck |
+| Model gateway mix | Residenz/Vertrag |
+
+## Checkliste
+
+- [ ] Event-Schema dokumentiert und versioniert
+- [ ] Pflicht-Events 1–7 implementiert
+- [ ] Kein Secret-Klartext in T0–T2
+- [ ] Retention-Tiers getrennt konfiguriert
+- [ ] `policy_version` und `agent_version` auf jedem Event
+- [ ] SIEM-Anbindung und Basis-Alerts
+- [ ] Zugriff auf T3 (falls vorhanden) break-glass + Audit
+- [ ] Forensik-Query „Session-Zeitlinie“ getestet
+- [ ] Log-Pipeline selbst zugriffsgeschützt
+
+## Zusammenfassung
+
+Gutes Agent-Logging beweist Kontrolle und schützt zugleich die Daten, die der
+Agent nicht leaken soll: reich an Entscheidungs-Metadaten, arm an Payloads.
+So wird aus Harness-Technik ein prüfbarer Dienst. Kapitel 10 bindet diese
+Nachweise in Enterprise-Governance ein; Kapitel 11 übersetzt Alerts in
+Playbooks.
@@ -0,0 +1,167 @@
+# 10 Enterprise- und Compliance-Patterns
+
+## Kern in einem Satz
+
+Compliance für Agents ist die Abbildung von Harness-Kontrollen auf bestehende
+Governance: Verträge, Residenz, Aufbewahrung, Freigaben.
+
+## Überblick
+
+Security Engineering (Kapitel 4–9) liefert Mechanismen. Enterprise-Patterns
+machen sie anschlussfähig an Einkauf, Rechtsabteilung, interne Revision und
+Linienmanagement. „Enterprise-ready“ heißt hier nicht Feature-Liste auf einer
+Folie, sondern: **erklären, freigeben und prüfen können**.
+
+Dieses Kapitel katalogisiert wiederkehrende Muster und mappt typische
+Audit-Fragen auf Systemnachweise.
+
+## Ausgangslage: Agents berühren mehrere Kontrollwelten
+
+| Domäne | Typische Frage |
+|--------|----------------|
+| Datenschutz | Welche personenbezogenen oder vertraulichen Daten gehen an wen? |
+| Informationssicherheit | Welche Rechte hat der Agent? Wie isolieren wir? |
+| Einkauf / Vendor | Welcher Auftragsverarbeiter, welches Subprocessing? |
+| Entwicklung | Wie bleibt DX akzeptabel unter Policy? |
+| Betrieb | Wer on-callt, wer darf Break-glass? |
+| Revision | Sind Controls designed *and* operating effectively? |
+
+Ein Harness, der nur „technisch sauber“ ist, aber keine Rollen, Verträge und
+Freigabewege kennt, bleibt in regulierten Umgebungen liegen.
+
+## Pattern-Katalog
+
+### 1 — Data Processing nur über freigegebene Gateways
+
+- Model-Calls ausschließlich über genehmigte Endpoints
+- Vertrag / DPA / AVV und Sicherheitsanhänge vorausgesetzt
+- technische Enforce: Allowlist im Gateway, nicht nur Wiki-Seite
+- Schatten-SDKs und lokale Consumer-Keys als Verstoß behandeln
+
+### 2 — Residenz- und Souveränitätszonen als Policy
+
+- explizite Zonen (z. B. `eu-prod`, `us-exp`, `local-lab`)
+- Routing nach Datenklasse und Repo-Label
+- keine „best effort region“ ohne Log
+- Experimente dürfen nicht still auf Prod-Zonen zugreifen
+
+### 3 — Retention-Tiers (an Kapitel 9 gekoppelt)
+
+- Telemetrie ≠ Prompt-Archiv ≠ Backup
+- Lösch- und Aufbewahrungsfristen pro Tier
+- Verantwortliche Owner benennen (Data Owner / Platform)
+
+### 4 — Rollenmodell
+
+| Rolle | Darf u. a. | Darf typisch nicht |
+|-------|------------|---------------------|
+| **Builder** | Policy-PRs, Detektoren entwickeln | Prod-Break-glass allein |
+| **Operator** | Sessions, Kill-Switch, On-call | Policy ohne Review mergen |
+| **Auditor** | lesen T1-Audit, Reports | Tools ausführen, Keys sehen |
+| **Developer** | Agents im erlaubten Profil nutzen | Policy umgehen, R3 default |
+| **Break-glass** | zeitlich begrenzte Erweiterung | Dauerzustand |
+
+IAM-Gruppen und Harness-Scopes müssen sich entsprechen (Kapitel 8).
+
+### 5 — Change Management für Policy und Detektoren
+
+- jede `policy_version` ist ein Release
+- Review, CI-Tests, Canary, Rollback-Pfad
+- Security als Pflicht-Reviewer bei riskanten Scope-Erweiterungen
+- Changelog, der Audit erklären kann („warum war shell gestern allow?“)
+
+### 6 — Vendor Exit und Portabilität
+
+- Export von Audit-Metadaten und Konfiguration
+- dokumentierte Löschwege beim Anbieter (wo vertraglich vorgesehen)
+- Fähigkeit, Gateway auf anderen Vendor oder internes Modell zu schwenken
+  ohne die DLP-/Permission-Schicht neu zu erfinden
+
+### 7 — Datenklassifikation steuert Agent-Profil
+
+| Klasse | Agent-Profil (Beispiel) |
+|--------|-------------------------|
+| Öffentlich / OSS | freizügiger, externes Modell möglich |
+| Intern | Standard-DLP, internes oder freigegebenes Gateway |
+| Vertraulich | strikte Pfade, Output-Scan, evtl. nur private Modelle |
+| Reguliert / PII-schwer | remote Sandbox, minimale Tools, oft Human-Review |
+
+Klassifikation ohne technische Durchsetzung ist Etikett.
+
+### 8 — Nachweisordner / Control Evidence
+
+Wiederkehrende Artefakte für Audits:
+
+- Architekturdiagramm Trust-Zonen (Kap. 4)
+- Policy- und Detektor-Versionen + Testergebnisse
+- Gateway- und Vendor-Liste mit Verträgen
+- Sampling von Audit-Logs (ohne Secrets)
+- Incident- und Exception-Reports mit TTL-Ausnahmen
+- Schulungs- oder Awareness-Nachweis für Entwickler (optional, je Org)
+
+## Mapping: Audit-Frage → Systemnachweis
+
+| Frage | Nachweis |
+|-------|----------|
+| Wer hat Zugriff auf den Agent-Dienst? | IAM, SSO-Gruppen, Session-Logs |
+| Welche Daten dürfen das Modell erreichen? | Datenklassen-Policy, DLP-Regeln, Deny-Metriken |
+| Wie verhindern wir Secret-Abfluss? | Kap. 5–6 Controls + Hit-Events ohne Klartext |
+| Wie begrenzen wir Aktionen? | Permissions R0–R4, Sandbox-Profile, Approvals |
+| Können wir eine Session rekonstruieren? | Trace aus Kap. 9 |
+| Was passiert bei Vorfall? | Playbooks Kap. 11, Postmortems |
+| Welcher Vendor verarbeitet was? | Gateway-Allowlist + Vertragsregister |
+| Wie ändern wir Controls? | Change-Prozess Pattern 5 |
+
+## Freigabemodell (skizziert)
+
+1. **Architektur-Freigabe** – Trust-Zonen, Gateway, Sandbox-Stufen  
+2. **Pilot** – ein Team, Schatten-DLP, enge Scopes  
+3. **Enforce** – block/redact an, Metriken grün  
+4. **Scale** – weitere Repos/Teams, Self-Service-Profile  
+5. **Re-Zertifizierung** – periodisch Policy, Vendor, Residenz  
+
+Jeder Sprung braucht messbare Exit-Kriterien (FP-Rate, Latenz, Incident-Zahl),
+nicht nur ein Statusmeeting.
+
+## Anti-Pattern in Enterprise-Kontexten
+
+1. **Schatten-Agents** mit privaten API-Keys neben dem freigegebenen Harness  
+2. **„Legal hat den Vendor freigegeben“** ohne technische Allowlist  
+3. **Einmalige Penetration-Demo** statt operating effectiveness  
+4. **Policy-Wiki ohne Version im Event-Log**  
+5. **Ausnahmen ohne TTL und Owner**  
+6. **Security-Tooling, das DX so zerstört, dass Bypass rational wird**
+
+## Zusammenspiel mit dem Harness
+
+Enterprise-Patterns sind keine parallele Excel-Welt. Sie fordern Hooks:
+
+- Gateway-Allowlist und Zonen-Tags  
+- Rollen → Default-Scopes  
+- `policy_version` in jedem Audit-Event  
+- Exception-API mit Ticket-Pflicht und Ablauf  
+- Report-Jobs (monatliche DLP- und Deny-Summaries) für Steuerungkreise  
+
+Platform Engineering besitzt die Implementierung; Security und Compliance
+besitzen die Anforderungen und die Abnahme – idealerweise in einem gemeinsamen
+Backlog.
+
+## Checkliste
+
+- [ ] Freigegebene Model-Gateways technisch erzwungen
+- [ ] Residenz-Zonen definiert und geroutet
+- [ ] Retention-Tiers mit Owner
+- [ ] Rollen IAM ↔ Harness-Scopes gemappt
+- [ ] Policy-Change-Prozess inkl. Canary
+- [ ] Vendor-/Exit-Dokumentation vorhanden
+- [ ] Datenklassen steuern Agent-Profile
+- [ ] Evidence-Paket für Audits vorbereitet
+- [ ] Pilot→Enforce-Kriterien schriftlich
+
+## Zusammenfassung
+
+Die Technik-Kapitel liefern die Schalter; Enterprise-ready wird es erst, wenn
+die Organisation sie vertraglich, rollenbasiert und revisionssicher einbettet.
+Patterns 1–8 sind wiederkehrende Bausteine, keine einmalige Checklisten-Show.
+Kapitel 11 macht daraus den Alltag: Incidents, False Positives und
+kontrollierte Abschaltung.
@@ -0,0 +1,185 @@
+# 11 Betrieb und Playbooks
+
+## Kern in einem Satz
+
+Produktionstaugliche Agents brauchen Runbooks: Incident, False Positives,
+Key-Rotation und kontrollierte Abschaltpfade.
+
+## Überblick
+
+Architektur und Compliance-Patterns (Kapitel 4–10) greifen nur, wenn Menschen
+im Ereignisfall **dieselbe Reihenfolge** abarbeiten. Dieses Kapitel übersetzt
+Kontrollen in Betrieb: Playbooks, SLOs, On-call-Grenzen und Postmortems.
+
+Zielgruppe sind Platform- und Security-Teams gemeinsam – nicht „der eine
+DevOps, der den Agent kennt“.
+
+## Betriebsmodell (kurz)
+
+| Funktion | Verantwortung |
+|----------|----------------|
+| On-call Platform | Verfügbarkeit Harness, Kill-Switch, Gateway |
+| Security Operations | Secret-Incidents, DLP-Anomalien, Forensik-Meta |
+| Policy Owner | Regel-/Scope-Änderungen, Exceptions mit TTL |
+| Team-Lead der Nutzer | Kommunikation, Workarounds ohne Schatten-IT |
+
+Klare Eskalation verhindert, dass bei Secret-Verdacht jeder lokal „kurz die
+Logs dump“ macht – und dabei Klartext verteilt.
+
+## Grundprinzipien für alle Playbooks
+
+1. **Sicherheit vor Forensik-Vollständigkeit** – erst stoppen/rotieren, dann
+   feinschnittig analysieren  
+2. **Kein Secret-Klartext in Tickets, Chat, Screenshots**  
+3. **Sessions und Keys haben IDs** – mit Fingerprints und `session_id` arbeiten  
+4. **Jede Ausnahme hat Owner und TTL**  
+5. **Alles Zeitstempeln** – für Postmortem und Audit (Kap. 9)
+
+## Playbook A — Secret im Prompt- oder Tool-Pfad (Verdacht oder bestätigt)
+
+**Auslöser:** DLP-block auf high-confidence Klasse; Nutzer-Report; Vendor-Hinweis;
+anomale Gateway-Nutzung mit sensiblen Pfaden.
+
+| Schritt | Aktion | Owner |
+|---------|--------|--------|
+| A1 | Betroffene Session(s) isolieren oder killen | Platform |
+| A2 | Weitere Sessions desselben Actors/Repos scannen (Metadaten) | Platform/Sec |
+| A3 | Verdächtigte Secrets **rotieren** (nicht nur „beobachten“) | Secret-Owner |
+| A4 | Audit-Zeitlinie ziehen: `session_id`, rule_ids, tool.calls, model.calls | Sec/Platform |
+| A5 | Prüfen: ging ein Call *nach* dem Treffer noch an Gateway? | Sec |
+| A6 | Vertragliche Meldepflichten prüfen (Vendor, Datenschutz, Kunden) | Sec/Legal |
+| A7 | Gate bewerten: welche Stufe versagt (Pfad, DLP, Scope)? | gemeinsam |
+| A8 | Fix (Regel, Deny-Path, Test) + Regression | Builder/Policy |
+| A9 | Postmortem mit Action Items und Termin | Policy Owner |
+
+**Nicht tun:** Secret in Ticket-Beschreibung pasten; „nur diesmal“ Filter global
+aus; unkontrolliert Prompt-Archive durchsuchen und exportieren.
+
+## Playbook B — False-Positive-Sturm
+
+**Auslöser:** Spike einer `rule_id`; Nutzer-Eskalation; Deny-Rate bricht DX.
+
+| Schritt | Aktion |
+|---------|--------|
+| B1 | Telemetrie: rule_id, Quellen, Sample von Fingerprints (keine Klartexte) |
+| B2 | Stichprobe labeln: echtes Secret / FP / unklar |
+| B3 | Wenn FP-dominiert: **gezielte** Allowlist oder Regel-Relax *mit Ticket + TTL* |
+| B4 | Parallel: dauerhafter Fix (Regex, Keyword-Nähe, Pfad-Ausnahme eng) |
+| B5 | Regressionstests ergänzen (pos + neg Fixtures) |
+| B6 | Nutzer informieren: was wann zurückgenommen wird |
+| B7 | TTL der Not-Allowlist erzwingen oder verlängern mit Review |
+
+Schattenmodus (Kap. 5–6) vor dem nächsten großen Regel-Release reduziert
+B-Stürme.
+
+## Playbook C — Agent außer Kontrolle (Tool-Loop, Kosten, Spam)
+
+**Auslöser:** Rate-Limit, Kostenalarm, hunderte Tool-Calls, Disk-Füllung in
+Sandbox.
+
+| Schritt | Aktion |
+|---------|--------|
+| C1 | Kill-Switch Session oder globaler Agent-Pause-Flag |
+| C2 | Rate-Limits und Output-Caps prüfen/härten |
+| C3 | Letzte N Tool-Calls (Metadaten) – Injection oder Bug? |
+| C4 | Sandbox-Netz/FS: Egress-Versuche? Workspace-Escape-Versuche? |
+| C5 | Policy enger (Scopes, erlaubte Tools), dann schrittweise freigeben |
+| C6 | Fix im Orchestrator (Loop-Detection, max depth) |
+
+## Playbook D — Gateway- oder Vendor-Vorfall
+
+**Auslöser:** Anbieter-Outage, Regions-Issue, Sicherheitsadvisory, Vertragsende.
+
+| Schritt | Aktion |
+|---------|--------|
+| D1 | Traffic auf Failover-Gateway oder read-only Modus |
+| D2 | Neue Sessions: nur freigegebene Rest-Kapazität |
+| D3 | Prüfen, ob Retries sensible Payloads vervielfachen |
+| D4 | Status an Entwickler (keine Spekulation über Datenlecks ohne Fakten) |
+| D5 | Nach Stabilisierung: Log-Sampling auf Anomalien |
+
+## Playbook E — Break-glass und Notfall-Rechte
+
+Break-glass ist vorgesehen – und gefährlich.
+
+- Anforderung mit Grund und Incident-/Change-ID  
+- Kurzlebige Scopes, harte TTL (Minuten/Stunden, nicht Wochen)  
+- Vier-Augen wo organisatorisch gefordert  
+- Automatisches Revoke + Alert an Security  
+- Post-hoc Review jedes Break-glass in der Woche  
+
+Dauerhaft erweiterte Rechte „weil sonst nichts geht“ sind gescheiterte Policy,
+kein Betriebsmodus.
+
+## Playbook F — Policy-Rollback
+
+Wenn ein Release DX oder Sicherheit verschlechtert:
+
+1. Canary stoppen  
+2. `policy_version` zurück auf letzten bekannten guten Stand  
+3. Caches invalidieren (Kap. 4)  
+4. Incident-light: was ist raus, was war deniert?  
+5. Hotfix-Zweig mit Tests, kein „Fix forward“ ohne Suite  
+
+## SLOs und SLIs (Beispiele)
+
+Werte kalibrieren Sie selbst; die *Existenz* der SLOs ist der erste Schritt.
+
+| SLI | Beispiel-SLO | Bemerkung |
+|-----|--------------|-----------|
+| DLP-Latenz p95 | < X ms pro Chunk | sonst umgehen Nutzer den Agent |
+| Harness-Verfügbarkeit | 99.x % | Kill-Switch zählt als bewusste Unavailability |
+| Mean time to revoke Session | < Y Min | Playbook A/C |
+| Mean time to rotate critical secret | < Z Std | org-abhängig |
+| Policy-Deploy ohne Canary in Prod | = 0 | hart |
+| Break-glass ohne Ticket | = 0 | hart |
+| Offene Exceptions ohne TTL | = 0 | wöchentlicher Job |
+
+## On-call-Runbook (Checkliste am Alarm)
+
+- [ ] Welches Alert-Label / welche rule_id / welche gateway_id?  
+- [ ] Scope: eine Session, ein Tenant, global?  
+- [ ] Sofortmaßnahme: kill, rate-limit, gateway failover?  
+- [ ] Secret-Verdacht? → Playbook A priorisieren  
+- [ ] Kommunikation: Statusseite / interner Channel, ohne Payloads  
+- [ ] Ticket mit `trace_id` / `session_id`, keine Screenshots von Secrets  
+- [ ] Handover und Follow-up-Owner  
+
+## Postmortem-Minimalgerüst
+
+1. Timeline (UTC)  
+2. Impact (Sessions, Repos, mögliche Datenklassen – ohne Klartext)  
+3. Detection (welches Signal hat gegriffen – oder nicht?)  
+4. Root cause (Gate, Prozess, Vendor)  
+5. What went well / poorly  
+6. Actions mit Owner und Datum  
+7. Welche Tests/SLOs verhindern Wiederholung?  
+
+Blameless gegenüber Personen, streng gegenüber fehlenden Controls.
+
+## Anti-Pattern im Betrieb
+
+- Incident-Chat mit eingefügten Keys „nur für die Analyse“  
+- Globaler DLP-Off-Schalter als erste Reaktion auf FP  
+- On-call ohne Zugriff auf Kill-Switch  
+- Playbooks nur in den Köpfen von zwei Personen  
+- Metriken ohne Owner, der sie wöchentlich liest  
+
+## Checkliste: betriebsbereit?
+
+- [ ] Playbooks A–F dokumentiert und verlinkt im Alert-Tool  
+- [ ] Kill-Switch getestet (Game day)  
+- [ ] Secret-Rotation mit den Secret-Ownern geprobt  
+- [ ] FP-Exception-Pfad mit TTL automatisiert oder erzwungen  
+- [ ] SLIs angebunden und Alarm-Schwellen gesetzt  
+- [ ] On-call-Roster kennt Harness *und* Security-Eskalation  
+- [ ] Postmortem-Template vorhanden  
+- [ ] Wöchentlicher Report: Break-glass, Top-Denies, offene TTLs  
+
+## Zusammenfassung
+
+Playbooks machen aus Patterns einen betreibbaren Dienst: stoppen, rotieren,
+begrenzte Ausnahmen, rollbacken, lernen. Fehlen sie, bleiben Freigaben und
+Architekturdiagramme Theorie. Mit Playbooks – und den technischen Gates der
+Kapitel 4–9 – können Teams Coding-Agents skalieren, ohne bei jedem Zwischenfall
+neu zu erfinden, was Sicherheit bedeutet.
@@ -0,0 +1,44 @@
+# Kolophon
+
+## Werk
+
+*Secure Coding Agents with Flue*  
+Untertitel: *Enterprise-ready Data Protection, Logging & Compliance Patterns*  
+Autor: Martin Richardt  
+1. Auflage 2026  
+
+## Herstellung
+
+- Manuskript: Markdown unter `manuskript/`, assembliert mit
+  `scripts/assemble_book.py`
+- Satz: Pandoc und LuaLaTeX, Dokumentklasse KOMA-Script (`scrbook`)
+- Template und Filter: `pdf/templates/`, `pdf/filters/` (portiert und angepasst
+  aus dem Schwesterprojekt *Die KI hinter dem Vorhang*)
+- Farben: Navy / Cyan / Emerald (`pdf/styles/secure-agents-colors.tex`)
+- Cover: generative, textfreie Art-Base; Typografie per Pillow-Overlay
+  (`scripts/build_cover.py` → `assets/cover/`)
+- Build: `just cover`, `just assemble`, `just pdf`
+
+## Schriften
+
+| Rolle | Schrift |
+|-------|---------|
+| Fließtext | Charter |
+| Sans (Überschriften, UI-nah) | DejaVu Sans |
+| Mono (Code) | DejaVu Sans Mono |
+| Cover-Titel | Baskerville / Avenir Next (System, Overlay) |
+
+## Inhaltlicher Anspruch
+
+Fachbuch-Skizze mit Vollfassungen der Kapitel zu Datenfluss, DLP, Entropie,
+Sandbox, Permissions, Audit, Enterprise-Patterns und Betrieb. Keine
+Rechtsberatung, kein Vendor-Zertifikat, kein vollständiges API-Handbuch zu Flue.
+
+## Rechte
+
+© 2026 Martin Richardt. Alle Rechte vorbehalten, soweit nicht anders vermerkt.
+
+## Danksagung (Platzhalter)
+
+Dank an alle, die Harness-Hooks, Deny-by-default und langweilige Audit-Logs
+für wichtiger halten als die nächste Demo – namentlich zu ergänzen.
@@ -0,0 +1,113 @@
+# Literatur und weiterführende Quellen
+
+Die folgende Liste ist eine **Arbeitsbibliografie**: stabile Einstiege und
+Orientierungsquellen zu den Themen des Buchs. Fassungen und URLs ändern sich;
+prüfen Sie vor verbindlicher Nutzung die jeweils aktuelle Version. Abrufstand
+der Links, soweit nicht anders vermerkt: 2026-07.
+
+Dieses Verzeichnis ersetzt keine Rechts- oder Audit-Beratung.
+
+## Standards, Frameworks und Top-Listen
+
+1. OWASP GenAI Security Project: *OWASP Top 10 for LLM Applications* (Fassung
+   2025 bzw. jeweils aktuell).  
+   <https://genai.owasp.org/llm-top-10/>  
+   Projektübersicht: <https://owasp.org/www-project-top-10-for-large-language-model-applications/>
+
+2. National Institute of Standards and Technology (NIST): *Artificial
+   Intelligence Risk Management Framework (AI RMF 1.0)* und Folgepublikationen.  
+   <https://www.nist.gov/itl/ai-risk-management-framework>
+
+3. International Organization for Standardization: *ISO/IEC 27001* –
+   Information security management systems (Controls zu Access, Logging,
+   Supplier Relationships – im Org-Kontext mappen).
+
+4. Europäische Union: *Verordnung (EU) 2016/679* (DSGVO) – insbesondere
+   Grundsätze der Datenminimierung, Zweckbindung und Auftragsverarbeitung.  
+   Konsolidierter Text u. a. über EUR-Lex.
+
+5. Europäische Union: *Verordnung (EU) 2024/1689* (AI Act) – wo Agenten-Systeme
+   in den Anwendungsbereich fallen; mit Fachjuristen und aktueller Guidance
+   abstimmen.
+
+## Secret Detection, DLP und Entropie
+
+6. Shannon, C. E. (1948): *A Mathematical Theory of Communication.* Bell System
+   Technical Journal – konzeptionelle Grundlage der Shannon-Entropie.
+
+7. Dokumentationen gängiger Secret-Scanning-Ansätze (Muster und Limitationen),
+   z. B. Open-Source-Scanner und Plattform-Features der großen Git-Hoster –
+   jeweils als *Inspiration für Detektorklassen*, nicht als alleinige
+   Enterprise-Control.
+
+8. OWASP: Materialien zu *Sensitive Information Disclosure* im LLM-/GenAI-
+   Kontext (siehe Top-10-Einträge der aktuellen Fassung unter [1]).
+
+## Prompt Injection, Agents und Tool-Use
+
+9. OWASP: *Prompt Injection* (LLM01 in den LLM-Top-10) – Definitionen,
+   Szenarien, Mitigationsskizzen.  
+   Einstieg über [1].
+
+10. Literatur und Reports zu *indirect prompt injection* in
+    Retrieval-/Tool-Systemen (Vendor- und Forschungsblogs; kritisch lesen und
+    mit dem eigenen Bedrohungsmodell abgleichen).
+
+11. Model Context Protocol (MCP) und vergleichbare Tool-Ökosysteme: offizielle
+    Spezifikationen und Security-Überlegungen der jeweiligen Projekte – relevant
+    für Permission- und Trust-Grenzen, sobald Agents externe Tool-Server nutzen.
+
+## Isolation, Supply Chain und sichere Ausführung
+
+12. Container- und Runtime-Härtung: Dokumentation zu User Namespaces,
+    Read-only Roots, Seccomp/AppArmor/SELinux und *nicht* privilegierten
+    Containern (je nach Stack).
+
+13. gVisor / microVM-Ansätze (z. B. Firecracker-Ökosystem): Hersteller- und
+    Projekt-Docs zu Isolationseigenschaften und Betriebsgrenzen.
+
+14. Supply-Chain-Sicherheit in der Entwicklung: SLSA-Framework und verwandte
+    Guidance zu Provenance und Build-Integrität.  
+    <https://slsa.dev/>
+
+15. NIST / Branchen-Guides zu *Secure Software Development* und Dependency-
+    Risiken – an die Agent-Pfade „install/build/test“ koppeln.
+
+## Logging, Audit und Betrieb
+
+16. Strukturiertes Logging und SIEM-Integration: interne Standards der
+    Organisation plus gängige Praxen (JSON-Events, Korrelations-IDs,
+    append-only Audit-Stores).
+
+17. Incident-Response-Playbooks: NIST SP 800-61 (Computer Security Incident
+    Handling) als organisatorischer Rahmen – Agent-spezifisch in Kapitel 11
+    ausgeprägt.  
+    <https://csrc.nist.gov/publications/detail/sp/800-61/rev-2/final>
+
+## Datenschutz und Auftragsverarbeitung (Orientierung)
+
+18. Aufsichtsbehörden und Standardvertragsklauseln zur Auftragsverarbeitung /
+    internationalem Datentransfer – jeweils die für Ihre Jurisdiktion
+    maßgeblichen Texte und FAQ.
+
+19. Anbieter-Dokumentationen zu *Training opt-out*, Zero Data Retention und
+    Regional Endpoints – vertraglich *und* technisch (Gateway-Flags) prüfen.
+
+## Weiterführende Themencluster (für eigene Vertiefung)
+
+| Cluster | Warum im Buch relevant |
+|---------|-------------------------|
+| High-Entropy- und Pattern-Secret-Detection | Kapitel 5–6 |
+| Agent frameworks & tool routers | Kapitel 2, 7–8 |
+| Least privilege & policy-as-code | Kapitel 8, 10 |
+| Sandbox escape literature | Kapitel 7 |
+| AI governance / model risk management | Kapitel 10 |
+| Blameless postmortems / SRE | Kapitel 11 |
+
+## Hinweis zur Pflege
+
+- Jede verbindliche Referenz in Audits sollte **Dokumenttitel, Version/Datum
+  und Abruf-URL** tragen.
+- Vendor-Blogs und Social Media ersetzen keine Standards.
+- Dieses Verzeichnis wächst mit der Manuskript- und Review-Arbeit; streichen
+  Sie Veraltetes lieber, als tote Links zu horten.
@@ -0,0 +1,98 @@
+# Prolog
+
+## Der Agent, der zu viel weiß
+
+Montag, 09:17. Eine Entwicklerin startet den Coding-Agenten in der IDE, weil
+der Integrationstest rot ist. Der Agent liest die Fehlerausgabe, öffnet zwei
+Konfigurationsdateien, schlägt einen Patch vor – und hängt, ohne dass es jemand
+bemerkt, den Inhalt einer `.env.local` in den Kontext, „nur zur Sicherheit, falls
+Credentials das Problem sind“.
+
+Sekunden später verlässt dieser Kontext den Vertrauensbereich des Unternehmens
+Richtung Model Gateway. Vielleicht speichert der Anbieter nichts. Vielleicht
+landen Fragmente in einem Missbrauchsfilter. Vielleicht ist der Key ohnehin nur
+für Staging. Nichts davon ändert die technische Tatsache: **eine automatisierte
+Schleife hat eine Entscheidung getroffen, die kein Mensch in diesem Moment
+bewusst freigegeben hat.**
+
+Das ist kein dystopisches Szenario und kein Angriff aus dem Lehrbuch. Es ist der
+Normalfall, sobald Teams Agents produktiv einsetzen, ohne explizite
+Datengrenzen, Filter und Audit-Spuren. Die Produktivität ist real. Das Risiko
+auch – nur stiller.
+
+## Worum es in diesem Buch geht
+
+Dieses Buch beschreibt, wie man Coding-Agents auf Basis eines Agent-Harnesses –
+exemplarisch das TypeScript-Framework **Flue** – so absichert, dass sie in
+Unternehmen freigabefähig werden:
+
+- welche Daten das Modell sehen darf und wie man den Fluss dorthin steuert,
+- wie DLP (Pattern Matching) und Entropie-Filter Secrets und heikle Fragmente
+  abfangen,
+- wie Sandboxes und Tool-Permissions den *Handlungsraum* begrenzen,
+- wie Logging und Audit Kontrolle *nachweisen*, ohne selbst zum Leck zu werden,
+- wie Enterprise-Patterns und Playbooks den Alltag aus Freigabe, Incident und
+  Betrieb tragen.
+
+Flue ist Bezugspunkt und Nomenklatur-Hilfe, kein Marketinggegenstand. Dieselben
+Schichten – Context Builder, Gateway, Tool Runtime, Policy, Observability –
+finden sich in anderen Harnesses unter anderen Namen. Die Patterns sind auf die
+*Stelle* gemünzt, nicht auf ein Logo.
+
+## Für wen dieses Buch ist
+
+- **Entwicklerinnen und Entwickler**, die Agents bauen, betreiben oder in den
+  Alltag holen und Security nicht an „die andere Abteilung“ abschieben können
+- **Security- und Compliance-Verantwortliche**, die freigeben, auditieren oder
+  stoppen müssen – und technische Anschlussstellen brauchen, keine Folien
+- **Plattform-Teams**, die einen gemeinsamen Harness standardisieren und
+  Self-Service mit Leitplanken liefern wollen
+
+Es ist **kein** Einstieg in Prompt-Engineering, **kein** Katalog von
+Model-Benchmarks und **kein** Tutorial für Hobby-Bots. Schwerpunkt sind
+kontrollierbare Datenflüsse, nachweisbare Entscheidungen und betriebsfähige
+Muster.
+
+## Was Sie nicht erwartet
+
+- Garantien der Form „mit diesen Regex sind Sie DSGVO-fertig“
+- Vendor-Vergleiche mit Siegerpodest
+- Vollständige Rechtsberatung
+- Ein einziges „sicheres Default-Prompt“
+
+Stattdessen: Architekturentscheidungen, Tabellen, Checklisten, Anti-Pattern und
+die wiederkehrende Zumutung, **Deny by default** ernst zu nehmen.
+
+## Drei Leitfragen
+
+Durch alle Kapitel ziehen sich dieselben Fragen:
+
+1. **Welche Daten verlassen den Vertrauensbereich – und warum?**  
+   (Kapitel 4–6)
+2. **Welche Kontrolle greift *vor* dem LLM-Call, welche *danach* – und was darf
+   der Agent *tun*?**  
+   (Kapitel 4–8)
+3. **Wie beweisen wir im Audit und im Incident, dass die Kontrolle funktioniert
+   hat?**  
+   (Kapitel 9–11)
+
+Kapitel 1–3 schaffen die gemeinsame Sprache: Warum das Thema zählt, wo der
+Harness sitzt, welches Bedrohungsmodell greift.
+
+## Wie Sie das Buch lesen können
+
+- **linear**, wenn Sie eine Plattform von Grund auf absichern,
+- **ab Kapitel 4**, wenn Architektur und Bedrohungsmodell klar sind und Sie
+  sofort DLP und Gateway brauchen,
+- **ab Kapitel 7**, wenn Datenfilter existieren, aber Tool-Chaos und fehlende
+  Isolation das eigentliche Problem sind,
+- **ab Kapitel 9**, wenn Security fragt: „Zeigt mir den Nachweis.“
+
+Am Ende jedes Hauptkapitels stehen Checklisten. Sie sind zum Abhaken gedacht,
+nicht als Dekoration.
+
+## Ein Satz vor dem ersten Kapitel
+
+Coding-Agents verändern, wie Software entsteht. Ob sie auch verändern, wie
+Unternehmen *unbemerkt* Daten und Rechte abgeben, entscheiden nicht die Modelle –
+sondern die Harness-Schicht, die Sie bauen oder dulden.
@@ -0,0 +1,23 @@
+# Über den Autor
+
+**Martin Richardt** arbeitet und schreibt an der Schnittstelle von
+Softwarearchitektur, KI-Systemen und nachvollziehbarer Technikvermittlung. Ihn
+interessiert, was Systeme *tun*, wenn Demos vorbei sind: Grenzen, Anreize,
+Betriebsalltag und die Stellen, an denen Sicherheit entweder zur
+Ingenieursdisziplin oder zur Folie wird.
+
+In *Secure Coding Agents with Flue* adressiert er die Lücke zwischen
+Agent-Hype und freigabefähigem Betrieb. Schwerpunkt sind kontrollierbare
+Datenflüsse zum Modell, Isolation und Least Privilege auf dem Aktionspfad sowie
+Audit und Playbooks, die Security und Plattform-Teams gemeinsam tragen können.
+Flue dient als architektonischer Bezugspunkt für TypeScript-Harnesses – die
+Patterns sind bewusst harness-übergreifend formuliert.
+
+Zuvor und parallel: Sachbuch- und Vermittlungsarbeit zu LLMs und Agenten-
+Systemen, unter anderem im Schwesterprojekt *Die KI hinter dem Vorhang*, sowie
+Praxis in der Entwicklung und im Design technischer Systeme, bei denen
+Nachvollziehbarkeit kein Nice-to-have ist.
+
+Dieses Buch spricht Entwicklerinnen und Entwickler, Security-Verantwortliche und
+Plattform-Teams an, die Agents nicht nur ausprobieren, sondern verantworten
+wollen.
@@ -0,0 +1,234 @@
+-- boxes.lua — Pandoc Lua filter for *Next Token*
+--
+-- Wraps selected sections into colored tcolorbox environments:
+--
+--   Intro (nexttokenintro):
+--     H2/H3 whose text contains "Kern in einem Satz" or "Worum geht es"
+--   Summary (nexttokensummary):
+--     H2 beginning with "Zusammenfassung"
+--   Vertiefung (nexttokenvertiefung):
+--     H2/H3: "Zum Weiterdenken", "Vertiefung", "Für Neugierige", "Fuer Neugierige"
+--   Info (nexttokeninfo):
+--     H2/H3: "Überblick"/"Ueberblick", "Häufiges Missverständnis"/"Haeufiges Missverstaendnis",
+--            "Stand der Technik"
+--
+-- Box opens after matched header; closes before next header of level <= opened level.
+-- Title is passed once to the tcolorbox (no duplicate body title).
+--
+-- Leading manuscript markers ▢ / ☐ are stripped from headers and bold titles
+-- so they never appear in body text or the TOC.
+--
+-- Note: Lua patterns are byte-oriented. Never put multi-byte UTF-8 in [].
+
+local function escape_tex(s)
+  s = s:gsub("\\", "\\textbackslash{}")
+  s = s:gsub("([&%%%$#_{}])", "\\%1")
+  s = s:gsub("~", "\\textasciitilde{}")
+  s = s:gsub("%^", "\\textasciicircum{}")
+  s = s:gsub("–", "---")
+  s = s:gsub("—", "---")
+  s = s:gsub("…", "\\ldots{}")
+  s = s:gsub("→", "$\\rightarrow$")
+  s = s:gsub("≠", "$\\neq$")
+  return s
+end
+
+local function stringify(el)
+  return pandoc.utils.stringify(el)
+end
+
+-- UTF-8 marker strings (exact match / prefix only — no [] character classes)
+local MARKERS = {
+  "▢", -- U+25A2 white square with rounded corners
+  "☐", -- U+2610 ballot box
+}
+
+local function strip_marker_prefix(s)
+  if not s or s == "" then return s, false end
+  for _, m in ipairs(MARKERS) do
+    if s == m then
+      return "", true
+    end
+    local n = #m
+    if s:sub(1, n) == m then
+      local rest = s:sub(n + 1)
+      -- also drop one ASCII space after marker if glued ("▢Text")
+      if rest:sub(1, 1) == " " then
+        rest = rest:sub(2)
+      end
+      return rest, true
+    end
+  end
+  return s, false
+end
+
+local function clean_title(s)
+  s = s or ""
+  s = s:gsub("^%s+", "")
+  s = select(1, strip_marker_prefix(s))
+  s = s:gsub("\194\160", " ") -- NBSP
+  s = s:gsub("\239\191\189", " ")
+  s = s:gsub("^[ \t\n\r\f\v]+", ""):gsub("[ \t\n\r\f\v]+$", "")
+  s = s:gsub("[ \t\n\r\f\v]+", " ")
+  return s
+end
+
+local function is_space_like(el)
+  return el.t == "Space" or el.t == "SoftBreak" or el.t == "LineBreak"
+end
+
+--- Remove a leading ▢/☐ (and following space) from an inline list.
+local function strip_leading_marker_inlines(inlines)
+  if not inlines or #inlines == 0 then return inlines end
+
+  local i = 1
+  while i <= #inlines and is_space_like(inlines[i]) do
+    i = i + 1
+  end
+  if i > #inlines then return inlines end
+
+  local el = inlines[i]
+
+  if el.t == "Str" then
+    local rest, hit = strip_marker_prefix(el.text)
+    if hit then
+      local out = {}
+      if rest ~= "" then
+        out[#out + 1] = pandoc.Str(rest)
+      end
+      i = i + 1
+      if i <= #inlines and is_space_like(inlines[i]) then
+        i = i + 1
+      end
+      for j = i, #inlines do
+        out[#out + 1] = inlines[j]
+      end
+      return out
+    end
+  end
+
+  if el.t == "Strong" or el.t == "Emph" then
+    el.content = strip_leading_marker_inlines(el.content)
+    inlines[i] = el
+  end
+
+  return inlines
+end
+
+local function header_text(el)
+  return clean_title(stringify(el))
+end
+
+local function is_intro(el)
+  if el.t ~= "Header" or el.level > 3 then return false end
+  local s = header_text(el)
+  return s:match("Kern in einem Satz")
+      or s:match("Worum geht es")
+end
+
+local function is_summary(el)
+  return el.t == "Header" and el.level == 2
+    and header_text(el):match("^Zusammenfassung")
+end
+
+local function is_vertiefung(el)
+  if el.t ~= "Header" or el.level > 3 then return false end
+  local s = header_text(el)
+  return s:match("^Zum Weiterdenken")
+      or s:match("^Vertiefung")
+      or s:match("Für Neugierige")
+      or s:match("Fuer Neugierige")
+end
+
+local function is_info(el)
+  if el.t ~= "Header" or el.level > 3 then return false end
+  local s = header_text(el)
+  return s:match("^Überblick")
+      or s:match("^Ueberblick")
+      or s:match("^Im Überblick")
+      or s:match("^Im Ueberblick")
+      or s:match("Häufiges Missverständnis")
+      or s:match("Haeufiges Missverstaendnis")
+      or s:match("Stand der Technik")
+end
+
+local function open_env(cls, title)
+  local env = cls == "intro" and "nexttokenintro"
+    or cls == "summary" and "nexttokensummary"
+    or cls == "vertiefung" and "nexttokenvertiefung"
+    or "nexttokeninfo"
+  local t = escape_tex(clean_title(title))
+  return pandoc.RawBlock("latex", "\\begin{" .. env .. "}{" .. t .. "}")
+end
+
+local function close_env(cls)
+  local env = cls == "intro" and "nexttokenintro"
+    or cls == "summary" and "nexttokensummary"
+    or cls == "vertiefung" and "nexttokenvertiefung"
+    or "nexttokeninfo"
+  return pandoc.RawBlock("latex", "\\end{" .. env .. "}")
+end
+
+local function sanitize_header(el)
+  el.content = strip_leading_marker_inlines(el.content)
+  return el
+end
+
+local function process(blocks)
+  local out = {}
+  local i = 1
+  local open = nil
+
+  while i <= #blocks do
+    local el = blocks[i]
+
+    if open and el.t == "Header" and el.level <= open.level then
+      out[#out + 1] = close_env(open.cls)
+      open = nil
+      -- re-process this header (may open a new box)
+    elseif open then
+      out[#out + 1] = el
+      i = i + 1
+    elseif el.t == "Header" then
+      el = sanitize_header(el)
+      local cls = nil
+      if is_intro(el) then
+        cls = "intro"
+      elseif is_summary(el) then
+        cls = "summary"
+      elseif is_vertiefung(el) then
+        cls = "vertiefung"
+      elseif is_info(el) then
+        cls = "info"
+      end
+
+      if cls then
+        open = {cls = cls, level = el.level}
+        out[#out + 1] = open_env(cls, stringify(el))
+        i = i + 1
+      else
+        out[#out + 1] = el
+        i = i + 1
+      end
+    else
+      out[#out + 1] = el
+      i = i + 1
+    end
+  end
+
+  if open then
+    out[#out + 1] = close_env(open.cls)
+  end
+
+  return out
+end
+
+function Strong(el)
+  el.content = strip_leading_marker_inlines(el.content)
+  return el
+end
+
+function Pandoc(doc)
+  doc.blocks = process(doc.blocks)
+  return doc
+end
@@ -0,0 +1,35 @@
+% impressum.tex — Copyright / imprint page (placeholder)
+\clearpage
+\thispagestyle{empty}
+\begingroup
+\small\color{nexttokentext}%
+\raggedright
+
+{\sffamily\color{nexttokenblue}\Large\bfseries Imprint\par}
+\vspace{0.8em}
+
+{\sffamily\bfseries Secure Coding Agents with Flue\par}
+{\itshape Enterprise-ready Data Protection, Logging \& Compliance Patterns\par}
+
+\vspace{1.0em}
+
+{\sffamily © 2026 Martin Richardt\par}
+All rights reserved.\par
+
+\vspace{0.6em}
+
+1st edition 2026\par
+Author: Martin Richardt\par
+
+\vspace{1.0em}
+
+This work is protected by copyright.
+Any use outside the narrow limits of copyright law
+without the author's consent is prohibited.\par
+
+\vspace{0.8em}
+
+% ISBN: add when assigned
+
+\endgroup
+\clearpage
@@ -0,0 +1,8 @@
+title: "Secure Coding Agents with Flue"
+subtitle: "Enterprise-ready Data Protection, Logging & Compliance Patterns"
+author: "Martin Richardt"
+date: "2026"
+lang: de-DE
+documentclass: scrbook
+classoption: [11pt, a4paper, oneside, openany, DIV=13]
+has-frontmatter: true
@@ -0,0 +1,26 @@
+% secure-agents-colors.tex — Farbpalette für *Secure Coding Agents with Flue*
+% Geladen via Pandoc `-H`. Vorausgesetzt: xcolor (Template lädt es).
+
+\IfFileExists{xcolor.sty}{\usepackage{xcolor}}{}
+
+% --- Hauptpalette (Enterprise Security: Navy / Cyan / Emerald) ------------
+\definecolor{secureagentsnavy}{HTML}{0B1220}     % Tiefes Navy   (H1, Kopf, TOC)
+\definecolor{secureagentscyan}{HTML}{00D4FF}     % Elektrisches Cyan (Akzent)
+\definecolor{secureagentsemerald}{HTML}{2A9D8F}  % Gedämpftes Emerald (Linien, Seitenzahl)
+\definecolor{secureagentstext}{HTML}{2C2C2C}     % Anthrazit     (Fließtext)
+\definecolor{secureagentsslates}{HTML}{4A5568}   % Schiefer      (Zitate, Hinweise)
+\definecolor{secureagentsparchment}{HTML}{F2F6F8}% Kühles Pergament (Boxen)
+\definecolor{secureagentslink}{HTML}{0B3A5C}     % Link-Navy
+
+% Aliase für Template-Kompatibilität mit nexttoken-Namensschema
+\colorlet{nexttokenblue}{secureagentsnavy}
+\colorlet{nexttokengold}{secureagentsemerald}
+\colorlet{nexttokenburgundy}{secureagentscyan}
+\colorlet{nexttokentext}{secureagentstext}
+\colorlet{nexttokenslate}{secureagentsslates}
+\colorlet{nexttokenparchment}{secureagentsparchment}
+\colorlet{nexttokenlink}{secureagentslink}
+
+\colorlet{secureagentsnavy!soft}{secureagentsnavy!18!white}
+\colorlet{secureagentscyan!soft}{secureagentscyan!20!white}
+\colorlet{secureagentsemerald!soft}{secureagentsemerald!25!white}
@@ -0,0 +1,166 @@
+\documentclass[
+$if(fontsize)$
+  $fontsize$,
+$else$
+  11pt,
+$endif$
+$if(papersize)$
+  $papersize$paper,
+$else$
+  a4paper,
+$endif$
+  oneside,
+  openany,
+  DIV=12,
+  BCOR=0mm,
+$for(classoption)$
+  $classoption$$sep$,
+$endfor$
+]{scrbook}
+
+\usepackage{xcolor}
+\definecolor{nexttokenlink}{HTML}{0B3A5C}
+
+$if(geometry)$
+\usepackage[$for(geometry)$$geometry$$sep$,$endfor$]{geometry}
+$endif$
+
+\usepackage{amsmath,amssymb}
+
+$if(numbersections)$
+\setcounter{secnumdepth}{$if(secnumdepth)$$secnumdepth$$else$5$endif$}
+$else$
+\setcounter{secnumdepth}{-\maxdimen}
+$endif$
+
+\usepackage{iftex}
+\ifLuaTeX
+  \usepackage{fontspec}
+  \setmainfont{Latin Modern Roman}
+  \setsansfont{Latin Modern Sans}
+  \setmonofont{Latin Modern Mono}
+\else
+  \usepackage{lmodern}
+\fi
+\usepackage{setspace}
+
+\usepackage[autostyle=true,english=american]{csquotes}
+\MakeOuterQuote{"}
+
+\IfFileExists{microtype.sty}{%
+  \usepackage{microtype}%
+  \UseMicrotypeSet[protrusion]{basicmath}%
+}{}
+
+\usepackage{booktabs}
+\usepackage{calc}
+\usepackage{enumitem}
+\usepackage{graphicx}
+\usepackage{longtable,array}
+
+\providecommand{\tightlist}{\setlength{\itemsep}{0pt}\setlength{\parskip}{0pt}}
+
+$for(header-includes)$
+$header-includes$
+$endfor$
+
+$highlighting-macros$
+
+\IfFileExists{pdf/templates/secure-agents-preamble.tex}{%
+  \input{pdf/templates/secure-agents-preamble.tex}%
+}{%
+  \InputIfFileExists{secure-agents-preamble.tex}{}{}%
+}
+
+\usepackage{hyperref}
+\hypersetup{
+$if(title-meta)$
+  pdftitle={$title-meta$},
+$endif$
+$if(author-meta)$
+  pdfauthor={$author-meta$},
+$endif$
+  pdflang={en},
+$if(colorlinks)$
+  colorlinks=true,
+  linkcolor=$if(linkcolor)$$linkcolor$$else$nexttokenlink$endif$,
+  urlcolor=$if(urlcolor)$$urlcolor$$else$nexttokenlink$endif$,
+  citecolor=$if(citecolor)$$citecolor$$else$nexttokenlink$endif$
+$else$
+  hidelinks
+$endif$
+}
+
+$if(title)$
+\title{$title$$if(thanks)$\thanks{$thanks$}$endif$}
+$endif$
+$if(subtitle)$
+\usepackage{etoolbox}
+\makeatletter
+\providecommand{\subtitle}[1]{%
+  \apptocmd{\@title}{\par {\large #1 \par}}{}{}
+}
+\makeatother
+\subtitle{$subtitle$}
+$endif$
+\author{$for(author)$$author$$sep$ \and $endfor$}
+\date{$date$}
+
+\begin{document}
+
+\ProjectCover
+\ProjectHalfTitle
+
+$if(has-frontmatter)$
+\frontmatter
+$endif$
+
+\IfFileExists{pdf/front/impressum.tex}{%
+  \input{pdf/front/impressum.tex}%
+}{}
+
+$for(include-before)$
+$include-before$
+
+$endfor$
+
+$if(toc)$
+$if(toc-title)$
+\renewcommand*\contentsname{$toc-title$}
+$endif$
+{
+$if(colorlinks)$
+\hypersetup{linkcolor=$if(toccolor)$$toccolor$$else$nexttokenlink$endif$}
+$endif$
+\setcounter{tocdepth}{$if(toc-depth)$$toc-depth$$else$2$endif$}
+\tableofcontents
+}
+$endif$
+
+$if(lof)$
+\listoffigures
+$endif$
+$if(lot)$
+\listoftables
+$endif$
+
+$if(linestretch)$
+\setstretch{$linestretch$}
+$endif$
+
+$if(has-frontmatter)$
+\mainmatter
+$endif$
+
+$body$
+
+$if(has-frontmatter)$
+\backmatter
+$endif$
+
+$for(include-after)$
+$include-after$
+
+$endfor$
+
+\end{document}
@@ -0,0 +1,267 @@
+% secure-agents-preamble.tex — Präambel für *Secure Coding Agents with Flue*
+% Portiert und verschlankt aus nexttoken-preamble.tex (ki-hinterm-vorhang).
+% Makros: \ProjectCover, \ProjectHalfTitle, \ProjectCoverImage, \ProjectPartPage
+
+% ===========================================================================
+% 1) FONTS
+% ===========================================================================
+\directlua{
+  luaotfload.add_fallback("secureagentsfb", {"DejaVu Serif:mode=node;"})
+}
+\setmainfont{Charter}[
+  Ligatures=TeX,
+  Scale=MatchLowercase,
+  RawFeature={fallback=secureagentsfb}
+]
+\setsansfont{DejaVu Sans}[
+  Ligatures=TeX,
+  Scale=MatchLowercase
+]
+\setmonofont{DejaVu Sans Mono}[
+  Scale=MatchLowercase
+]
+
+% ===========================================================================
+% 2) KOMA-Script Überschriften
+% ===========================================================================
+\addtokomafont{chapter}{\color{nexttokenblue}\sffamily\bfseries}
+\addtokomafont{part}{\color{nexttokenblue}\sffamily\bfseries}
+\addtokomafont{section}{\color{nexttokenblue}}
+\addtokomafont{subsection}{\color{nexttokengold}}
+\addtokomafont{disposition}{\normalcolor}
+
+\RedeclareSectionCommand[beforeskip=1.8\baselineskip,afterskip=.8\baselineskip]{chapter}
+\RedeclareSectionCommand[beforeskip=1.3\baselineskip,afterskip=.5\baselineskip]{section}
+\RedeclareSectionCommand[beforeskip=1.0\baselineskip,afterskip=.3\baselineskip]{subsection}
+
+% ===========================================================================
+% 3) Kopf-/Fußzeile
+% ===========================================================================
+\usepackage{scrlayer-scrpage}
+\clearpairofpagestyles
+\lehead{\headmark}
+\rohead{\headmark}
+\chead{}
+\cfoot*{\pagemark}
+\setkomafont{pagehead}{\color{nexttokenblue}\sffamily}
+\setkomafont{pagenumber}{\color{nexttokengold}\sffamily\bfseries}
+\KOMAoptions{headsepline=.6pt}
+\addtokomafont{headsepline}{\color{nexttokengold}}
+
+% ===========================================================================
+% 4) TOC
+% ===========================================================================
+\setcounter{tocdepth}{2}
+\setcounter{secnumdepth}{0}
+\setkomafont{partentry}{\color{nexttokenblue}\bfseries\sffamily}
+\setkomafont{chapterentry}{\color{nexttokenblue}\sffamily}
+\KOMAoptions{toc=chapterentrywithdots}
+
+% ===========================================================================
+% 5) Pandoc-Shaded
+% ===========================================================================
+\usepackage{framed}
+\usepackage{color}
+\definecolor{shadecolor}{RGB}{248,248,248}
+
+% ===========================================================================
+% 6) Zitat-Box
+% ===========================================================================
+\usepackage{mdframed}
+\newmdenv[
+  leftline=true,
+  rightline=false,
+  topline=false,
+  bottomline=false,
+  linewidth=2.5pt,
+  linecolor=nexttokengold,
+  backgroundcolor=nexttokenslate!6!white,
+  leftmargin=0pt,
+  rightmargin=0pt,
+  innerleftmargin=12pt,
+  innerrightmargin=6pt,
+  innertopmargin=4pt,
+  innerbottommargin=4pt,
+  skipabove=10pt,
+  skipbelow=10pt
+]{secureagentsquotebox}
+
+\newenvironment{secureagentsquote}
+  {\begin{secureagentsquotebox}\itshape\color{nexttokenslate}}
+  {\end{secureagentsquotebox}}
+
+% ===========================================================================
+% 7) tcolorbox (boxes.lua → nexttoken* env names for filter reuse)
+% ===========================================================================
+\usepackage{tcolorbox}
+\tcbuselibrary{breakable,skins}
+\usepackage{float}
+\usepackage{placeins}
+
+\floatplacement{figure}{htbp}
+\setcounter{topnumber}{3}
+\setcounter{bottomnumber}{2}
+\setcounter{totalnumber}{5}
+\renewcommand{\topfraction}{0.85}
+\renewcommand{\bottomfraction}{0.7}
+\renewcommand{\textfraction}{0.12}
+\renewcommand{\floatpagefraction}{0.7}
+\setlength{\textfloatsep}{12pt plus 3pt minus 2pt}
+\setlength{\floatsep}{10pt plus 2pt minus 2pt}
+\setlength{\intextsep}{10pt plus 2pt minus 2pt}
+
+\newtcolorbox{nexttokenintro}[1]{
+  colback=nexttokenparchment,
+  colframe=nexttokengold,
+  coltext=nexttokentext,
+  boxrule=0.6pt,
+  arc=4pt,
+  left=10pt, right=10pt, top=8pt, bottom=8pt,
+  fontupper=\small,
+  breakable,
+  sharp corners=downhill,
+  title={\sffamily\bfseries\color{nexttokenblue}#1},
+  titlerule=0pt,
+  colbacktitle=nexttokengold!10!white,
+  coltitle=nexttokenblue,
+  title after break={\sffamily\bfseries\color{nexttokenblue}#1\ (continued)}
+}
+
+\newtcolorbox{nexttokensummary}[1]{
+  colback=nexttokenparchment!40,
+  colframe=nexttokenblue,
+  coltext=nexttokentext,
+  boxrule=0.8pt,
+  arc=4pt,
+  left=10pt, right=10pt, top=10pt, bottom=8pt,
+  fontupper=\small,
+  breakable,
+  sharp corners=downhill,
+  title={\sffamily\bfseries\color{nexttokenblue}#1},
+  titlerule=0pt,
+  colbacktitle=nexttokenblue!12!white,
+  coltitle=nexttokenblue,
+  title after break={\sffamily\bfseries\color{nexttokenblue}#1\ (continued)}
+}
+
+\newtcolorbox{nexttokenvertiefung}[1]{
+  colback=nexttokenparchment!92!nexttokengold,
+  colframe=nexttokengold,
+  coltext=nexttokentext,
+  boxrule=0.8pt,
+  arc=4pt,
+  left=10pt, right=10pt, top=10pt, bottom=8pt,
+  fontupper=\small,
+  breakable,
+  sharp corners=downhill,
+  title={\sffamily\bfseries\color{nexttokenblue}#1},
+  titlerule=0pt,
+  colbacktitle=nexttokengold!14!white,
+  coltitle=nexttokenblue,
+  title after break={\sffamily\bfseries\color{nexttokenblue}#1\ (continued)}
+}
+
+\newtcolorbox{nexttokeninfo}[1]{
+  colback=nexttokenblue!6!white,
+  colframe=nexttokenblue,
+  coltext=nexttokentext,
+  boxrule=0.7pt,
+  arc=4pt,
+  left=10pt, right=10pt, top=10pt, bottom=8pt,
+  fontupper=\small,
+  breakable,
+  sharp corners=downhill,
+  title={\sffamily\bfseries\color{nexttokenblue}#1},
+  titlerule=0pt,
+  colbacktitle=nexttokenblue!12!white,
+  coltitle=nexttokenblue,
+  title after break={\sffamily\bfseries\color{nexttokenblue}#1\ (continued)}
+}
+
+% ===========================================================================
+% 8) Cover- und Part-Page-Befehle
+% ===========================================================================
+\usepackage{eso-pic}
+
+\newcommand{\ProjectHalfTitle}{%
+  \clearpage
+  \thispagestyle{empty}%
+  \null
+  \vspace*{0.28\textheight}%
+  \begin{center}
+    {\sffamily\color{nexttokengold}\Large\bfseries\MakeUppercase{Secure Coding Agents with Flue}\par}
+    \vspace{0.7cm}
+    \rule{0.35\textwidth}{0.8pt}\par
+    \vspace{0.7cm}
+    {\sffamily\color{nexttokenblue}\LARGE\bfseries Enterprise-ready Data Protection,\par
+     \vspace{0.15cm} Logging \& Compliance Patterns\par}
+    \vspace{1.6cm}
+    {\sffamily\color{nexttokentext}\large Martin Richardt\par}
+  \end{center}
+  \vfill
+  \clearpage
+}
+
+\newcommand{\ProjectCoverImage}[1]{%
+  \AddToShipoutPictureBG*{%
+    \AtPageLowerLeft{%
+      \includegraphics[width=\paperwidth,height=\paperheight]{#1}%
+    }%
+  }%
+  \null\vfill
+}
+
+\newcommand{\ProjectCover}{%
+  \begin{titlepage}
+    \thispagestyle{empty}%
+    \IfFileExists{assets/cover/cover.jpg}{%
+      \ProjectCoverImage{assets/cover/cover.jpg}%
+    }{%
+      \IfFileExists{assets/cover/cover.png}{%
+        \ProjectCoverImage{assets/cover/cover.png}%
+      }{%
+        \centering
+        \vspace*{1.5cm}
+        {\sffamily\color{nexttokengold}\Large\bfseries\MakeUppercase{Secure Coding Agents with Flue}\par}
+        \vspace{0.6cm}
+        \rule{0.5\textwidth}{1.2pt}\par
+        \vspace{0.8cm}
+        {\sffamily\color{nexttokenblue}\Huge\bfseries Enterprise-ready Data Protection,\par
+         \vspace{0.2cm} Logging \& Compliance Patterns\par}
+        \vspace{0.8cm}
+        \rule{0.5\textwidth}{1.2pt}\par
+        \vspace{1.0cm}
+        {\sffamily\color{nexttokentext}\Large Security patterns for coding agents\par}
+        \vfill
+        {\sffamily\color{nexttokenslate}\footnotesize Martin Richardt\par}
+      }%
+    }%
+  \end{titlepage}
+}
+
+% \ProjectPartPage{nr}{title}{image path} — reserved for later manuscript parts
+\newcommand{\ProjectPartPage}[3]{%
+  \cleardoubleoddpage
+  \thispagestyle{empty}%
+  \begingroup
+  \centering
+  \vspace*{0.5cm}%
+  {\sffamily\color{nexttokengold}\Huge\bfseries Teil #1\par}%
+  \vspace{0.35cm}%
+  \rule{0.4\textwidth}{1.2pt}\par
+  \vspace{0.4cm}%
+  {\sffamily\color{nexttokenblue}\huge\bfseries #2\par}%
+  \vspace{0.45cm}%
+  \IfFileExists{#3}{%
+    \includegraphics[width=0.92\textwidth,height=0.72\textheight,keepaspectratio]{#3}\par
+  }{%
+    \fbox{\parbox{0.92\textwidth}{\centering\vspace{1.4cm}%
+      \sffamily\color{nexttokenslate}\small (Teil-Bild folgt: #3)\par
+      \vspace{1.4cm}}\par}%
+  }%
+  \vfill
+  \endgroup
+  \clearpage
+}
+
+\AtBeginDocument{\color{nexttokentext}\raggedbottom}
@@ -0,0 +1,148 @@
+#!/usr/bin/env python3
+"""Assemble *Secure Coding Agents with Flue* from manuskript/*.md sources.
+
+Reads chapters in fixed CHAPTER_ORDER, injects optional Part-Pages,
+writes build/book.md. Source files are never modified.
+
+CLI:
+    python3 scripts/assemble_book.py [--out PATH]
+"""
+
+from __future__ import annotations
+
+import argparse
+import pathlib
+import re
+
+REPO_ROOT = pathlib.Path(__file__).resolve().parent.parent
+SOURCE_DIR = REPO_ROOT / "manuskript"
+BUILD_DIR = REPO_ROOT / "build"
+DEFAULT_TARGET = BUILD_DIR / "book.md"
+
+CHAPTER_ORDER = [
+    ("prolog.md", "body"),
+    ("kapitel-01-warum-sichere-agents.md", "body"),
+    ("kapitel-02-flue-architektur.md", "body"),
+    ("kapitel-03-bedrohungsmodell.md", "body"),
+    ("kapitel-04-datenfluss-llm.md", "body"),
+    ("kapitel-05-dlp-pattern-matching.md", "body"),
+    ("kapitel-06-entropie-filter.md", "body"),
+    ("kapitel-07-sandbox-strategien.md", "body"),
+    ("kapitel-08-tool-permissions.md", "body"),
+    ("kapitel-09-logging-audit.md", "body"),
+    ("kapitel-10-enterprise-patterns.md", "body"),
+    ("kapitel-11-betrieb-playbooks.md", "body"),
+    ("epilog.md", "body"),
+    ("glossar.md", "body"),
+    ("literatur.md", "body"),
+    ("ueber-den-autor.md", "body"),
+    ("kolophon.md", "body"),
+]
+
+BACKMATTER_BEFORE = {"glossar.md"}
+
+# Part dividers (images optional — placeholder if missing)
+PART_BEFORE = {
+    "kapitel-01-warum-sichere-agents.md": (
+        1,
+        "Grundlagen",
+        "assets/parts/teil-01.png",
+    ),
+    "kapitel-04-datenfluss-llm.md": (
+        2,
+        "Datenschutz und DLP",
+        "assets/parts/teil-02.png",
+    ),
+    "kapitel-07-sandbox-strategien.md": (
+        3,
+        "Isolation und Runtime",
+        "assets/parts/teil-03.png",
+    ),
+    "kapitel-09-logging-audit.md": (
+        4,
+        "Compliance und Betrieb",
+        "assets/parts/teil-04.png",
+    ),
+}
+
+FIGURE_MARKERS: dict[str, list[str]] = {}
+
+_H1_RE = re.compile(r"^#\s+(.*?)\s*$")
+
+
+def first_h1_title(text: str) -> str | None:
+    for line in text.splitlines():
+        m = _H1_RE.match(line)
+        if m:
+            return m.group(1)
+    return None
+
+
+def make_part_page_block(number: int, title: str, image: str) -> str:
+    return (
+        "```{=latex}\n"
+        f"\\ProjectPartPage{{{number}}}{{{title}}}{{{image}}}\n"
+        "```\n"
+    )
+
+
+def assemble(out_path: pathlib.Path) -> None:
+    BUILD_DIR.mkdir(parents=True, exist_ok=True)
+
+    parts: list[str] = []
+    for filename, kind in CHAPTER_ORDER:
+        src = SOURCE_DIR / filename
+        if not src.exists():
+            raise SystemExit(f"Quelldatei nicht gefunden: {src}")
+
+        if filename in PART_BEFORE:
+            number, title, image = PART_BEFORE[filename]
+            parts.append(make_part_page_block(number, title, image))
+
+        if filename in BACKMATTER_BEFORE:
+            parts.append("```{=latex}\n\\backmatter\n```")
+
+        if kind == "part":
+            pass
+
+        content = src.read_text(encoding="utf-8").rstrip("\n")
+
+        if content.startswith("---"):
+            end = content.find("\n---", 3)
+            if end != -1:
+                content = content[end + 4 :].lstrip("\n")
+
+        parts.append(content)
+        for marker in FIGURE_MARKERS.get(filename, []):
+            if marker in content:
+                continue
+            parts.append("")
+            parts.append(marker)
+
+    book_md = "\n\n".join(parts).strip() + "\n"
+    out_path.write_text(book_md, encoding="utf-8")
+
+    n_parts = len(PART_BEFORE)
+    print(
+        f"Assembliert: {len(CHAPTER_ORDER)} Dateien "
+        f"({n_parts} Part-Pages) -> {out_path}"
+    )
+
+
+def main() -> int:
+    parser = argparse.ArgumentParser(
+        description="Assemble Secure Coding Agents with Flue into build/book.md"
+    )
+    parser.add_argument(
+        "--out",
+        type=pathlib.Path,
+        default=DEFAULT_TARGET,
+        help="Output path (default: build/book.md)",
+    )
+    args = parser.parse_args()
+    assemble(args.out)
+    return 0
+
+
+if __name__ == "__main__":
+    raise SystemExit(main())
@@ -0,0 +1,202 @@
+#!/usr/bin/env python3
+"""Build the book cover: art base + precise typography overlay.
+
+Requires: Pillow (pip install pillow)
+Art base: assets/cover/cover-art.jpg  (text-free background)
+Output:   assets/cover/cover.jpg, cover-hires.png, cover-web.jpg
+"""
+
+from __future__ import annotations
+
+from pathlib import Path
+
+from PIL import Image, ImageDraw, ImageEnhance, ImageFilter, ImageFont
+
+ROOT = Path(__file__).resolve().parents[1]
+ART = ROOT / "assets" / "cover" / "cover-art.jpg"
+OUT = ROOT / "assets" / "cover"
+
+W, H = 1600, 2400
+
+# macOS system fonts (same approach as ki-hinterm-vorhang)
+BASK = "/System/Library/Fonts/Supplemental/Baskerville.ttc"
+AVEN = "/System/Library/Fonts/Avenir Next.ttc"
+HELV = "/System/Library/Fonts/Helvetica.ttc"
+
+# --- tunable layout (fractions of canvas height) ---------------------------
+KICKER_Y = 0.078
+TITLE_Y = 0.125
+TITLE_SIZE = 62
+SUB_SIZE = 23
+TAG_SIZE = 16
+AUTHOR_SIZE = 26
+AUTHOR_Y = 0.875
+YEAR_Y = 0.925
+
+
+def font(path: str, index: int, size: int) -> ImageFont.FreeTypeFont:
+    return ImageFont.truetype(path, size=size, index=index)
+
+
+def main() -> None:
+    if not ART.exists():
+        raise SystemExit(f"Missing art base: {ART}")
+
+    bg = Image.open(ART).convert("RGBA").resize((W, H), Image.Resampling.LANCZOS)
+
+    # Soft readability veil behind the title block only
+    panel = Image.new("RGBA", (W, H), (0, 0, 0, 0))
+    pd = ImageDraw.Draw(panel)
+    pd.rounded_rectangle([120, 140, W - 120, 720], radius=40, fill=(4, 10, 24, 92))
+    panel = panel.filter(ImageFilter.GaussianBlur(48))
+    base = Image.alpha_composite(bg, panel)
+
+    # Soft veil for author/footer band
+    foot = Image.new("RGBA", (W, H), (0, 0, 0, 0))
+    fd = ImageDraw.Draw(foot)
+    fd.rounded_rectangle([200, int(H * 0.84), W - 200, int(H * 0.97)], radius=28, fill=(4, 10, 24, 70))
+    foot = foot.filter(ImageFilter.GaussianBlur(28))
+    base = Image.alpha_composite(base, foot)
+
+    # Baskerville: 0 Regular, 1 Bold, 4 SemiBold
+    # Avenir Next: 5 Medium, 7 Regular, 10 Ultra Light
+    title_f = font(BASK, 4, TITLE_SIZE)
+    sub_f = font(AVEN, 5, SUB_SIZE)
+    kicker_f = font(AVEN, 5, 16)
+    tag_f = font(AVEN, 7, TAG_SIZE)
+    author_f = font(AVEN, 5, AUTHOR_SIZE)
+    year_f = font(AVEN, 7, 15)
+
+    WHITE = (238, 242, 248, 252)
+    SUB = (186, 204, 222, 230)
+    KICKER = (100, 210, 230, 220)
+    TAG = (130, 170, 185, 175)
+    AUTHOR = (220, 228, 238, 245)
+    YEAR = (120, 150, 170, 160)
+    CYAN = (0, 212, 255, 210)
+    EMERALD = (42, 157, 143, 180)
+    LINE = (160, 195, 210, 140)
+
+    layer = Image.new("RGBA", (W, H), (0, 0, 0, 0))
+    draw = ImageDraw.Draw(layer)
+
+    def measure(fnt, text: str) -> tuple[int, int]:
+        b = draw.textbbox((0, 0), text, font=fnt)
+        return b[2] - b[0], b[3] - b[1]
+
+    def draw_text(x, y, text, fnt, fill, shadow=True):
+        if shadow:
+            draw.text((x + 1, y + 2), text, font=fnt, fill=(0, 0, 0, 100))
+        draw.text((x, y), text, font=fnt, fill=fill)
+
+    def draw_centered(y, text, fnt, fill, tracking=0, shadow=True) -> int:
+        if tracking <= 0:
+            w, h = measure(fnt, text)
+            draw_text((W - w) // 2, y, text, fnt, fill, shadow=shadow)
+            return h
+        chars = list(text)
+        widths = [measure(fnt, c)[0] for c in chars]
+        total = sum(widths) + tracking * max(len(chars) - 1, 0)
+        x = (W - total) // 2
+        h = measure(fnt, text)[1]
+        for c, cw in zip(chars, widths):
+            draw_text(x, y, c, fnt, fill, shadow=shadow)
+            x += cw + tracking
+        return h
+
+    def draw_lines(y, lines, fnt, fill, gap=8) -> int:
+        th = 0
+        for line in lines:
+            h = draw_centered(y + th, line, fnt, fill)
+            th += h + gap
+        return th
+
+    def rule(y, width, with_dot=False):
+        rx = (W - width) // 2
+        if with_dot:
+            gap = 11
+            draw.line([(rx, y), (W // 2 - gap, y)], fill=LINE, width=1)
+            draw.line([(W // 2 + gap, y), (rx + width, y)], fill=LINE, width=1)
+            cx = W // 2
+            draw.ellipse([cx - 3.2, y - 3.2, cx + 3.2, y + 3.2], outline=CYAN, width=1)
+            draw.ellipse([cx - 1.2, y - 1.2, cx + 1.2, y + 1.2], fill=CYAN)
+        else:
+            draw.line([(rx, y), (rx + width, y)], fill=LINE, width=1)
+
+    # 1) Kicker
+    y = int(H * KICKER_Y)
+    draw_centered(y, "SECURITY ENGINEERING", kicker_f, KICKER, tracking=10, shadow=False)
+    kw = measure(kicker_f, "SECURITY ENGINEERING")[0] + 10 * 20
+    kx = (W - kw) // 2
+    draw.line([(kx, y + 26), (kx + kw, y + 26)], fill=CYAN, width=1)
+
+    # 2) Title — two lines
+    y = int(H * TITLE_Y)
+    th = 0
+    for i, line in enumerate(["Secure Coding Agents", "with Flue"]):
+        size = TITLE_SIZE if i == 0 else int(TITLE_SIZE * 0.88)
+        fnt = font(BASK, 4, size)
+        h = draw_centered(y + th, line, fnt, WHITE, tracking=0.4)
+        th += h + (10 if i == 0 else 0)
+
+    # 3) Divider
+    y_rule = y + th + 24
+    rule(y_rule, 120, with_dot=True)
+
+    # 4) Subtitle
+    y_sub = y_rule + 26
+    sh = draw_lines(
+        y_sub,
+        [
+            "Enterprise-ready Data Protection,",
+            "Logging & Compliance Patterns",
+        ],
+        sub_f,
+        SUB,
+        gap=7,
+    )
+
+    # 5) Thematic tags
+    y_tag = y_sub + sh + 22
+    draw_centered(
+        y_tag,
+        "DLP  ·  Sandbox  ·  Audit",
+        tag_f,
+        TAG,
+        tracking=2,
+        shadow=False,
+    )
+    # subtle emerald accent under tags
+    tw = measure(tag_f, "DLP  ·  Sandbox  ·  Audit")[0]
+    draw.line(
+        [((W - tw) // 2, y_tag + 28), ((W + tw) // 2, y_tag + 28)],
+        fill=EMERALD,
+        width=1,
+    )
+
+    # 6) Author
+    y_author = int(H * AUTHOR_Y)
+    rule(y_author - 20, 64, with_dot=False)
+    draw_centered(y_author, "Martin Richardt", author_f, AUTHOR)
+
+    # 7) Year
+    draw_centered(int(H * YEAR_Y), "2026", year_f, YEAR, tracking=10, shadow=False)
+
+    rgb = Image.alpha_composite(base, layer).convert("RGB")
+    rgb = ImageEnhance.Contrast(rgb).enhance(1.03)
+    rgb = ImageEnhance.Color(rgb).enhance(1.04)
+
+    OUT.mkdir(parents=True, exist_ok=True)
+    rgb.save(OUT / "cover-hires.png", "PNG")
+    rgb.save(OUT / "cover.jpg", "JPEG", quality=93, optimize=True, progressive=True)
+    mid = rgb.resize((800, 1200), Image.Resampling.LANCZOS)
+    mid.save(OUT / "cover-web.jpg", "JPEG", quality=88, optimize=True)
+    print(f"Wrote {OUT / 'cover.jpg'} ({W}×{H})")
+    print(
+        f"sizes: title={TITLE_SIZE} sub={SUB_SIZE} author={AUTHOR_SIZE} "
+        f"| author_y={AUTHOR_Y:.0%} tags='DLP · Sandbox · Audit'"
+    )
+
+
+if __name__ == "__main__":
+    main()