Tighten appendices, add Product Gates, rebuild PDF.

Condense framework and onboarding material, clarify threat-model scope, and document project-side verify pipelines for agent merges; sync design notes, DE sandbox diagram labels, HANDOFF, and the book PDF.
2026-08-07 19:14:14 +02:00
1 parent 091966e4f5
commit d921e7d2c2
@@ -0,0 +1,196 @@
+# Handoff — Secure Coding Agents with Flue
+
+**Stand:** 2026-08-07  
+**Branch:** `main` (ahead of last commit; **uncommitted** P0+P1 + Product-Gates)  
+**Repo:** `/Volumes/SSD2TB/books/ki-agent`  
+**Letzter Commit (vor offenen Edits):** `091966e` Retitle cover to Secure Coding Agents with Flue secondary.
+
+---
+
+## Was das Projekt ist
+
+Fachbuch (DE) *Secure Coding Agents with Flue* (Richardt, 2026): Agent-Harness-
+Security (DLP, Sandbox, Permissions, Audit, Enterprise). Pipeline: Pandoc +
+LuaLaTeX → `dist/secure-coding-agents-flue.pdf` (`just pdf`).
+
+Quellen: `manuskript/` · Design: `design/` · Abbildungen: `bilder/diagrams/`,
+`pics/` · Build: `scripts/assemble_book.py`, `justfile`.
+
+---
+
+## Erledigt in dieser Arbeitsphase
+
+### Inhaltsanalyse (Plan freigegeben)
+
+- Kernkapitel **nicht** pauschal vereinfachen (1–11 angemessen).
+- Hauptproblem: **Anhänge zu schwer** vs. Kern; überlappende Einführungspläne;
+  G-Framing veraltet; vage Literatur; Kap. 7–8 Happy-Path-Redundanz.
+- Zielbalance: Kern ~55–60 % / Anhänge ~40–45 % (Richtung, kein Zwang pro %).
+
+### P0 — Sofort-Paket (umgesetzt, uncommitted)
+
+| # | Maßnahme | Dateien |
+|---|----------|---------|
+| 1 | Anhang-Matrix + kanonischer Strang H→G→B/C | `manuskript/prolog.md` |
+| 2 | G: „Buch-Schwächen“ → bewusste Grenzen; Titel operativ | `appendix-g-…`, `design/einfuehrungs-paket-30-tage.md` (Sync) |
+| 3 | Kap. 3: Out-of-Scope-Box → A; OWASP LLM Top 10 Mapping | `kapitel-03-bedrohungsmodell.md` |
+| 4 | Literatur: konkrete URLs (Scanner, MCP, gVisor, SSDF, OTel, …) | `literatur.md` |
+| 5 | Kap. 7–8: Happy/Fail konsolidiert (Tabellen/knapp) | `kapitel-07…`, `kapitel-08…` |
+
+### P1 — Kurzfristig (umgesetzt, uncommitted)
+
+| # | Maßnahme | Dateien |
+|---|----------|---------|
+| 6 | Anhang E ~5 800 → ~1 720 Wörter; Geltungsstand + Verfall ≤12 Monate | `appendix-e-alternativen-frameworks.md` |
+| 7 | 30/60/90 nur G (+H) ausführlich; B/C/D → Kurzskizze + Verweis | `appendix-b/c/d-…` |
+| 8 | Kap. 10 kurzes Mapping; C kanonische Detailtabelle; Typo F→**G** | `kapitel-10…`, `appendix-c…` |
+| 9 | Diagramm-Labels DE (Sandbox); Policy dokumentiert; F06 neu gerendert | `scripts/render_all_diagrams.py`, `render_p1…`, `design/diagram-workflow.md`, `bilder/diagrams/fig-sandbox-levels.jpg`, `pics/F06-…` |
+| 10 | Schnellnavigation Parts I–V im Prolog | `manuskript/prolog.md` |
+
+### PDF-Build (Stichprobe OK)
+
+- `just import-pics && just pdf` → `dist/secure-coding-agents-flue.pdf`
+- **188 Seiten**, ~3,8 MB, Exit 0 (Stand vor Product-Gates-Text; **PDF neu bauen** nach Verify-Abschnitt)
+
+### P2 / Product Gates — Hybrid D (umgesetzt, uncommitted)
+
+**Befund:** Harness-Verifikation war gut; **Produktcode-Verifikation** (Coverage,
+Mutation, Types, Kontrakte, Complexity) fehlte thematisch.
+
+**Entscheidung User:** Hybrid D, Haupttext Kap. 8, Normativität =
+Kalibrierungsbasis (wie Anhang B).
+
+| # | Maßnahme | Dateien |
+|---|----------|---------|
+| 11 | Kap. 8: Abschnitt *Von Tool-Rechten zu Merge-Rechten* (~910 Wörter): zwei Ebenen, Verify-Pipeline, Change-Risk C0–C4, Coverage-Δ/Mutation/Types/Kontrakte, Anti-Pattern, Happy/Fail | `kapitel-08-tool-permissions.md` |
+| 12 | Anker Prolog + Kap. 1 Fehlannahme + Lesepfad | `prolog.md`, `kapitel-01-…` |
+| 13 | Kap. 10 Evidence + Mapping-Zeile Merges | `kapitel-10-…` |
+| 14 | Product-Verify-SLIs (6 Zeilen) | `appendix-b-…` |
+| 15 | DoD Mindest-Verify-Pipeline + Non-DoD Mutation-Monorepo | `appendix-g-…`, `design/einfuehrungs-paket-30-tage.md` |
+| 16 | Glossar: Change-Risk, Contract-Test, Coverage-Δ, Mutation, Product Gates, Produkt-Kontrakt, Property-based | `glossar.md` |
+| 17 | Literatur: ASVS, Mutation-Survey, TS typecheck (+ Verweis SSDF #15) | `literatur.md` |
+
+### Bewusste Nicht-Ziele dieser Phase
+
+- Keine pauschale Kürzung Kap. 1–11.
+- Keine neue Figur D5–D12 (war „ggf.“).
+- Kein Legal-Fachreview, **kein Commit** (User hat nicht gebeten).
+- Kein Testmethodik-Lehrbuch; kein Anhang I; kein paralleler 90-Tage-Testplan.
+
+---
+
+## Kanonische Lesestränge (nicht erneut umbauen)
+
+1. **Startup:** Prolog → Kap. 1–2 skimming → **Anhang H** (2 Wochen) → bei Bedarf Kap. 5/8/9 → später 10/G  
+2. **Einführung:** **Anhang G** (30 Tage, DoD)  
+3. **Messung / Audit-Tiefe:** **B** / **C** (Methodik, nicht zweiter 90-Tage-Plan)  
+4. **Framework-Wahl:** **E** (kurz, verfällt); Mapping Flue-Nähte: **F** (optional)
+
+---
+
+## Offene Arbeit (priorisiert)
+
+### Als Nächstes (empfohlen)
+
+1. **PDF neu bauen** und Stichprobe (Product Gates in Kap. 8, Glossar, B-SLIs, G-DoD):
+   ```bash
+   just import-pics && just pdf
+   ```
+2. **Commit** — empfohlen getrennte oder klar beschriebene Commits:
+   - P0+P1 Inhaltsarbeit
+   - Product Gates (Kap. 8 + Anker)
+   - Diagramme  
+   Nur nach User-OK.
+
+### Später / vor Publikation
+
+| Thema | Hinweis |
+|-------|---------|
+| Anhang A weiter optional straffen | noch ~4 200 Wörter; nicht P0/P1 |
+| Kap. 11 Playbooks | optional A/E+Break-glass im Kern, B–D/F als Karten |
+| Kap. 4 / 5–6 | leichte Straffung optional |
+| Break-glass / policy_version in Anhängen | Kernbotschaft 1×, Anhänge ausdünnen |
+| Diagramme | übrige EN-Reste nur wo nötig |
+| TOC im PDF | Parts sichtbar? |
+| Legal-Fachreview | DSGVO/AI-Act (`expose.md`) |
+| Klappentext final | `design/klappentext.md` |
+| LoF | reaktivieren wenn Counter stabil |
+| Lektorat Runde 3 | Lautlesen Prolog + Kap. 4–6; **neu:** Kap. 8 Product Gates |
+
+---
+
+## Geänderte Dateien (Working Tree)
+
+```
+manuskript/prolog.md
+manuskript/kapitel-01-warum-sichere-agents.md
+manuskript/kapitel-03-bedrohungsmodell.md
+manuskript/kapitel-07-sandbox-strategien.md
+manuskript/kapitel-08-tool-permissions.md
+manuskript/kapitel-10-enterprise-patterns.md
+manuskript/literatur.md
+manuskript/glossar.md
+manuskript/appendix-b-empirie-quantifizierung.md
+manuskript/appendix-c-audit-freigabe-reife.md
+manuskript/appendix-d-developer-experience.md
+manuskript/appendix-e-alternativen-frameworks.md
+manuskript/appendix-g-einfuehrungs-paket-30-tage.md
+design/einfuehrungs-paket-30-tage.md
+design/diagram-workflow.md
+scripts/render_all_diagrams.py
+scripts/render_p1_diagrams.py
+bilder/diagrams/fig-sandbox-levels.jpg
+pics/F06- Sandbox-Strategiestufen (1–5).png
+HANDOFF.md   ← diese Datei
+```
+
+---
+
+## Wortumfang (Orientierung)
+
+| Segment | ca. Wörter |
+|---------|------------|
+| Gesamtes `manuskript/*.md` | ~53 000 |
+| Kap. 8 (inkl. Product Gates ~910) | ~3 470 |
+| E | ~1 720 (war ~5 800) |
+
+---
+
+## Entscheidungsregeln für Folgesessions
+
+- **H → G** ist der einzige ausführliche Einführungszeitplan; B/C/D nur Methodik-Skizzen.
+- Kap. 10 = Patterns + **kurzes** Audit-Mapping; Anhang C = Evidence 2.0 + **Detail-Mapping**.
+- E = Dimensionen + Kurzprofile + Leitfaden; keine Feature-Changelogs im Buch.
+- Security-Tiefe der Kernkapitel nicht abflachen.
+- **Product Gates** = Kap. 8; Harness-Contract-Test ≠ Produkt-Kontrakt (Glossar).
+- Change-Risk **C0–C4** parallel zu Tool-Risk **R0–R4**, anderer Gegenstand (Merge vs. Tool).
+- `design/einfuehrungs-paket-30-tage.md` bei G-Änderungen mitziehen.
+- Diagramm-Policy: DE-Labels; technische IDs neutral — `design/diagram-workflow.md`.
+
+---
+
+## Kopierbarer Einstiegs-Prompt (neue Session)
+
+```
+Projekt: /Volumes/SSD2TB/books/ki-agent (Buch Secure Coding Agents with Flue).
+Lies HANDOFF.md. Branch main, uncommitted: P0+P1 + Product Gates (Kap. 8
+Verify-Pipeline, Change-Risk C0–C4, Anker Prolog/1/10, B-SLIs, G-DoD, Glossar).
+
+Nächste Aufgabe: [PDF bauen und prüfen | committen | P2-Thema X].
+Nicht erneut: pauschale Vereinfachung Kap.1–11; parallele 90-Tage-Pläne in B/C/D;
+E wieder aufblasen; Product Gates zu Test-Lehrbuch aufblasen.
+```
+
+---
+
+## Build-Kurzreferenz
+
+```bash
+just cover          # optional
+just import-pics    # pics → bilder
+just assemble       # → build/book.md
+just pdf            # → dist/secure-coding-agents-flue.pdf
+just pdf-sample     # Prolog + Kap. 1–2
+```
+
+Diagramme neu: `cd scripts && python3 render_all_diagrams.py` dann `just import-pics`.
@@ -12,6 +12,14 @@ Ziel: **schick** (Deep Signal) und **inhaltlich korrekt** (Manuskript-Labels).

 **Nicht:** Gesamtdiagramm mit 15+ Wörtern aus dem Bildmodell erzeugen und hoffen.

+
+## Label-Sprache (Policy)
+
+- **Fließtext und Box-Labels in den Abbildungen: Deutsch** (z. B. Prozessisolation, Netzwerk-Policy, Happy Path / Abweichung als Buch-Termini).
+- **Technische IDs bleiben englisch/neutral:** `Z0`–`Z4`, `R0`–`R4`, `policy_version`, `session_id`, `ALLOW`/`DENY` wo sie Event-Werte sind.
+- Quelle der Wahrheit: Manuskript-Kapitel + diese Renderer (`scripts/render_all_diagrams.py`). Keine EN-Marketing-Labels in Diagrammen.
+
+
 ## Austausch in 6 Schritten

 ```text
@@ -1,7 +1,9 @@
-# Schwächen-resistentes Einführungs-Paket (30 Tage)
+# Operatives Einführungs-Paket (30 Tage)

 Begleitdokument zu *Secure Coding Agents with Flue* (Martin Richardt, 2026).  
-**Zweck:** die bekannten Buch-Schwächen (Credentials, fehlende Fallstudien, kein Production-Code, DACH/Enterprise-Bias, junges Flue, Tabellen-Dichte) **operativ abfedern** – nicht das Buch nacherzählen.
+**Zweck:** die **bewussten Grenzen** des Buchs (keine org-eigenen Zahlen, kein
+drop-in Production-Code, framework-agnostische Patterns) in 30 Tagen operational
+schließen – nicht das Buch nacherzählen und nicht als „Buch-Schwächen“-Katalog.

 **Buch-Fassung:** `manuskript/appendix-g-einfuehrungs-paket-30-tage.md` (Anhang G im PDF).  
 Inhaltlich spiegeln; bei Abweichungen gilt die Manuskript-Fassung für den Build.
@@ -9,7 +11,7 @@ Inhaltlich spiegeln; bei Abweichungen gilt die Manuskript-Fassung für den Build
 | Feld | Inhalt |
 |------|--------|
 | **Audience** | Platform (Implementierung), Security (Policy/Risiko), Engineering (Tool-Surface, Adoption), On-call (Betrieb) |
-| **Doc-Version** | `v1.1.0` |
+| **Doc-Version** | `v1.2.0` |
 | **policy_version** | Living Doc: jede inhaltliche Änderung an Controls, Checklisten oder DoD erhöht die Version und wird im Changelog/PR festgehalten |
 | **Framework** | agnostisch (Flue, Mastra, Eve, Sandcastle, Eigenbau) – Nahtstellen, keine Vendor-APIs |
 | **Kanonische Ablage** | Manuskript (Anhang G) + dieses Design-Doc; Notion/Linear nur als Spiegel |
@@ -18,7 +20,7 @@ Inhaltlich spiegeln; bei Abweichungen gilt die Manuskript-Fassung für den Build

 ## 1. Kurzfassung der Strategie

-Nutze das Buch als **Kontroll- und Betriebs-Landkarte**, nicht als fertige Implementierung oder Case-Study-Quelle. Ersetze fehlende Zahlen und Production-Code durch **eigene Shadow-Messungen und Artefakte ab Tag 1**. Mappe die Nahtstellen framework-agnostisch: **Context Gate → DLP/Entropie → Gateway → Permission → Sandbox → Output-DLP**. Lies selektiv (Kap. 1–3, 4–8, 9, 11; Kap. 10 und Anhänge nur bei Bedarf). Führe Checklisten als **versioniertes Living Document** mit Owner und wöchentlichem Review. Implementiere in **vier Wochen iterativ** (messen → shadow → sandbox/kill → warn/break-glass), nicht als Big-Bang-Freigabe. Enforce nur nach Shadow-Baseline, FP-Stichprobe und Security-Freigabe. Erfolg nach 30 Tagen ist **messbare Kontrolle auf realen Agent-Pfaden**, nicht Zertifizierung oder Framework-Lock-in.
+Nutze das Buch als **Kontroll- und Betriebs-Landkarte**, nicht als fertige Implementierung für deine Organisation. Eigene Zahlen und Production-Artefakte entstehen durch **Shadow-Messungen und Nahtstellen-Arbeit ab Tag 1** (Fallstudien-Rahmen: Anhang B). Mappe die Nahtstellen framework-agnostisch: **Context Gate → DLP/Entropie → Gateway → Permission → Sandbox → Output-DLP**. Lies selektiv (Kap. 1–3, 4–8, 9, 11; Kap. 10 und Anhänge nur bei Bedarf; Startup: zuerst Anhang H). Führe Checklisten als **versioniertes Living Document** mit Owner und wöchentlichem Review. Implementiere in **vier Wochen iterativ** (messen → shadow → sandbox/kill → warn/break-glass), nicht als Big-Bang-Freigabe. Enforce nur nach Shadow-Baseline, FP-Stichprobe und Security-Freigabe. Erfolg nach 30 Tagen ist **messbare Kontrolle auf realen Agent-Pfaden**, nicht Zertifizierung oder Framework-Lock-in.

 ---

@@ -235,16 +237,19 @@ Muster, keine Firmen-Retellings.

 ---

-## 6. Risiken & Gegenmaßnahmen beim Einführen trotz der Buch-Schwächen
+## 6. Risiken & Gegenmaßnahmen an den bewussten Grenzen des Buchs

-| Buch-Schwäche / Risiko | Symptom im Projekt | Gegenmaßnahme (dieses Paket) |
-|------------------------|--------------------|------------------------------|
-| **Fehlende Fallstudien / Zahlen** | Stakeholder fordern „Beweis“, Roadmap stoppt | Eigene Baseline in 30 Tagen: SLIs, Shadow-Metriken, Kill-Switch-Protokoll aus *eurem* Traffic |
-| **Kein Prod-Code im Buch** | Spielzeug-Demos; Prod-Nahtstellen unkartiert | DoD: Nahtstellen-Map + 8 MVC an realen Tools/CI/Repos |
-| **Enterprise- / DACH-Bias** | Kleine Teams kopieren Gremien; Monate Verzug | Schlanke Owner-Liste; ISO nur Evidence-Brücke; Fokus P0-MVC + Playbooks |
-| **Junges Framework (z. B. Flue Beta)** | API-Brüche, Lock-in-Angst blockiert Start | Framework-agnostische Controls; dünne Adapter; kein Lock-in in der DoD |
-| **Tabellen-Überlast** | Schein-Compliance, Overwhelm | Kurze Living Checklists; P0 enforce oder begründet deferred; Rest → 60-Tage-Backlog |
-| **Begrenzte Autor-Credentials** | Security/Legal blockiert oder ignoriert | Explizite DoD und Non-DoD; Ticket+TTL; Evidence ohne Legal-Freigabe als 30-Tage-Ziel |
+Das Buch liefert Patterns und illustrative Empirie (Anhang B) – **keine**
+org-eigene Baseline und **keinen** drop-in Production-Code.
+
+| Grenze / Risiko | Symptom im Projekt | Gegenmaßnahme (dieses Paket) |
+|-----------------|--------------------|------------------------------|
+| **Keine org-eigenen Zahlen im Buch** | Stakeholder fordern „Beweis“, Roadmap stoppt | Eigene Baseline in 30 Tagen: SLIs, Shadow-Metriken, Kill-Switch-Protokoll aus *eurem* Traffic |
+| **Code-Skizzen, kein drop-in Prod-Code** | Spielzeug-Demos; Prod-Nahtstellen unkartiert | DoD: Nahtstellen-Map + 8 MVC an realen Tools/CI/Repos |
+| **Enterprise-Lesart wirkt schwergewichtig** | Kleine Teams kopieren Gremien; Monate Verzug | Schlanke Owner-Liste; ISO nur Evidence-Brücke; Fokus P0-MVC + Playbooks; Start ggf. über Anhang H |
+| **Junges / wechselndes Framework (z. B. Flue)** | API-Brüche, Lock-in-Angst blockiert Start | Framework-agnostische Controls; dünne Adapter; kein Lock-in in der DoD |
+| **Tabellen- und Checklisten-Dichte** | Schein-Compliance, Overwhelm | Kurze Living Checklists; P0 enforce oder begründet deferred; Rest → 60-Tage-Backlog |
+| **Recht/Audit bleiben Fachentscheid** | Security/Legal blockiert oder ignoriert | Explizite DoD und Non-DoD; Ticket+TTL; Evidence ohne Legal-Freigabe als 30-Tage-Ziel |
 | **Over-engineering** | Voll-DLP, Multi-Region, Enterprise-IAM vor erstem Shadow-Run | Schmaler 30-Tage-Muss: Map, Shadow, P0, SLIs, Game day, Break-glass |
 | **Shadow-Mode ohne Labels** | Shadow läuft, niemand sieht FP/Coverage/Bypass | Labels + Owner; wöchentlicher Report; Enforce vs. deferred mit Begründung |

@@ -262,6 +267,8 @@ Muster, keine Firmen-Retellings.
 - [ ] **Break-glass-Pfad**: Ticket + TTL + Nachvollziehbarkeit
 - [ ] **Living Checklists** versioniert (Git/Change-Prozess), nicht nur Wiki-Snapshot
 - [ ] **60-Tage-Backlog** priorisiert (P1, Enforce-Ausweitung, Postmortem-Übung, optional Red-Team)
+- [ ] **Mindest-Verify-Pipeline** für Agent-PRs dokumentiert (Types + Tests +
+  Coverage-Δ; Owner benannt; Change-Risk C3/C4 mit Review) – Details Kapitel 8

 ### Explizit nicht DoD

@@ -271,6 +278,7 @@ Muster, keine Firmen-Retellings.
 - Kein Framework- oder Vendor-Lock-in als Erfolgsmaß
 - Keine Legal-Freigabe AI-Act/DSGVO als Liefergegenstand
 - Kein Multi-Region- / HA-Enterprise-Setup für Agent-Security
+- Kein vollständiges Mutation-Testing-Rollout auf dem gesamten Monorepo

 **Tag 31:** SLIs und FP/FN kalibrieren, Enforce gezielt ausweiten, eine echte Postmortem-Übung an Near-Miss oder Game-day-Befund durchführen.

@@ -283,3 +291,5 @@ Muster, keine Firmen-Retellings.
 | `v1.0.0` | 2026-07-24 | Erstfassung: Strategie, 30-Tage-Plan, 8 MVC, Living Checklists, Quellen, Risiken, DoD |
 | `v1.1.0` | 2026-07-24 | Als Anhang F ins Manuskript/PDF übernommen |
 | `v1.1.1` | 2026-07-24 | Umnummeriert zu Anhang G (neues F: Flue-Pattern-Mapping) |
+| `v1.2.0` | 2026-08-07 | Framing: „Buch-Schwächen“ → bewusste Grenzen; Titel „Operatives Einführungs-Paket“; H→G→B/C Lesestrang |
+| `v1.3.0` | 2026-08-07 | DoD: Mindest-Verify-Pipeline (Product Gates, Kap. 8); Non-DoD Mutation-Monorepo |
@@ -35,7 +35,7 @@ Lesepfad:
 5. Kosten- und Latenzmodell der Sandbox-Stufen
 6. Break-glass und Exception-Metriken
 7. Datenerhebung im Harness (Events und Felder)
-8. Anti-Pattern, Checkliste, 30-/60-/90-Tage-Plan
+8. Anti-Pattern, Checkliste; Kurzskizze Messung (Details: Anhang G)
 9. Grenzen der Quantifizierung
 10. Fallstudien und Messwerte (Startup, Scale-up, Enterprise)

@@ -196,6 +196,25 @@ kalibriert man an der eigenen Baseline.
 | Weich (kalibrieren) | Latenz-ms, FP-%, Break-glass / 1k | ja, nach Baseline |
 | Kontext | absolute R3/R4-Anteile, Sandbox-cold-Start | nur relativ zur eigenen Historie und Datenklasse |

+### Product-Verify-SLIs (orientierend)
+
+Die Harness-SLIs oben messen *Controls*. Sobald Agents produktiven Code
+schreiben, braucht die **Merge-Pipeline** eigene Signale – komplementär, nicht
+ersatzweise (Kapitel 8, Change-Risk C0–C4). Werte sind Kalibrierungsbasis.
+
+| Metrik-Name | Definition | Erhebungsort | Warum sie zählt |
+|-------------|------------|--------------|-----------------|
+| `agent_pr_typecheck_fail_rate` | Anteil Agent-PRs mit Typecheck-Fail vor Merge | CI | billige harte Kante; Drift bei strict-Absenkung |
+| `coverage_delta_on_touched` | Coverage auf geänderten Zeilen (line/branch) | CI Coverage | Diff-Bezug statt globales %-Fetish |
+| `mutation_score_critical_pkgs` | Mutation-Score auf C3/C4-Paketen (Fenster) | CI Mutation (gezielt) | schwache Tests sichtbar; teuer → eng scope |
+| `change_risk_review_rate` | Anteil C2+ Diffs mit menschlichem Review | PR-Metadaten | HITL dort, wo Change-Risk es verlangt |
+| `ci_gate_tamper_prs` | PRs, die Gate-Config/required checks mit Feature-Code mischen | CI + Codeowners | Tampering-Signal (Kap. 8, Anhang A) |
+| `avg_cognitive_delta_agent_pr` | mittlere Complexity-Δ pro Agent-PR | static analysis | Soft-Trigger für Review, kein Hard-Dogma |
+
+**Lesart:** Diese SLIs steuern die Verify-Pipeline und Review-Last – sie
+ersetzen weder DLP-FP-Raten noch Break-glass-Metriken. Evidence-Anschluss
+(Gate-Configs versioniert): Kapitel 10.
+
 ## Schattenmodus als empirisches Instrument

 Kapitel 5 und 6 fordern Schattenmodus vor hartem Enforce. Empirie beginnt dort,
@@ -570,27 +589,27 @@ Controls seien messbar und steuerbar.
 - [ ] Wöchentlicher One-Pager an Platform + Security (Break-glass, Top-Denies, Exception debt, Latenz)
 - [ ] Mindestens eine Policy-Entscheidung der letzten 90 Tage ist mit Metriken begründet dokumentiert

-## Empfehlung zur Einführung (30 / 60 / 90 Tage)
+## Empirie im Einführungsstrang (Kurzskizze)

-Ziel ist nicht das perfekte Observability-Produkt. Ziel ist: von null Empirie zu
-**steuerbaren** Metriken, mit denen ein Team Enforce und Relax begründen kann.
-Der 90-Tage-Plan staffelt Instrumentation, Baseline und Steuerbarkeit – damit
-Tag‑1-Enforce und „Dashboard irgendwann“ gleichermaßen vermieden werden.
+Der **kanonische Zeitplan** steht in **Anhang H** (zwei Wochen Startup) und
+**Anhang G** (30-Tage-Paket mit DoD). Dieser Anhang liefert die
+**Mess-Methodik** – SLIs, SLOs, Labeling, Fallstudien – nicht einen zweiten
+90-Tage-Fahrplan.

-| Horizont | Fokus | Konkrete Deliverables |
-|----------|-------|------------------------|
-| **Tage 0–30** | Instrumentation | Pflicht-Events inkl. `duration_ms` und `policy_version`; T0-Dashboard-MVP; Break-glass und Denies zählen; **keine** neuen harten Blocks „auf Verdacht“ |
-| **Tage 31–60** | Baseline und Schatten | 2–4 Wochen Observe; 50–200 Labels auf Top-Regeln; erste Precision; Latenz-Budgets als Start-SLOs; Exception-TTL technisch erzwungen |
-| **Tage 61–90** | Steuerbarkeit | SLOs mit Owner; Canary redact→block für 1–2 Regelklassen; Sandbox-Starts messen; Wochenreport; Game Day Revoke/Rollback; Entscheidungstabelle live |
+**Empirie-Schwerpunkte, sobald G läuft:**

-**Erfolgskriterium nach 90 Tagen:** Mindestens **eine** Policy-Entscheidung
-(Enforce, Relax oder Rollback) wurde mit Metriken begründet und im
-Change-/Audit-Trail referenziert (`policy_version`, Fenster, n, Precision oder
-Deny-Spike). Fehlt das, haben Sie Telemetrie – aber noch keine Empirie.
+| Phase (an G gekoppelt) | Mess-Fokus |
+|------------------------|------------|
+| Instrumentation | Pflicht-Events inkl. `duration_ms` und `policy_version`; Denies und Break-glass zählen |
+| Baseline / Schatten | Observe-Fenster; Labels auf Top-`rule_id`; Precision und Latenz-Budgets |
+| Steuerbarkeit | SLOs mit Owner; Canary redact→block; eine metrik-begründete Policy-Entscheidung im Trail |

-Rollen (Richtwert): Platform instrumentiert und dashboard’t; Security co-owned
-SLOs und Labeling-Qualität; Engineering-Vertreter liefern DX-Feedback; niemand
-„outsourct“ das wöchentliche Lesen der Kacheln an ein Tool.
+**Erfolgskriterium (Empirie):** Mindestens **eine** Policy-Entscheidung
+(Enforce, Relax oder Rollback) mit Metriken im Change-/Audit-Trail
+(`policy_version`, Fenster, n, Precision oder Deny-Spike). Fehlt das, haben
+Sie Telemetrie – aber noch keine Empirie. Rollen und wöchentliches Lesen der
+Kacheln: Platform instrumentiert, Security co-owned SLOs, Engineering liefert
+DX-Feedback – Details und DoD in **Anhang G**.

 ## Grenzen der Quantifizierung

@@ -730,6 +749,6 @@ Illustrative Start-SLOs und Sandbox-Größenordnungen sind **Kalibrierungsbasis*
 keine Wahrheit von der Stange. Schattenmodus wird empirisch erst mit Labeling,
 Stichprobe und Exit-Kriterien für observe → redact → block. Break-glass- und
 Exception-Metriken zeigen, ob das Notventil trägt oder die Policy gescheitert
-ist. Innerhalb von 90 Tagen sollte jede Organisation von bloßer Telemetrie zu
-mindestens einer metrikbegründeten Policy-Entscheidung kommen – und ehrlich
-benennen, was sie bewusst nicht messen kann.
+ist. Parallel zum Einführungsstrang (H → G) sollte jede Organisation von
+bloßer Telemetrie zu mindestens einer metrikbegründeten Policy-Entscheidung
+kommen – und ehrlich benennen, was sie bewusst nicht messen kann.
@@ -40,7 +40,7 @@ Lesepfad:
 4. Mapping Audit-Frage → Nachweis → typische Schwächen,
 5. organisatorische Realitäten und politische Fallstricke,
 6. Reifegradmodell und Living Evidence / Re-Zertifizierung,
-7. Anti-Pattern, Checkliste, 30-/60-/90-Tage- und 6-Monats-Fahrplan,
+7. Anti-Pattern, Checkliste; Assurance-Kurzskizze (Zeitplan: Anhänge H/G),
 8. Abgrenzung.

 ## Kritische Einordnung
@@ -278,10 +278,11 @@ sind **Design-Evidence**, keine Enforce-Evidence.

 ## Mapping: Audit-Frage → Nachweis → typische Schwächen

-Die folgende Erweiterung der Tabelle aus Kapitel 10 verbindet die Frage der
-Revision mit dem idealen Nachweis und der Lücke, die in der Praxis am
-häufigsten offen bleibt. Nutzen Sie sie als Review-Raster vor dem formalen
-Zyklus.
+**Arbeitsteilung mit Kapitel 10:** Kap. 10 führt das **kurze** Mapping
+(Frage → Systemnachweis) im Pattern-Kontext. **Diese** Tabelle ist die
+**kanonische Detailfassung** – Frage, idealer Nachweis, häufige reale Lücke.
+Nicht parallel pflegen: Änderungen an den Fragen hier und in Kap. 10
+abstimmen; Schwächen und Sampling-Tiefe nur hier.

 | Frage | Idealer Nachweis | Häufige reale Lücke |
 |-------|------------------|---------------------|
@@ -596,36 +597,25 @@ Freigabe-Leitplanke, nicht als Punktesystem.
 | Designed + Operating + Evidence 2.0 | **Audit-ready-Kandidat** (Stufe 4) |
 | plus Living über ≥ 2 Zyklen | **Sustained** (Stufe 5) |

-## Pragmatischer Fahrplan (30 / 60 / 90 Tage / 6 Monate)
+## Assurance im Einführungsstrang (Kurzskizze)

-Anschluss an Kapitel 10 (Pilot→Enforce) und Anhang B (Instrumentation zuerst) –
-dieser Plan legt die **Assurance-Schicht** darüber, ohne Empirie und Enforce zu
-ersetzen. Die Horizonte sind seriell: ohne Inventory und Enforce in den ersten
-30 Tagen bleibt der Sample-Zyklus Theater.
+Der **kanonische Zeitplan** steht in **Anhang H** → **Anhang G**. Kapitel 10
+liefert Patterns und das **kurze** Mapping Audit-Frage → Systemnachweis;
+dieser Anhang die **Evidence- und Reife-Tiefe**. Kein dritter 90-Tage-Plan.

-| Horizont | Fokus | Konkrete Deliverables |
-|----------|-------|------------------------|
-| **Tage 0–30** | Inventory & Instrumentation | Pflicht-Events und `policy_version` verifizieren; Gateway-Allowlist **enforce** (nicht nur doku); Exception-Register v0; erste Schatten-Agent-Inventur anstoßen; RACI-Entwurf |
-| **Tage 31–60** | Erster Sample-Zyklus | Sampling-Protokoll freigeben; ein voller Lauf auf Pilot-Population; Remediation-Pipeline (Ticket-Labels, Verify-Regel); IAM-Mapping-Diff v1; Break-glass 100 %-Review im Fenster |
-| **Tage 61–90** | Audit-ready light | Evidence E1–E5 + E8/E9 für den Scope; Kill- oder Rollback-Drill; offene Critical = 0; Lücken-Backlog priorisiert; Re-Cert-Termin; E7 Enforce-Spalte (Call-Mix) |
-| **Monat 4–6** | Sustained-Pfad | zweiter Sample-Zyklus oder Sample light + Delta; Scale-Exit-Kriterien wo Rollout wächst; Report-Jobs automatisieren; E10-Trend; Minutes des ersten formalen Re-Cert |
+**Assurance-Schwerpunkte nach Enforce (Kap. 10 / G):**

-**Erfolg nach 90 Tagen:** Ein Außenstehender (interne Revision light, Security
-Assurance oder benachbartes Team) kann anhand von E3 und E5 nachvollziehen,
-*welche* Abweichungen gefunden, *wie* behoben und *womit* verifiziert wurden –
-ohne Demo-Umgebung und ohne „wir haben DLP“-Folie.
+| Fokus | Deliverable (siehe Evidence 2.0 oben) |
+|-------|--------------------------------------|
+| Inventory | Pflicht-Events, `policy_version`, Gateway-Allowlist **enforce**, Exception-Register v0 |
+| Erster Sample-Zyklus | Sampling-Protokoll, ein voller Pilot-Lauf, Remediation mit Verify |
+| Audit-ready light | E1–E5 + E8/E9 im Scope; Critical = 0; Kill-/Rollback-Drill; Re-Cert-Termin |
+| Sustained (Monate 4–6+) | zweiter Zyklus oder Sample light; Living Evidence; formales Re-Cert |

-**Mini-Szenario:** Nach 60 Tagen zeigt der erste Sample-Lauf zwei Criticals
-(unbekanntes Gateway in einer Canary-Flanke, Exception ohne TTL). Remediation
-schließt beide mit Verify-Sample; der 90-Tage-Review referenziert E3/E5 statt
-einer grünen Dashboard-Folie. Genau das unterscheidet Audit-ready light von
-„wir loggen“.
-
-Rollen (Richtwert): Platform liefert Queries, Config-Exports und Drills;
-Security co-owned Sampling und Severity; Fachbereich Exceptions und
-Datenklassen; Assurance/Revision samplet unabhängig oder reviewed die
-Methode. Niemand outsourct die Existenz des Registers an „das Tool wird das
-schon tracken“.
+**Erfolgskriterium (Assurance):** Ein Außenstehender kann anhand von E3 und E5
+nachvollziehen, *welche* Abweichungen gefunden, *wie* behoben und *womit*
+verifiziert wurden – ohne Demo und ohne „wir haben DLP“-Folie. RACI und
+Rollen: Abschnitt Ownership oben; operative DoD: **Anhang G**.

 ## Abgrenzung

@@ -658,9 +648,9 @@ mit Exit-Kriterien statt Statusfolien.

 Living Evidence und periodische Re-Zertifizierung verhindern, dass der
 Launch-Ordner zur Reliquie wird. Anti-Pattern und Checkliste machen
-Selbsttäuschung teurer als Nacharbeit. Der 30-/60-/90-Tage- und 6-Monats-Pfad
-koppelt Instrumentation (Anhang B) und Enforce (Kap. 10) an die erste
-wirklich prüfbare Assurance-Schleife.
+Selbsttäuschung teurer als Nacharbeit. Instrumentation (Anhang B), Enforce (Kap. 10) und der Einführungsstrang
+(H → G) koppeln an die erste wirklich prüfbare Assurance-Schleife – die
+Evidence-Tiefe bleibt in diesem Anhang.

 Der Harness bleibt die Kontrollfläche: was nicht in Events, `policy_version`,
 Sandbox-Profilen, Approvals und Gateway-Logs landet, lässt sich im Ernstfall
@@ -40,7 +40,7 @@ Lesepfad:
 6. Organisatorische und politische Dimension
 7. Anti-Pattern der unterschätzten DX
 8. Checkliste
-9. 30-/60-/90-Tage-Plan, Grenzen, Zusammenfassung
+9. DX im Einführungsstrang (Kurzskizze), Grenzen, Zusammenfassung

 Abgrenzung: Anhang B fragt *„Wie oft greift das Control falsch und wie teuer
 ist es?“* Dieser Anhang fragt *„Wann wird Compliance irrational – und wie
@@ -545,28 +545,24 @@ aufgeweichtem Deny by default ist kein Erfolg.
 - [ ] Kein Secret-Klartext in DX-Telemetrie oder Deny-UI
 - [ ] Exceptions ohne TTL/Owner = 0 (Job + Alarm)

-## Pragmatischer Einführungs- und Betriebsplan (30 / 60 / 90 Tage)
+## DX im Einführungsstrang (Kurzskizze)

-Ziel ist nicht das „freundliche“ Security-Produkt. Ziel ist: von ignorierter
-Reibung zu **steuerbarer** DX, die Security-Controls adoptionsfähig hält.
-Die Phasen bauen aufeinander auf: zuerst Sichtbarkeit, dann Kalibrierung,
-dann Steuerung – ohne neue harte Blocks „auf DX-Verdacht“ ohne Baseline.
+Der **kanonische Zeitplan** steht in **Anhang H** → **Anhang G**. Dieser
+Anhang liefert DX-Metriken, Reibungsmodell und Patterns – keinen parallelen
+90-Tage-Fahrplan.

-| Horizont | Fokus | Konkrete Deliverables |
-|----------|-------|------------------------|
-| **Tage 0–30** | Sichtbarkeit | `session_abandon_after_deny`, `deny_to_resolution_time`, Exception-Request-Zähler; actionable Deny-MVP für Top-10-`rule_id`s; Friction-Pulse v0; **keine** neuen harten Blocks „auf DX-Verdacht“ ohne Baseline |
-| **Tage 31–60** | Kalibrierung | 2–4 Wochen Baseline; Top-Regeln nach Abandon ranken; Fast-Path-Exception Low-Risk live; Sandbox-Warm-Path für erlaubte Profile; Policy-Canary mit DX-Gates; Shadow-Proxy-Inventur anstoßen |
-| **Tage 61–90** | Steuerung | DX-SLOs mit Owner; wöchentlicher DX+Security-One-Pager; ≥ 1 Policy- oder Prozess-Entscheidung mit DX-Metriken begründet (Enforce, Relax oder Exception-Redesign); Abandon oder Deny-to-Resolution messbar verbessert **ohne** Security-Hart-SLOs zu verletzen |
+**DX-Schwerpunkte parallel zu G / Enforce:**

-**Erfolgskriterium nach 90 Tagen:** Mindestens eine Änderung am Harness oder
-am Exception-Prozess hat Abandon after Deny oder Deny-to-Resolution
-**verbessert**, und Break-glass-/Exception-debt-Grenzen (Anhang B) sind nicht
-schlechter geworden. Fehlt das, haben Sie DX-Telemetrie – aber noch keine
-DX-Steuerung.
+| Fokus | Mess- und Prozess-Fokus |
+|-------|-------------------------|
+| Sichtbarkeit | `session_abandon_after_deny`, `deny_to_resolution_time`; actionable Deny-MVP für Top-`rule_id`s |
+| Kalibrierung | Abandon-Ranking, Fast-Path-Exception Low-Risk, Sandbox-Warm-Path, Canary mit DX-Gates |
+| Steuerung | DX-SLOs mit Owner; ≥ 1 Policy-/Prozess-Entscheidung, die Adoption verbessert **ohne** Security-Hart-SLOs zu verletzen |

-Rollen (Richtwert): Platform instrumentiert; Security co-owned Schwellen und
-Risk-Klassen; Engineering-Vertreter lesen Friction und Abandon mit; niemand
-outsourct das wöchentliche Lesen der Kacheln.
+**Erfolgskriterium (DX):** Mindestens eine Änderung hat Abandon after Deny
+oder Deny-to-Resolution **verbessert**, und Break-glass-/Exception-debt
+(Anhang B) ist nicht schlechter. Fehlt das: DX-Telemetrie ohne Steuerung.
+Operative DoD und Wochenrhythmus: **Anhang G**.

 ## Grenzen

@@ -607,9 +603,9 @@ nicht auf.

 Ownership und Politik entscheiden, ob Metriken steuern oder dekorieren.
 Anti-Pattern und Checkliste machen sichtbar, ob die Organisation Schatten-IT
-systematisch erzeugt. Innerhalb von 90 Tagen sollte aus Telemetrie Steuerung
-werden: mindestens eine begründete Policy- oder Prozess-Entscheidung, die
-Adoption messbar verbessert, ohne Security-Härte zu opfern.
+systematisch erzeugt. Ziel bleibt: aus Telemetrie Steuerung machen – mindestens eine begründete
+Policy- oder Prozess-Entscheidung, die Adoption messbar verbessert, ohne
+Security-Härte zu opfern (Zeitplan: Anhänge H/G).

 Wer DX unterschätzt, baut Controls für das Review. Wer DX steuert, baut
 Controls für den Alltag – und nur der Alltag zählt für operating effectiveness.
@@ -1,24 +1,32 @@
-# Anhang G Schwächen-resistentes Einführungs-Paket (30 Tage)
+# Anhang G Operatives Einführungs-Paket (30 Tage)

 ## Kern in einem Satz

-Die Buch-Schwächen (fehlende Fallstudien, kein Production-Code, junges Flue,
-Enterprise-Bias, dichte Tabellen) lassen sich in 30 Tagen operational abfedern –
-durch Shadow Mode, eigene SLIs, framework-agnostische Nahtstellen und Living
-Checklists, nicht durch Warten auf den nächsten Framework-Release.
+Die **bewussten Grenzen** des Buchs (keine fertigen Org-Zahlen, kein
+drop-in Production-Code, framework-agnostische Patterns statt Vendor-Lock-in)
+lassen sich in 30 Tagen operational schließen – durch Shadow Mode, eigene SLIs,
+Nahtstellen-Maps und Living Checklists, nicht durch Warten auf den nächsten
+Framework-Release.

 ## Überblick

-Dieser Anhang ist **kein** Ersatz für die Kapitel 1–11 und **keine**
-Fallstudie. Er ist ein operatives Einführungs-Paket für Platform-, Security-
-und Engineering-Teams, die Coding-Agent-Security (Harness wie Flue, Mastra,
-Eve, Sandcastle oder Eigenbau) **trotzdem** starten wollen – mit messbaren
-Artefakten, nicht mit einer Big-Bang-Freigabe.
+Dieser Anhang ist **kein** Ersatz für die Kapitel 1–11. Er ist ein operatives
+Einführungs-Paket für Platform-, Security- und Engineering-Teams, die
+Coding-Agent-Security (Harness wie Flue, Mastra, Eve, Sandcastle oder Eigenbau)
+**starten** wollen – mit messbaren Artefakten, nicht mit einer Big-Bang-Freigabe.

-Was im Haupttext fehlt (eigene Zahlen, Production-Code, reife Framework-APIs),
-ersetzen Sie ab Tag 1 durch Shadow-Messung, Nahtstellen-Map und versionierte
-Checklisten. Die Meta-Felder unten legen Audience, Framework-Annahme und
-Lesepfad fest, bevor der 30-Tage-Plan greift.
+**Lesereihenfolge:** Wer ohne Security-Abteilung startet, beginnt mit
+**Anhang H** (zwei Wochen, sechs Controls). Dieser Anhang G skaliert denselben
+Strang auf **30 Tage** mit DoD, RACI und Kill-Switch-Probe. Mess- und
+Audit-Vertiefung: **Anhänge B und C**.
+
+Was das Buch **bewusst nicht liefert** – eure Baseline-Zahlen, euren
+Production-Code, reife Vendor-APIs als Copy-Paste – ersetzen Sie ab Tag 1 durch
+Shadow-Messung, Nahtstellen-Map und versionierte Checklisten. Fallstudien und
+illustrative Metriken finden Sie in **Anhang B**; Code-Skizzen in den
+Kapiteln 5–9 sind **illustrativ**, nicht API-stabil. Die Meta-Felder unten
+legen Audience, Framework-Annahme und Lesepfad fest, bevor der 30-Tage-Plan
+greift.

 | Feld | Inhalt |
 |------|--------|
@@ -32,8 +40,9 @@ Lesepfad fest, bevor der 30-Tage-Plan greift.
 ## 1. Kurzfassung der Strategie

 Nutzen Sie das Buch als **Kontroll- und Betriebs-Landkarte**, nicht als fertige
-Implementierung oder Case-Study-Quelle. Fehlende Zahlen und Production-Code
-ersetzen Sie durch **eigene Shadow-Messungen und Artefakte ab Tag 1**.
+Implementierung für Ihre Organisation. Eigene Zahlen und Production-Artefakte
+entstehen durch **Shadow-Messungen und Nahtstellen-Arbeit ab Tag 1** – parallel
+zu den Mustern aus Kapitel 4–11 und den Fallstudien-Rahmen in Anhang B.

 Mappe die Kontrollkette framework-agnostisch:

@@ -327,9 +336,11 @@ Review und Audit dieselbe Einstiegsspur haben.

 ## 5. Empfohlene Ergänzungsquellen

-Kuratiert. Zweck: dort absichern, wo Fallstudien, Prod-Code und Framework-Reife
-im Buch fehlen – ohne den 30-Tage-Fokus durch Vendor-Pitch oder
-Zertifizierungsziele zu ersetzen.
+Kuratiert. Zweck: Standards und Tool-Klassen anbinden, die das 30-Tage-Paket
+**ergänzen** (Taxonomie, Governance-Sprache, Scanner-Klassen) – ohne den Fokus
+durch Vendor-Pitch oder Zertifizierungsziele zu ersetzen. Buch-intern:
+Fallstudien/SLIs → Anhang B; Audit-Evidence → Anhang C; Framework-Vergleich →
+Anhang E (mit Verfallsrisiko).

 ### Standards & Frameworks

@@ -371,20 +382,22 @@ den jeweiligen Lernpunkt operational adressiert.

 ---

-## 6. Risiken & Gegenmaßnahmen beim Einführen trotz der Buch-Schwächen
+## 6. Risiken & Gegenmaßnahmen an den bewussten Grenzen des Buchs

-Buch-Schwächen werden hier als **Projektrisiken** gelesen: Symptom im Vorhaben,
-Gegenmaßnahme im Paket. Die Tabelle ersetzt keine Threat Model-Arbeit
-(Kapitel 3, Anhang A) – sie hält die Einführung ehrlich.
+Das Buch liefert Patterns, Checklisten und (in Anhang B) illustrative Empirie –
+**keine** fertige Baseline für Ihre Organisation und **keinen** drop-in
+Production-Code. Die folgende Tabelle liest diese Grenzen als
+**Projektrisiken**: Symptom im Vorhaben, Gegenmaßnahme im Paket. Sie ersetzt
+keine Threat-Model-Arbeit (Kapitel 3, Anhang A) – sie hält die Einführung ehrlich.

-| Buch-Schwäche / Risiko | Symptom im Projekt | Gegenmaßnahme (dieses Paket) |
-|------------------------|--------------------|------------------------------|
-| **Fehlende Fallstudien / Zahlen** | Stakeholder fordern „Beweis“, Roadmap stoppt | Eigene Baseline in 30 Tagen: SLIs, Shadow-Metriken, Kill-Switch-Protokoll aus *eurem* Traffic |
-| **Kein Prod-Code im Buch** | Spielzeug-Demos; Prod-Nahtstellen unkartiert | DoD: Nahtstellen-Map + 8 MVC an realen Tools/CI/Repos |
-| **Enterprise- / DACH-Bias** | Kleine Teams kopieren Gremien; Monate Verzug | Schlanke Owner-Liste; ISO nur Evidence-Brücke; Fokus P0-MVC + Playbooks |
-| **Junges Framework (z. B. Flue Beta)** | API-Brüche, Lock-in-Angst blockiert Start | Framework-agnostische Controls; dünne Adapter; kein Lock-in in der DoD |
-| **Tabellen-Überlast** | Schein-Compliance, Overwhelm | Kurze Living Checklists; P0 enforce oder begründet deferred; Rest → 60-Tage-Backlog |
-| **Begrenzte Autor-Credentials** | Security/Legal blockiert oder ignoriert | Explizite DoD und Non-DoD; Ticket+TTL; Evidence ohne Legal-Freigabe als 30-Tage-Ziel |
+| Grenze / Risiko | Symptom im Projekt | Gegenmaßnahme (dieses Paket) |
+|-----------------|--------------------|------------------------------|
+| **Keine org-eigenen Zahlen im Buch** (Fallstudien in B sind illustrativ) | Stakeholder fordern „Beweis“, Roadmap stoppt | Eigene Baseline in 30 Tagen: SLIs, Shadow-Metriken, Kill-Switch-Protokoll aus *eurem* Traffic |
+| **Code-Skizzen, kein drop-in Prod-Code** | Spielzeug-Demos; Prod-Nahtstellen unkartiert | DoD: Nahtstellen-Map + 8 MVC an realen Tools/CI/Repos |
+| **Enterprise-Lesart wirkt schwergewichtig** | Kleine Teams kopieren Gremien; Monate Verzug | Schlanke Owner-Liste; ISO nur Evidence-Brücke; Fokus P0-MVC + Playbooks; Start ggf. über Anhang H |
+| **Junges / wechselndes Framework (z. B. Flue)** | API-Brüche, Lock-in-Angst blockiert Start | Framework-agnostische Controls; dünne Adapter; kein Lock-in in der DoD |
+| **Tabellen- und Checklisten-Dichte** | Schein-Compliance, Overwhelm | Kurze Living Checklists; P0 enforce oder begründet deferred; Rest → 60-Tage-Backlog |
+| **Recht/Audit bleiben Fachentscheid** | Security/Legal blockiert oder ignoriert | Explizite DoD und Non-DoD; Ticket+TTL; Evidence ohne Legal-Freigabe als 30-Tage-Ziel |
 | **Over-engineering** | Voll-DLP, Multi-Region, Enterprise-IAM vor erstem Shadow-Run | Schmaler 30-Tage-Muss: Map, Shadow, P0, SLIs, Game day, Break-glass |
 | **Shadow-Mode ohne Labels** | Shadow läuft, niemand sieht FP/Coverage/Bypass | Labels + Owner; wöchentlicher Report; Enforce vs. deferred mit Begründung |

@@ -406,6 +419,8 @@ Zertifizierungsreife.
 - [ ] **Break-glass-Pfad**: Ticket + TTL + Nachvollziehbarkeit
 - [ ] **Living Checklists** versioniert (Git/Change-Prozess), nicht nur Wiki-Snapshot
 - [ ] **60-Tage-Backlog** priorisiert (P1, Enforce-Ausweitung, Postmortem-Übung, optional Red-Team)
+- [ ] **Mindest-Verify-Pipeline** für Agent-PRs dokumentiert (Types + Tests +
+  Coverage-Δ; Owner benannt; Change-Risk C3/C4 mit Review) – Details Kapitel 8

 ### Explizit nicht DoD

@@ -415,6 +430,7 @@ Zertifizierungsreife.
 - Kein Framework- oder Vendor-Lock-in als Erfolgsmaß
 - Keine Legal-Freigabe AI-Act/DSGVO als Liefergegenstand
 - Kein Multi-Region- / HA-Enterprise-Setup für Agent-Security
+- Kein vollständiges Mutation-Testing-Rollout auf dem gesamten Monorepo

 **Tag 31:** SLIs und FP/FN kalibrieren, Enforce gezielt ausweiten, eine echte
 Postmortem-Übung an Near-Miss oder Game-day-Befund durchführen.
@@ -423,7 +439,8 @@ Postmortem-Übung an Near-Miss oder Game-day-Befund durchführen.

 Anhang G macht aus den Mustern der Kapitel 4–11 einen **30-Tage-Start**: messen
 vor blockieren, acht Minimal-Controls, Living Checklists und eine harte
-Definition of Done. Was fehlt, ersetzen Sie durch eigene Zahlen und Artefakte –
-nicht durch weiteres Lesen allein. Deny by default, Shadow vor Enforce und
+Definition of Done. Was das Buch bewusst nicht liefern kann – eure Baseline,
+euren Production-Code – ersetzen Sie durch eigene Zahlen und Artefakte, nicht
+durch weiteres Lesen allein. Deny by default, Shadow vor Enforce und
 versionierte Owner bleiben die Leitplanken; der Rest ist Kalibrierung und
 konsequente Artefakt-Arbeit auf realen Agent-Pfaden.
@@ -34,16 +34,31 @@ im Alltag dominieren, steht die gebräuchliche Form voran.
 : Zeitlich eng begrenzte Notfall-Erweiterung von Rechten; immer mit Audit und
  TTL (Kapitel 11).

+**Change-Risk (C0–C4)**
+: Einordnung von Code-Diffs (typisch agent-geschrieben) nach Wirkung:
+  Docs/Format, Logik, API/Refactor, Auth/Crypto/PII, IAM/CI-Gates/Infra.
+  Steuert Product Gates und HITL – parallel zu Tool-Risk R0–R4, aber für
+  *Merge*-Rechte (Kapitel 8).
+
 **Context Builder**
 : Harness-Komponente, die Quellen selektiert, Chunks bildet und den
  Modell-Kontext unter Budget zusammenstellt (Kapitel 4).

+**Contract-Test (Harness)**
+: Deterministischer Test des Tool-Routers bzw. der Policy-Naht (allow/deny,
+  Schema) – nicht zu verwechseln mit Produkt-Kontrakten (API/Invarianten).
+  Kapitel 8.
+
 **Control Evidence / Evidence-Paket**
 : Zusammenstellung prüfbarer Nachweise (Config-Exports, Events, Sampling-
  Reports, Exception-Register, Remediation-Tickets), dass Controls designed
  und operating effectively greifen – nicht nur Screenshots (Kapitel 10,
  Anhang C).

+**Coverage-Delta (Coverage-Δ)**
+: Testabdeckung bezogen auf *geänderte* Zeilen eines Diffs; für Agent-PRs
+  aussagekräftiger als ein globales Repo-Coverage-% (Kapitel 8).
+
 **Datenklassifikation**
 : Einordnung von Repos/Inhalten (z. B. öffentlich, intern, vertraulich,
  reguliert); steuert Agent-Profile und Gateway-Zonen (Kapitel 10).
@@ -107,6 +122,11 @@ im Alltag dominieren, steht die gebräuchliche Form voran.
 : Kontrollierter Zugang zu LLM-Anbietern: Endpoint-Allowlist, Auth, Residenz,
  Retention-Flags (Kapitel 4, 10).

+**Mutation Score / Mutation Testing**
+: Anteil künstlich eingeschleuster Programmfehler (Mutanten), den die
+  Test-Suite erkennt; teures Signal für Testschwäche, gezielt auf kritische
+  Pakete (Kapitel 8).
+
 **Operating Effectiveness**
 : Nachweis, dass ein Control im betrachteten Zeitraum *tatsächlich* greift
  (Stichproben, Ausnahme-Tracking, Remediation, Drills) – im Unterschied zur
@@ -126,10 +146,24 @@ im Alltag dominieren, steht die gebräuchliche Form voran.
  *Policy-Version* (Konzept), in Event-Feldern und Code als `policy_version`.
  Pflichtfeld in Audit-Events.

+**Product Gates / Verify-Pipeline**
+: Gestapelte Merge-Kontrollen für agent-geschriebene Änderungen: Lint, Types,
+  Tests, Coverage-Δ, optional Mutation, Complexity-Trigger, Produkt-Kontrakte
+  (Kapitel 8). Komplementär zu Harness-Permissions.
+
+**Produkt-Kontrakt**
+: API- oder Domain-Garantie (OpenAPI/JSON-Schema, Consumer Contract, runtime
+  Invariante), die ein Patch nicht brechen darf – abzugrenzen vom
+  Harness-Contract-Test (Kapitel 8).
+
 **Prompt Injection**
 : Manipulation des Agent-Verhaltens über eingeschleusten Text in
  Nutzer- oder Kontextquellen (direkt oder indirekt).

+**Property-based Testing**
+: Tests gegen generierte Eingaben und Invarianten statt nur handgeschriebene
+  Beispiele; sinnvoll u. a. für Parser, Codecs, Policy-Engines (Kapitel 8).
+
 **Quarantine**
 : Aktion, bei der Material nicht in den Prompt geht, sondern in einen
  Review-Pfad (Ticket/Security-Queue).
@@ -108,6 +108,7 @@ flächendeckendes Rollout.
 | „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. |
+| „Suite grün = Patch ist sicher und korrekt.“ | Der Agent kann Tests mitbiegen; ohne Types, Coverage-Δ, Change-Risk und Review bleibt Grün eine schwache Aussage (Kap. 8). |

 Die späteren Kapitel ersetzen jede Zeile durch prüfbare Patterns.

@@ -127,7 +128,7 @@ Nachweise; die organisatorische Einbettung steht in Kapitel 10–11.
 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. 7–8  Aktionspfad (Sandbox, Permissions, Product Gates)
 Kap. 9–11 Nachweis und Betrieb
 ```

@@ -20,11 +20,25 @@ sondern mit zwei Sätzen:
 ## Scope des Modells

 **In scope:** Coding-Agents mit Repo-Zugriff, Tool-Ausführung und LLM-Gateway
-in Unternehmenskontexten (IDE und CI).
+in Unternehmenskontexten (IDE und CI) – typischerweise **Single-Session** ohne
+persistentes Cross-Session-Memory und ohne Multi-Agent-Delegation.

-**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.
+**Out of scope (dieses Kapitel):**
+
+- physische Sicherheit
+- klassische Web-App-OWASP im Detail
+- vollständige Lieferkettenanalyse aller Dependencies – außer wo sie den
+  Agent-Pfad kreuzen
+
+> **Box – Was dieses Kapitel bewusst ausklammert**  
+> Persistentes Memory, Multi-Agent-Delegation, adversariale Policy-Arbeit,
+> erweiterte Vendor-Nebenkanäle, Install-/MCP-Runtimes und Multi-Tenant-Isolation
+> gehören **nicht** in die Einstiegs-Pfade D1–D4. Sobald eines davon im Scope
+> liegt, erweitern Sie das Modell um die Pfade **D5–D12** in
+> **Anhang A (Erweitertes Bedrohungsmodell)** – ohne die Philosophie zu
+> wechseln: Deny by default, Harness als Kontrollfläche, Controls an
+> Daten- und Aktionspfad. Die Kurzverweise weiter unten und in der Checkliste
+> sind Einstiege, kein Ersatz für Anhang A.

 Annahmen (anpassen, nicht ignorieren):

@@ -121,6 +135,30 @@ zusätzlich die Pfade **D5–D12** – ausgearbeitet in
 Wenn ein späteres Pattern kein Ziel aus dieser Liste trifft, ist es
 Dekoration – oder Ihr Modell ist unvollständig und muss erweitert werden.

+## Mapping: OWASP LLM Top 10 → Controls in diesem Buch
+
+Die OWASP *Top 10 for LLM Applications* (Fassung 2025; siehe Literatur [1])
+ist eine **Risiko-Taxonomie**, kein Ersatz für das agent-spezifische Modell
+oben. Die Tabelle mappt die zehn Einträge grob auf Pfade und Kapitel dieses
+Buchs – als Brücke zu Security-Reviews, die OWASP-Sprache erwarten.
+
+| OWASP (2025) | Primärer Bezug im Buch | Kapitel / Anhang |
+|--------------|------------------------|------------------|
+| **LLM01** Prompt Injection | Pfad D2; untrusted Sources; Permissions | 3–4, 7–8; A |
+| **LLM02** Sensitive Information Disclosure | Secrets/PII an Modell und Log; D1, D3 | 4–6, 9 |
+| **LLM03** Supply Chain | Dependencies, Images, Tool-Server | 3, 7; A |
+| **LLM04** Data and Model Poisoning | Memory-/Kontext-Vergiftung (erweitert) | A; teilweise 4 |
+| **LLM05** Improper Output Handling | Tool-Output, Output-DLP, unsichere Ausführung | 5–8 |
+| **LLM06** Excessive Agency | Risk-Klassen R0–R4, Scopes, Approvals | 7–8 |
+| **LLM07** System Prompt Leakage | Prompt ist kein Secret-Store; Policy im Harness | 2, 8–9 |
+| **LLM08** Vector and Embedding Weaknesses | RAG/Retrieval als untrusted Channel | 4; A |
+| **LLM09** Misinformation | außerhalb Kernthema; Governance/Review | 10 (org.) |
+| **LLM10** Unbounded Consumption | Token-/Tool-Budgets, Kill-Switch, Loops | 2, 11 |
+
+**Hinweis:** Ein grünes Häkchen pro OWASP-Zeile ist **kein** Freigabenachweis.
+Maßgeblich bleiben Assets, Pfade D1–D4 (bzw. D5–D12) und die Kontrollziele der
+vorherigen Abschnitte.
+
 ## Bedrohungsmodell pflegen

 - **Trigger:** neues Tool, neues Gateway, neues Repo-Label, Incident, Vendor-Wechsel;
@@ -82,8 +82,8 @@ den erfolgreichen Exfil.

 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. Jede Stufe
-hat einen Happy Path und ein klares Bild, was bei Abweichung passiert.
+Sie nicht bei „npm test lokal“, wenn untrusted Code im Spiel ist. Die Tabelle
+am Ende des Abschnitts fasst Happy Path und Abweichung pro Stufe zusammen.

 ### Stufe 1 – Process isolation

@@ -98,16 +98,6 @@ Grenze für interne, lesende Arbeit.

 **Geeignet für:** interne Repos, vertrauenswürdige Entwickler, lesende Tools.

-**Happy Path:** Tool-Calls laufen unter reduziertem User mit Timeouts und
-Resource-Caps; das Environment enthält keine Host-Secrets; bei Erfolg fließt
-nur der freigegebene Output zurück.
-
-**Was passiert bei Abweichung:** Ohne eigenen User und ohne Limits erbt der
-Agent die volle Desktop-Session – inklusive `SSH_AUTH_SOCK`, Cloud-CLI-Tokens
-und der Fähigkeit, andere Prozesse und Plattenbereiche mitzuziehen. Ein
-hängender Loop wird dann zum Kosten- und Verfügbarkeitsproblem, nicht nur zum
-lästigen Agent-Fehler.
-
 ### Stufe 2 – Filesystem jail / Workspace-Bindung

 Die Dateisystem-Grenze entscheidet, *was der Agent überhaupt sehen und
@@ -121,15 +111,6 @@ schreiben kann*. Ohne sie ist jede Shell-Allowlist nur Kosmetik: ein

 **Pattern:** ephemerer Workspace pro Session, am Ende löschen oder archivieren.

-**Happy Path:** Lesen und Schreiben bleiben im Session-Workspace; Artefakte
-werden bewusst exportiert; Host-Home und Key-Material sind schlicht nicht
-sichtbar.
-
-**Was passiert bei Abweichung:** Fehlt die Bindung, greifen `../`-Pfade,
-Symlinks und „hilfreiche“ Default-Pfade auf `~/.aws`, `~/.ssh` oder
-Browser-Profile zu – oft ohne dass die Shell-Policy das als Verstoß erkennt.
-Was gemountet ist, gilt als erreichbar.
-
 ### Stufe 3 – Network policy

 Netz ist der klassische Exfiltrations- und Nachladekanal. Die Default-Haltung
@@ -148,15 +129,6 @@ Deny by default für Egress, dann Allowlist:
 „Netz offen, weil sonst `npm install` scheitert“ ist ein Architekturgeruch:
 lösen Sie es mit Proxy und gespiegelten Registries, nicht mit offenem Egress.

-**Happy Path:** Erlaubte Ziele (Proxy, festes Gateway, internes Git) sind
-erreichbar; alles andere scheitert deterministisch mit einer sprechenden
-Fehlermeldung und einem Audit-Event zur Netz-Policy-Version.
-
-**Was passiert bei Abweichung:** Offener Egress macht aus jedem erlaubten
-Shell- oder HTTP-Tool einen Datenkanal nach außen – inklusive Cloud-Metadaten
-und ungeprüfter Fremdhosts. Ein „temporär offenes“ Netz überlebt Demos und
-wird zur Dauerlücke.
-
 ### Stufe 4 – Containerisierte Ephemerals

 Container (oder gleichwertige Ephemerals) liefern frisches Dateisystem,
@@ -173,15 +145,6 @@ der erste Incident da ist.
 **Geeignet für:** gemischte Trust-Level, CI-ähnliche Agent-Läufe, Multi-Tenant-
 Plattformen.

-**Happy Path:** Pro Session startet ein frisches Image mit bekanntem Digest;
-Netz und FS folgen dem Profil; nach TTL oder Abschluss ist die Runtime weg,
-Secrets sind abgelaufen, der Host-Socket war nie gemountet.
-
-**Was passiert bei Abweichung:** Langlebige Container mit `$HOME`,
-Docker-Socket oder Host-Credentials sind Privilegienverlängerung, keine
-Sandbox. Was „nur für den Demo-Tag“ privileged war, wird kopiert, in Templates
-übernommen und taucht Monate später in Prod-nahen Läufen wieder auf.
-
 ### Stufe 5 – Stärkere Isolation / Remote execution

 Für regulierte Daten, untrusted Contributions und hohe Integritätsanforderungen
@@ -196,14 +159,15 @@ Netzsegmente; lokal bleiben Review-Artefakte, nicht die volle Runtime.
 **Geeignet für:** regulierte Daten, untrusted Contributions, hohe
 Integritätsanforderungen.

-**Happy Path:** Untrusted oder hochsensible Arbeit läuft remote unter
-eigenem Konto und Netz; der Entwickler erhält Diffs, Logs und Reports – nicht
-einen Shell-Zugang in dieselbe Vertrauenszone wie Prod.
+### Happy Path und Abweichung (Stufen 1–5)

-**Was passiert bei Abweichung:** Wer untrusted Forks oder PII-nahe Repos
-lokal mit VPN und Host-Credentials ausführt, koppelt Prompt-Risiko direkt an
-Prod-Nähe. Eine gelungene Injection ist dann kein Sandbox-Fail im Log, sondern
-ein Vorfall in der echten Infrastruktur.
+| Stufe | Happy Path | Bei Abweichung |
+|-------|------------|----------------|
+| **1** Process | Reduzierter User, Timeouts/Caps, kein Secret-Env; nur freigegebener Output zurück | Volle Desktop-Session (`SSH_AUTH_SOCK`, Cloud-Tokens); Loops werden Kosten-/Verfügbarkeitsproblem |
+| **2** FS-Jail | Lesen/Schreiben nur im Session-Workspace; Host-Home und Keys unsichtbar; Artefakte explizit exportiert | `../`, Symlinks, Default-Pfade auf `~/.aws` / `~/.ssh`; Shell-Policy erkennt das oft nicht |
+| **3** Netz | Proxy/Gateway/Git laut Allowlist; Rest failt deterministisch + Audit mit Policy-Version | Offener Egress = Exfil- und Nachladekanal; „temporär offen“ wird Dauerlücke |
+| **4** Ephemeral | Frisches Image (Digest), Profil für Netz/FS, TTL/Tear-down, kein Host-Socket | Langlebige Container mit `$HOME`/Socket/Host-Creds = Privilegienverlängerung |
+| **5** Remote | Untrusted/sensible Arbeit remote; lokal nur Diffs/Logs/Reports | Untrusted Forks lokal mit VPN/Host-Creds koppeln Prompt-Risiko an Prod |

 ## Referenzarchitektur im Harness

@@ -225,15 +189,10 @@ 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.

-**Happy Path:** Der Orchestrator entscheidet Policy und Approvals; erlaubte
-Tools laufen nur in der Sandbox-Stufe der Risk-Klasse; Modell-Calls gehen über
-den Gateway-Pfad mit eigenen Credentials; Tool-Output kehrt durch DLP zurück,
-bevor er wieder Kontext wird.
-
-**Was passiert bei Abweichung:** Liegen Model-Keys in der Tool-Sandbox oder
-darf die Runtime den Gateway mit Host-Rechten ansprechen, kollabieren zwei
-Kontrollschichten zu einer. Ein entkommenes Tool erbt dann nicht nur FS und
-Netz, sondern auch den privilegierten Modellzugang.
+**Erfolg:** Orchestrator steuert Policy/Approvals; Tools nur in der
+Sandbox-Stufe der Risk-Klasse; Modell-Calls über eigenen Gateway-Pfad;
+Tool-Output durch DLP zurück. **Fail:** Model-Keys in der Tool-Sandbox oder
+Runtime mit Host-Rechten am Gateway – zwei Schichten kollabieren zu einer.

 ## Auswahlmatrix

@@ -290,17 +249,10 @@ Empfohlene Kette:
 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.
-
-**Happy Path:** Allowlist → Schema-/Pfad-Validierung → Sandbox der Risk-Klasse
-→ DLP auf dem Output → Kontext. Jeder Schritt hinterlässt Policy- und
-Profil-IDs im Audit, keinen Secret-Klartext.
-
-**Was passiert bei Abweichung:** Fehlt Schritt 2, umgehen relative Pfade und
-Flags die Intent der Allowlist. Fehlt Schritt 4, wird eine „sichere“ Shell zum
-Datenleck in den Prompt. Fehlt die Stufenkopplung in Schritt 3, laufen
-High-Risk-Tools in Low-Risk-Runtimes – die Isolation gilt dann nur auf dem
-Papier.
+können Secrets in stdout drucken. **Erfolg:** alle vier Schritte mit Policy-
+und Profil-IDs im Audit, ohne Secret-Klartext. **Fail-Modi:** fehlende
+Argument-Validierung (Schritt 2), fehlende DLP auf dem Output (Schritt 4) oder
+High-Risk-Tools in Low-Risk-Runtimes (Schritt 3).

 ## Testbarkeit und Nachweis

@@ -324,14 +276,10 @@ sonst lassen sich Vorfälle nicht rekonstruieren:
 - Netz-Policy-Version
 - Session-ID und Tear-down-Status

-**Happy Path:** Escape-, Egress- und Limit-Tests laufen in CI grün; jedes
-Prod-Profil verweist auf eine getestete Profil-ID und, wo nötig, einen
-Image-Digest.
-
-**Was passiert bei Abweichung:** Ohne diese Tests driftet die „Sandbox“ zur
-Konvention: ein neues Mount, ein gelockertes Netz oder ein vergessenes Timeout
-bleibt unbemerkt, bis der erste produktive Agent-Lauf die Lücke ausnutzt – oder
-ein Audit nach Profil-Version fragt und keine Antwort findet.
+**Erfolg:** Escape-/Egress-/Limit-Tests in CI grün; jedes Prod-Profil mit
+getesteter Profil-ID und, wo nötig, Image-Digest. **Ohne Tests** driftet die
+„Sandbox“ zur Konvention – bis der erste produktive Lauf oder ein Audit die
+Lücke findet.

 ## Betriebsaspekte

@@ -23,9 +23,10 @@ voller Brechstangen: Der Agent bleibt „drin“ – aber greift nach allem, was
 erreichbar ist.

 Das Kapitel folgt dem Weg von Risk-Klassen und Scopes über Argument-Constraints
-und Approval Gates bis zu Policy-as-Code, Sandbox-Mapping und Betrieb. Am Ende
-steht eine Checkliste, mit der Sie Least Privilege scharf schalten können,
-ohne Entwickler in Schatten-Tools zu treiben.
+und Approval Gates bis zu Policy-as-Code, Sandbox-Mapping, der
+**Verifikation agent-geschriebener Änderungen** (Product Gates) und Betrieb.
+Am Ende steht eine Checkliste, mit der Sie Least Privilege scharf schalten
+können, ohne Entwickler in Schatten-Tools zu treiben.

 ## Warum der System-Prompt keine Policy ist

@@ -67,15 +68,10 @@ Approval-Pfaden – nicht mit „erst mal alles erlauben“.

 Deshalb zählen **Tool-Name + validierte Argumente + Zielkontext**, nicht der
 Tool-Name allein. Ein `run_terminal` ohne Argument-Schema ist de facto R3 – auch
-wenn die UI es als „Dev-Helfer“ verkauft.
-
-**Happy Path:** Ein Call mit `risk: R1`, gültigem Workspace-Pfad und passender
-Policy-Version erhält das Sandbox-Profil `rw_workspace`, läuft ohne Approval und
-wird mit `policy_version` auditiert.
-
-**Was passiert bei Abweichung:** Fehlt die Risk-Zuordnung oder wird R3/R4 ohne
-Approval durchgewunken, erbt die Session Seiteneffekte nach außen. Der Harness
-muss dann hard-deny’en (`approval_required`) – nicht „Modell nochmal fragen“.
+wenn die UI es als „Dev-Helfer“ verkauft. **Erfolg:** `risk: R1`, gültiger
+Workspace-Pfad und `policy_version` → Profil `rw_workspace`, kein Approval,
+Audit mit Version. **Fail:** fehlende Risk-Zuordnung oder R3/R4 ohne Approval →
+Harness hard-deny (`approval_required`), nicht „Modell nochmal fragen“.

 ### Referenzimplementierung: Risk-Klasse → Sandbox-Profil

@@ -207,14 +203,8 @@ Vergabe über Rollen und Kontext, nicht über Gewohnheit:
 - über Task-Typ (Refactor vs. Incident),
 - über Repo-Label (öffentlich / intern / reguliert).

-**Happy Path:** Eine Docs-Session startet mit `fs:read` und `git:read`. Der
-Agent liest und sucht; Schreib- und Netz-Scopes fehlen – und damit die
-Angriffsfläche.
-
-**Was passiert bei Abweichung:** Fehlt die Scope-Bindung an Session und Task,
-erbt die nächste Session gestrige Deploy-Rechte. Ohne explizite Negation
-(`secrets:never` als Anker) bleibt unklar, ob „kein Scope“ Zufall oder Policy
-ist.
+Docs-Session: `fs:read` + `git:read` ohne Schreib-/Netz-Scopes. Fehlt die
+Bindung an Session und Task, erbt die nächste Session gestrige Deploy-Rechte.

 ### Argument-Constraints

@@ -253,13 +243,8 @@ Rechte gelten nicht „für den User für immer“, sondern für:
 Ein Agent, der gestern Deploy-Rechte für Hotfix hatte, erbt sie nicht still in
 die morgige Docs-Session. Session Binding macht Privilegien-Ausbreitung
 messbar: Sie sehen in Telemetrie, welche Sessions jemals R3 trugen – und warum.
-
-**Happy Path:** Hotfix-Session mit TTL und Change-Ticket; nach Ablauf fallen
-Scopes auf den Session-Default zurück.
-
-**Was passiert bei Abweichung:** Ohne Binding und TTL wird aus einer einmaligen
-Freigabe eine Dauerberechtigung. Der nächste Prompt Injection in derselben
-langlebigen Session erbt Deploy- und Netz-Rechte „kostenlos“.
+Hotfix: TTL + Change-Ticket; nach Ablauf Default-Scopes. Ohne Binding/TTL wird
+eine einmalige Freigabe zur Dauerberechtigung – und Injection erbt sie mit.

 ### Approval Gates

@@ -275,15 +260,18 @@ begrenzen kann: R3/R4 und bewusste Abweichungen von der Allowlist.

 Approvals loggen: wer, wann, was, welche Policy-Version, welcher Diff-Hash.
 Ein Klick „Allow all for 24h“ ohne Scope-Begrenzung ist ein Anti-Pattern – er
-verwandelt das Gate in einen Master-Key mit kurzer Erinnerung.
+verwandelt das Gate in einen Master-Key mit kurzer Erinnerung. Fehlt das Gate
+oder der Audit-Trail, laufen R3/R4 wie R1 – und der Kontrollnachweis ist im
+Incident wertlos.

-**Happy Path:** Deploy-Call triggert Approval; zwei Reviewer bestätigen Ticket
-und Diff-Hash; der Harness speichert Token + `policy_version` und führt genau
-diesen Call aus.
+### Bausteine auf einen Blick

-**Was passiert bei Abweichung:** Fehlt das Gate oder wird es mit „Allow all“
-umgangen, laufen R3/R4 wie R1. Fehlt der Audit (wer/wann/was), ist der
-Kontrollnachweis im Incident wertlos – auch wenn „irgendwer freigegeben hat“.
+| Baustein | Erfolg | Fail |
+|----------|--------|------|
+| Scopes | Session nur mit benötigten Fähigkeiten | Deploy-Rechte „erben“ über Sessions |
+| Argumente | Schema vor Sandbox; Deny + Telemetrie | Validierung erst im Kernel/Netz |
+| Session Binding | TTL, Policy-Version, Task-ID | Einmal-Allow wird Dauerrecht |
+| Approval | Token + Diff-Hash + `policy_version` | „Allow all“ oder Gate ohne Audit |

 ## Policy-Entscheidungsablauf

@@ -297,15 +285,10 @@ Jeder Schritt kann mit stabilen Fehlercodes abbrechen
 (`POLICY_DENY_SCOPE`, `POLICY_DENY_PATH`, `POLICY_NEEDS_APPROVAL`, …), damit
 UI und Tests deterministisch reagieren.

-**Happy Path:** Scope ok → Argumente ok → Risk-Profil gewählt → ggf. Approval
-vorhanden → Sandbox-Profil aktiv → Execute → Output durch DLP zurück in den
-Kontext.
-
-**Was passiert bei Abweichung:** Fehlt der frühe Abbruch bei Scope- oder
-Path-Deny, läuft der Call bis in die Sandbox und scheitert erst spät – teurer,
-unklarer Audit-Trail, und riskante Nebenpfade (Logging des vollen Befehls)
-werden wahrscheinlicher. Stabile Codes verhindern, dass Clients Deny als
-„Modell-Fehler“ umdeuten und den Call stumm wiederholen.
+**Kette (Erfolg):** Scope → Argumente → Risk-Profil → ggf. Approval →
+Sandbox → Execute → Output-DLP → Kontext. **Fail:** späte Abbrüche erst in der
+Sandbox (teurer, unklarer Audit-Trail) oder Clients, die Deny als
+„Modell-Fehler“ umdeuten und stumm wiederholen.

 ## Trennung Lesen / Schreiben / Ausführen

@@ -353,15 +336,10 @@ Ergänzend – und ohne die Deny-by-default-Linie aufzuweichen:
 - erhöhte Risk-Klasse, wenn der auslösende Chunk aus untrusted Source-ID stammt
  (Kapitel 4).

-**Happy Path:** Untrusted Issue-Text steht als Daten im Kontext; der Agent
-schlägt einen Shell-Call vor; der Harness deny’t mangels Scope und Allowlist;
-das Audit trägt `POLICY_DENY_SCOPE`, nicht den injizierten Befehl als „User
-intent“.
-
-**Was passiert bei Abweichung:** Werden Tool-Vorschläge aus untrusted Chunks
-1:1 als erlaubte Calls übernommen, umgeht die Injection die Modell-Ebene und
-trifft direkt den Router. Fehlt die Source-gebundene Risk-Erhöhung, läuft
-exakt derselbe Call wie bei trusted Workspace-Code.
+**Mini-Szenario:** Untrusted Issue-Text steht als Daten im Kontext; der Agent
+schlägt einen Shell-Call vor; der Harness deny’t (`POLICY_DENY_SCOPE`). Werden
+Tool-Vorschläge aus untrusted Chunks 1:1 als erlaubte Calls übernommen, trifft
+die Injection den Router direkt – oft ohne Source-gebundene Risk-Erhöhung.

 ## Policy-as-Code

@@ -411,14 +389,10 @@ Reihenfolge ist Absicht: Schema vor Suite, Suite vor Review, Review vor Canary.
 3. Diff-Review durch Platform/Security
 4. Canary auf Nicht-Prod-Agenten

-**Happy Path:** Policy-PR mit Fixtures (allow und deny), grüne CI, Canary ohne
-Anstieg der Abandon-after-Deny-Rate, dann Rollout mit neuer `policy_version` in
-allen Events.
-
-**Was passiert bei Abweichung:** Merge ohne Fixture-Tests und ohne Canary
-führt zu flächigen False Denies oder – schlimmer – zu stillen Allows. Ohne
-`policy_version` im Event können Sie nach einem Incident nicht rekonstruieren,
-*welche* Policy gegriffen hat.
+**Erfolg:** Fixtures (allow/deny), grüne CI, Canary ohne Anstieg der
+Abandon-after-Deny-Rate, Rollout mit neuer `policy_version` in allen Events.
+**Fail:** Merge ohne Tests/Canary → flächige False Denies oder stille Allows;
+ohne `policy_version` im Event ist die greifende Policy im Incident unklar.

 ## Mapping auf Sandbox-Stufen

@@ -436,15 +410,135 @@ aus.
 | R4 | Remote / break-glass, separate Identität |

 Permissions ohne Sandbox-Mapping erzeugen Scheinsicherheit: deny in der UI,
-execute trotzdem auf dem Host.
+execute trotzdem auf dem Host. R2 im ephemeral Container ohne Netz, R3 nur mit
+Approval und Allowlist-DNS; R4 mit **separater** Identität – dieselbe CI-
+Identität wie Docs-Sessions macht Break-glass zum Dauerzustand.

-**Happy Path:** R2-Testlauf startet im ephemeral Container ohne Netz; R3 wartet
-auf Approval und läuft nur mit Allowlist-DNS.
+## Von Tool-Rechten zu Merge-Rechten: Verifikation agent-geschriebener Änderungen

-**Was passiert bei Abweichung:** Fehlt das Mapping, genügt ein Client-Bypass
-oder ein falsch verdrahteter Router, und R3 landet auf dem Entwicklerhost.
-Separate Identität für R4 ist Pflicht: dieselbe CI-Identität wie für Docs-
-Sessions macht Break-glass zum Dauerzustand.
+R1 erlaubt Workspace-Writes, R2 erlaubt Tests, Build und Linter in der
+Sandbox. Das begrenzt *Handlung* – nicht die *Qualität und Sicherheit des
+Patches*. Ein Agent mit engem Scope und grüner Suite kann trotzdem Tests an die
+Implementation anpassen, Typ-Löcher ausnutzen, ungetestete Zweige übersehen
+oder CI-Schwellen schwächen. Harness-Kontrolle und Produkt-Verifikation sind
+**komplementär**: die eine fragt „darf der Agent das anstoßen?“, die andere
+„darf dieser Diff gemerged werden?“.
+
+Dieses Unterkapitel ist **kein** Testmethodik-Lehrbuch. Es ordnet die
+Verifikationsschichten, die Agent-Arbeit riskant macht, an denselben Stellen
+ein wie Permissions: als versionierbare Gates mit Owner – Kalibrierungsbasis,
+keine Universal-%-Dogmen (Empirie-Denken: Anhang B).
+
+### Zwei Ebenen
+
+| Ebene | Gegenstand | Typische Artefakte | Kapitel |
+|-------|------------|--------------------|---------|
+| **Harness-Verifikation** | Policy, DLP, Tool-Router, Schemas | allow/deny-Fixtures, Contract-Tests am Router, `policy_version` | 5, 8 (oben), 10 |
+| **Produkt-Verifikation** | Code, den der Agent schreibt oder ändert | Types, Tests, Coverage-Δ, Mutation, Kontrakte, Complexity-Trigger | **dieser Abschnitt** |
+
+**Contract-Test** meint in diesem Buch standardmäßig den **Harness-/Router-
+Contract** (Policy-Entscheidung und Tool-Schema gegen reale Naht).
+**Produkt-Kontrakte** (API-Schemas, Invarianten, Consumer Contracts) sind eine
+eigene Schicht – siehe unten und Glossar.
+
+### Agent-Output als untrusted Change Set
+
+Behandeln Sie den Diff des Agents analog zu untrusted Tool-Output (Kapitel 4,
+Anhang A): syntaktisch plausibel, semantisch nicht vertrauenswürdig, bis die
+**Verify-Pipeline** und – bei höherem Change-Risk – ein Mensch greifen. Der
+Agent darf im Workspace iterieren (R1/R2); die **Merge-Entscheidung** liegt
+außerhalb der Agent-Session – in CI und Review, nicht im Chat-„LGTM“.
+
+### Verify-Pipeline (gestapelt)
+
+Die Reihenfolge ist Absicht: billige, harte Kanten zuerst; teure Signale gezielt.
+
+| Stufe | Signal (Klasse) | Typisches Fail | Owner (typisch) |
+|-------|-----------------|----------------|-----------------|
+| 1 Format / Lint | style, import order, verbotene APIs | CI rot vor Review | Engineering |
+| 2 Typecheck | `tsc --noEmit`, pyright/mypy, go vet | Typfehler, `any`-Explosion wo strict gilt | Engineering |
+| 3 Tests | Unit + risk-scoped Integration | Suite rot; Flakes getrennt tracken | Engineering |
+| 4 Coverage-**Δ** | line/branch **auf geänderten Zeilen** | touched code ohne ausreichende Tests | Engineering |
+| 5 Mutation (gezielt) | Score auf kritischen Paketen | Überlebende Mutanten in Auth/Policy/… | Eng + Sec |
+| 6 Complexity / Churn | cognitive/cyclomatic, Diff-Größe | Review-Trigger, selten Hard-Fail | Eng + Tech Lead |
+| 7 Produkt-Kontrakte | OpenAPI/Schema, Pact, Invarianten | gebrochene API-/Domain-Garantien | Eng + API-Owner |
+| 8 Static AppSec | SAST, Secret-Scan (Brücke Kap. 3/5) | High-Findings ohne Ticket | Sec + Eng |
+
+Property-based Tests und Fuzzing gehören dort hin, wo Parser, Codecs,
+Policy-Engines oder Serialisierung die Domäne tragen – analog zur
+Fixture-Disziplin bei DLP (Kapitel 5), nicht als Default für jeden Diff.
+
+### Change-Risk C0–C4
+
+Tool-Risk (R0–R4) klassifiziert *was der Agent ausführen darf*.
+**Change-Risk** klassifiziert *was der Diff bedeutet*, wenn er landet.
+Dieselbe Metaphorik, anderer Gegenstand – bewusst parallel, damit Teams eine
+Sprache teilen.
+
+| Klasse | Beispiele | Mindest-Gates (Kalibrierungsbasis) | HITL |
+|--------|-----------|-------------------------------------|------|
+| **C0** | Docs, Kommentare, reine Formatierung | Lint | nein |
+| **C1** | reine Logik ohne Security-Rand, Tests ergänzend | Types + Tests + Coverage-Δ | Stichprobe |
+| **C2** | API-Rand, Persistenz, nichttriviale Refactors | + Integration wo berührt; Complexity-Trigger | Review |
+| **C3** | AuthZ/AuthN, Crypto, Payments, PII-Pfade, Migrations | + gezielte Mutation/Contracts; kein Auto-Merge | **ja** |
+| **C4** | IAM, CI-Gate-Config, Policy-Harness, Secret-Handling, Prod-Infra | dual control / Security-Review; Agent schwächt Gates nicht allein | **ja, eng** |
+
+Richtwerte – **ersetzen durch eigene Baseline**, sobald Messdaten da sind:
+
+- **Coverage-Δ:** geänderte ausführbare Zeilen sollen getestet sein; globales
+  „80 % Repo“ ohne Blick auf den Diff ist für Agent-PRs schwach.
+- **Mutation:** teuer – auf C3/C4-Pakete und Hotspots begrenzen; Startziel
+  eher „keine trivial überlebenden Mutanten in kritischen Pfaden“ als eine
+  fixe Prozentzahl fürs ganze Monorepo.
+- **Types:** strict wo der Stack es hergibt; Agent-Diffs, die strict absenken
+  oder flächig `any`/casts einführen, sind ein Security- und Wartungs-Signal.
+- **Complexity:** Soft-Gate (Review-Pflicht ab Schwelle), kein Fetisch einer
+  einzelnen cyclomatic-Zahl.
+
+### „Tests grün“ ist notwendig, nicht hinreichend
+
+Besonders riskant: der Agent ändert **Implementation und Tests in einem
+Schritt**. Dann beweist Grün oft nur Konsistenz, nicht Spezifikationstreue.
+Gegenmittel (kombinierbar):
+
+- Coverage-Δ und Review-Fokus auf *neue* Assertions, nicht nur grüne Häkchen,
+- Mutation auf kritischen Modulen (schwache Tests sterben sichtbar),
+- getrennte Policy: Prod-Code-Änderung vs. Schwächung von Gates/CI-Config
+  (C4),
+- Produkt-Kontrakte und Golden Fixtures, die der Agent nicht „mitbiegen“ darf
+  ohne C3/C4-Review.
+
+### Produkt-Kontrakte vs. Harness-Contract-Tests
+
+| | Harness-Contract-Test | Produkt-Kontrakt |
+|--|----------------------|------------------|
+| **Frage** | Entscheidet Policy/Router korrekt? | Hält der Patch API-/Domain-Garantien? |
+| **Artefakt** | allow/deny + Schema am Tool-Router | OpenAPI, Pact, runtime asserts, Invarianten |
+| **Owner** | Platform / Policy | Service- / API-Owner |
+
+Beide gehören in CI; sie ersetzen einander nicht.
+
+### Anti-Pattern der Product Gates
+
+1. **Nur globales Coverage-%** ohne Diff-Bezug  
+2. **Types aus oder strict absenken**, „damit der Agent durchkommt“  
+3. **Agent darf CI-Config und Gate-Schwellen** in demselben PR unreviewed
+   schwächen (Tampering; vgl. Anhang A)  
+4. **Snapshot-Spam** statt gezielter Assertions  
+5. **„LGTM weil grün“** bei C3/C4  
+6. **Mutation nie**, obwohl Auth/Policy agent-angefasst werden  
+
+**Happy Path:** Agent iteriert unter R1/R2; PR trifft Types → Tests →
+Coverage-Δ; C3-Diff mit Review und gezielter Mutation/Contracts; CI-Config
+unverändert oder eigener C4-Change mit Security-Review; Merge außerhalb der
+Session.
+
+**Fail:** Auto-Merge nach „Suite grün“, obwohl Tests mit dem Bug mitwanderten;
+oder Agent lockert `required_status_checks` im selben Diff wie Feature-Code.
+
+Mess-SLIs (orientierend, Produkt-Pipeline – **kein** Ersatz für Harness-SLIs):
+Anhang B, Abschnitt Product-Verify. Evidence-Anschluss (Gate-Configs als Living
+Evidence): Kapitel 10.

 ## Anti-Pattern

@@ -458,6 +552,8 @@ davon unterläuft Least Privilege – oft mit der Begründung „nur kurz“ ode
 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**  
+7. **Merge nur weil die Suite grün ist** – ohne Product Gates / Change-Risk
+   (Abschnitt oben)  

 **Mini-Szenario:** „Allow once“ für `curl` in einer Debugging-Session wird zur
 Session-Dauerfreigabe. Stunden später injiziert ein Issue-Kommentar denselben
@@ -487,15 +583,10 @@ Metriken, die Schärfe und Reibung gleichzeitig sichtbar machen:
 | Break-glass-Häufigkeit | Prozess- oder Policy-Problem |

 DX als First-Class-Steuerung (Abandon after Deny, Deny-to-Resolution,
-Fast-Path-Exceptions, Ownership): **Anhang D**.
-
-**Happy Path:** Deny nennt Regel und Alternativ-Tool; Exception mit TTL und
-Owner; Metriken zeigen stabile Deny-Rate ohne Anstieg der Break-glass-Fälle.
-
-**Was passiert bei Abweichung:** Undurchsichtige Denies ohne Ausnahmeweg
-führen zu lokalen Bypass-Skripten und unkontrollierten Chat-UIs. Steigt
-Break-glass-Häufigkeit, ist die Policy zu eng *oder* der Normalpfad zu
-schlecht – beides ist ein Betriebsproblem, kein „User-Fehler“.
+Fast-Path-Exceptions, Ownership): **Anhang D**. Actionable Denies (Regel +
+Alternativ-Tool + TTL-Exception) halten Break-glass und Schatten-Tools niedrig;
+undurchsichtige Denies ohne Ausnahmeweg sind ein Betriebsproblem, kein
+„User-Fehler“.

 ## Checkliste

@@ -508,17 +599,23 @@ Validierung, Approval und Output-Pfad ab – nicht die gesamte Enterprise-IAM.
 - [ ] R3/R4: Approval + Audit; Break-glass mit TTL
 - [ ] Tool-Output durch DLP; Denies actionable  
  *Startup:* `read`/`patch` allow; Shell nur sandboxed; R3/R4 aus
+- [ ] Product Gates dokumentiert: Types + Tests + Coverage-Δ; Change-Risk
+  C3/C4 mit Review; Agent schwächt CI-Gates nicht unreviewed

 ## 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.
+Product Gates begrenzen, *was davon in die Codebasis darf*: Types, Tests,
+Coverage-Δ, gezielt Mutation und Kontrakte – kalibriert, gestapelt, mit
+Change-Risk statt „grün = fertig“.

 Wer hier „später“ sagt, skaliert Seitenwirkungen mit jeder erfolgreichen
-Agent-Demo. Wer mit Deny by default, engen Tools und versionierter Policy
-startet, bekommt Kontrolle, die im Audit erklärbar bleibt – und die Teams
-mittragen, weil Denies actionable sind.
+Agent-Demo. Wer mit Deny by default, engen Tools, versionierter Policy und
+einer klaren Verify-Pipeline startet, bekommt Kontrolle, die im Audit
+erklärbar bleibt – und die Teams mittragen, weil Denies actionable und Merges
+nachvollziehbar sind.

 Kapitel 9 wendet sich dem Nachweis zu: Logging und Audit, ohne Secrets in die
 Logs zu schreiben.
@@ -16,13 +16,15 @@ Folie, sondern: **erklären, freigeben und prüfen können**.
 **Zwei Lesepfade.** Kleine Teams und Startups: zuerst **Anhang H** (sechs
 Controls, zwei Wochen). Die Patterns unten sind dann Erweiterungen, sobald AVV,
 Revision oder mehrere BU-Profile greifen – nicht die Einstiegshürde. Platform-
-und Security-Teams in größeren Orgs: dieses Kapitel linear, ergänzt um Anhang C
-(Reife) und F (30-Tage-Paket).
+und Security-Teams in größeren Orgs: dieses Kapitel linear, ergänzt um **Anhang C**
+(Evidence- und Reife-Tiefe) und **Anhang G** (30-Tage-Paket).

-Dieses Kapitel katalogisiert wiederkehrende Muster und mappt typische
-Audit-Fragen auf Systemnachweise. Wer die Patterns als Checkliste abhakt, ohne
-Happy Path und Abweichung im Betrieb zu definieren, produziert Design-Artefakte –
-keine operating effectiveness.
+Dieses Kapitel katalogisiert wiederkehrende Muster und führt das **kurze**
+Mapping Audit-Frage → Systemnachweis. Die erweiterte Tabelle (Nachweis +
+typische Schwächen), Evidence-Paket 2.0 und das Reifegradmodell stehen **einmal**
+in **Anhang C** – hier nicht dupliziert. Wer die Patterns als Checkliste abhakt,
+ohne Happy Path und Abweichung im Betrieb zu definieren, produziert
+Design-Artefakte – keine operating effectiveness.

 ## Ausgangslage: Agents berühren mehrere Kontrollwelten

@@ -201,44 +203,41 @@ erste Vorfall die Lücke zeigt.
 ### 8 — Nachweisordner / Control Evidence

 Audits fragen nicht nach Absicht, sondern nach Artefakten und Stichproben.
-Wiederkehrende Nachweise halten den Einstieg schlank; die Tiefe (Sampling-
-Methodik, Remediation-Kette, TTL-Historie, Re-Zertifizierung) steht in
-**Anhang C**.
+Einstieg (wiederkehrende Artefakte): Trust-Zonen-Diagramm (Kap. 4),
+Policy-/Detektor-Versionen inkl. Tests, Gateway-/Vendor-Liste mit Verträgen,
+Sampling von Audit-Logs (ohne Secrets), Incident- und Exception-Reports mit
+TTL, optional Awareness-Nachweise. Zur **Produkt-Verifikation** agent-
+geschriebener Änderungen (Kapitel 8) gehören außerdem: CI-Gate-Definition
+(Types, Tests, Coverage-Δ), Change-Risk-Policy (C0–C4) in derselben
+Versionierungslogik wie `policy_version`, ggf. Mutation-Config für kritische
+Pakete und der Nachweis, dass Agents CI-Schwellen nicht unreviewed absenken
+dürfen – Living Evidence, nicht Wiki-Absicht.

-Wiederkehrende Artefakte für Audits:
+**Alles Weitere einmal in Anhang C:** Evidence-Paket 2.0 (E1–E10),
+Sampling-Methodik, Remediation-Kette, TTL-Historie, Living Evidence und
+Re-Zertifizierung. Ohne diese Tiefe bleibt der Nachweisordner Design-Theater.

- 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)
+**Happy Path:** Evidence versioniert und periodisch frisch; Stichproben belegen
+operating effectiveness.

-Diese Liste ist der **Einstieg**. Was bei ernsthafter interner oder externer
-Prüfung an Sampling-Methodik, Remediation-Kette, TTL-Historie und
-Re-Zertifizierung verlangt wird – und wo der Enterprise-ready-Anspruch
-performativ bleibt, wenn nur Design-Artefakte vorliegen – steht in
-**Anhang C** (Evidence-Paket 2.0, Reifegradmodell, Living Evidence).
-
-**Happy Path:** Evidence liegt versioniert und periodisch aktualisiert vor;
-Stichproben belegen operating effectiveness, nicht nur „wir haben ein Diagramm“.
-
-**Was passiert bei Abweichung:** Ein Ordner mit veralteten PDFs und ohne
-Sampling übersteht den Kickoff, scheitert aber an „operating effectively“ –
-und blockiert die nächste Freigabestufe.
+**Was passiert bei Abweichung:** Veraltete PDFs ohne Sampling überstehen den
+Kickoff, scheitern an „operating effectively“ und blockieren die nächste Stufe.

 ## Mapping: Audit-Frage → Systemnachweis

-Revision und Security stellen wiederkehrende Fragen. Die folgende Tabelle mappt
-sie auf Systemnachweise – damit Antworten aus dem Harness und den Verträgen
-kommen, nicht aus dem Gedächtnis des letzten On-Calls.
+Revision und Security stellen wiederkehrende Fragen. Die **kurze** Tabelle
+unten ist der Einstieg für Stakeholder – Antworten aus Harness und Verträgen,
+nicht aus dem Gedächtnis des letzten On-Calls. **Kanonische Detailtabelle**
+(Frage → idealer Nachweis → typische reale Lücke) und Sampling-/Remediation-
+Logik: **einmal** in **Anhang C**.

-| Frage | Nachweis |
-|-------|----------|
+| Frage | Nachweis (Einstieg) |
+|-------|---------------------|
 | 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 |
+| Wie begrenzen wir *Merges* agent-geschriebener Diffs? | Product Gates + Change-Risk C0–C4 (Kap. 8), CI-Config als Evidence |
 | 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 |
@@ -35,68 +35,91 @@ Dieses Verzeichnis ersetzt keine Rechts- oder Audit-Beratung.
 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.
+7. Open-Source- und Plattform-Secret-Scanner (als *Inspiration für
+   Detektorklassen*, nicht als alleinige Enterprise-Control):  
+   - Gitleaks: <https://github.com/gitleaks/gitleaks>  
+   - TruffleHog: <https://github.com/trufflesecurity/trufflehog>  
+   - GitHub: *About secret scanning*  
+     <https://docs.github.com/en/code-security/secret-scanning/about-secret-scanning>

-8. OWASP: Materialien zu *Sensitive Information Disclosure* im LLM-/GenAI-
-   Kontext (siehe Top-10-Einträge der aktuellen Fassung unter [1]).
+8. OWASP LLM Top 10 – Eintrag *LLM02:2025 Sensitive Information Disclosure*
+   (Definition und Mitigationsskizzen); Einstieg über [1] bzw.  
+   <https://genai.owasp.org/llmrisk/llm022025-sensitive-information-disclosure/>

 ## Prompt Injection, Agents und Tool-Use

-9. OWASP: *Prompt Injection* (LLM01 in den LLM-Top-10) – Definitionen,
-   Szenarien, Mitigationsskizzen.  
-   Einstieg über [1].
+9. OWASP: *LLM01:2025 Prompt Injection* – Definitionen, Szenarien,
+   Mitigationsskizzen.  
+   <https://genai.owasp.org/llmrisk/llm01-prompt-injection/>  
+   Überblick auch ü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).
+10. Greshake, K. et al. (2023): *Not what you’ve signed up for: Compromising
+    Real-World LLM-Integrated Applications with Indirect Prompt Injection.*  
+    arXiv:2302.12173 – <https://arxiv.org/abs/2302.12173>  
+    (Klassiker zu *indirect* Injection in Retrieval-/Tool-Systemen; 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.
+11. Model Context Protocol (MCP): Spezifikation und Security-Überlegungen –
+    relevant für Permission- und Trust-Grenzen, sobald Agents externe
+    Tool-Server nutzen.  
+    <https://modelcontextprotocol.io/>  
+    Spezifikation: <https://spec.modelcontextprotocol.io/>

 ## 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).
+12. Container- und Runtime-Härtung (je nach Stack):  
+    - Docker Security:  
+      <https://docs.docker.com/engine/security/>  
+    - OCI / Linux: User Namespaces, read-only Root, Seccomp, AppArmor/SELinux,
+      nicht privilegierte Container – Distributions- und Runtime-Docs des
+      gewählten Stacks.

-13. gVisor / microVM-Ansätze (z. B. Firecracker-Ökosystem): Hersteller- und
-    Projekt-Docs zu Isolationseigenschaften und Betriebsgrenzen.
+13. Stärkere Isolation:  
+    - gVisor: <https://gvisor.dev/docs/>  
+    - Firecracker (microVM): <https://firecracker-microvm.github.io/>  
+      · <https://github.com/firecracker-microvm/firecracker>

 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.
+15. NIST SP 800-218: *Secure Software Development Framework (SSDF) Version 1.1*
+    – an die Agent-Pfade „install/build/test“ koppeln.  
+    <https://csrc.nist.gov/pubs/sp/800/218/final>

 ## 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).
+16. Strukturiertes Logging und Telemetrie:  
+    - OpenTelemetry Specification (Traces/Logs/Metrics):  
+      <https://opentelemetry.io/docs/specs/>  
+    - Interne SIEM-/Audit-Standards der Organisation (JSON-Events,
+      Korrelations-IDs, append-only Audit-Stores) – verbindlich für Nachweise.

-17. Incident-Response-Playbooks: NIST SP 800-61 (Computer Security Incident
-    Handling) als organisatorischer Rahmen – Agent-spezifisch in Kapitel 11
-    ausgeprägt.  
+17. Incident-Response-Playbooks: NIST SP 800-61 Rev. 2 (*Computer Security
+    Incident Handling Guide*) als organisatorischer Rahmen – Agent-spezifisch
+    in Kapitel 11 ausgeprägt. (Nachfolger/Revisionen bei NIST prüfen.)  
    <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.
+18. Internationaler Datentransfer und Auftragsverarbeitung (Orientierung, keine
+    Rechtsberatung):  
+    - EU-Kommission: Standardvertragsklauseln (SCC)  
+      <https://commission.europa.eu/law/law-topic/data-protection/international-dimension-data-protection/standard-contractual-clauses-scc_en>  
+    - EDPB: Guidelines und FAQ zum internationalen Transfer  
+      <https://www.edpb.europa.eu/>  
+    Maßgeblich bleiben die für Ihre Jurisdiktion aktuellen Texte.

 19. Anbieter-Dokumentationen zu *Training opt-out*, Zero Data Retention und
    Regional Endpoints – vertraglich *und* technisch (Gateway-Flags) prüfen.
+    Jeweils die aktuelle Enterprise-/API-Doku des gewählten Model-Vendors.

 ## Agent-Frameworks und TypeScript-Harnesses (Orientierung)

 20. Flue (Astro-Team): Runtime-/Harness-Dokumentation und Repository – Bezugspunkt
    dieses Buchs; API- und Target-Matrix jeweils am aktuellen Stand prüfen.
+    (Interne oder projektspezifische Docs des jeweiligen Releases; kein
+    stabiler Public-Canonical-URL-Anspruch in dieser Arbeitsbibliografie.)

 21. Mastra: *TypeScript AI Framework for Agents and Apps* – Agents, Workflows,
    Memory, Observability, Durable Agents, optional Platform.  
@@ -117,7 +140,8 @@ Dieses Verzeichnis ersetzt keine Rechts- oder Audit-Beratung.

 25. LangGraph.js / LangChain.js: explizite State-Graphs und Agent-Orchestrierung
    im JS/TS-Ökosystem – Python-Parity und Hosting-Grenzen prüfen.  
-    Einstieg über die aktuelle LangChain-/LangGraph-Dokumentation.
+    LangGraph: <https://langchain-ai.github.io/langgraphjs/>  
+    LangChain.js: <https://js.langchain.com/>

 26. OpenAI Agents SDK for TypeScript: leichtgewichtige Agents, Handoffs,
    Guardrails, Sandbox Agents, Tracing.  
@@ -125,7 +149,23 @@ Dieses Verzeichnis ersetzt keine Rechts- oder Audit-Beratung.

 27. CrewAI: rollenbasierte Multi-Agent-Orchestrierung im Python-Ökosystem –
    Kontrastfolie zu TypeScript-Harnesses, nicht als Drop-in-Ersatz.  
-    Projektdokumentation des jeweiligen Releases.
+    <https://docs.crewai.com/>
+
+## Verifikation, Tests und Secure SDLC (Orientierung)
+
+28. OWASP: *Application Security Verification Standard (ASVS)* – Prüftiefe und
+    Verifikationsanforderungen (als Orientierungsraster, nicht als Agent-Checkliste).  
+    <https://owasp.org/www-project-application-security-verification-standard/>
+
+29. Jia, Y. & Harman, M. (2011): *An Analysis and Survey of the Development of
+    Mutation Testing.* IEEE Transactions on Software Engineering – konzeptioneller
+    Einstieg Mutation Testing (Tooling 2026 separat wählen).
+
+30. TypeScript Handbook: *Type Checking JavaScript Files* / Strictness-Optionen
+    (als Beispiel einer billigen harten Verify-Kante; analog mypy/pyright, go vet).  
+    <https://www.typescriptlang.org/docs/handbook/type-checking-javascript-files.html>
+
+    Siehe auch SSDF (Eintrag 15) für Verifikation im Secure SDLC.

 ## Weiterführende Themencluster (für eigene Vertiefung)

@@ -134,6 +174,7 @@ Dieses Verzeichnis ersetzt keine Rechts- oder Audit-Beratung.
 | High-Entropy- und Pattern-Secret-Detection | Kapitel 5–6 |
 | Agent frameworks & tool routers | Kapitel 2, 7–8, Anhang E |
 | Least privilege & policy-as-code | Kapitel 8, 10 |
+| Product Gates / Mutation / Coverage-Δ | Kapitel 8, Anhang B |
 | Sandbox escape literature | Kapitel 7 |
 | AI governance / model risk management | Kapitel 10 |
 | Blameless postmortems / SRE | Kapitel 11 |
@@ -33,6 +33,8 @@ Im Einzelnen geht es um:
 - wie DLP (Pattern Matching) und Entropie-Filter Secrets und heikle Fragmente
  abfangen,
 - wie Sandboxes und Tool-Permissions den *Handlungsraum* begrenzen,
+- wie projektseitige Verifikationsgates (Types, Tests, Coverage, ggf. Mutation)
+  agent-geschriebenen Code vor dem Merge absichern (Kapitel 8),
 - 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.
@@ -67,6 +69,10 @@ Ebenso klar ist, was dieses Buch bewusst *nicht* liefert:
 - Vendor-Vergleiche mit Siegerpodest
 - Vollständige Rechtsberatung
 - Ein einziges „sicheres Default-Prompt“
+- ein vollständiges Testmethodik- oder TDD-Lehrbuch – wohl aber das
+  agent-spezifische Muster **Product Gates** (Kapitel 8): Harness begrenzt
+  Handlung und Daten; Korrektheit und Wartbarkeit des Diffs verlangen
+  zusätzlich projektseitige Verify-Pipelines

 Stattdessen: Architekturentscheidungen, Patterns, die man bauen und messen
 kann, und die Arbeitsannahme **Deny by default**. Nicht als Moralpredigt,
@@ -113,6 +119,42 @@ nicht als Dekoration. Fallstudien mit Messwerten: **Anhang B**. Flue-Reife und
 Kombinationsstrategie: **Anhang E**. Optionales Mapping der Buch-Nähte auf Flue:
 **Anhang F**.

+### Anhang-Matrix: was muss, was wartet
+
+Die Anhänge sind **größer als der Kern** – absichtlich, aber nicht alle
+gleichwertig. Nutzen Sie die Matrix, bevor Sie „hinten noch alles“ lesen.
+**Kanonischer Einführungsstrang:** Anhang H (zwei Wochen, Startup) → Anhang G
+(30 Tage) → Anhänge B/C (Messung und Audit-Reife). Der Rest ist Vertiefung oder
+Supplement.
+
+| Anhang | Rolle | Priorität | Wann |
+|--------|-------|-----------|------|
+| **H** Schnelleinstieg Startups | Sechs Controls, zwei Wochen | **Startup-Muss** | Ohne Security-Abteilung; vor G |
+| **G** Einführungs-Paket 30 Tage | Operativer Rollout mit DoD | **Einführung** | Nach H oder parallel zu Kap. 4–9 |
+| **A** Erweitertes Bedrohungsmodell | Pfade D5–D12 | **Bei Scope-Erweiterung** | Memory, Multi-Agent, MCP, Vendor-Nebenkanäle |
+| **B** Empirie & Quantifizierung | SLIs, SLOs, Fallstudien | **Bei Messung / Audit** | Nach ersten Shadow-Läufen; Details zu Kap. 11 |
+| **C** Audit- & Freigabe-Reife | Evidence, Freigabestufen | **Bei Audit / Enterprise** | Vor formaler Freigabe; Ergänzung zu Kap. 10 |
+| **D** Developer Experience | Deny-DX, Adoption | **Bei Reibung** | Wenn Denies umgangen werden |
+| **E** Alternativen & Frameworks | Dimensionen + Kurzprofile | **Optional / verfällt** | Framework-Wahl; Geltungsstand prüfen (≤12 Monate); Details online |
+| **F** Mapping Flue-Patterns | Naht → Flue-Begriff | **Optional** | Nur wenn Flue der konkrete Harness ist |
+
+**Lesen Sie nicht linear A–H.** Der Kern (Kapitel 1–11) bleibt die Autorität;
+Anhänge erweitern, messen und operationalisieren – sie ersetzen die Kapitel
+nicht.
+
+### Schnellnavigation (Parts)
+
+| Part | Inhalt | Einstieg |
+|------|--------|----------|
+| **I – Warum & Modell** | Kap. 1–3 | Motivation, Flue/Harness, Bedrohungsmodell + OWASP |
+| **II – Kontrollschichten** | Kap. 4–8 | Datenfluss, DLP, Entropie, Sandbox, Permissions |
+| **III – Nachweis & Betrieb** | Kap. 9–11 | Audit-Events, Enterprise-Patterns, Playbooks |
+| **IV – Anhänge** | A–H | Matrix oben; Strang H → G → B/C |
+| **V – Apparat** | Glossar, Literatur, Kolophon | Nachschlagen |
+
+Diagramm-Policy: Fachlabels in Abbildungen sind **deutsch** (IDs wie `Z0`,
+`R3`, `policy_version` bleiben technisch); siehe `design/diagram-workflow.md`.
+
 ## Ein Satz vor dem ersten Kapitel

 Coding-Agents verändern, wie Software entsteht. Ob dabei unbemerkt Daten und
@@ -314,10 +314,10 @@ def render_f05() -> None:
 def render_f06() -> None:
    W, H = 1500, 820
    levels = [
-        (1, "Process isolation", "User, Limits, Timeouts", "IDE / lesen", CYAN),
+        (1, "Prozessisolation", "User, Limits, Timeouts", "IDE / lesen", CYAN),
        (2, "FS-Jail / Workspace", "nur Worktree", "lokales Schreiben", TEAL),
-        (3, "Network policy", "Egress deny-by-default", "Proxy / Gateway", BLUE),
-        (4, "Container-Ephemeral", "Image, TTL, Tear-down", "CI / gemischter Trust", AMBER),
+        (3, "Netzwerk-Policy", "Egress deny-by-default", "Proxy / Gateway", BLUE),
+        (4, "Ephemerer Container", "Image, TTL, Tear-down", "CI / gemischter Trust", AMBER),
        (5, "Remote / starke Isolation", "separate Runtime", "untrusted / reguliert", RED),
    ]
    parts = [
@@ -332,7 +332,7 @@ def render_f06() -> None:
        parts.append(f'<text x="{x+w/2}" y="{y+30}" text-anchor="middle" class="lbl" style="fill:{col}">Stufe {n}</text>')
        parts.append(f'<text x="{x+w/2}" y="{y+55}" text-anchor="middle" class="box">{title}</text>')
        parts.append(f'<text x="{x+w/2}" y="{y+78}" text-anchor="middle" class="xs">{detail}</text>')
-        parts.append(f'<text x="{x+w/2}" y="{y+h-18}" text-anchor="middle" class="tiny">Use: {use}</text>')
+        parts.append(f'<text x="{x+w/2}" y="{y+h-18}" text-anchor="middle" class="tiny">Einsatz: {use}</text>')
    parts.append(glass(80, 100, 640, 115, accent=TEAL))
    parts.append(f'<text x="100" y="138" class="h" style="fill:{TEAL}">Happy Path</text>')
    parts.append(f'<text x="100" y="168" class="s">Risk-Klasse (Kap. 8) wählt Stufe · R2 oft 3–4 · R3/R4 + Approval</text>')
@@ -174,10 +174,10 @@ def render_f06() -> None:
    """Sandbox levels 1–5: isolation up, host blast radius down."""
    W, H = 1500, 820
    levels = [
-        (1, "Process isolation", "OS-User, Limits, Timeouts", "IDE / lesen", "#67e8f9"),
+        (1, "Prozessisolation", "OS-User, Limits, Timeouts", "IDE / lesen", "#67e8f9"),
        (2, "FS-Jail / Workspace", "nur Worktree, kein Host-Home", "lokales Schreiben", "#2dd4bf"),
-        (3, "Network policy", "Egress deny-by-default + Allowlist", "Proxy / Gateway", "#60a5fa"),
-        (4, "Container-Ephemeral", "frisches Image, TTL, Tear-down", "CI / gemischter Trust", "#fbbf24"),
+        (3, "Netzwerk-Policy", "Egress deny-by-default + Allowlist", "Proxy / Gateway", "#60a5fa"),
+        (4, "Ephemerer Container", "frisches Image, TTL, Tear-down", "CI / gemischter Trust", "#fbbf24"),
        (5, "Remote / starke Isolation", "separate Runtime, starke Grenze", "untrusted / reguliert", "#f87171"),
    ]
    parts = [