ki-eit/12-security-review-und-governance.md

12. Security, Review und Governance

Kern: Agent-Diffs sind Contractor-Diffs: Review, Scanner, keine Secrets, HITL bei Prod und Destruktion — plus enge Permissions in Shared Repos.

Agents schreiben schnell Code, der aussieht wie euer Stack — inklusive Security-Defaults, die „erstmal zum Testen“ offen sind. Das ist kein Spezialproblem eines Produkts; es ist die Konsequenz aus Geschwindigkeit ohne Invariants. Weiches Memory (Instructions) sagt wie; hartes (Permissions, CI, Merge-Policy) begrenzt was überhaupt geht. Generische Agent-Security: Coding Agents in der Praxis. Optionale Copilot-Permissions-Produktiefe: Der Copilot-CLI-Harness. Hier die Enterprise-Stack-Übersetzung.

{width=90%}

12.1 Die typische Security-Session, die schiefgeht

Auftrag: „POST /api/orders anlegen.“ Der Agent liefert Endpoint, Service, Test — und permitAll „damit die Spec durchläuft“, ein Debug-Log mit Authorization-Header, und in der Beispiel-YAML einen scheinbaren Secret-Wert (sk-…, ghp_…), der verdächtig nach Copy-Paste aus dem Chat aussieht — kein YOUR_TOKEN-Platzhalter. Unit-Tests grün. Reviewer findet die Lücke erst im PR. Parallel hat jemand in der Session /yolo an, weil „sonst nervt die Approval“.

Du merkst den Drift daran, dass:

• Security im PR-Text als TODO steht, im Code aber produktiv erreichbar ist,
• Secrets (API-Keys, Passwörter, Bearer-Werte) in Diff, Log oder Instructions landen,
• der Agent destruktive oder Deploy-Tools ohne HITL ausführen darf,
• Review nur Stil diskutiert und AuthZ überspringt.

Was du tust: Slice stoppen, Invariants und Permissions nachziehen, Security-Touch als gelb/rot markieren — nicht „noch schnell die Spec grün machen“ mit offener Policy.

12.2 Stack-Invariants

Invariants gehören in Root-Instructions (kurz) und Package-AGENTS.md (konkret) — und in den Review, nicht nur ins Wiki.

Invariant	Praxis im Stack
Keine Secrets	nicht in Code, Logs, Compact, Handoff, Instructions; nur Platzhalter (YOUR_TOKEN, your-org/your-repo)
AuthZ an neuen API-Endpoints	Spring / Quarkus Security: kein Default-permitAll für produktive Pfade
FE-Auth (Angular)	Guards/CanActivate (o. Ä.) und öffentliche Routen bewusst; im Merge-Diff nicht aushebeln; Token-Storage/Interceptor nach Golden Path
Management-Fläche	Actuator/Management-Endpoints bewusst; nicht „alles offen lokal = Merge“
CORS / JWT	Konfiguration reviewen; zu breites @CrossOrigin ist Signal
Dependencies	neue Starter/Libs nur mit Auftrag; Supply-Chain im Heavy/Scanner
Contract	API-Änderungen mit OpenAPI; keine stillen Breaking Changes

Framework-Fallen: Kap. 6.4 (Spring), 7 (Quarkus), 5 (Angular Guards). Skill: templates/skill-security-pass-enterprise/, templates/skill-spring-security-endpoint/.

False green: Unit-Tests grün bei weicher Security — nur Happy-Path-@WithMockUser / kein Negativ-Test / Security-Filter im Slice abgeschaltet. DoD an AuthZ-relevanten Diffs: positiv und negativ (401/403 bzw. Guard blockt). Review-Frage: Welcher Test verbietet unauthentifizierten Zugriff? Ohne Antwort: gelb/rot, nicht „CI war grün“.

Do this	Avoid that
Positiv- und Negativ-Test an AuthZ (API und FE-Guard wo relevant)	Nur Happy-Path-Mocks; Security-Filter im Test abgeschaltet
Security-DoD-Zeile im Task	„Security später / TODO“ im Merge-Diff
Secrets-Scan in Heavy wo möglich	„war nur Beispiel“ mit echtem Secret-Wert

12.3 Review-Fokus bei Agent-Code

Agent-Diffs sind Contractor-Diffs: schneller produziert, oft breiter als der Auftrag, stilistisch überzeugend auch wenn falsch. Review-Budget (Kap. 3) und Ampel gelten hier doppelt.

Priorität (typisch):

1. API-AuthZ und FE-Guards/Routen an neuen oder geänderten Endpoints und public routes
2. False green — fehlt der Negativ-Test / die Aussage „unauth verboten“?
3. Injection / mass assignment — ungebundene Felder, vertrauenswürdige Client-IDs
4. Dependency-Diffs — neue Libraries, Version-Jumps
5. zu breite permitAll / CORS / public routes
6. Diff matcht Auftrag und Golden Path — Standalone vs. NgModule, Layer, kein Drive-by
7. Secrets und Logs — API-Keys, PII, Stacktraces mit sensiblen Headers

Checkliste: checklists/review-agent-diff-enterprise.md. Severity-Sprache (Blocker / Should / Nit) hilft Teach-back (Kap. 3.3): dreimal derselbe Security-Fehler → Rule/Skill am selben Tag in einer eigenen kurzen Session, nicht nur PR-Kommentar und nicht im Feature-Merge verstecken.

Ampel (Budget/Triage) und Severity (Kommentar-Sprache) sind komplementär — nicht synonym. Ampel steuert wer wie tief reviewt; Severity steuert was im PR-Kommentar steht:

Ampel (Kap. 3.3)	Review-Tiefe	Typische Severity im Diff
Grün	Routine, peer ok	Nit; kein Blocker
Gelb	Senior-Blick	Should; Security oft Blocker bis geklärt
Rot	HITL / prod-nah	Blocker vor Merge

Surfaces: Checkliste und Severity im PR-Ritual (weich); Permissions, Hooks und CI als harte Gates (Anhang C). Optionale Copilot-Flags: templates/permissions-hints-enterprise.md.

Teach-back ist hier kein Soft-Skill-Extra: wiederkehrende permitAll-Diffs sind ein Repo-Bug in den Instructions, kein Persönlichkeitsproblem des Agents.

12.4 Agent-Governance (Enterprise)

Hebel	Praxis
Workspace Trust / Trusted Directory	vor Session; kein Agent auf untrusted Roots
Permissions	Deny für rm, force-push, Deploy; Allowlist an mvnw/npm test — Copilot-Surface-Startmuster: templates/permissions-hints-enterprise.md (andere Agents: Policy analog mappen, Anhang C)
YOLO / Allow-all	kein Team-Default in gemeinsamen Repos
Instructions	keine Secrets; nur Platzhalter; Security-Invariants knapper Satz
CI programmatic	Credential-Scope und Policy teamweit; produktspezifisch (optional Copilot: Der Copilot-CLI-Harness)

Weich (Instructions, Skills) steuert Verhalten; hart (Permissions, Hooks, CI) begrenzt Schaden (Kap. 4.5, 10). In Shared Monorepos ist YOLO Geschwindigkeit auf Kredit — die Rechnung kommt im Review oder im Incident.

HITL (Human in the Loop) bei: Produktion, destruktiven Shell-Befehlen, Secret-Stores, Deploy, breiten DB-Schreibrechten über MCP (Kap. 10.5). Der Agent darf vorschlagen; der Mensch bestätigt, wo Schaden irreversibel ist.

Do this	Avoid that
Deny-Default + enge Allowlist	Team-/yolo „weil schneller“
Permissions wie Code reviewen	Jeder dev hat private Super-Allowlist still
HITL an Prod/Destruktion	Agent mit Deploy-Credential im Chat-Default

12.5 Governance-Ritual (minimal)

1. Session-Start: Trust, Instructions geladen, Permissions eng (checklists/session-start-angular-java.md).
2. Slice: Security-Touchpoints im Task benennen (AuthZ ja/nein; welche Rolle).
3. Verify: Tight-Loop inkl. Security-Tests wo der Slice sie braucht (Kap. 9).
4. Review: Checkliste Agent-Diff; Blocker vor Merge.
5. Heavy: Scanner/SBOM/Policy-Gates nach Team-Standard — gelabelt, nicht als Tight-Loop.
6. Teach-back: wiederkehrende Fehler → Instructions/Skill/AGENTS.md am selben Tag — in eigener kurzer Session (Kap. 2.5, 3.3).

{width=90%}

Das Ritual ist absichtlich langweilig. Spannung soll im Diff stecken, nicht im „darf der Agent das?“-Theater.

Key Takeaways

• Security-Invariants in Instructions und AGENTS.md — und im Review erzwingen.
• Agent-Diffs wie Contractor-Diffs lesen: AuthZ, Dependencies, Scope, Secrets.
• HITL bei Prod und Destruktion; kein YOLO als Team-Default.
• Permissions sind Teil der Enterprise-DoD, nicht „nice to have“.
• Teach-back schließt den Kreis: Fehler → Repo-Wahrheit, nicht nur Kommentar.

Praktische nächste Schritte

1. Invariants in Root-Instructions + Package-AGENTS.md (drei bis fünf harte Sätze).
2. checklists/review-agent-diff-enterprise.md im PR-Ritual verankern.
3. Permissions-Policy teamweit festzurren (Copilot-Startmuster: templates/permissions-hints-enterprise.md; andere Surfaces: Anhang C).
4. Einmal bewusst einen Security-Touch-Slice mit Negativ-Test und HITL fahren.
5. Danach Kap. 13 — Anti-Patterns und Schluss: was ihr behalten wollt, wenn der Hype weiterzieht.