Skip to content
Berktug Berke Ates
Berktug Berke Ates

Software Engineer

Blog

Berechtigungsmodelle für Multi-Tenant-AI-Copilots

· 7 Min. Lesezeit

Ein Multi-Tenant-AI-Copilot der Chat-Permissions erbt aber Data-ACLs ignoriert, zitiert selbstbewusst den falschen Tenant. Tool-Calls brauchen denselben Authorization-Pfad wie Ihre APIs—scoped pro Tenant, Rolle und Resource.

Chat-Zugang ist kein Data-Zugang

Nutzer die ein Copilot-Panel öffnen können, dürfen nicht automatisch jedes Dokument lesen das das Modell retrieve kann. Trennen Sie Conversation-Membership von Resource-Entitlements. Das Modell sieht nur was eine server-seitige Policy für diesen Principal in diesem Tenant erlaubt—nie was ein Prompt behauptet der User brauche.

Cross-Tenant-Leakage beginnt oft im Retrieval: Embeddings ohne Tenant-Predicates indexiert, oder shared Vector-Collections nur per Similarity abgefragt. Tenant-Id in jede Index-Partition und jede Tool-Argument-Validation setzen.

Tools wie öffentliche APIs autorisieren

Jeder Tool-Aufruf sollte dieselbe Authz-Middleware wie Ihre REST- oder gRPC-Handler durchlaufen: User (oder Service-Identity) authentifizieren, Tenant-Context resolven, RBAC/ABAC prüfen, dann least privilege ausführen. Agents dürfen keine langlebigen God-Tokens halten die Row-Level-Checks bypassen.

Kurzlebige, scoped Credentials pro Session oder Tool-Call bevorzugen. Bei Agent-Fan-out Subject- und Tenant-Claims propagieren—Scope nicht weiten weil ein Planner-Schritt 'mehr Context braucht.'

  • Tenant-Predicates auf Retrieval-Indexes und Tool-Argumenten erzwingen
  • API-Authz-Middleware für jeden Tool-Call wiederverwenden; kein Shadow-Permission-Pfad
  • Kurzlebige scoped Credentials statt shared Service-Gods ausstellen
  • Principal, Tenant, Tool, Resource und Decision pro Call auditieren

Den Principal modellieren als den der Agent handelt

Entscheiden ob der Copilot als Endnutzer, als constrained Assistant-Rolle oder als Break-Glass-Operator mit separater Freigabe handelt. Unterschied für Support und Compliance dokumentieren. Impersonation ohne Audit ist ein Security-Incident der wartet.

Prompt Injection kann Tools elevaten wollen. Defense ist Policy-Enforcement außerhalb des Modells: Deny-Lists, Allow-Lists von Tools pro Rolle und Output-Filter die keine neuen Permissions gewähren können.

Isolation kontinuierlich beweisen

Automatisierte Tests hinzufügen die Cross-Tenant-Retrieval und Tool-Calls mit gestohlenen Conversation-Ids versuchen. Denial-Rates und unerwartete Allow-Spikes nach Prompt- oder Index-Änderungen monitoren. Multi-Tenant-Copilots scheitern laut in Demos und leise in Production—instrumentieren Sie für die leisen Failures.

Permissions sind Produkt-Surface. Designen Sie sie mit derselben Sorgfalt wie das Modell das dahinter spricht.


Veröffentlicht am 17. September 2026 von Berktug Berke Ates.