Berater: getrennte Kunden, getrennte Zugangsdaten, getrennte Memory

Der Berater-Albtraum ist kein Hack. Es ist ein Absatz, entworfen mit den Zahlen von Kunde A, eingefügt in eine E-Mail an Kunde B. Sobald dein KI-Agent über Mandate hinweg arbeitet, hört dieses Risiko auf, eine Frage deiner Aufmerksamkeit zu sein, und wird eine Architekturfrage: Sind die Tools, Zugangsdaten und der Kontext deiner Kunden wirklich getrennt, oder nur in deinem Kopf?

MCP für Berater ist größtenteils dieselbe Verkabelung wie für alle anderen, ein Standardprotokoll zwischen einem Agenten und seinen Tools. Was sich ändert, ist das Anforderungsprofil. Drei Dinge rücken nach oben: Trennung, Widerruf und Nachweis.

Trennung: eine Grenze pro Mandat

Der Agent eines Beraters kann an einem Nachmittag die Analytics von Kunde A, das CRM von Kunde B und dein eigenes Rechnungs-Tool anfassen. Das faule Setup wirft alles in eine Agenten-Config, und ab dann verhindert nur noch Glück die Querkontamination.

Das saubere Setup zieht eine Grenze pro Mandat. Die Verbindungen jedes Kunden leben gruppiert unter diesem Kunden, Tools kommen namespaced an (kundeA__get_report ist nicht kundeB__get_report), und der Agent arbeitet in einer Grenze zur Zeit. Ein Gateway macht das natürlich: Verbindungen sind dort gruppiert, wo sie verwaltet werden, statt über Konfigdateien verstreut. Wenn du je zwei Kunden aus zwei Browser-Profilen gefahren hast, um die Cookies zu trennen, ist das derselbe Instinkt, nur an einer Stelle, an der er wirklich hält.

Dieselbe Grenze muss für Memory gelten, und diesen Teil übersehen die meisten Setups. Ein Agent, der sich erinnert, ist ein Gewinn; ein Agent, der sich an die Churn-Zahlen von Kunde A erinnert, während er für Kunde B schreibt, ist ein Risiko. Memory braucht Scoping pro Mandat, damit ein recall in der Arbeit des einen Kunden nie Fakten des anderen hochspült. Endet das Mandat, sollte diese Memory exportierbar oder löschbar sein, nicht versteinert in einem globalen Blob. Wie Memory auf Gateway-Ebene funktioniert, steht in [MCP Gateway mit Memory](/de/blog/mcp-gateway-with-memory).

Widerruf: das Offboarding ist der echte Test

Jedes Mandat endet. Die Übergabe-Mail geht raus, die letzte Rechnung wird bezahlt, und der Zugriff, den du hältst, sollte in derselben Woche sterben. Genau da versagen die meisten Solo-Setups leise: Der API-Key des Kunden liegt noch in einer Config in irgendeinem Projektordner, funktionierend, mächtig, vergessen. Warum dieses Muster fault, steht in [Hör auf, API-Keys in Agenten-Configs zu kleben](/de/blog/stop-pasting-api-keys).

Der Test für dein eigenes Setup ist brutal und simpel: Könntest du alles, was zu einem Kunden gehört, in unter fünf Minuten widerrufen, und könntest du auflisten, was du widerrufen hast? Mit OAuth-Freigaben pro Verbindung an einer Stelle lautet die Antwort zweimal ja. Mit Keys in Dateien lautet die ehrliche Antwort "wahrscheinlich nicht, und beweisbar sicher nicht".

Widerrufs-Geschwindigkeit ist keine Paranoia. Sie ist Professionalität zum Vorzeigen: "Euer Zugriff wurde am 14. entfernt, hier ist die Liste" ist ein Satz, der den nächsten Vertrag gewinnt.

Nachweis: der Audit-Trail gehört zum Lieferumfang

Wenn dein Agent das CRM eines Kunden aktualisiert oder dessen Tracking-Setup anpasst, handelst du auf dem Produktivsystem eines anderen. Sieht zwei Wochen später etwas seltsam aus, ist "mein Agent könnte das angefasst haben" ein furchtbarer Satz gegenüber einem Kunden.

Ein Audit-Trail macht daraus einen guten: jeder Aufruf deines Agenten, mit Zeitstempel, Argumenten und Ergebnissen, filterbar nach Mandat. Dieses Log ist keine Bürokratie; für einen Berater ist es Abrechnungsbeleg, Streitfall-Versicherung und das schnellste Debugging-Werkzeug, das du besitzt. Das volle Argument steht in [Audit-Trails für KI-Agenten](/de/blog/ai-agent-audit-trail).

Der Zinseszins-Teil: Hör auf, deine eigenen Kunden neu zu lernen

Trennung, Widerruf, Nachweis: Das ist die defensive Hälfte. Die offensive Hälfte ist, was Memory mit deinen Margen macht.

Beratung läuft auf Kontext. Die KPI-Definitionen des Kunden, der Stakeholder, der immer in Kopie muss, die Entscheidung aus dem März-Workshop, die Art, wie dieser Kunde Zahlen gerundet haben will. Ein zustandsloser Agent lässt dich all das am Anfang jeder Arbeits-Session neu liefern, was zwischen lästig und teuer liegt. Gescopte Memory heißt: Jedes Mandat sammelt sein eigenes Arbeitswissen. Du erklärst die KPI-Definitionen einmal, und in Woche sechs wendet der Agent sie noch an. Pro Kunde, nie über Kunden hinweg.

Die Stundensatz-Rechnung ist unromantisch und real. Frisst der Kontext-Neuaufbau fünfzehn Minuten pro Kunden-Session und fährst du sechs Kunden-Sessions pro Woche, sind das neunzig Minuten unabrechenbares Ritual, jede Woche, die Memory größtenteils löscht.

Was du in jedem Tool prüfst, das du übernimmst

Unserem oder irgendeinem. Nimm diese Liste mit.

• Verbindungen pro Kunde gruppierbar, Tools namespaced, kein globaler Haufen
• OAuth wo möglich, begrenzte Freigaben, Geheimnisse in einem verschlüsselten Vault
• Widerruf pro Kunde auf einem Screen, hinterher verifizierbar
• Ein Audit-Trail, filterbar nach Mandat
• Memory pro Mandat gescoped, exportierbar und löschbar
• Klarer Datenstandort (bei EU-Kundenarbeit kommt diese Frage irgendwann vom Kunden; siehe [Warum EU-Teams fragen, wo ihre KI-Infrastruktur läuft](/de/blog/eu-hosting-for-ai-infrastructure))

Volle Transparenz: Tulimoa ist unser Produkt, und das [Gateway](/de/gateway) ist genau entlang dieser Linien gebaut (verschlüsselter Vault pro Geheimnis, Widerruf pro Verbindung, Audit-Trail, Memory-Tools kostenlos auf jedem Plan, EU-gehostet). Es ist in früher Beta und noch nicht self-serve, und jeder Plan verbindet aktuell einen Agenten. Führst du eine ganze Agentur statt einer Solo-Praxis, verschiebt sich die Form etwas: [Die Agentur-Version](/de/blog/mcp-gateway-for-agencies) gibt es separat.

Was auch immer du wählst: Übernimm den Standard vor dem Tooling. Eine Grenze pro Kunde, toter Zugriff bei der Übergabe und ein Log, das du dem Kunden zeigen würdest. Das ist die ganze Disziplin.