Wenn viele Kunden ein Bedrock-Modell teilen, gibt das Modell keinerlei Isolation und war das auch nie vorgesehen. Es ist eine zustandslose Funktion: gleicher Input, gleiches Verhalten, keine Erinnerung daran, wer aufgerufen hat. Jede Grenze zwischen Tenants muss in den Schichten rund um das Modell gebaut werden, nicht von ihm erwartet werden. Teams verstehen das genau falsch herum, nehmen an, der Managed Service übernehme die Trennung, und liefern eine App aus, in der Daten, Kosten und Last eines Tenants in einen anderen hineinbluten. Das gemeinsame Modell ist unproblematisch. Das gemeinsam genutzte Alles-andere ist das Problem.

Das Beruhigende ist, dass die Zustandslosigkeit des Modells genau das ist, was Multi-Tenancy handhabbar macht. Es gibt keinen Zustand pro Tenant im Modell, der auslaufen könnte, weil es überhaupt keinen Zustand gibt. Isolation reduziert sich auf drei konkrete Grenzen, die man bereits zu bauen weiß: welche Daten die Anfrage eines Tenants erreichen kann, wie viel der gemeinsamen Kapazität sie verbrauchen darf, und unter welcher Identität sie läuft.

Datenisolation: das Retrieval eingrenzen, nicht das Modell

Das eigentliche Leck-Risiko in einer RAG- oder Agenten-App liegt nicht in den Gewichten, sondern im Context, den man vor sie setzt. Wenn die Frage von Tenant A Dokumente von Tenant B abruft, hat man einen Datenschutzvorfall, der als hilfreiche Antwort verkleidet ist. Die Retrieval-Schicht ist also der Ort, an dem die Tenant-Trennung lebt.

Zwei brauchbare Formen, je nachdem wie strikt die Grenze sein muss:

  • Knowledge Base pro Tenant. Die harte Grenze. Jeder Tenant bekommt seine eigene Bedrock Knowledge Base, sodass eine Abfrage niemals aus etwas anderem als dem Korpus dieses Tenants abrufen kann. Am saubersten zu durchdenken, mehr bewegliche Teile, je mehr Tenants dazukommen.
  • Gemeinsamer Speicher, tenant-gefiltert. Ein Vektorspeicher mit einem verpflichtenden Tenant-ID-Filter auf jeder Abfrage, sodass Ergebnisse nach Metadaten eingegrenzt sind. Günstiger im Betrieb, aber der Filter ist jetzt sicherheitskritisch. Er muss serverseitig aus einer authentifizierten Identität angewendet werden, nie aus einem Wert, den der Client setzen kann.

Der zu vermeidende Fehler ist, nach einer Tenant-ID zu filtern, die im Request-Body ankam. Wenn der Client seinen eigenen Tenant benennen kann, kann er auch den von jemand anderem benennen. Man leitet den Tenant aus dem authentifizierten Principal ab und wendet die Eingrenzung dort an, wo der Client sie nicht erreichen kann.

Der laute Nachbar: eine gemeinsame Quote ist ein gemeinsamer Ausfall

Bedrock drosselt Tokens pro Minute auf Account- und Modellebene. Diese Zahl wird über jeden Tenant hinweg geteilt, der dieses Modell im eigenen Account trifft. Wenn also ein Tenant einen schweren Batch-Job fährt, verbraucht er das gemeinsame Token-Budget, und jeder andere Tenant sammelt Throttling-Fehler für Last, die er nicht selbst erzeugt hat. Das Modell ist logisch isoliert und operativ gekoppelt.

Isolation bedeutet hier, pro Tenant zu messen und zu deckeln, bevor die gemeinsame Obergrenze es für einen tut:

  • Token-Budgets pro Tenant. Man trackt verbrauchte Tokens pro Tenant pro Zeitfenster und lehnt einen Tenant ab oder stellt ihn in die Warteschlange, wenn er sein eigenes Kontingent sprengt, sodass sein Spike nicht den gemeinsamen Pool auffrisst.
  • Faire Warteschlangen. Ein begrenzter Worker-Pool pro Tenant vor dem Modell macht aus dem Burst eines Tenants dessen eigene Verlangsamung, nicht den Ausfall für alle.
  • Prioritätsstufen. Wenn Tenants für unterschiedliche Service-Level zahlen, setzt man das in der Admission Control durch. Ein Free-Tier-Batch sollte nicht den interaktiven Traffic eines zahlenden Tenants aushungern können.

Identität: die Tenant-Grenze muss bis zu den Tools reichen

Isolation kann nicht beim Retrieval aufhören. In dem Moment, in dem ein Agent ein Tool aufruft, aus einer Datenbank liest oder in einen Speicher schreibt, muss die Tenant-Grenze mit der Anfrage mitreisen. Das heißt, die Anfrage läuft unter einer auf den Tenant eingeschränkten Identität, sodass selbst wenn das Modell dazu gebracht wird, die falschen Daten anzufragen, die Credentials hinter dem Tool sie nicht abrufen können. Die Modellschicht vertraut nichts, die IAM-Schicht setzt alles durch. Das ist Least Privilege pro Tenant angewendet, und es ist das, was einen Prompt-Injection-Versuch davon abhält, zu einem tenant-übergreifenden Lesezugriff zu werden.

Das Fazit

Ein gemeinsames Modell ist keine App, in der alles gemeinsam genutzt wird. Das Modell ist zustandslos, es bietet also keine Isolation und braucht auch keine eigene geschützte. Die eigene Aufgabe sind die drei Grenzen drum herum: das Retrieval so eingrenzen, dass ein Tenant nur seine eigenen Daten sieht, die Kapazität messen und deckeln, damit kein Tenant die anderen bei der gemeinsamen Token-Quote aushungert, und eine Identität pro Tenant bis zu den Tools mitführen, sodass ein eingeschränktes Credential die letzte Verteidigungslinie ist, wenn die Prompt-Schicht ausgetrickst wird. Baut man diese drei, bedient ein Modell viele Kunden sicher. Überspringt man eine davon, bedient das Modell fröhlich die Daten des falschen Kunden an den falschen Kunden.

Weiterlesen

Für die Plattform- und Multi-Account-Isolationsseite desselben Problems gibt es die Cloud-Notizen auf ercan.cloud, und der Hub ist unter ercanermis.com.