Enterprise-MCP-Server: Sicherheit, Scope, Governance

Die prägende Enterprise-KI-Verschiebung des Jahres 2026 ist der Übergang von Pilotprojekten zur Produktion. Mit der General Availability des Microsoft Agent Framework 1.0 am 3. April 2026 und der Reifung von Azure AI Foundry als zentraler Plattform zum Bauen und Governen von Agenten lautet die Frage nicht mehr können wir einen Agenten bauen, sondern können wir einen sicher gegen unsere realen Systeme betreiben. Das Model Context Protocol (MCP) ist der Ort, an dem diese Frage beantwortet wird, denn der MCP-Server ist die Grenze, an der ein autonomes Modell auf Ihre Produktionsdaten trifft.

In diesem Beitrag geht es darum, diese Grenze gut zu gestalten. Wir haben MCP-Server für regulierte europäische Kunden gebaut und geprüft, und die Fehler, die wir sehen, betreffen selten das Protokoll selbst — sie entstehen, weil ein MCP-Server als Entwickler-Spielzeug behandelt wird statt als die sicherheitskritische Infrastruktur, die er tatsächlich ist.

TL;DR / Kernaussagen

• Ein Enterprise-MCP-Server ist eine Sicherheitsgrenze, keine Komfortschicht: Authentifizierung, Autorisierung und Audit gehören auf den Server, niemals in den Prompt.
• Bevorzugen Sie viele kleine, domänenbezogene Server gegenüber einem Monolithen — Least Privilege und Audit-Scope folgen der Servergrenze.
• Der Aufrufer ist ein nicht-deterministisches Modell, also validieren Sie jedes Argument serverseitig und beschränken Tokens auf den handelnden Menschen, nicht auf den Agenten.
• Tools mit hoher Auswirkung (Schreiben, Löschen, Zahlen, Versenden) brauchen Allow-Lists und Human-in-the-Loop statt Modell-Ermessen.
• MCP-Tool-Aufrufe sind genau die nachvollziehbaren Nachweise, die NIS2 und der EU AI Act erwarten — planen Sie Observability und Logging von Tag eins ein.

Was ein MCP-Server tatsächlich ist

Das Model Context Protocol standardisiert, wie ein KI-Agent Fähigkeiten entdeckt und aufruft. Ein MCP-Server stellt drei Primitive bereit: Tools (Aktionen, die das Modell aufrufen kann), Ressourcen (Daten, die das Modell lesen kann) und Prompts (wiederverwendbare Vorlagen). Das Microsoft Agent Framework 1.0 liefert MCP-Integration neben dem A2A-Protokoll, sodass Agenten sowohl Ihre Server aufrufen als auch untereinander delegieren können.

Was dies enterprise-relevant — und riskant — macht, ist, dass der Aufrufer ein Sprachmodell ist. Eine REST-API wird von deterministischem Code aufgerufen, den ein Reviewer lesen kann. Ein MCP-Tool wird aufgerufen, weil ein Modell in natürlicher Sprache geschlussfolgert hat, dass es das tun sollte. Dieser eine Unterschied verändert jede der folgenden Designentscheidungen.

Scope: die wichtigste Designentscheidung

Beim Scope geht das meiste MCP-Design schief. Die Versuchung ist, einen mächtigen Server zu bauen, der alles bereitstellt, weil das für den Agenten bequem ist. Widerstehen Sie ihr.

Wir gestalten MCP-Server um abgegrenzte Domänen, jede mit eigener Identität, eigenem RBAC-Modell und eigenem Wirkungsradius. Ein Monolith konzentriert das Risiko: ein einziger erfolgreicher Prompt-Injection-Angriff oder ein einziges zu weit gefasstes Token kompromittiert alles. Domänenbezogene Server halten Least Privilege durchsetzbar und Audits handhabbar.

Designdimension	Monolithischer MCP-Server	Domänenbezogene MCP-Server
Wirkungsradius	Gesamtsystem	Eine Domäne
Least Privilege	Schwer durchsetzbar	Natürlich pro Server
Audit-Scope	Verwoben	Pro Domäne, sauber
Versionierung / Stilllegung	Riskant, gekoppelt	Unabhängig
Identitätsmodell	Eine überberechtigte Identität	Eine Identität pro Server
Governance	Verhandlung	Richtlinie

Innerhalb eines Servers beschränken Sie jedes Tool auf die engste nützliche Operation. Ein Tool query_invoices(customer_id, date_range) ist auditierbar und abgegrenzt; ein Tool run_sql(query) ist ein Risiko, das dem Modell Ihre Datenbank ausliefert.

Authentifizierung und Autorisierung

Zwei Regeln bestimmen hier die Sicherheit, und beide sind nicht verhandelbar.

Autorisierung liegt auf dem Server. Das Modell darf alles anfragen — das ist seine Aufgabe. Der Server entscheidet, was ausgeführt wird. Kodieren Sie Zugriffsregeln niemals im System-Prompt; ein Prompt ist eine Empfehlung, keine Kontrolle. Das spiegelt die breiteren Muster wider, die wir im Beitrag zum Agent-to-Agent-A2A-Protokoll behandeln, wo Vertrauen zwischen Komponenten explizit statt vorausgesetzt sein muss.

Tokens sind auf den Menschen beschränkt, nicht auf den Agenten. Wenn ein Agent im Auftrag eines Benutzers handelt, sollte der MCP-Server ein Token erhalten, das die effektiven Berechtigungen dieses Benutzers trägt, nicht einen breiten Service Principal, der alles für jeden tun kann. In Azure bedeutet das On-Behalf-Of-Token-Flows und Entra ID, damit der Finanz-Agent, der für einen Junior-Analysten handelt, nicht lesen kann, was nur der CFO sehen darf.

Eine praktische Checkliste für jedes Tool:

Loading diagram...

1. Authentifizieren Sie den Aufrufer und lösen Sie die handelnde menschliche Identität auf.
2. Autorisieren Sie das konkrete Tool gegen die effektiven Berechtigungen dieses Menschen.
3. Validieren Sie jedes Argument serverseitig — Typen, Wertebereiche, Allow-Lists, injektionssicher.
4. Klassifizieren Sie die Auswirkung des Tools (Lesen / Schreiben / irreversibel / extern).
5. Begrenzen Sie Tools mit hoher Auswirkung durch explizite Allow-Lists und, wo gerechtfertigt, menschliche Freigabe.
6. Protokollieren Sie die Anfrage, die erklärte Absicht des Modells, die Argumente und das Ergebnis.

Verteidigung gegen das Modell selbst

Prompt Injection ist der Angriff, der in klassischen APIs kein Pendant hat. Ein Dokument, das der Agent liest, eine E-Mail, die er zusammenfasst, oder ein Datensatz, den er abfragt, kann Anweisungen enthalten, die das Modell kapern und es Tools bösartig aufrufen lassen. Sie lösen das nicht im Modell. Sie begrenzen es am Server.

Die Kontrollen, die sich in der Praxis bewähren:

• Auswirkungs-Tiering. Lesende Tools dürfen großzügig sein. Tools für Schreiben, Löschen, Zahlung und externen Versand erfordern Allow-Lists, Rate Limits und Freigabe. Das Modell erhält nie ungefilterten Zugriff auf irreversible Aktionen.
• Argumentvalidierung als Sicherheitskontrolle. Behandeln Sie jedes Tool-Argument als feindliche Eingabe. Lehnen Sie alles außerhalb eines bekannten Schemas ab. Das ist Ihre stärkste Einzelverteidigung gegen injizierte Payloads.
• Human-in-the-Loop für die gefährliche Stufe. Ein Bestätigungsschritt bei einer Zahlung oder einem Massenlöschvorgang ist keine Reibung; er ist der Unterschied zwischen einem eingedämmten Vorfall und einer Schlagzeile.
• Ausgabefilterung. Entfernen Sie Geheimnisse und personenbezogene Daten aus Tool-Antworten, bevor sie wieder in den Modellkontext gelangen, damit ein kompromittierter Prompt nicht exfiltrieren kann, was er nicht sehen darf.

Observability und Kosten-Governance

Sie können nicht governen, was Sie nicht sehen. Ein MCP-Server in Produktion braucht durchgängiges Tracing, das die Benutzeranfrage, die Schlussfolgerung des Agenten, jeden Tool-Aufruf, dessen Argumente und dessen Ergebnis verknüpft. Wir instrumentieren mit OpenTelemetry und leiten in Azure AI Foundry und das SIEM des Kunden — dieselbe Disziplin, die wir im Beitrag zu Observability und Tracing für KI-Agenten ausführen.

Erfassen Sie pro Tool: Latenz, Fehlerrate und Kosten. Agenten können in einer Weise schleifen, wiederholen und sich verzweigen, die den Token-Verbrauch leise vervielfacht, daher gehören Kosten pro Tool und pro Konversation auf ein Dashboard mit Budget-Alerts. Ebenso wichtig: Alarmieren Sie bei auffälligen Mustern — ein plötzlicher Anstieg von Schreiboperationen oder ein Agent, der ein nie zuvor genutztes Tool aufruft, ist ein Frühsignal für Fehlverhalten oder Kompromittierung. Wie sich dies in die Laufzeit einfügt, zeigt der Beitrag zur Architektur des Microsoft Agent Framework 1.0.

Governance und EU-regulatorische Einordnung

Für europäische Unternehmen ist MCP-Server-Design nicht nur eine Engineering-, sondern eine Compliance-Frage.

• NIS2. Berühren Ihre Agenten wesentliche oder wichtige Dienste, fällt der MCP-Server unter Ihre Risikomanagementmaßnahmen, und die Verantwortung liegt bei der Geschäftsleitung. Tool-Aufruf-Logs sind Teil Ihres Kontrollnachweises.
• EU AI Act. Ist das Agentensystem hochriskant, trägt der MCP-Server zu den Protokollierungs-, Aufsichts- und Dokumentationspflichten bei, die Sie in einer Konformitätsbewertung nachweisen müssen. Prüfer erwarten nachvollziehbare Aufzeichnungen (Nachweispflichten) — und MCP-Tool-Aufrufe sind genau das, wenn Sie sie entsprechend gestaltet haben.
• Lieferkette. Drittanbieter-MCP-Server sind Abhängigkeiten. Prüfen Sie sie, fixieren Sie Versionen und bewerten Sie ihre Tool-Oberfläche wie jede Lieferantenkomponente.

Eine pragmatische Governance-Baseline:

1. Führen Sie ein Verzeichnis jedes MCP-Servers, seines Verantwortlichen, seiner Tools und deren Auswirkungsstufe.
2. Verlangen Sie ein Review-Gate, bevor ein neues schreibfähiges Tool ausgeliefert wird.
3. Setzen Sie eine Aufbewahrung für Tool-Aufruf-Logs durch, die Ihre Audit- und Meldepflichten erfüllt.
4. Führen Sie regelmäßige Zugriffsüberprüfungen für die eingeschränkten Identitäten jedes Servers durch.

Wo Sie anfangen

Wenn Sie von Pilot zu Produktion übergehen, beginnen Sie mit einer abgegrenzten Domäne. Bauen Sie einen einzelnen domänenbezogenen Server, bringen Sie Authentifizierung, serverseitige Autorisierung, Argumentvalidierung und Tracing in Ordnung und übertragen Sie dieses Muster dann als Vorlage auf weitere Domänen. Die Disziplin, die Sie am ersten Server etablieren, ist es, die den zehnten sicher macht.

FAQ

Was ist ein MCP-Server im Enterprise-Kontext? Ein MCP-Server (Model Context Protocol) stellt KI-Agenten Tools, Ressourcen und Prompts über eine standardisierte Schnittstelle bereit. Im Enterprise-Kontext liegt er zwischen einer Agent-Laufzeit und Ihren internen Systemen — Datenbanken, APIs, Ticketing, ERP — und wird zur kontrollierten Grenze, an der Authentifizierung, Autorisierung, Scoping und Audit-Logging durchgesetzt werden. Behandeln Sie ihn als Produktionsinfrastruktur, nicht als Entwickler-Komfort.

Wie unterscheidet sich MCP-Sicherheit von der Absicherung einer normalen REST-API? Eine REST-API wird von deterministischem Code aufgerufen; ein MCP-Server wird von einem nicht-deterministischen Modell aufgerufen, das Tools auf Basis natürlichsprachlicher Schlussfolgerungen auswählt. Sie können sich also nicht auf vorhersehbares Verhalten des Aufrufers verlassen. Sie müssen pro Tool das Least-Privilege-Prinzip durchsetzen, jedes Argument serverseitig validieren, Tokens auf den handelnden Benutzer statt auf den Agenten beschränken und die Absicht des Modells gemeinsam mit der Aktion protokollieren. Prompt Injection macht die Tool-Bereitstellung zu einer Angriffsfläche, die eine normale API nicht hat.

Sollte jedes Team einen großen MCP-Server bauen oder mehrere kleine? Bevorzugen Sie viele kleine, domänenbezogene Server gegenüber einem Monolithen. Ein Finanz-MCP-Server, ein HR-MCP-Server und ein Observability-MCP-Server tragen jeweils ihre eigene Identität, RBAC und ihren eigenen Wirkungsradius. Das hält Least Privilege durchsetzbar, macht Audits handhabbar und erlaubt es, eine Fähigkeit zu versionieren oder stillzulegen, ohne unverwandte Tools anzufassen. Ein monolithischer Server konzentriert das Risiko und macht Governance zur Verhandlungssache statt zur Richtlinie.

Wie verhindert man, dass ein Agent Tools aufruft, die er nicht aufrufen sollte? Autorisierung erfolgt auf dem Server, niemals im Prompt. Jedes Tool prüft das eingeschränkte Token des Aufrufers und die effektiven Berechtigungen der Person, in deren Auftrag der Agent handelt. Tools mit hoher Auswirkung (Schreiben, Löschen, Zahlung, externer Versand) erfordern explizite Allow-Lists und, wo angemessen, eine Freigabe durch einen Menschen (Human-in-the-Loop). Das Modell darf alles anfragen; der Server entscheidet, was tatsächlich ausgeführt wird.

Wie ordnet sich MCP-Server-Design in EU-Regulierung wie NIS2 und den EU AI Act ein? Ein MCP-Server, der wichtige oder wesentliche Dienste berührt, fällt unter Ihre NIS2-Risikomanagementmaßnahmen und die Verantwortung der Geschäftsleitung. Ist das Agentensystem nach dem EU AI Act hochriskant, ist der Server Teil der Protokollierungs-, Aufsichts- und Dokumentationsnachweise, die Sie in einer Konformitätsbewertung erbringen müssen. Tool-Aufrufe sind genau die Art nachvollziehbarer Aufzeichnungen, die Prüfer erwarten — planen Sie Audit-Logging daher von Tag eins ein.

Wie sieht Observability für MCP-Server in Produktion aus? Sie brauchen durchgängiges Tracing, das die Benutzeranfrage, die Schlussfolgerung des Agenten, jeden Tool-Aufruf, die übergebenen Argumente und das Ergebnis verknüpft — typischerweise über OpenTelemetry in Azure AI Foundry oder Ihr bestehendes SIEM. Erfassen Sie Latenz, Fehlerraten und Kosten pro Tool und alarmieren Sie bei auffälligen Aufrufmustern wie einem plötzlichen Anstieg von Schreiboperationen. Ohne dies bleibt ein fehlverhaltender Agent unsichtbar, bis er Schaden anrichtet.

---

CC Conceptualise gestaltet sichere, governte MCP-Server und Agentenplattformen für europäische Unternehmen auf dem Weg vom Pilot zur Produktion. Wenn Sie Agenten vor Ihre realen Systeme stellen, sehen Sie unsere Leistungen für KI- und Data-Platform-Engineering oder erreichen Sie uns unter mbrahim@conceptualise.de.