Berechtigungs-Scopes

Scopes übersetzen die CQRS-Trennung in Richtlinien. Sie erlauben dir, einem Agenten genau die Macht zu geben, die er braucht – und nicht mehr.

Read-only-Keys

Ein Key kann read-only sein: Er kann jede Query und keinen Command ausführen. Das ist die Standardwahl für alles, was nur lesen muss – Dashboards, Reporting-Agenten, Such-Integrationen. Ein Read-only-Key kann Daten nicht aus Versehen ändern, weil er es konstruktionsbedingt nicht kann.

Das bildet sich direkt auf CQRS ab: Lese-Scopes decken Queries ab; alles, was Zustand ändert, erfordert einen Key mit Schreibrechten. Siehe CQRS.

Auf bestimmte Fähigkeiten begrenzt

Über die Lese-/Schreib-Trennung hinaus ist der Zugriff auf bestimmte Fähigkeiten gescoped. Ein Agent, der Dokumente verarbeitet, bekommt Dokumenten-Endpoints; Bankaktionen bekommt er nicht. Bei Vendor-Integrationen läuft die Fähigkeitssteuerung pro Integrationstyp – jede Integration erreicht genau die Endpoints, die ihr gewährt wurden.

Destruktive Aktionen separat gesteuert

Löschen ist nicht dasselbe wie Ändern. Destruktive Aktionen sind separat von normalen Schreibrechten gesteuert: Ein Key, der Dokumente anlegen und ändern darf, kann sie trotzdem nicht löschen, solange das nicht explizit gewährt ist. Zusammen mit Soft Delete und Audit-Trail bedeutet das: Ein Agent kann seine Arbeit tun, während die schädlichste Klasse von Aktionen hinter einer zusätzlichen Schwelle bleibt.

Scopes in der Praxis wählen

• Reporting-Agent → read-only.
• Support-Bot, der Notizen erfasst → Lesen + Schreiben, fähigkeitsbegrenzt, keine destruktiven Aktionen.
• Migrations-Werkzeug → den vollen Umfang, den es braucht, betrieben von einem Unternehmens-Agenten – und deaktiviert, sobald die Migration abgeschlossen ist.

Scope-Entscheidungen sind im Log sichtbar: Was ein Agent hätte tun können, ist Teil des Verständnisses dessen, was er getan hat. Weiter: Rollback – oder Änderungszuordnung, um zu sehen, wie das Protokoll funktioniert.