Explicit Request Autonomy¶

Ziel¶

Eine ausdrueckliche Aenderungsanweisung eines authentifizierten Benutzers kann Low- und Medium-Risk-Changes ohne zweite manuelle Approval-Schleife ausfuehren. Preflight, Prestate, Backup, Locking, Verification, Audit und Rollback bleiben verpflichtend.

Vertrauensgrenze¶

explicit_change_request ist kein frei vom MCP-Client uebernehmbares Feld. Nur ein authentifiziertes Gateway darf einen Request-Kontext mit Quelle, Benutzer-ID und Request-ID an execute_controlled uebergeben. Ohne diese Attestierung ist Auto-Execution blockiert.

Auto-Execution¶

Der Server erlaubt sie nur bei Low oder Medium Risk, wenn alle Bedingungen erfuellt sind:

expliziter Benutzerauftrag durch codex_task oder lanstyle_gateway attestiert
Scope klar
Preflight erfolgreich
Backup oder Prestate verfuegbar
Rollbackpfad vorhanden
kein Lock- oder Policy-Konflikt
LANSTYLE_EXPLICIT_REQUEST_AUTONOMY_ENABLED=true ist bewusst serverseitig gesetzt

Die letzte Bedingung bleibt bis zum erfolgreichen Staging-Rollout deaktiviert.

Weiterhin Manuell¶

Manuelle Approval bleibt Pflicht fuer destruktive oder irreversible Aktionen, hohen Blast Radius, Privileg-Eskalation, tenantweite Identity-Aenderungen und Scope-Erweiterungen. Fehlende Attestierung, Prestate, Rollback oder ein Lock blockieren die Ausfuehrung.

RBAC¶

autonomous_operator ist eine separate Rolle fuer Low-/Medium-Scoped-Writes. Bestehende operator-Tokens behalten ihre bisherigen Read-only-, Preflight- und Mock-Rechte. Das Token-Mapping wird erst mit dem Runtime-Rollout im Vaultwarden-/Broker-gesteuerten RBAC-Store gesetzt.

Rollout¶

Gateway-Attestierung serverseitig implementieren und gegen eine echte Codex-Task-ID testen.
Proxmox- und Gitea-Actions mit kundenbezogenem Context, Broker und Preflight implementieren.
Staging mit einem dedizierten autonomous_operator-Token validieren.
Runtime-Flag aktivieren und Audit-/Rollback-Proben pruefen.

Bis dahin bleibt die produktive Runtime unveraendert und Live-Write bleibt deaktiviert.