Fallstudie · Daten und Governance

Analysten Agenten für Produktionsdaten geben — ohne die Schlüssel auszuhändigen.

Ein Datenteam wünschte sich Self-Service-KI-Agenten gegen das Warehouse und interne APIs, aber keine Welt, in der jeder Analysten-Laptop Produktions-Zugangsdaten trägt. Ein onemcp-Portal hielt die Authentifizierung hostseitig und den Zugriff zentral.

Branche: Daten und Analytik
Team: ~25 Analysten + ein 4-köpfiges Datenplattform-Team
Tech-Stack: Snowflake · dbt · Postgres · interne Metrik-API · GitHub

# Überblick

Keine Produktions-Zugangsdaten auf Analysten-Rechnern
1 Portal als zentraler Punkt der Zugriffskontrolle
Neue Werkzeuge zentral hinzugefügt, nicht Laptop für Laptop

Illustratives Szenario, angelehnt an gängige onemcp-Bereitstellungen. Das Team ist eine Komposition und kein namentlich genannter Kunde; die Zahlen sind repräsentativ, nicht gemessen.

Hintergrund

Ein Datenteam von rund fünfundzwanzig Analysten wollte KI-Agenten für die tägliche Arbeit nutzen: Abfragen schreiben, Metrikdefinitionen nachverfolgen, die Gesundheit von Pipelines prüfen. Die benötigten Werkzeuge — Snowflake, dbt, eine interne Metrik-API, ein paar Postgres-Replikate — hatten allesamt verfügbare MCP-Server.

Der Engpass war nie der Agent. Es war die Frage, die die Security jedes Mal stellte: *Wo liegen die Zugangsdaten?*

Die Herausforderung

Der naheliegende Weg wäre gewesen, jedem Analysten die MCP-Server zu geben und ihn sich selbst authentifizieren zu lassen. Die Security hätte das nicht freigegeben, und sie hatte recht damit.

Zugangsdaten würden sich ausbreiten. Fünfundzwanzig Analysten, die je auf ihrem Rechner Warehouse- und API-Zugangsdaten halten, sind fünfundzwanzig Stellen, an denen ein Geheimnis lecken kann — ohne saubere Möglichkeit zur Rotation.
Zugriff war alles oder nichts. Einen Server auszuhändigen, hieß, alles auszuhändigen, was dessen Token vermochte, bei kaum vorhandener Sicht darauf, wer was besaß.
Governance skalierte nicht. Zugriffe Laptop für Laptop zu prüfen und zu entziehen, war ein Prozess, den niemand verantworten wollte.

Der Ansatz

Das Datenplattform-Team betrieb ein einziges onemcp-Portal als Grenze zwischen Analysten und Produktionssystemen.

Zugangsdaten bleiben hostseitig. Jeder Upstream wird einmal im Portal authentifiziert. Natives Upstream-OAuth und Tokens leben dort — nie auf dem Rechner eines Analysten, nie in einem Repository. Die Agenten der Analysten verbinden sich mit dem Portal, nicht mit den Datenbanken.
Zugriff ist zentral. Welche Server verfügbar sind und für wen, wird an einer Stelle entschieden. Ein neues Werkzeug einzuführen ist eine Portal-Änderung; einen Zugriff zu entziehen, erfordert kein Eingreifen in irgendeine Einrichtung.
Der Katalog bleibt im Kontext schlank. Über den Code Mode stellt das Portal search, describe und execute bereit statt des Schemas jedes Werkzeugs — Agenten holen also nur die für eine Aufgabe nötigen Werkzeuge, und der Kontext des Analysten bleibt bei der Analyse.

Die Ergebnisse

Keine Produktions-Zugangsdaten auf Laptops. Die Geheimnisse liegen im Portal. Ein ausscheidender Analyst oder ein verlorenes Gerät ist kein Rotations-Notfall mehr.
Ein Ort für Governance. Die Security prüft und verwaltet Zugriffe am Portal, nicht quer über fünfundzwanzig einzelne Konfigurationen.
Self-Service ohne Wildwuchs. Die Analysten bekamen ihre Agenten; das Plattform-Team behielt einen einzigen, prüfbaren Kontrollpunkt — und das nächste Werkzeug hinzuzufügen ist eine einzige zentrale Änderung.

Der Durchbruch war nicht der Agent — es war, dass wir ja sagen konnten. Der Zugriff liegt im Portal, also musste die Security eine Sache prüfen statt dreißig Laptops.