ACP-gebundene Befehlsautorisierung (Vorschlag)

Status: Vorgeschlagen, noch nicht implementiert.

Dieses Dokument beschreibt ein langfristiges Autorisierungsmodell für native Befehle in ACP-gebundenen Konversationen. Es ist ein Experiments-Vorschlag und ersetzt nicht das aktuelle Produktionsverhalten.

Für implementiertes Verhalten, lies Quellcode und Tests in:

  • src/telegram/bot-native-commands.ts
  • src/discord/monitor/native-command.ts
  • src/auto-reply/reply/commands-core.ts

Problem

Heute haben wir befehlsspezifische Prüfungen (z. B. /new und /reset), die auch in ACP-gebundenen Kanälen/Topics funktionieren müssen, selbst wenn Allowlists leer sind. Das löst unmittelbaren UX-Schmerz, aber befehlsnamenbasierte Ausnahmen skalieren nicht.

Langfristige Form

Befehlsautorisierung von Ad-hoc-Handler-Logik zu Befehlsmetadaten plus einem gemeinsamen Policy-Evaluator verschieben.

1) Auth-Policy-Metadaten zu Befehlsdefinitionen hinzufügen

Jede Befehlsdefinition sollte eine Auth-Policy deklarieren. Beispielform:

type CommandAuthPolicy =
  | { mode: "owner_or_allowlist" } // Standard, aktuelles striktes Verhalten
  | { mode: "bound_acp_or_owner_or_allowlist" } // in explizit gebundenen ACP-Konversationen erlauben
  | { mode: "owner_only" };

/new und /reset würden bound_acp_or_owner_or_allowlist verwenden. Die meisten anderen Befehle würden bei owner_or_allowlist bleiben.

2) Einen Evaluator über Kanäle hinweg teilen

Einen Helper einführen, der Befehlsauth evaluiert mit:

  • Befehls-Policy-Metadaten
  • Absender-Autorisierungsstatus
  • Aufgelöstem Konversations-Binding-Status

Sowohl Telegram- als auch Discord-Native-Handler sollten denselben Helper aufrufen, um Verhaltensdrift zu vermeiden.

3) Binding-Match als Bypass-Grenze verwenden

Wenn die Policy den ACP-gebundenen Bypass erlaubt, nur autorisieren wenn ein konfiguriertes Binding-Match für die aktuelle Konversation aufgelöst wurde (nicht nur weil der aktuelle Session-Key ACP-artig aussieht).

Das hält die Grenze explizit und minimiert versehentliche Erweiterung.

Warum das besser ist

  • Skaliert für zukünftige Befehle ohne zusätzliche Befehlsnamen-Konditionale.
  • Hält Verhalten über Kanäle hinweg konsistent.
  • Bewahrt das aktuelle Sicherheitsmodell durch Erfordernis eines expliziten Binding-Match.
  • Lässt Allowlists optionale Härtung statt universelle Anforderung bleiben.

Rollout-Plan (zukünftig)

  1. Befehls-Auth-Policy-Feld zu Command-Registry-Typen und Befehlsdaten hinzufügen.
  2. Gemeinsamen Evaluator implementieren und Telegram + Discord Native-Handler migrieren.
  3. /new und /reset auf metadatengesteuerte Policy verschieben.
  4. Tests pro Policy-Modus und Kanaloberfläche hinzufügen.

Nicht-Ziele

  • Dieser Vorschlag ändert nicht das ACP-Session-Lifecycle-Verhalten.
  • Dieser Vorschlag erfordert keine Allowlists für alle ACP-gebundenen Befehle.
  • Dieser Vorschlag ändert nicht bestehende Route-Binding-Semantiken.

Hinweis

Dieser Vorschlag ist bewusst additiv und löscht oder ersetzt keine bestehenden Experiments-Dokumente.

Weiter
Overview
arrow_forward