KI-Assistenten im Team: ERP-Zugriff per MCP mit Rechten

Ein schneller Prototyp sieht oft so aus: ein Werkzeug „SQL ausführen“ mit einem Lesekonto auf der ERP-Datenbank, oder ein Werkzeug, das beliebige Pfade der vorhandenen REST-API aufruft. Beides funktioniert in der Vorführung und ist im Betrieb schwer zu beherrschen. Das OWASP-Projekt zur Sicherheit generativer KI führt dieses Muster als eigenes Risiko: Excessive Agency, also zu viel Handlungsspielraum. Als Ursache nennt es typischerweise einen oder mehrere von drei Faktoren: zu viele Funktionen, zu weitreichende Rechte und zu viel Autonomie (OWASP LLM06:2025). Ein offenes SQL-Werkzeug vereint die ersten beiden. Es kann mehr als die Fragen, für die es gedacht war, und das Datenbankkonto sieht typischerweise mehr Tabellen, als eine einzelne Person im Team sehen dürfte.

OWASP beschreibt den Fall konkret: Eine Erweiterung, die nur Daten lesen soll, verbindet sich mit einer Identität, die neben SELECT auch UPDATE, INSERT und DELETE darf. Als Gegenmittel empfiehlt das Projekt, offene Erweiterungen wie Shell-Befehle oder beliebige Abrufe zu vermeiden und stattdessen Werkzeuge mit eng umrissener Funktion zu bauen (OWASP LLM06:2025). Das Bundesamt für Sicherheit in der Informationstechnik kommt zum selben Schluss: Zugriffs- und Ausführungsrechte von LLM-basierten Anwendungen sollen auf das notwendige Minimum beschränkt werden (BSI, Generative KI-Modelle, Version 2.0). Für den Zugriff auf hinterlegte Wissensdaten rät das BSI zudem ausdrücklich davon ab, das Rechte- und Rollensystem über textuelle Instruktionen umzusetzen, weil das angreifbar ist. Ein Satz im Systemprompt wie „Gib keine Einkaufspreise heraus“ ist also keine Zugriffskontrolle.

Der MCP-Server ist damit keine zusätzliche Schicht um ihrer selbst willen, sondern der Ort, an dem fachliche Regeln stehen. Er übersetzt „Bestand lesen“ in die passenden Aufrufe der Warenwirtschaftsanbindung, streicht Felder, die der Assistent nicht braucht, und lehnt ab, was die Rolle der fragenden Person nicht erlaubt. Wer bereits eine Middleware betreibt, hängt den Server dahinter und nutzt deren Abbildungen und Wiederholungslogik mit. Die Abwägung zwischen direkter REST-Anbindung und Vermittlungsschicht beschreibt der Beitrag REST-API oder Middleware.

Ein typischer Konstruktionsfehler interner Assistenten ist das Sammelkonto: Der Server spricht mit einem einzigen technischen Schlüssel mit dem ERP, und jede Person im Team sieht über den Assistenten alles, was dieser Schlüssel sieht. OWASP beschreibt genau diesen Fall - eine Erweiterung, die im Kontext eines einzelnen Nutzers arbeiten soll, greift mit einer allgemeinen, hoch privilegierten Identität auf nachgelagerte Systeme zu - und empfiehlt, Aktionen im Kontext der jeweiligen Person und mit minimalen Rechten auszuführen (OWASP LLM06:2025). Für einen Assistenten im Innendienst heißt das: Wer im Lager arbeitet, bekommt über den Assistenten dieselben Daten wie in der ERP-Maske, nicht mehr.

Die MCP-Spezifikation liefert dafür einen Autorisierungsrahmen für HTTP-basierte Verbindungen auf Basis von OAuth 2.1 (MCP-Spezifikation, Authorization). Ein geschützter MCP-Server ist dabei OAuth-Ressourcenserver, der Client im Assistenten ist OAuth-Client. Server müssen ihre Metadaten nach RFC 9728 veröffentlichen, damit Clients den zuständigen Autorisierungsserver finden, und Clients müssen bei Autorisierungs- und Token-Anfragen mit dem Parameter resource nach RFC 8707 angeben, für welchen Server das Token gedacht ist (MCP-Spezifikation, Authorization). Der Server muss prüfen, dass ein Token genau für ihn ausgestellt wurde. Ein so zielgebundenes Token kann der Empfänger nicht an anderer Stelle für den Zugriff auf fremde Ressourcen einsetzen (RFC 8707). Als Autorisierungsserver bietet sich der vorhandene Identitätsdienst an, über den sich das Team ohnehin anmeldet.

Wichtig für die ERP-Seite ist das Verbot der Token-Weitergabe: MCP-Server dürfen keine anderen Tokens annehmen oder durchreichen (MCP-Spezifikation, Authorization). Der Sicherheitsleitfaden zur Spezifikation nennt das Durchreichen ausdrücklich ein Anti-Muster, weil der Server dann nicht mehr unterscheiden kann, welcher Client anfragt, und die Protokolle der nachgelagerten API eine falsche Identität zeigen (MCP-Sicherheitsleitfaden). In der Praxis meldet sich der Server mit eigenen Zugangsdaten an der ERP-API an - etwa per Client-Credentials, wie im Beitrag zu OAuth 2.0 für ERP-Schnittstellen beschrieben - und gibt die Identität der fragenden Person als geprüftes Merkmal mit. So kann das ERP seine Rollen und Datenfilter anwenden, und sein Protokoll zeigt, in wessen Namen ein Aufruf erfolgte.

Die Rechte wirken schon bei der Werkzeugliste. Die Liste, die ein Server auf tools/list zurückgibt, darf von der Autorisierung der Anfrage abhängen, etwa indem sie nur die Werkzeuge enthält, die die gewährten Scopes erlauben (MCP-Spezifikation, Abschnitt Tools). Wer im Lager arbeitet, sieht „Auftrag buchen“ dann gar nicht erst, und das Modell kommt nicht in Versuchung, es zu nutzen. Fehlt für einen Aufruf ein Scope, antwortet der Server mit HTTP 403 und error="insufficient_scope"; der Client kann daraufhin eine Erweiterung der Rechte anstoßen, statt von Anfang an alle Scopes anzufordern (MCP-Spezifikation, Authorization). Der Sicherheitsleitfaden empfiehlt dazu ein schrittweises Modell mit einem kleinen Anfangssatz für risikoarme Lese- und Erkundungsoperationen (MCP-Sicherheitsleitfaden).

Zu den Sicherheitsanforderungen der Spezifikation gehört, dass Server alle Eingaben prüfen, Zugriffe kontrollieren, Werkzeugaufrufe begrenzen und Ausgaben bereinigen; Clients sollen die Nutzung von Werkzeugen für Prüfzwecke protokollieren (MCP-Spezifikation, Abschnitt Tools). Für einen ERP-Server reicht das Protokoll des Clients allerdings nicht, denn es entsteht in Anwendungen, die der Betreiber des Servers nicht in der Hand hat. Das maßgebliche Protokoll schreibt der Server selbst, und zwar strukturiert, damit es sich auswerten lässt.

Die Datenschutz-Grundverordnung verlangt Datenschutz durch Voreinstellung: Der Verantwortliche trifft Maßnahmen, damit grundsätzlich nur die personenbezogenen Daten verarbeitet werden, deren Verarbeitung für den jeweiligen Zweck erforderlich ist - bezogen auf Menge, Umfang der Verarbeitung, Speicherfrist und Zugänglichkeit (Art. 25 Abs. 2 DSGVO). Für den MCP-Server heißt das: Das Ausgabeschema von show_order enthält Lieferadresse und Ansprechpartner nur, wenn die Frage sie braucht, und das Protokoll speichert Kennungen statt Freitexten. Wie Daten über Systemgrenzen hinweg wieder gelöscht werden, beschreibt der Beitrag zum Löschkonzept für Shop, ERP und Buchhaltung.

Ein Protokoll, das jeden Werkzeugaufruf einer Person zuordnet, berührt außerdem das Arbeitsrecht. Nach § 87 Abs. 1 Nr. 6 BetrVG bestimmt der Betriebsrat bei der Einführung und Anwendung technischer Einrichtungen mit, die dazu bestimmt sind, das Verhalten oder die Leistung der Arbeitnehmer zu überwachen (BetrVG). Ob ein Assistenten-Protokoll darunter fällt, ist im Einzelfall zu klären; in Betrieben mit Betriebsrat gehört das Thema deshalb früh in die Abstimmung, zusammen mit Zweck, Aufbewahrungsdauer und Zugriff auf das Protokoll. Die rechtliche Bewertung gehört in die Rechtsberatung, die technische Umsetzung lässt sich daran ausrichten: getrennte Rollen für den Betrieb des Servers und für die Auswertung, Löschfristen im Protokollspeicher und Auswertungen nur zu festgelegten Anlässen.

Hinzu kommt die KI-Verordnung der EU. Ihr Kapitel I gilt seit dem 2. Februar 2025 (Verordnung (EU) 2024/1689, Art. 113), darunter Artikel 4 zur KI-Kompetenz. In der durch die Verordnung (EU) 2026/1744 geänderten Fassung verlangt er, dass Anbieter und Betreiber von KI-Systemen Maßnahmen ergreifen, um die Entwicklung der KI-Kompetenz ihres Personals zu unterstützen; ein bestimmtes Kompetenzniveau je Person müssen sie danach nicht gewährleisten (Verordnung (EU) 2024/1689, Art. 4). Ein Team, das per Assistent Aufträge vorbereitet, sollte wissen, was ein Entwurf ist, was die Freigabe bedeutet und woran eine manipulierte Antwort zu erkennen ist. Die Einweisung gehört deshalb in den Projektplan und nicht in die Zeit nach dem Start.

Ein MCP-Server für ein ERP ist im Kern API-Entwicklung: Werkzeuge entwerfen, Schemas festlegen, Rechte anbinden, testen und betreiben. Der Aufwand hängt weniger am Protokoll als an der vorhandenen Schnittstelle. Liefert die ERP-API Bestände und Aufträge bereits sauber, bleibt der Server schlank; muss erst eine Schnittstelle entstehen, steckt dort die Arbeit. Wie sich solche Posten im Budget niederschlagen, zeigt der Beitrag Was kostet eine ERP-Anbindung?

Der lesende Start ist kein Zögern, sondern Messung. In den ersten Wochen zeigt das Protokoll, welche Werkzeuge tatsächlich gerufen werden, wo der Assistent falsche Parameter wählt und welche Fragen kein Werkzeug abdeckt. Erst mit diesen Daten lässt sich entscheiden, welche schreibenden Werkzeuge sich lohnen. Für die Überwachung im Betrieb gelten dieselben Grundsätze wie für jede andere Schnittstelle; der Beitrag zu Observability für Schnittstellen beschreibt Korrelationskennungen und Alarme. Wer Schnittstellen ohnehin inventarisiert, nimmt den MCP-Server als eigene Schnittstelle in die Liste auf, wie im Beitrag zu NIS2 und API-Sicherheit beschrieben. Auch die Frage, welches System Rechnungen erzeugt, beantwortet das Projekt nicht neu: Der Assistent legt Aufträge an, Belege entstehen weiter dort, wo sie heute entstehen - mehr dazu im Beitrag Rechnung aus Shop oder ERP?