Policy Engine

Stand: 2026-05-26

Ziel

Die Policy Engine entscheidet, ob eine geplante Chain aus Governance-Sicht blockiert, eskaliert oder mit Standard-Approval weitergeplant werden darf.

Status

• read-only
• keine Writes
• keine automatische Scheduling-Ausfuehrung
• keine automatische Reconciliation

Pruefungen

• forbidden systems
• forbidden action combinations
• Approval Escalation
• Maintenance Window
• Concurrency Protection
• Dependency Locks
• Cleanup Cooldown
• Blast Radius
• Drift-/Reconciliation-Status

Forbidden Combinations

Automatisch blockiert oder eskaliert:

• parallele destructive Chains
• DNS, NPM und Firewall in einer Chain kombiniert
• Cleanup Execute ohne Cooldown
• produktive Changes ausserhalb Maintenance Window ohne Emergency Override
• AD-/Exchange-/Intune-Writes in diesem Layer
• aktive Dependency Locks

API

• GET /policy-risk/policy
• GET /policy-risk/lxc-124
• POST /policy-risk/evaluate

Alle Endpunkte sind read-only.

Dependency Lock Integration

Die Policy Engine beruecksichtigt Lock-Status:

• aktiver Write Lock blockiert Execution
• Cleanup Lock blockiert destruktive Folgeschritte
• stale Lock erzeugt Manual-Review-Warnung
• Emergency Hold wirkt als globaler Block

OpenCode muss policy_decision=blocked respektieren und darf keinen Execute starten.

Wenn ein Lock-Konflikt an die Policy Engine uebergeben wird, wird daraus ein harter Block. Stale Locks erzeugen eine Manual-Review-Constraint, orphaned oder failed-release Locks blockieren das Zielobjekt bis zur manuellen Klaerung.

Die Policy Engine liest den operationalen SQLite-Lock-Store. JSONL-Historie bleibt Audit, aber nicht mehr Entscheidungsquelle fuer aktive Locks.

Lock Recovery darf Policy-Blocker nicht umgehen. Ein Recovery Execute ist nur erlaubt, wenn die Verification bestaetigt, dass keine aktive Chain, kein ungepruefter Rollback und kein relevanter Drift-Konflikt offen ist.