Dienstkonto-Flag: Gate in beide Richtungen, richtige Rechte-Domaene (R184)

R184-01: Setzen war gegatet, Entfernen nicht - und das Entfernen ist der
gefaehrlichere Weg. Der Heartbeat-Wachhund fragt isServiceAccount:true ab,
haengt also am Live-Kennzeichen; die Hypothese des Pentesters war richtig,
Un-Flaggen kappt die Wache. Genau das stilllegen-und-auf-Stille-setzen, gegen
das der Tripwire gebaut wurde. Fix: Gate in beide Richtungen mit eigenem
Wortlaut beim Entfernen.

Wichtiger noch: Die Aenderung geht jetzt zusaetzlich in den Alarmkanal
(PERMISSION_CHANGED/CRITICAL), nicht nur ins Audit-Log - eine CRITICAL-Zeile
muss jemand lesen, das war die R183-02-Klasse.

R184-02: Das Kennzeichen hing an users:update, obwohl es ein
Audit-Governance-Eingriff ist - Geschwister von retention-shorten,
seal-backlog, rehash und cleanup, die alle audit:admin verlangen. Heute
deckungsgleich, aber jede kuenftige Rolle mit Benutzer-bearbeiten haette still
Login-Alarme-herunterstufen geerbt. Fix: zusaetzliche Pruefung auf audit:admin.

Verifiziert: Entfernen ohne Bestaetigung jetzt 400 statt 200, ohne audit:admin
403, zwei CRITICAL-Meldungen im Alarmkanal.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

docs/todo.md

@@ -97,6 +97,32 @@ isolierte Instanz (keine Multi-Tenancy im Code), Provisioning + Abrechnung
 
 ## ✅ Erledigt
 
+- [x] **🔓 Dienstkonto-Flag: Gate in beide Richtungen, richtige Rechte-Domaene (Pentest R184-01/-02)** (2026-08-24)
+  - **R184-01** – Setzen war gegatet, **Entfernen nicht**. Und das Entfernen ist
+    der gefaehrlichere Weg: Der Heartbeat-Wachhund fragt `isServiceAccount:
+    true` ab, haengt also am **Live-Kennzeichen**. Seine Hypothese war damit
+    richtig – Un-Flaggen kappt die Wache und macht genau das moeglich, wogegen
+    der Tripwire gebaut wurde: stilllegen und auf Stille setzen.
+    Fix: Gate in beide Richtungen, mit unterschiedlichem Wortlaut (beim
+    Entfernen: „faellt aus der Ueberwachung heraus“).
+  - **Wichtiger noch:** Die Aenderung geht jetzt zusaetzlich in den
+    **Alarmkanal** (`PERMISSION_CHANGED`/CRITICAL), nicht nur ins Audit-Log.
+    Eine CRITICAL-Zeile muss jemand LESEN – das war die R183-02-Klasse. Jetzt
+    reagiert die Ueberwachung automatisch.
+  - **R184-02** – Das Kennzeichen hing an `users:update`, einer
+    Anwendungs-Berechtigung, obwohl es ein Audit-Governance-Eingriff ist –
+    Geschwister von retention-shorten, seal-backlog, rehash und cleanup, die
+    alle `audit:admin` verlangen. Heute deckungsgleich, aber jede kuenftige
+    Rolle mit „Benutzer bearbeiten“ haette still „Login-Alarme herunterstufen“
+    geerbt. Fix: zusaetzliche Pruefung auf `audit:admin` im Controller.
+  - Verifiziert: Setzen mit `audit:admin` 200 · Entfernen ohne Bestaetigung
+    **400** (vorher 200) · mit Bestaetigung 200 · ohne `audit:admin` **403** ·
+    zwei CRITICAL-Meldungen im Alarmkanal mit sprechendem Text. Frontend sendet
+    die Bestaetigung in beide Richtungen. `npm run build` und Backend-`tsc`
+    gruen.
+  - Seine Non-Findings uebernommen: Selbst-Block nicht ueber Methode, Pfad oder
+    ID-Aliasing umgehbar; Create streift das Feld ab; Confirm-Gate strikt.
+
 - [x] **🔒 Dienstkonto-Kennzeichen gegatet, laut protokolliert, kein Selbstbedienen (Pentest R184)** (2026-08-24)
   - Der Pentester hat sofort erkannt, was das Scharfschalten des Feldes
     bedeutet: Ein Attribut, das die **Alarmstufe senkt**, war ueber den