MCP · 12 Min.
MCP Enterprise Connectors 2026: Governance für Agenten-Toolzugriff
MCP macht Agenten schneller integrationsfähig. Genau deshalb brauchen Unternehmen Connector Governance, bevor jedes Tool offen ist.
SYSTEMS Grafik zu MCP Enterprise Connectors: Context -> Tools -> Control. Fokus: Wie Unternehmen MCP-Connectors sicher strukturieren und Tool-Zugriff für Agenten kontrollieren.
Kurzfassung
MCP erleichtert Tool- und Datenzugriff für Agenten. Jede Verbindung braucht Scope, Ownership, Logging und Review. Connector Governance verhindert, dass Integrationen unkontrolliert wachsen.
Strategischer Lesepfad
Baue das Thema im passenden Cluster weiter aus und verknüpfe es mit den nächsten Architekturentscheidungen.
Update Mai 2026: Connectors werden zur Datenprodukt-Schicht Remote MCP -Server können private Datenquellen für ChatGPT, Deep Research oder API-Integrationen verfügbar machen. OpenAI beschreibt dafür unter anderem Search- und Fetch-Muster: Ein Connector findet relevante Einträge und liefert anschliessend den konkreten Inhalt. Genau hier entsteht Governance-Bedarf.
Ein Connector ist nicht einfach ein technischer Adapter. Er ist ein Datenprodukt mit Zweck, Datenklasse, Berechtigungen, Logging und Missbrauchsrisiko. Wenn diese Metadaten fehlen, weiss später niemand, welcher Agent welche Unternehmensdaten lesen oder weiterverarbeiten durfte.
Warum MCP so schnell relevant wird Agenten werden erst produktiv, wenn sie mit echten Systemen arbeiten. MCP standardisiert diesen Zugriff und macht Integrationen wiederverwendbarer.
Das ist stark, aber es verschiebt Sicherheitsfragen in die Connector-Schicht.
Stand Mai 2026: MCP ist Tool-Infrastruktur, nicht nur Protokoll Anthropic, OpenAI und andere Plattformen nutzen MCP, um Agenten mit Tools, Datenbanken und APIs zu verbinden. MCP beschreibt Server-Konzepte, Tools, Resources und Prompts. Die Authorization-Spezifikation und Security Best Practices machen aber auch klar: Ein Connector ist eine Sicherheitsgrenze.
Besonders wichtig: Tools sind die riskanteste Primitive, weil das Modell sie aktiv auswählt. MCP liefert Bausteine für Governance, aber keine automatische Sicherheit. Authorization kann sauber umgesetzt werden, Tool-Annotations können read-only oder destructive Verhalten markieren, und Security Best Practices warnen vor Confused-Deputy-Risiken, Token Passthrough, SSRF und lokalen Server-Risiken.
Das heisst für Enterprise: Ein MCP-Server darf nicht einfach User-Tokens durchreichen und hoffen, dass Downstream-Systeme es richtig verstehen. Scope-Design, Approval-Flows, Token-Audience-Prüfung, Tool-Scoping und Audit-Logs müssen bewusst gebaut werden.
Was ein Connector-Katalog braucht Unternehmen sollten jeden Connector erfassen: System, Zweck, Datenklasse, Rechte, Owner, Risiko, Umgebung, Auth-Modell, erlaubte Agenten und Audit-Log. Ohne Katalog weiss niemand, welche Agenten welche Werkzeuge nutzen.
Das wird später teuer.
Ein guter Connector-Katalog enthält:
Name: System, Server, Tool-Gruppe, Umgebung. Zweck: welche Aufgabe der Connector löst. Datenklasse: public, intern, vertraulich, personenbezogen, kundenspezifisch. Aktionen: search, fetch, read, create, update, delete, execute. Rollen: welche Agenten und Menschen Zugriff haben. Auth: OAuth, Service Account, User Delegation, Token Audience. Risiko: Datenabfluss, Schreibaktion, finanzielle Aktion, Kundenauswirkung. Logging: Tool Call, Input, Output, User, Agent, Zeit, Resultat. Owner: technischer und fachlicher Verantwortlicher. Evals: Testfälle für Missbrauch, Prompt Injection und Rechteverletzung. Scope ist die wichtigste Entscheidung Ein Connector sollte nicht pauschal alles können. Besser sind enge Tools: lesen, suchen, vorschlagen, vorbereiten, schreiben. Schreibrechte kommen spät und nur mit Evals.
So bleibt Autonomie kontrollierbar.
Search/Fetch ist besser als Alles-Tool OpenAI beschreibt für Connectoren häufig das Search/Fetch-Muster: Ein Tool sucht relevante Objekte, ein anderes holt den konkreten Inhalt. Das ist für Governance gut, weil Suche und Datenzugriff getrennt werden.
Praktisch:
Ein grosses `do_anything`-Tool ist für Agenten bequem und für Security schlecht.
`search_customers` liefert nur IDs, Titel, Snippets und Relevanz. `fetch_customer` holt Details nur bei Bedarf und mit Berechtigungsprüfung. `create_note` schreibt nur in erlaubte Felder. `send_email` bleibt hinter Review oder Freigabe. Tool-Permissions müssen eng bleiben Claude Code dokumentiert MCP-Tools mit klaren Namen und Permission-Mechaniken. Die Agent-SDK-Doku empfiehlt, erlaubte Tools gezielt zu setzen, statt breite Permission-Modi zu nutzen. Das ist ein Enterprise-Prinzip: Nicht der Server wird pauschal erlaubt, sondern konkrete Aktionen.
Ein Connector kann hunderte Tools expose'n. Zu viele Tools machen Agenten schlechter und riskanter. Progressive Discovery ist deshalb nicht nur Context-Optimierung, sondern Governance: Der Agent sieht nur die Werkzeuge, die für den aktuellen Auftrag nötig sind.
Prompt Injection und Tool Poisoning MCP-Connectoren lesen oft untrusted Content: Tickets, Dokumente, Webseiten, Kundennotizen. Genau dort kann Prompt Injection stecken. OWASP MCP Top 10 und MCP Security Best Practices passen hier zusammen: Tool-Beschreibungen, externe Inhalte, Resource-Metadaten und Tool-Rückgaben müssen als Angriffsoberfläche behandelt werden.
Gute Controls:
externe Inhalte nie als Systeminstruktion behandeln. Tool-Beschreibungen versionieren und reviewen. sensitive Tools nie aus untrusted Content heraus automatisch ausführen. Schreibaktionen mit Human Approval oder Policy Gate absichern. Outputs vor Weitergabe klassifizieren. Connector-Logs für Incident Response speichern. Evals für MCP-Connectoren Vor Produktivbetrieb sollte getestet werden:
MCP wird erst Enterprise-tauglich, wenn diese Tests Teil des Rollouts sind.
ruft der Agent nur erlaubte Tools auf? eskaliert er Schreibaktionen korrekt? verhindert der Connector Token Passthrough und falsche Audience? blockiert er Prompt-Injection-Versuche in Dokumenten? respektiert er Mandanten- und Rollenrechte? sind Logs für Tool Calls vollständig? bleibt Tool-Auswahl stabil, wenn viele Connectoren aktiv sind? Der SYSTEMS-Blick Wir bauen MCP nicht als Integrations-Wildwuchs, sondern als Tool-Governance-Schicht. Erst Katalog, dann Scope, dann Tests, dann Rollout.
Damit wird MCP zu Infrastruktur statt Risiko: Connectoren werden Datenprodukte mit Owner, Rechten, Evals und Audit.
