KI-Agenten und Databricks: Datenzugriff auf Tabellen und Spalten kontrollieren

Bei den Daten wird es in vielen KI-Agenten-Projekten ernst. Eine Frage wie „wie viele Bestellungen sind letzte Woche an der Zahlung gescheitert, aufgeteilt nach Land“ kann ein Agent gut beantworten, und er nimmt einem Analysten damit einen kleinen, aber ständigen Strom an Anfragen ab. Gleichzeitig liegen in einer Datenplattform wie Databricks genau die Informationen, die das Unternehmen nicht ohne Grund verlassen sollen: Kundendaten, Zahlungsinformationen, Mitarbeiterdaten. Ein Agent mit einem weitreichenden Warehouse-Token kann all das lesen, und was er liest, kann in einem Prompt beim Modellanbieter landen.

Dieser Beitrag beschreibt, wie sich der Zugriff von Agenten auf Databricks auf bestimmte Tabellen und Spalten begrenzen lässt, warum rohes SQL die falsche Schnittstelle für Agenten ist und wie personenbezogene Daten maskiert werden können, bevor sie das Modell erreichen. Er gehört zu unserer Serie über KI-Agenten in der Softwareentwicklung.

Warum direkter Warehouse-Zugriff ein Problem ist

Üblicherweise wird ein Agent über einen Personal Access Token oder einen Service Principal mit Leserechten auf einen Katalog an Databricks angebunden, dazu kommt ein Tool, das SQL ausführt. Das ist schnell eingerichtet und funktioniert in einer Demo gut. Im produktiven Einsatz hat es drei Schwächen.

Erstens ist der Zugriff zu breit. Berechtigungen im Warehouse werden meist pro Katalog oder Schema vergeben, und zwar für Menschen, die Daten explorativ untersuchen. Ein Agent, der nur Fragen zu Bestellungen beantworten soll, erbt damit den Zugriff auf jede Tabelle in diesem Schema, auch auf jene mit personenbezogenen Daten.

Zweitens ist rohes SQL eine sehr mächtige Schnittstelle. Ein Agent kann Tabellen joinen, Unterabfragen schreiben und jede beliebige Spalte auswählen. Auch ohne böse Absicht kann er Daten auf eine Weise kombinieren, die niemand geprüft hat. Stammen Teile der Abfrage aus Benutzereingaben oder aus Texten, die der Agent anderswo gelesen hat, kommt das klassische Risiko einer Injection hinzu.

Drittens geht das Ergebnis an das Modell. Jede Zeile, die der Agent liest, wird Teil seines Kontexts, und bei einem gehosteten Modell heißt das: Sie wird an einen Dritten übertragen. Aus Sicht des Datenschutzes (etwa nach der DSGVO) ist daher nicht nur die Frage, wer eine Tabelle abfragen darf, sondern auch, welche Werte das eigene Netz überhaupt verlassen dürfen.

Eine engere Schnittstelle: strukturierte Abfragen, nur lesend

Vordix geht einen anderen Weg. Statt SQL anzunehmen, bietet es vier lesende Operationen an:

• get_tables listet die Tabellen, die der Agent verwenden darf,
• describe_table liefert die Spalten einer freigegebenen Tabelle,
• query_table liest Zeilen mit Filtern, Sortierung und einer Zeilengrenze (vom Gateway gedeckelt),
• aggregate_table berechnet gruppierte Kennzahlen (Anzahl, Summe, Durchschnitt, Minimum, Maximum).

Der Agent beschreibt in strukturierten Parametern, was er braucht (Tabelle, Spalten, Filter, Gruppierung), und Vordix baut die SQL-Anweisung selbst. Filterwerte werden als gebundene Parameter übergeben und nie in den Abfragetext eingesetzt. Joins, Unterabfragen und rohes SQL werden nicht unterstützt. Schreibende Operationen gibt es für Databricks überhaupt nicht.

Das ist deutlich weniger flexibel als freies SQL, und genau diese Abwägung ist gewollt. Die Schnittstelle deckt die Fragen ab, die Agenten typischerweise gestellt bekommen (gefilterte Listen, Anzahlen und Summen pro Gruppe), und macht es gleichzeitig unmöglich, Tabellen oder Spalten außerhalb der Konfiguration abzufragen.

Freigaben pro Tabelle und pro Spalte

Tabellen werden über einen vollständigen Schlüssel der Form connection.catalog.schema.table angesprochen. Der Teil connection erlaubt mehrere benannte Databricks-Verbindungen, zum Beispiel eine pro Workspace oder Umgebung. Vordix meldet sich über OAuth Machine-to-Machine mit einem Service Principal an, ein persönlicher Token ist also nicht im Spiel.

Der Zugriff wird auf zwei Ebenen konfiguriert:

1. Tabellen. Der Administrator gibt einzelne Tabellen frei, zunächst auf Organisationsebene als Obergrenze und dann pro Projekt. Eine nicht freigegebene Tabelle erscheint nicht in get_tables, und eine Abfrage darauf wird abgelehnt.
2. Spalten pro Tabelle. Unter jeder freigegebenen Tabelle sind die Spalten eine eigene Allowlist. Die freigegebenen Spalten werden gegen einen gespeicherten Scan des Warehouse-Schemas geprüft. Der Wert * steht für alle Spalten dieser Tabelle, was für Tabellen ohne sensible Inhalte praktisch ist. Für eine Kundentabelle würde eine typische Konfiguration country, created_at und segment erlauben, aber nicht email, name oder iban.

Da Spalten pro Tabelle freigegeben werden, kann derselbe Spaltenname in einer Tabelle erlaubt und in einer anderen gesperrt sein. Die organisationsweite Obergrenze begrenzt, was ein Projekt freigeben kann; ein Projekt kann keine Tabelle und keine Spalte erlauben, die die Organisation nicht freigegeben hat.

Personenbezogene Daten in Ergebnissen maskieren

Die Einschränkung auf Spalten entfernt die offensichtlichen Felder, aber personenbezogene Daten stehen auch an unerwarteten Stellen: eine E-Mail-Adresse in einem Freitextkommentar, eine IBAN in einem Referenzfeld, IP-Adressen in einer Log-Spalte. Für diese Fälle wendet Vordix Datenrichtlinien auf die Antwort an, bevor sie an den Agenten zurückgeht.

Eine Datenrichtlinie arbeitet in drei Schichten:

• Regeln für Feldpfade bei bekannten Feldern (zum Beispiel customer.email immer maskieren),
• eingebaute Erkennung für gängige Muster: E-Mail-Adressen, Telefonnummern, IBANs, Kreditkartennummern (geprüft mit dem Luhn-Algorithmus), IP-Adressen sowie Ausweis- und Identifikationsnummern aus Deutschland, Österreich und der Schweiz,
• organisationsweite Begriffslisten für interne Begriffe wie Projektcodenamen.

Für jeden Treffer legt die Richtlinie fest, was passiert: Der Wert wird maskiert, pseudonymisiert (durch einen stabilen Platzhalter ersetzt, sodass derselbe Kunde weiterhin als dieselbe Einheit erkennbar bleibt), geschwärzt oder entfernt, oder die gesamte Antwort wird blockiert. Mit einer Vorschau lässt sich an einem Beispiel prüfen, was eine Richtlinie bewirkt, bevor sie aktiv wird.

Zusätzlich lassen sich die Felder einer Antwort filtern: Nur freigegebene Felder werden zurückgegeben, und wenn der Filter nicht angewendet werden kann, schlägt der Aufruf fehl, statt ungefilterte Daten zu liefern.

Audit-Log und Rate Limits

Jede Abfrage landet im Audit-Log, auch abgelehnte mit dem Grund (zum Beispiel „Tabelle nicht freigegeben“ oder „Spalte nicht freigegeben“). Parameter werden vor dem Schreiben geschwärzt, damit das Log nicht selbst zur zweiten Kopie sensibler Filterwerte wird. Rate Limits pro Schlüssel verhindern, dass ein Agent ungeplant zum Massenexport wird. Mehr zum Protokoll steht im Beitrag Audit-Log für KI-Agenten.

Grenzen und Abwägungen

Der Ansatz hat klare Grenzen, und es ist besser, sie vor Projektbeginn zu kennen:

• Keine Joins. Fragen, die Daten aus mehreren Tabellen brauchen, lassen sich nicht mit einem Aufruf beantworten. Der Agent kann Tabellen nacheinander abfragen, für regelmäßige Auswertungen ist aber eine vorbereitete Tabelle, die die Daten bereits zusammenführt, die bessere Lösung. Das verlagert etwas Arbeit zum Datenteam.
• Kein rohes SQL, keine Schreibzugriffe. Komplexe Analysen, Window Functions oder Änderungen an Daten sind nicht vorgesehen. Die Schnittstelle dient dazu, Fragen zu beantworten, nicht für Data Engineering.
• Die Erkennung basiert auf Mustern. E-Mail-Adressen oder IBANs werden zuverlässig erkannt; Personennamen im Freitext gehören nicht zu den eingebauten Erkennungen. Spalten mit Namen sollten daher über die Spalten-Allowlist ausgeschlossen oder über Feldpfad-Regeln abgedeckt werden, statt sich auf die Erkennung zu verlassen.
• Aufwand für die Konfiguration. Die Auswahl von Tabellen und Spalten ist eine Entscheidung der Data Governance und braucht jemanden, der die Daten kennt. Der Platzhalter * spart Zeit, sollte aber nur für Tabellen verwendet werden, bei denen jede heutige und künftige Spalte unbedenklich ist.

Fazit

KI-Agenten Zugriff auf Databricks zu geben ist sinnvoll, aber ein Warehouse-Token zusammen mit freiem SQL gibt ihnen weit mehr, als die Aufgabe erfordert. Eine engere Schnittstelle mit strukturierten, rein lesenden Abfragen, Freigaben für Tabellen und für Spalten pro Tabelle sowie die Maskierung personenbezogener Daten in den Ergebnissen erhalten den nützlichen Teil (Antworten auf wiederkehrende Datenfragen) und beseitigen den Großteil des Risikos. Die verbleibenden Grenzen, vor allem fehlende Joins und die musterbasierte Erkennung, sind beherrschbar, wenn man sie von Anfang an einplant.

Mehr aus dieser Serie: Was ist ein MCP Gateway? und Audit-Log für KI-Agenten. Wenn Sie die Kontrollen für Databricks mit Ihrem eigenen Warehouse testen möchten, können Sie eine Demo anfragen oder die Databricks-Integrationsseite in der Vordix-Dokumentation lesen.