Mandanten-Isolation bei KI-Agenten: warum ein Agent immer nur einen Kunden sehen darf

Das Problem, das niemand benennt

Stell dir vor, du betreibst eine Agentur. Du hast zehn Kunden, für jeden läuft ein KI-Agent, der Kampagnen-Daten analysiert, Berichte erstellt und Optimierungsempfehlungen generiert. Klingt effizient. Aber was genau sieht dieser Agent, wenn er arbeitet?

In vielen Setups, die wir bei galineo analysieren, lautet die ehrliche Antwort: mehr als er sollte. Ein Agent, der im selben Prozess für Kunde A eine Kampagne bewertet und kurz darauf für Kunde B eine Empfehlung formuliert, trägt Kontext mit sich, den er nicht tragen dürfte. Das ist kein Fehler im Modell. Das ist ein Fehler in der Architektur.

Die gute Nachricht: Das Problem ist lösbar. Die schlechte Nachricht: Es lässt sich nicht mit einem besseren Prompt lösen. Wer glaubt, ein System-Prompt mit dem Satz "Verwende niemals Daten anderer Kunden" sei ausreichend, unterschätzt, wie KI-Agenten im Betrieb tatsächlich funktionieren.

KI-Agenten für Unternehmen haben in den letzten Monaten eine Reife erreicht, die echten Betrieb ermöglicht. Exponential View beziffert es für Ende 2025 so: Systeme schaffen zuverlässig rund 100 Schritte, bevor ein Mensch eingreifen muss, und bei Aufgaben mit zwei Stunden Laufzeit liegt die Zuverlässigkeit bei etwa 50 Prozent. Die Zahlen altern schnell, die Richtung ist aber eindeutig. Das bedeutet: Agenten arbeiten länger, autonomer und mit mehr Zwischenspeicherung als je zuvor. Genau das macht Mandanten-Isolation zu einem drängenden Thema.

Was Mandanten-Isolation bei KI-Agenten wirklich bedeutet

Mandanten-Isolation ist aus der Software-Entwicklung bekannt. Bei Multi-Tenant-Anwendungen bedeutet sie, dass jeder Kunde eine logisch oder physisch getrennte Umgebung bekommt. Seine Daten sind in separaten Tabellen, seine Prozesse laufen in eigenen Containern, seine Zugriffe werden durch Middleware gefiltert.

Bei KI-Agenten gilt dasselbe Prinzip - aber die Umsetzung ist komplizierter, weil Agenten nicht nur auf Datenbanken zugreifen, sondern Kontext aufbauen. Ein Agent, der eine Aufgabe bearbeitet, entwickelt ein Arbeitsgedächtnis aus allem, was er im aktuellen Kontext-Fenster gesehen hat. Dieses Gedächtnis ist nicht explizit adressierbar und nicht einfach zu löschen.

Die drei Ebenen der Isolation

Echte Isolation bedeutet, dass alle drei Ebenen gleichzeitig getrennt sind. Ein System, das Daten trennt, aber den Kontext teilt, ist nicht isoliert. Ein System, das Kontext trennt, aber dieselben Credentials verwendet, ist nicht isoliert. Alle drei Ebenen müssen als Einheit betrachtet werden.

Was passiert, wenn Isolation fehlt

Die Risiken fehlender Mandanten-Isolation lassen sich in drei Kategorien einteilen: operative Fehler, Datenschutzverstöße und Vertrauensverlust.

Operative Fehler

Der häufigste Fall: Ein Agent, der für Kunde A gelernt hat, dass aggressive Gebotsstrategien funktionieren, wendet diese Logik auf Kunde B an - obwohl Kunde B ein anderes Margen-Modell hat. Der Agent macht keinen Fehler im technischen Sinne. Er lernt aus dem, was er gesehen hat. Das Problem ist, dass er das Falsche gesehen hat.

Bei langen Aufgaben mit vielen Zwischenschritten, wie sie in modernen Agenten-Systemen die Norm sind, akkumuliert sich dieser Effekt. Was als kleine Kontamination beginnt, wächst mit jedem Tool-Aufruf und jedem Reasoning-Schritt.

Datenschutzverstöße

Kampagnen-Daten, Budgetinformationen, Zielgruppen-Profile und Conversion-Rates sind in der Regel vertraulich. Wenn ein Agent diese Daten in seinem Kontext trägt und danach für einen anderen Kunden arbeitet, ist das keine abstrakte Gefahr. Es ist ein konkretes Datenschutzproblem - unabhängig davon, ob die Daten explizit ausgegeben werden oder implizit die Empfehlungen beeinflussen.

Vertrauensverlust

Wenn ein Kunde herausfindet, dass sein KI-Agent dieselbe Instanz ist wie der seines Mitbewerbers - oder auch nur wie die Instanz eines anderen Kunden derselben Agentur - ist das Vertrauen weg. Nicht weil etwas Nachweisbares passiert ist, sondern weil die Möglichkeit besteht.

Architektur-Muster für echte Isolation

Es gibt im Wesentlichen drei Architektur-Muster, die in produktiven Systemen eingesetzt werden. Sie unterscheiden sich in Kosten, Komplexität und Isolations-Grad.

Muster 1: Eine Instanz pro Mandant

Das sicherste Muster: Jeder Mandant bekommt eine vollständig eigene Agenten-Instanz mit eigenem Kontext-Fenster, eigenen Credentials und eigenem Zugriff auf exklusiv zugängliche Daten. Kein gemeinsamer Zustand, keine gemeinsame Historie.

Das ist teurer in der Infrastruktur, aber es ist das einzige Muster, das wirklich wasserdichte Isolation garantiert. Für sensible Branchen oder hochpreisige Mandanten ist es die einzige vertretbare Wahl.

Muster 2: Orchestrator mit isolierten Sub-Agenten

Ein zentraler Orchestrator verwaltet die Aufgaben-Verteilung, spawnt aber für jeden Mandanten eigene Sub-Agenten. Diese Sub-Agenten haben keinen Zugriff auf den Kontext der anderen. Die Isolation findet auf Orchestrator-Ebene statt, nicht darunter.

Dieses Muster ist inspiriert von Architekturen wie dem AMP-System, das Beyang Liu beschreibt: Statt eines generischen Modells gibt es spezialisierte Sub-Agenten für spezifische Aufgaben - einen für die Suche, einen für tiefes Reasoning, einen für Code-Anpassungen. Der entscheidende Gedanke dahinter ist, dass die Wahl des Modells nicht das zentrale Design-Problem ist. Stattdessen geht es darum, die Agenten-Architektur auf spezifische Aufgaben zu optimieren. Übertragen auf Mandanten-Isolation bedeutet das: Die Grenze zwischen Mandanten muss als explizite Architektur-Entscheidung auf Orchestrator-Ebene gezogen werden - nicht als nachträgliche Prompt-Instruktion.

Muster 3: Shared Infrastructure mit strikter Scope-Kontrolle

Das kosteneffizienteste Muster, aber das fehleranfälligste: Eine gemeinsame Infrastruktur mit strikt kontrollierten Scopes für Tool-Zugriffe, Datenbank-Abfragen und API-Calls. Jeder Tool-Aufruf enthält die Mandanten-ID als Pflichtparameter, und die Middleware verweigert jeden Aufruf ohne valide Mandanten-Zuordnung.

Dieses Muster funktioniert nur, wenn alle Tools konsequent auf Mandanten-Ebene scopen und kein Tool je Ergebnisse aus mehreren Mandanten-Scopes zurückgibt. Eine einzige Ausnahme genügt, um die Isolation zu brechen.

Kontext-Fenster und die unterschätzte Gefahr der Datenlecks

Das Kontext-Fenster ist das Arbeitsgedächtnis eines KI-Agenten. Alles, was darin steht, beeinflusst alle nachfolgenden Ausgaben. Das ist die Grundlage, auf der Agenten funktionieren - und gleichzeitig die Schwachstelle, die Mandanten-Isolation am häufigsten untergräbt.

Katelyn Lesse von Anthropic beschreibt in ihrer Analyse der Claude-API-Entwicklung für Agenten, dass eine der drei zentralen Fähigkeiten, die Anthropic für Entwickler bereitstellt, explizit das effektive Management des Kontext-Fensters ist. Das ist kein Zufall: Anthropic hat erkannt, dass das Kontext-Fenster die kritische Ressource ist, die über Erfolg oder Misserfolg eines Agenten-Systems entscheidet. Was für Performance gilt, gilt für Datensicherheit genauso: Wer das Kontext-Fenster nicht aktiv kontrolliert, verliert die Kontrolle über das, was ein Agent weiß.

Wie Kontamination im Kontext-Fenster entsteht

In produktiven Systemen sieht eine typische Kontext-Kontamination so aus: Ein Agent bearbeitet eine Aufgabe für Mandant A, ruft dabei Tools auf und erhält Ergebnisse. Diese Ergebnisse werden in den Kontext geschrieben. Der Agent schließt die Aufgabe ab. Jetzt soll er eine Aufgabe für Mandant B bearbeiten - aber der Kontext ist nicht zurückgesetzt worden. Die Ergebnisse der Tool-Aufrufe für Mandant A sind noch sichtbar.

Das passiert nicht nur bei fahrlässigen Implementierungen. Es passiert bei jedem System, das Kontext über mehrere Aufgaben hinweg wiederverwendet, um Kosten zu sparen oder Latenz zu reduzieren. Das ist ein nachvollziehbarer wirtschaftlicher Anreiz - aber kein akzeptabler Trade-off, wenn Mandanten-Isolation gefordert ist.

Sub-Agenten richtig einsetzen - ohne die Isolation zu opfern

Sub-Agenten-Architekturen sind in modernen KI-Systemen weit verbreitet, weil sie es erlauben, spezialisierte Fähigkeiten zu kombinieren, ohne ein einzelnes Modell zu überlasten. Replit beschreibt in seiner Agenten-Architektur drei zentrale Säulen: Frontier-Modell-Fähigkeiten, Verifikation durch autonomes Browser-Testing und Kontext-Management über Sub-Agenten. Besonders interessant ist der Hinweis zur Kontext-Verwaltung: Durch den Einsatz von Sub-Agenten wurde die effektive Kontext-Länge deutlich erhöht, was komplexere Aufgaben ermöglicht.

Der Effizienzgewinn ist real. Die Frage ist: Wo in dieser Architektur sitzt die Mandanten-Grenze?

Die goldene Regel für Sub-Agenten und Mandanten

Die Mandanten-Grenze muss immer oberhalb der Sub-Agenten-Schicht liegen. Das bedeutet: Der Orchestrator, der Sub-Agenten koordiniert, muss bereits vollständig mandanten-isoliert sein. Sub-Agenten dürfen nur Aufgaben aus einem einzigen Mandanten-Kontext erhalten. Sie dürfen niemals als mandanten-übergreifende Dienste betrieben werden.

Umsetzung in der Praxis: konkrete Schritte

Theorie ist gut, aber Mandanten-Isolation muss in echten Systemen funktionieren - unter Kostendruck, mit heterogenen Datenquellen und in Umgebungen, die nicht von Grund auf neu gebaut werden können. Hier sind die Schritte, die in der Praxis tatsächlich funktionieren.

Schritt 1: Mandanten-Grenze zuerst definieren

Bevor du irgendeinen Agenten baust, musst du wissen, wo die Mandanten-Grenze in deiner Architektur liegt. Ist es auf Datenbank-Ebene? Auf API-Gateway-Ebene? Auf Agenten-Instanz-Ebene? Diese Entscheidung bestimmt alles andere. Und sie muss dokumentiert sein, nicht nur im Kopf der Person, die das System gebaut hat.

Schritt 2: Tool-Zugriffe auditieren

Gehe durch jedes Tool, das dein Agent verwenden kann. Frage für jedes Tool: Kann dieses Tool Daten aus mehr als einem Mandanten-Kontext zurückgeben? Wenn ja: Ist die Mandanten-ID ein Pflichtparameter? Wird sie validiert, bevor das Tool antwortet? Ein Tool ohne Mandanten-Scope ist ein Einfallstor für Kontamination.

Schritt 3: Kontext-Lifecycle definieren

Definiere explizit, wann ein Kontext-Fenster beginnt und wann es endet. Kein Kontext darf über Mandanten-Grenzen hinaus leben. Baue automatisierte Tests, die prüfen, ob nach einer Aufgabe für Mandant A noch Daten von Mandant A in einem Kontext vorhanden sind, der danach für Mandant B genutzt wird.

Schritt 4: Logging mit Mandanten-Zuordnung

Jeder Tool-Aufruf, jede Agenten-Aktion und jede Ausgabe muss mit einer validen Mandanten-ID geloggt werden. Nicht als optionales Feld, sondern als Pflichtfeld, das bei jedem Schritt validiert wird. Nur so kannst du im Nachhinein nachweisen, dass keine Vermischung stattgefunden hat.

Schritt 5: Autonomie und Isolation in Balance bringen

Echte Agent-Autonomie bedeutet nicht, dass ein Agent stundenlang läuft - sondern dass er alle technischen Entscheidungen selbst trifft, während die Nutzer die Kontrolle über das Ziel behalten. Dieses Prinzip ist direkt auf Mandanten-Isolation übertragbar: Der Agent darf autonom handeln, aber die Grenzen seines Handlungsraums werden durch die Architektur definiert - nicht durch Anweisungen im Prompt. Autonomie innerhalb klar definierter Grenzen ist das Ziel, nicht Autonomie ohne Grenzen.

Woran du gute Isolation erkennst - und was du sofort prüfen kannst

Gute Mandanten-Isolation ist nicht unsichtbar. Sie hinterlässt Spuren in der Architektur, im Code und in der Dokumentation. Hier sind die Signale, die du in einem bestehenden System suchen solltest.

Isolation ist dabei nur eine von mehreren Entscheidungen, die beim Aufbau zusammenkommen. Wie so ein System insgesamt entsteht, steht in der Schritt-für-Schritt-Anleitung zum Aufbau eines KI-Systems. Warum es überhaupt einen Unterschied macht, ob die KI dein Geschäft kennt oder nur Prompts bekommt, behandelt der Artikel zum Client Brain für Unternehmen. Die Abgrenzung zwischen einzelnen Prompts und einem echten System zeigt der Vergleich von ChatGPT und KI-System.

Wer wissen will, wie autonome Steuerung in einem konkreten, eng abgegrenzten Bereich aussieht, findet das in Agentic AI im Google-Ads-Konto. Und wie mehrere Konten parallel ohne Vermischung überwacht werden, beschreibt KI-gestütztes Client-Monitoring.

Positiv-Signale für gute Isolation

• Jede Agenten-Instanz hat eine explizite Mandanten-ID, die vor dem ersten Tool-Aufruf gesetzt wird
• Tool-Definitionen enthalten die Mandanten-ID als validierten Parameter, nicht als optionalen Kontext
• Automatisierte Tests prüfen, ob Kontext-Reset nach jeder Aufgabe sauber durchgeführt wird
• Logs enthalten für jeden Schritt eine Mandanten-Zuordnung, die maschinell auditierbar ist
• Die Architektur-Dokumentation enthält einen expliziten Abschnitt zur Mandanten-Grenze und ihrer technischen Umsetzung

Warnsignale für fehlende Isolation

• Die Mandanten-Trennung wird im System-Prompt beschrieben, nicht in der Infrastruktur erzwungen
• Ein Agent bearbeitet nacheinander Aufgaben verschiedener Mandanten ohne vollständigen Kontext-Reset
• Tools geben Ergebnisse ohne Mandanten-Scope zurück und verlassen sich auf den Prompt zur Filterung
• Die Frage "Welcher Mandant hat diesen Tool-Aufruf ausgelöst?" lässt sich im Log nicht eindeutig beantworten

Die vollständige Prüfliste mit allen Kontrollpunkten findest du als Download. Sie enthält nicht nur die Fragen, die du stellen musst, sondern auch konkrete Bewertungskriterien für jede Antwort.

Fragen aus der Praxis