Multi-tenant LLM analytics with row-level security: How we built a secure agent on AWS
TL;DR
PAR beschreibt einen produktionsreifen Text-to-SQL-Agenten für Restaurant-Analytics auf AWS, der mehrere Mandanten, Geschäftsbereiche und Admin-Rechte sauber trennen soll. Die Architektur setzt drei unabhängige Sicherheitslagen ein: AWS SigV4 für signierte Requests, Amazon Bedrock für semantische Vorprüfung und Split-Plane SQL für programmatische Zeilenfilter.
Nauti's Take
Das ist die richtige Richtung für AI-Agenten in echten Datenumgebungen: Der LLM sitzt in einem Käfig aus Identität, Validierung und vorgefiltertem SQL, statt frei auf die Datenbank losgelassen zu werden. Besonders stark ist die Trennung zwischen Sicherheitslogik und Intelligenzlogik.
Schwach bleibt: Es ist ein AWS-Blog, also kein neutraler Architekturvergleich. Trotzdem ist die Kernlektion sauber: Wenn ein Prompt deine Row-Level-Security halten muss, hast du keine Row-Level-Security.
Einordnunganzeigen
LLM-Analytics scheitert in Unternehmen selten am Demo-Case, sondern an Zugriffskontrolle, Haftung und Mandantentrennung. Der wichtige Punkt ist hier: Das Modell darf analysieren, aber nicht entscheiden, welche Daten sichtbar sind. Diese Grenze wird serverseitig und deterministisch gebaut, nicht als höfliche Bitte im Prompt.
Quellen
