Das Problem
Multi-Tenant Agents scheitern auf vorhersehbare Arten:
- Daten aus Tenant A landen im Kontext von Tenant B,
- ein Tool Call läuft mit falschen Tenant-Credentials,
- Retries vervielfachen Writes, weil Idempotency fehlt,
- Logs sind zu dünn, um zu beweisen, was passiert ist.
Das ist selten ein Modellproblem. Fast immer fehlt Isolation im Runtime.
Nicht verhandelbar
1) Tenant-Kontext binden, bevor der Agent läuft
Tenant-Identität muss aus Auth + Routing kommen — nicht vom Modell.
2) Jeden Tool Call auf den Tenant scopen
Tools müssen tenant-scoped Credentials und tenant-scoped Resource-IDs bekommen.
3) State (und Caches) pro Tenant trennen
Memory, Artifacts und Caches müssen per Tenant (und oft per Environment) gekeyed sein.
4) Per-Tenant Budgets und Rate Limits
Budgets und Rate Limits müssen pro Tenant gelten, damit ein Tenant nicht das gesamte System-Budget verbrennt.
Diagramm (tenant-scoped Tool Gateway)
Häufige Failure Modes
- Credential bleed: geteilte API-Keys oder globale Clients, die über Tenants wiederverwendet werden.
- Cache bleed: Retrieval-Caches nur nach URL/Query, nicht nach Tenant.
- Write duplication: Retries ohne Idempotency Keys.
- Silent partial writes: Step N schreibt erfolgreich, Step N+1 scheitert → inkonsistenter State.
Minimum Controls für Shipping
- Default-deny Allowlists, scoped pro Tenant und Environment.
- Idempotency Keys für alle Writes.
- Per-Tenant Budgets (steps/seconds/$) + per-Tenant Rate Limits.
- Vollständige Traces mit tenant_id + stop_reason für jeden Run.