Multi-Tenant: Agenten zwischen Kunden isolieren

Die Idee in 30 Sekunden

Multi-Tenant ist ein Architekturansatz, bei dem ein Agent-System viele Kunden bedient, aber jeder Tenant (ein einzelner Kunde) isoliert ist.

Isolation darf nicht nur in den Daten existieren. Sie wird in der ganzen Kette gebraucht:

• Runtime-Kontext;
• Memory und Cache;
• Tool-Zugriffe;
• Budget-Limits und Rate Limits;
• Audit und Trace.

Wann man es braucht: wenn ein Service für viele Kunden, Teams oder Workspaces auf gemeinsamer Infrastruktur läuft.

Ein LLM sollte den Tenant-Kontext nicht selbst festlegen. Tenant muss über Auth oder Routing bestimmt werden, und das System muss ihn in jedem Schritt erzwingen.

Problem

Ohne klare multi-tenant Isolation funktioniert das System zwar, aber Risiken werden schnell kritisch.

LLM-Agenten erhöhen das Risiko von cross-tenant Leaks, weil eine Anfrage Memory lesen, Tools aufrufen und Daten in mehrere Systeme schreiben kann.

Typische Ausfälle:

• Kontext eines Tenants landet in der Antwort eines anderen;
• ein Tool Call läuft mit fremden credentials;
• Memory oder Cache werden zwischen Kunden vermischt;
• ein Tenant verbraucht das gesamte gemeinsame Budget (noisy neighbor);
• Audit kann nicht belegen, wer eine Aktion initiiert hat.

In Production bedeutet das Datenlecks, Sicherheitsvorfälle und schwierige Compliance.

Lösung

Multi-Tenant als explizite Isolationsgrenze (tenant boundary) zwischen Agent Runtime und allen Zuständen/Aktionen des Systems hinzufügen.

Diese Grenze definiert:

• wie der Tenant identifiziert wird;
• welche Ressourcen diesem Tenant verfügbar sind;
• welche Limits spezifisch auf diesen Tenant angewendet werden;
• wie Tenant-Kontext in Logs und Traces erfasst wird.

Analogie: wie Bankschließfächer.

Das Gebäude ist eins, aber Zugriff auf jedes Fach hat nur der Eigentümer.

Multi-Tenant ermöglicht genauso eine gemeinsame Plattform ohne Vermischung von Zugriff und Daten.

Wie Multi-Tenant funktioniert

Multi-Tenant ist eine gesteuerte Schicht zwischen eingehender Anfrage und Aktionsausführung, die jeden Run per tenant_id erzwungen isoliert.

Dieser Zyklus erlaubt, einen Service auf viele Kunden zu skalieren, ohne cross-tenant Vermischung.

Im Code sieht es so aus

class MultiTenantArchitecture:
    def __init__(self, auth, runtime, policy, tools, memory, budgets, audit):
        self.auth = auth
        self.runtime = runtime
        self.policy = policy
        self.tools = tools
        self.memory = memory
        self.budgets = budgets
        self.audit = audit

    def run(self, request, auth_token):
        identity = self.auth.resolve(auth_token) or {}
        tenant_id = identity.get("tenant_id")
        actor_id = identity.get("actor_id")
        if not tenant_id:
            return {"ok": False, "reason_code": "tenant_missing"}

        if not self.budgets.allowed(tenant_id=tenant_id):
            return {"ok": False, "reason_code": "tenant_budget_exceeded"}

        # Der gesamte Kontext ist strikt an den Tenant gebunden.
        state = self.runtime.start(request=request, tenant_id=tenant_id)
        memory_items = self.memory.retrieve(tenant_id=tenant_id, query=request["text"], top_k=4)
        action = self.runtime.decide(state=state, memory_items=memory_items)

        gate = self.policy.authorize(
            tenant_id=tenant_id,
            actor_id=actor_id,
            action=action,
        )
        if not gate["ok"]:
            self.audit.log(
                tenant_id=tenant_id,
                actor_id=actor_id,
                action=action.get("name"),
                outcome="denied",
                reason_code=gate.get("reason_code", "policy_denied"),
            )
            return {"ok": False, "reason_code": gate.get("reason_code", "policy_denied")}

        result = self.tools.execute(
            action=action,
            tenant_id=tenant_id,
            scopes=gate.get("scopes", []),
        )

        self.audit.log(
            tenant_id=tenant_id,
            actor_id=actor_id,
            action=action.get("name"),
            outcome="executed",
            reason_code=result.get("reason_code", "ok"),
        )
        return result

So sieht es während der Ausführung aus

Anfrage: "Aktualisiere den Status von Bestellung #918 und sende dem Kunden eine Bestätigung"

Step 1
Auth + Routing: bestimmt tenant_id = tenant_acme
Multi-Tenant Boundary: setzt Tenant-Kontext und per-tenant Limits

Step 2
Agent Runtime: bildet action
Policy: prüft role + tenant scopes + allowlist
Tool Execution: führt die Aktion nur mit credentials von tenant_acme aus

Step 3
Audit: speichert tenant_id, actor_id, action, outcome, reason_code
Runtime: liefert Ergebnis ohne Vermischung mit anderen Kunden zurück

Multi-Tenant ändert die Agent-Logik nicht. Es macht sie vorhersagbar und sicher für eine Multi-Kunden-Umgebung.

Wann es passt und wann nicht

Multi-Tenant wird dort benötigt, wo ein System viele Kunden oder Teams mit unterschiedlichen Zugriffsrechten bedient.

Passt

Passt nicht

In einem einfachen single-tenant Szenario reicht manchmal ein Basiskontext:

result = runtime.run(request=request, tenant_id="default")

Typische Probleme und Ausfälle

Die meisten multi-tenant Vorfälle entstehen nicht im Modell, sondern an einer schwachen Grenze zwischen Kontext und Ausführung.

Wie es mit anderen Patterns zusammenspielt

Multi-Tenant ist eine querschnittliche Architektur-Schicht, die Sicherheit und Stabilität des gesamten Systems verstärkt.

• Agent Runtime — Runtime führt Schritte aus, und Multi-Tenant setzt Tenant-Kontext-Grenzen in jedem Schritt.
• Tool Execution Layer — jeder tool_call muss mit tenant-scoped Zugriffsrechten laufen.
• Memory Layer — Memory und Cache müssen nach tenant_id isoliert sein.
• Policy Boundaries — policy rules werden unter Berücksichtigung von tenant, role und scopes angewendet.
• Orchestration Topologies — in multi-agent Flows muss Tenant-Kontext über alle Branches weitergegeben werden.
• Hybrid Workflow Agent — workflow-Commits müssen innerhalb der Ressourcen des jeweiligen Tenants bleiben.
• Human-in-the-Loop Architecture — auch Approval-Schritte brauchen tenant-gebundenes Audit und Zugriffsrechte.
• Containerizing Agents — Container liefern eine stabile Umgebung, aber Tenant-Isolation wird spezifisch durch die Multi-Tenant-Grenze sichergestellt.

Anders gesagt:

• Multi-Tenant definiert wessen Aktion das ist und wessen Kontext das ist
• Andere Architektur-Schichten definieren wie diese Aktion ausgeführt wird

Kurz gesagt

FAQ

Q: Reicht es, einfach tenant_id zur Anfrage hinzuzufügen?
A: Nein. tenant_id muss durch Runtime, Policy, Tools, Memory, Cache und Audit erzwungen werden.

Q: Wo passieren cross-tenant Leaks am häufigsten?
A: Am häufigsten in Caches, Memory und globalen Clients für externe APIs.

Q: Wie migriert man sicher von single-tenant zu multi-tenant?
A: Mit tenant_id in Auth/Routing starten, dann Memory/Cache/Tools isolieren, per-tenant Limits und Audit hinzufügen und erst dann Daten schrittweise migrieren.

Q: Was ist zuerst wichtiger: per-tenant Budgets oder per-tenant Policy?
A: Beides ist wichtig. Policy schützt Zugriffe, Budgets schützen vor noisy-neighbor und Kostenexplosion.

Was als Naechstes

Multi-Tenant-Architektur beginnt mit Isolation, endet aber nicht dort. Als Naechstes schau, wie Stabilitaet unter realer Last gehalten wird:

• Memory Layer - wie tenant-scoped Memory ohne Leaks zwischen Kunden aufgebaut wird.
• Containerizing Agents - wie reproduzierbare Ausfuehrung pro Tenant sichergestellt wird.
• Policy Boundaries - wie Berechtigungen, Rollen und riskante Aktionen getrennt werden.
• Production Stack - wie daraus ein gesteuertes Production-Modell wird.