AWS: Multi-Tenant-KI-Agent mit Row-Level-Security und Split-Plane-SQL als kryptographische Datengrenzen

PAR Technology — ein SaaS-Unternehmen für das Management von Restaurantketten — hat einen KI-Analyse-Agenten für 300+ Restaurantmarken auf einem gemeinsamen System aufgebaut. Die Anforderung ist deterministisch: Ein Franchisenehmer sieht ausschließlich seine eigenen Verkaufsdaten (z.B. 84.000 USD für zwei Standorte), während ein Markenmanager die nationalen Gesamtdaten sieht (9,2 Mio. USD) — identische Abfrage, gleiche Datenbank, völlig unterschiedliche Ergebnisse. AWS ML Blog beschreibt die Architektur dieses Systems als Produktionslösung, nicht als Proof-of-Concept.

Drei Schutzschichten: Von der Signatur bis zur kryptografischen Grenze

Eine Multi-Tenant-Umgebung (Mehrmieter-Umgebung) bedeutet, dass mehrere Kunden dieselbe Datenbankinfrastruktur teilen. Row-Level-Security (Sicherheit auf Zeilenebene) — ein Mechanismus, der Datenbankzeilen nach Benutzer filtert — wird in LLM-Agenten klassisch über Prompt-Instruktionen umgesetzt, ein Ansatz, den das Modell ignorieren oder durch Prompt-Injection-Angriffe umgehen kann.

Die AWS-Architektur führt drei deterministische Schutzschichten ein. Schicht 1 verwendet AWS Signature Version 4 (SigV4): kryptografische Signierung, die Tenant-ID, Business-ID und Admin-ID an jeden API-Aufruf bindet; jede Payload-Modifikation macht die Signatur sofort ungültig. Schicht 2 verwendet Amazon Bedrock als semantischen Validator — das Modell prüft, ob die Benutzerfrage eindeutig und unterstützt ist, bevor die Anfrage den SQL-Generator erreicht; unspezifische Anfragen wie „Zeig mir alles” werden abgelehnt. Schicht 3 ist Split-Plane SQL.

Was ist Split-Plane SQL und warum reicht Prompt-Schutz nicht aus?

Split-Plane SQL (doppelter SQL-Generationsplan) teilt die Abfragegenerierung in zwei unabhängige Ströme. Der Sicherheitsstrom generiert SQL Common Table Expressions (CTE), die Datenbanktabellen ausschließlich auf autorisierte Zeilen vorfiltern. Erst dann erhält Amazon Bedrock das Schema dieser temporären, gefilterten Ansichten — nicht das Schema der zugrunde liegenden Tabellen. Das LLM kann physisch keine Daten außerhalb des Sandboxes referenzieren, unabhängig vom Inhalt des generierten SQL. Der Unterschied zum klassischen Ansatz ist strukturell: Eine Prompt-Instruktion sagt dem Modell, was es darf; Split-Plane SQL erzwingt diese Grenze kryptografisch auf Architekturebene.

PAR Technology: 50.000 Anfragen ohne Cross-Tenant-Datenleck-Vorfall

Die Produktionsimplementierung hat mehr als 50.000 Anfragen ohne einen einzigen Datenleck-Vorfall zwischen Kunden verarbeitet. Die Infrastruktur umfasst einen Databricks-Cluster mit Netzwerkisolierung, TLS 1.3, AWS-KMS-Verschlüsselung mit automatischer Schlüsselrotation und CloudTrail-Audit-Logs mit Anomalieerkennung. AWS fasst das grundlegende Architekturprinzip zusammen: „Das LLM sitzt innerhalb der Architektur, nicht darüber.”