Die Abfrage aus dem Lern-Dashboard, die nie bei der Datenbank ankommt

Die Abfrage aus dem Lern-Dashboard, die nie bei der Datenbank ankommt

Stell dir vor, eine Führungskraft einer Bank möchte mit einem KI-erstellten Akademie-Dashboard die Schulungsabschlüsse in ihren Lerngruppen vergleichen. Die erzeugte Abfrage enthält keine Einschränkung auf den Mandanten und bindet per Join vertrauliche Bewertungsnotizen ein. Die Führungskraft darf das Dashboard öffnen. Das berechtigt sie aber nicht zu jeder Abfrage, die es erzeugt. Wenn die Notizen erst nach dem Abruf ausgeblendet werden, fällt die Sicherheitsentscheidung zu spät.

Zugriffsregeln werden an der Ressource durchgesetzt

Retool beschreibt in der Ankündigung vom 22. Oktober 2026 Data Access Enforcement als öffentliche Beta für Enterprise-Organisationen, die Postgres nutzen. Die Richtlinien sind an der Ressource hinterlegt und gelten über Apps, Workflows und KI-Agenten hinweg, soweit der jeweilige Ausführungspfad unterstützt wird. Sobald die Durchsetzung aktiviert ist, bleibt der Zugriff gesperrt, bis aktive Richtlinien ihn erlauben.

Das ist eine hypothetische Referenzarchitektur. Damit wird nicht behauptet, dass App-Learning Retools Beta nutzt. Für mandantenfähige Lernanalysen ist sie wertvoll, weil sie stabile Datenberechtigungen von wechselnden Berichtsoberflächen trennt.

Vier Prüfungen vor der Datenabfrage

Retools Modell zur Durchsetzung von Zugriffsregeln prüft die Berechtigungen vor der Ausführung und blockiert Abfragen, die es nicht bewerten kann. Es regelt den Zugriff über die Retool-Verbindung, nicht über unabhängige Datenbankverbindungen oder PostgreSQL-Berechtigungen. Für die Akademie würde der Datenvertrag vier Dimensionen abdecken.

• Die Identität ordnet die Abfrage der angemeldeten Person zu.
• Tabellenberechtigungen erlauben den Zugriff auf Abschlussdaten, nicht auf Personaltabellen, die damit nichts zu tun haben.
• Spaltenberechtigungen erlauben den Zugriff auf benötigte Felder, nicht auf vertrauliche Bewertungsnotizen.
• Zeilenfilter beschränken die Datensätze auf den freigegebenen Mandanten und die freigegebenen Lerngruppen.

In dieser Architektur wird eine Abfrage vor der Ausführung abgewiesen, wenn sie eine Notizspalte ohne entsprechende Berechtigung auswählt. Fehlt eine Mandantenbedingung, wird die Abfrage dagegen nicht zwingend abgewiesen: Die durchgesetzten Zeilenfilter begrenzen die zulässigen Ergebnisse. Berechtigungen für LMS-Analysen gehören in diesen Datenvertrag, nicht in den KI-Prompt. Auch ein Dashboard mit Zugriffsschutz auf Zeilenebene braucht Regeln für Tabellen und Spalten.

Die Rolle bestimmt, welche Nachweise sichtbar sind

In der hypothetischen Akademie würden für rein lesende Auswertungen folgende Zugriffsgrenzen gelten.

• Führungskräfte sehen die benötigten Felder zum Schulungsabschluss für ihren Mandanten und die ihnen zugewiesenen Lerngruppen.
• Schulungsadmins sehen innerhalb ihres zugewiesenen Mandanten die Kennungen der Lernenden, den Kursstatus und das jeweilige Abschlussdatum.
• HR sieht festgelegte, auf den Mandanten beschränkte Übersichtstabellen, aber keine Details zu einzelnen Lernenden. Wie Ergebnisse für kleine Gruppen unterdrückt werden, wird gesondert festgelegt.
• KI-Agenten handeln im Rahmen der Berechtigungen einer konkreten angemeldeten Person. Unbeaufsichtigte Analysen ohne zuordenbare Identität werden gestoppt.

Retools Einrichtungsanleitung warnt davor, dass sich Berechtigungen addieren. Eine weitreichende Richtlinie vom Typ Full access kann engere Regeln deshalb aushebeln. Die Anleitung setzt außerdem Prepared Statements voraus und warnt vor Connection-Pooling-Proxys. Die Zugriffskontrolle für KI-Agenten erfordert daher eine Prüfung der Konfiguration, nicht nur der Prompts.

Auswertungen im Hintergrund brauchen ein eigenes Konzept

Retools Dokumentation zur Fehlerbehebung nennt öffentliche und eingebettete Apps sowie zeitgesteuerte oder per Webhook gestartete Workflow-Ausführungen ohne Identität als blockierte Ausführungspfade. In selbst gehosteten Installationen wird derzeit jede Workflow-Abfrage an Ressourcen mit aktivierter Zugriffsdurchsetzung blockiert. Andere Workflow-Blöcke können trotzdem erfolgreich durchlaufen. Solche Teilausfälle sind deshalb ein Betriebsrisiko.

Der dokumentierte Umweg für Workflows nutzt eine separate Ressource ohne Zugriffsdurchsetzung, mit eigenen Datenbankzugangsdaten und eingeschränkter Nutzung. Diese Abfragen übernehmen die Richtlinien der Ressource mit Zugriffsdurchsetzung nicht. Für einen nächtlichen Akademiebericht braucht dieser Ausführungspfad daher eigene, eng begrenzte Datenbankberechtigungen.

Gezielt abgewiesene Zugriffe gehören in die Abnahmetests

1. Teste fehlende Identitäten und Attribute, mandantenübergreifende Anfragen sowie nicht freigegebene Spalten in Joins oder Filtern.
2. Prüfe, ob abgewiesene Abfragen keine geschützten Daten zurückgeben und erlaubte Abfragen weiterhin nur die zulässigen Zeilen liefern.
3. Teste überlappende Rollen, Schemaänderungen, Exporte und Hintergrundjobs in jeder Bereitstellungsumgebung.

Für App-Learning sollten rollen- und mandantenbezogene Analysen eine Voraussetzung für Vertrauen im B2B-Geschäft sein. Eine Bank braucht Nachweise für den Kompetenzaufbau, ohne dass jedes generierte Dashboard zu einem neuen Berechtigungsprojekt wird. Die Oberfläche kann sich schnell ändern. Die Zugriffsgrenze für Lerndaten sollte klar definiert, testbar und davon unabhängig bleiben.