---
title: "Fallstudie: Self-Service-Datenagenten, ohne Zugangsdaten preiszugeben — onemcp"
description: "Ein illustratives Datenteam wollte, dass Analysten KI-Agenten gegen Produktionssysteme nutzen, ohne Datenbank- und Warehouse-Zugangsdaten zu verteilen. Die hostseitige Authentifizierung von onemcp hielt die Geheimnisse von jedem Laptop fern."
ogTitle: "Fallstudie: Self-Service-Datenagenten, Geheimnisse bleiben, wo sie hingehören"
ogDescription: "Wie ein Datenteam seinen Analysten KI-Agenten für Produktionswerkzeuge gab und dabei jedes Zugangsdatum hostseitig in einem onemcp-Portal hielt."
url: "https://onemcp.dev/de/case-studies/data-team-secure-agents"
eyebrow: "Fallstudie · Daten und Governance"
headline: "Analysten Agenten für Produktionsdaten geben — ohne die Schlüssel auszuhändigen."
summary: "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."
industry: "Daten und Analytik"
teamSize: "~25 Analysten + ein 4-köpfiges Datenplattform-Team"
stack: "Snowflake · dbt · Postgres · interne Metrik-API · GitHub"
illustrative: "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."
results:
  - "Keine Produktions-Zugangsdaten auf Analysten-Rechnern"
  - "1 Portal als zentraler Punkt der Zugriffskontrolle"
  - "Neue Werkzeuge zentral hinzugefügt, nicht Laptop für Laptop"
quote: "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."
quoteAttribution: "Leitung Datenplattform (illustrativ)"
---

## 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.

## Verwandte Fallstudien

- [Ein Plattform-Team bündelt 20 MCP-Server hinter einem Endpunkt](/de/case-studies/platform-team-mcp-gateway)
- [Ein KI-Support-Agent auf Token-Diät](/de/case-studies/support-agent-token-diet)