MCP-Server für Unternehmenssysteme: aufbauen, absichern und steuern

Dieser Leitfaden richtet sich an Engineering Leads, Architekten und IT-Governance-Verantwortliche in mittelständischen Unternehmen, die einen KI-Agenten oder -Assistenten mit einem vorhandenen ERP-, CRM- oder Finance-System verbinden sollen – nachdem die Agent-Architektur selbst entschieden wurde (der Leitfaden zur agentischen KI-Architektur behandelt die Platzierung von Kontrollpunkten; diese Seite beschreibt die darunter liegende Verbindungsschicht). Die Umsetzung erfolgt über agentische KI-Automatisierung. Wenn ein zweiter spezialisierter Agent ebenfalls diesen aufrufen muss, entscheidet unser A2A- und MCP-Leitfaden, ob diese Übergabe zusätzlich das A2A-Protokoll erfordert.

In diesem Leitfaden

• Was sollte ein MCP-Server aus einem Unternehmenssystem bereitstellen?
• Die Drei-Stufen-Freigabematrix
• Den Server absichern: Identität, Scope und das Gateway
• MCP im großen Maßstab steuern: Registry, Review und Widerruf
• Ein Ablaufplan für die Inbetriebnahme eines MCP-Servers
• Welche Rolle KI beim Aufbau eines MCP-Servers spielt
• Welche Delivery-Nachweise existieren und welche nicht
• Alternativen: Wer die MCP-Schicht aufbaut und betreibt
• Grenzen dieses Leitfadens
• Häufig gestellte Fragen
• Nächster Schritt

Was sollte ein MCP-Server aus einem Unternehmenssystem bereitstellen?

Stellen Sie die kleinstmögliche Menge benannter Aktionen bereit, die der Agent für seine Aufgabe benötigt – niemals einen generischen Durchgriff auf die ERP-, CRM- oder Finance-API. Ein Tool wie get_invoice_status oder list_open_orders ist eine bewusste, typisierte und prüfbare Funktion; ein Tool, das beliebiges SQL weiterleitet oder einen ungegrenzten REST-Aufruf ausführt, ist kein MCP-Tool, sondern die gesamte API mit einem zusätzlichen Zwischenschritt – einschließlich aller Risiken des dahinterliegenden Systems.

Die Drei-Stufen-Freigabematrix

Ordnen Sie jede mögliche ERP-, CRM- oder Finance-Aktion einer der drei Stufen zu, bevor ein einziges Tool gebaut wird. Die Stufe – nicht das System, das sie berührt – bestimmt die Genehmigungsregel.

Die meisten ersten MCP-Server überschreiten den Umfang der Write-Stufe: Ein create_order-Tool, das auch einen Rabattprozentsatz akzeptiert, überträgt dem Agenten eine Befugnis, die niemand geprüft hat. Benennen Sie die Felder eines Tools so eng wie die Aufgabe es erfordert – nicht so weit wie die API es erlaubt.

Den Server absichern: Identität, Scope und das Gateway

Die Autorisierungsspezifikation des Model Context Protocol ordnet den MCP-Server der OAuth-2.1-Ressourcenserver-Rolle zu: Er akzeptiert Bearer-Tokens, validiert, dass jedes Token speziell für ihn ausgestellt wurde, und weist ein Token zurück, das für einen anderen Server ausgestellt wurde – die Audience-Binding-Anforderung, die OAuth 2.0 Resource Indicators (RFC 8707) definieren. Daraus ergeben sich drei Entscheidungen.

• Authentifizierung über den eigenen Identity-Provider des Unternehmens – niemals über einen statischen gemeinsamen API-Key –, damit ein Token an die eigene Identität des aufrufenden Agenten gebunden ist und eine spätere Prüfung oder ein Widerruf überhaupt möglich ist.
• Jedes Token auf die kleinste benötigte Menge von Tools eingrenzen. Ein Token, das alle Tools des Servers aufrufen kann, hebelt die Drei-Stufen-Matrix oben aus; Scopes werden pro Tool oder pro Tool-Gruppe vergeben, gemäß der Least-Privilege-Vorgabe der Spezifikation.
• Ein Gateway vor mehr als einem MCP-Server schalten. Sobald ein zweiter Server existiert, ist ein einziger Durchsetzungspunkt für Authentifizierung, Rate-Limiting und Logging einfacher abzusichern und zu prüfen als die native Absicherung jedes einzelnen Servers.

Netbase sichert dies so ab, wie es alles andere absichert, das es baut: TLS während der Übertragung, rollenbasierte Zugriffskontrolle, MFA auf jedem Dashboard, das ein Write-Tool genehmigen kann, sowie die ISO-27001- und SOC-2-Type-II-Frameworks und die DSGVO-, HIPAA- und CCPA-konformen Praktiken, die es bereits auf seine eigene Delivery anwendet.

MCP im großen Maßstab steuern: Registry, Review und Widerruf

Governance beginnt, bevor das zweite Tool ausgeliefert wird – nicht nach dem zehnten. Führen Sie ein Registry über jeden MCP-Server, jedes bereitgestellte Tool und jeden verbundenen Agenten oder Aufrufer: Ohne diesen Katalog gibt es nichts zu prüfen, und eine Verbindung, an die sich niemand erinnert, wird auch von niemandem widerrufen. Ein veröffentlichtes MCP-Governance-Framework behandelt dieses Registry – mit Least-Privilege-Scopes und automatisierter Credential-Rotation – als Kern einer unternehmensweiten MCP-Steuerung.

Drei Praktiken halten das Registry nutzbar:

1. Jeden Aufruf protokollieren – mit der Identität des Aufrufers, dem Tool-Namen, den Argumenten und der Information, ob er automatisch genehmigt oder eskaliert wurde –, damit ein strittiger Schreibvorgang auf den auslösenden Aufruf zurückverfolgt werden kann.
2. Verbindungen nach einem festen Zeitplan überprüfen, so wie ein Zugriffsreview jeden anderen System-Account abdeckt, und entziehen, was niemand begründen kann.
3. Einen funktionierenden Kill-Switch vorhalten. Das Widerrufen eines Tokens oder das Deaktivieren eines Tools sollte eine einzige Aktion erfordern – keine Deployment.

Welche Delivery-Nachweise existieren und welche nicht

Netbase hat die Art von System gebaut, vor dem ein MCP-Server sitzt, und hat KI-Projekte ausgeliefert, die definierte Aktionen dagegen aufrufen – allerdings noch nicht beides zusammen in einem einzigen Projekt:

• Multi-Tenant-Cloud-ERP für einen US-Kunden (nicht namentlich genannt). Seit 2020 Offshore-Entwicklung und Managing Partner für ein als SaaS ausgeliefertes Cloud-ERP; Phase 1 umfasst CRM, eine Wissensdatenbank, Arbeits- und Projektmanagement sowie API-Integrationen – die Oberfläche, aus der ein MCP-Tool-Katalog seine ersten Read-only-Tools beziehen würde.
• ERP- und CRM-Beratung (nicht namentlich genannt). Odoo-Beratung und -Anpassung, E-Commerce-zu-ERP-Integrationen, die Kataloge, Bestände, Bestellungen und Kundendaten per API synchronisieren, sowie ein Vtiger-zu-ERP-Upgrade; jede ist die Art von definierter, begrenzter Aktion, die ein MCP-Tool kapselt – keine rohe Datenbankverbindung.
• Ein WhatsApp-KI-Chatbot mit CRM-Synchronisierung (nicht namentlich genannt). Ein Agent, der CRM-Daten auf einem definierten Aktionssatz liest und schreibt, ausgeliefert bevor MCP die gängige Aufrufkonvention dafür war.
• Weitere ausgelieferte KI-Projekte, anonymisiert: retrieval-augmented Wissensassistenten, Dokumenten-KI und MLOps-Pipelines für hier nicht namentlich genannte Kunden.

Was nicht existiert. Kein veröffentlichter Netbase-Nachweis beschreibt einen ausgelieferten MCP-Server, ein veröffentlichtes Tool-Registry oder einen Agenten, der das ERP-, CRM- oder Finance-System eines Kunden über MCP aufruft. Die Matrix und der Ablaufplan oben stammen aus der ERP/CRM-Integrations- und agentenseitigen Delivery-Praxis von Netbase sowie den zitierten Quellen – nicht aus einem gemessenen MCP-Projekt; es werden keine Angaben zu Dauer, Kosten, Genauigkeit oder Adoptionsrate gemacht.

Alternativen: Wer die MCP-Schicht aufbaut und betreibt

Wann noch nicht gebaut werden sollte. Ein einzelnes internes Skript mit einem Aufrufer und ohne Plan für einen zweiten Agenten benötigt selten ein Protokoll, ein Registry oder ein Gateway; der Overhead kauft Interoperabilität, die eine Ein-Aufrufer-Integration nicht nutzt. Bauen Sie auf MCP hin, sobald ein zweiter Agent, Assistent oder Partner dieselbe Tool-Oberfläche benötigt.

In der kundenspezifischen Entwicklung von Netbase liegt das geistige Eigentum des Erstellten beim Kunden, und die meisten Projekte laufen auf Festpreis-Verträgen, die nach der Discovery vereinbart werden. Die zugrundeliegende API-Arbeit liegt in Systems- und API-Integration und ERP- und CRM-Entwicklung, die agentenseitige Schicht in KI-Integration, ausgeliefert über agentische KI-Automatisierung und die Enterprise-KI-Agenten-Plattform, für Branchen wie Professional Services, in denen ERP-, CRM- und Finance-Daten hinter denselben Genehmigungsfragen liegen.

Grenzen dieses Leitfadens

• Die MCP-Spezifikation ist jung und wird häufig überarbeitet; prüfen Sie sie, bevor Sie einen Autorisierungsflow dagegen implementieren.
• Die Drei-Stufen-Matrix und der Ablaufplan sind ein Ausgangsentwurf, keine Garantie dafür, dass ein bestimmtes Tool für Ihr System sicher ist.
• Es werden keine Angaben zu Dauer, Kosten, Genauigkeit oder Adoptionsrate gemacht; reale Zahlen hängen von Ihren eigenen Systemen und Ihrem Aufrufvolumen ab.
• Scoping, Logging und ein Registry reduzieren Risiken; sie ersetzen nicht die Notwendigkeit, einen ungewöhnlichen Schreibvorgang zu überprüfen, wie die OWASP-Leitlinien zu Excessive Agency empfehlen.

Nächster Schritt

Teilen Sie uns mit, welche ERP-, CRM- oder Finance-Aktionen ein Agent aufrufen soll, und wir vereinbaren ein Solution-Review, um die Freigabematrix, das Authentifizierungsmodell und das Registry dafür zu konzipieren. Sie können auch den Service agentische KI-Automatisierung ansehen oder weitere Netbase-Insights durchsuchen.

Verwandte Leistungen und Lösungen