Magento REST API und MCP-Server sicher verbinden

Inhaltsverzeichnis

Was passiert, wenn eine für klassische Systemintegrationen entwickelte REST API plötzlich von einem KI-Agenten genutzt wird?

Die REST API gehört seit den ersten Versionen von Magento 2 zu den wichtigsten Schnittstellen des Shopsystems. Über sie können externe Anwendungen auf Produkte, Kunden, Bestellungen, Kategorien, Lagerbestände und zahlreiche weitere Daten zugreifen.

Bisher wurde die Schnittstelle vor allem von fest programmierten Systemen verwendet. Ein ERP-System ruft Bestellungen ab. Eine Warenwirtschaft überträgt Lagerbestände. Ein PIM aktualisiert Produktbeschreibungen und Attribute. Eine mobile Anwendung liest Produktdaten aus.

Mit MCP-Servern entsteht ein neuer Nutzungskontext. Nun kann ein KI-Agent auf die REST API zugreifen. Der Agent erhält eine natürlich formulierte Aufgabe, plant die erforderlichen Abfragen und wählt selbstständig passende Werkzeuge aus.

Dadurch treffen zwei unterschiedliche technische Konzepte aufeinander. Die Magento REST API wurde für vorhersehbare Integrationsprozesse entwickelt. Ein KI-Agent arbeitet dagegen dynamisch und entscheidet abhängig von der jeweiligen Aufgabe, welche Schritte notwendig erscheinen.

Bei den Arbeiten an einer eigenen Erweiterung der Magento REST API zeigte sich deshalb ein grundlegendes Problem. Wichtige Bereiche der Magento-Core-API unterscheiden bei der Rechtevergabe nicht konsequent zwischen Lesen, Anlegen, Bearbeiten und Löschen.

Für klassische Integrationen war diese grobe Rechtevergabe häufig beherrschbar. Bei einem KI-Agenten kann daraus ein erhebliches Risiko entstehen.

Wofür wurde die Magento REST API ursprünglich entwickelt?

Die Magento REST API sollte externe Anwendungen und Drittsysteme mit dem Onlineshop verbinden. Adobe nennt als typische Beispiele mobile Shopping-Anwendungen, Anwendungen für Mitarbeiter im stationären Verkauf sowie Verbindungen zu CRM-, ERP- und Content-Management-Systemen.

Die Schnittstelle diente damit vor allem der Kommunikation zwischen bekannten Softwaresystemen. Der Ablauf wurde zuvor von Entwicklern festgelegt und anschließend automatisiert ausgeführt.

Quelle https://developer.adobe.com/commerce/webapi/rest/

Ein Warenwirtschaftssystem könnte beispielsweise regelmäßig neue Bestellungen aus Magento abrufen. Anschließend verarbeitet es die Bestellungen intern und übermittelt später den Versandstatus sowie die Sendungsnummer zurück an Magento.

Ein Produktinformationsmanagementsystem könnte Produktnamen, Beschreibungen, Preise und Attribute verwalten. Änderungen werden nach festen Regeln an den Magento-Shop übertragen.

Weitere typische Einsatzbereiche sind:

Synchronisierung von Produktdaten
Übertragung von Lagerbeständen
Abfrage und Aktualisierung von Bestellungen
Verbindung zu Versanddienstleistern
Anbindung von CRM-Systemen
Austausch von Kundendaten
Integration von Marktplätzen
mobile Anwendungen
Headless-Frontends
individuelle Unternehmenssoftware

Die Web APIs werden von Adobe ausdrücklich als Grundlage zur Integration von Drittsystemen und zum Aufbau entkoppelter Frontends beschrieben.

Quelle https://developer.adobe.com/commerce/webapi/

Wie funktionierten klassische REST-Integrationen?

Bei einer klassischen Integration entscheidet der Entwickler bereits während der Programmierung, welche API-Endpunkte verwendet werden.

Ein Programm enthält beispielsweise einen festgelegten Ablauf:

Bestellung anhand ihrer Nummer abrufen
Bestellpositionen auslesen
Versandstatus im ERP prüfen
Sendungsnummer an Magento übertragen
Bestellung als versendet markieren

Das System kann normalerweise nur die Funktionen ausführen, die vorher programmiert wurden. Selbst wenn der verwendete Magento-Zugang umfangreiche Rechte besitzt, ruft das Programm nur die im Quellcode vorgesehenen Endpunkte auf.

Das bedeutet nicht, dass breite API-Rechte bei klassischen Integrationen unproblematisch sind. Ein gestohlener Zugangsschlüssel oder ein Programmierfehler kann auch dort erhebliche Schäden verursachen. Der mögliche Ablauf ist jedoch vergleichsweise gut vorhersehbar.

Ein PIM-System, das ausschließlich Produktdaten aktualisieren soll, entscheidet nicht spontan, Kundenkonten zu durchsuchen oder Produkte zu löschen. Es führt die Prozesse aus, die für dieses System entwickelt wurden.

Welche Rolle spielen Magento Service Contracts und Repositories?

Magento stellt viele Funktionen über sogenannte Service Contracts bereit. Dazu gehören Repository-Schnittstellen für Produkte, Kunden, Kategorien und weitere Entitäten.

Ein Repository bündelt häufig mehrere grundlegende Operationen:

Datensatz anlegen
Datensatz lesen
mehrere Datensätze suchen
Datensatz aktualisieren
Datensatz löschen

Diese Operationen werden häufig als CRUD bezeichnet. Die Abkürzung steht für Create, Read, Update und Delete.

Adobe beschreibt Repositories ausdrücklich als Service Contracts, über die Entitäten angelegt, gelesen, aktualisiert und gelöscht werden können.

Quelle https://developer.adobe.com/commerce/php/development/components/searching-with-repositories

Dieses Modell ist für eine Commerce-Plattform sinnvoll. Ein Produkt-Repository bündelt die zentrale Verwaltung von Produkten. Ein Kunden-Repository stellt Funktionen für Kundenkonten bereit. Ein Kategorie-Repository verwaltet Kategorien.

Problematisch wird es, wenn alle Operationen eines solchen fachlichen Bereichs derselben Berechtigung zugeordnet werden.

Wie vergibt Magento Rechte für die REST API?

Magento verwendet ein ACL-System. ACL steht für Access Control List. Über diese Zugriffssteuerung wird festgelegt, auf welche Bereiche ein Administrator, eine Rolle oder eine Integration zugreifen darf.

Die verfügbaren Rechte werden in den acl.xml-Dateien der Magento-Module definiert. In den jeweiligen webapi.xml-Dateien wird anschließend festgelegt, welches Recht für einen REST- oder SOAP-Endpunkt erforderlich ist.

Adobe beschreibt, dass die Rechte aus der acl.xml sowohl für Admin-Rollen als auch für den Zugriff von Drittsystemen verwendet werden. Die webapi.xml verweist auf diese Rechte und schützt damit die einzelnen Schnittstellen.

Quelle https://developer.adobe.com/commerce/webapi/get-started/authentication/

Ein wichtiger Punkt liegt in der Struktur dieser Rechte. Viele Berechtigungen sind fachlich nach Bereichen gegliedert:

Produkte
Kategorien
Kunden
Bestellungen
Lagerbestand
Konfiguration

Die entscheidende Frage lautet dann häufig:

Darf diese Integration auf Produkte zugreifen?

Für einen KI-Agenten wäre jedoch eine genauere Fragestellung notwendig:

Darf dieser Agent Produkte ausschließlich lesen, oder darf er sie auch anlegen, bearbeiten und löschen?

Wo liegt das konkrete Problem bei Produktdaten?

In Magento Open Source 2.4.9 verwenden die zentralen Produktendpunkte dieselbe ACL-Ressource Magento_Catalog::products.

Dazu gehören unter anderem:

POST /V1/products zum Anlegen eines Produkts
PUT /V1/products/:sku zum Ändern eines Produkts
DELETE /V1/products/:sku zum Löschen eines Produkts
GET /V1/products zum Suchen und Lesen von Produkten
GET /V1/products/:sku zum Lesen eines einzelnen Produkts

Alle diese Endpunkte verweisen auf das Produktrecht Magento_Catalog::products.

Quelle https://github.com/magento/magento2/blob/2.4.9/app/code/Magento/Catalog/etc/webapi.xml

Auch in der ACL-Struktur des Catalog-Moduls gibt es für diesen Bereich lediglich die Ressource „Products“. Eigene Core-Rechte wie products_read, products_update oder products_delete sind dort nicht definiert.

Quelle https://github.com/magento/magento2/blob/2.4.9/app/code/Magento/Catalog/etc/acl.xml

Soll ein externer Dienst über diese Standardendpunkte geschützte Produktinformationen auslesen, benötigt er damit ein Recht, das zugleich für verändernde und löschende Produktoperationen verwendet wird.

Dieses Verhalten ist nicht in allen Magento-Bereichen identisch. Einige Module besitzen deutlich feinere Berechtigungen. Die Rechtevergabe innerhalb der Core-API ist daher nicht vollständig einheitlich.

War das bereits in den ersten Magento-2-Versionen so?

Ein Blick auf Magento 2.0.0 zeigt, dass die Struktur historisch gewachsen ist.

Bereits damals verwendeten die Endpunkte zum Anlegen, Bearbeiten und Löschen von Produkten gemeinsam die Ressource Magento_Catalog::products.

Die zentralen GET-Endpunkte zum Lesen von Produktlisten und einzelnen Produkten waren in Magento 2.0.0 allerdings teilweise mit der Ressource anonymous freigegeben. Sie konnten damit ohne ein administratives Produktrecht angesprochen werden.

Quelle https://github.com/magento/magento2/blob/2.0.0/app/code/Magento/Catalog/etc/webapi.xml

Dies passt zu einem damaligen Anwendungsszenario, in dem Produktinformationen für mobile Shopping-Anwendungen oder alternative Storefronts zugänglich sein sollten. Diese Einordnung ist eine technische Schlussfolgerung aus dem damaligen Code und den dokumentierten Anwendungsfällen. Eine ausdrückliche historische Begründung von Magento oder Adobe liegt uns dazu nicht vor.

In späteren Versionen wurde der anonyme Zugriff auf verschiedene Katalogendpunkte eingeschränkt. Die zentrale Produktberechtigung wurde dabei jedoch nicht in getrennte Rechte für Lesen, Schreiben und Löschen aufgeteilt.

Was verändert sich durch einen MCP-Server?

Ein MCP-Server stellt KI-Anwendungen Werkzeuge zur Verfügung. Ein Werkzeug kann beispielsweise ein Produkt anhand seiner SKU suchen, Bestellungen zu einer E-Mail-Adresse abrufen oder Lagerbestände prüfen.

Die MCP-Spezifikation beschreibt solche Werkzeuge als modellgesteuert. Ein Sprachmodell kann verfügbare Tools erkennen und sie abhängig vom Kontext und von der Eingabe des Benutzers selbstständig aufrufen.

Quelle https://modelcontextprotocol.io/specification/draft/server/tools

Bei einer klassischen Integration sieht der Ablauf beispielsweise so aus:

Eine fest programmierte Funktion ruft einen festgelegten Magento-Endpunkt mit vorgegebenen Parametern auf.

Bei einem KI-Agenten sieht der Ablauf anders aus:

Ein Benutzer beschreibt eine Aufgabe in natürlicher Sprache.
Das Sprachmodell interpretiert das gewünschte Ergebnis.
Der Agent plant mehrere Arbeitsschritte.
Er wählt passende MCP-Werkzeuge aus.
Der MCP-Server übersetzt die Werkzeugaufrufe in Magento-REST-Anfragen.
Die Ergebnisse beeinflussen möglicherweise die nächsten Schritte des Agenten.

Der KI-Agent arbeitet damit flexibler. Gleichzeitig entstehen zusätzliche Fehlerquellen.

Warum reicht eine Anweisung im Prompt nicht aus?

Ein KI-Agent kann die Anweisung erhalten, ausschließlich lesend auf Magento zuzugreifen. Eine solche Anweisung ist jedoch keine technische Zugriffskontrolle.

Sprachmodelle können Aufgaben missverstehen. Begriffe wie „bereinigen“, „korrigieren“, „aufräumen“ oder „nicht mehr benötigte Produkte entfernen“ sind fachlich nicht eindeutig.

Ein Benutzer könnte fragen:

Prüfe, welche deaktivierten Produkte seit mehreren Jahren nicht mehr verkauft wurden und bereinige den Katalog.

Der Benutzer erwartet möglicherweise eine Liste mit möglichen Kandidaten. Ein Agent könnte „bereinigen“ jedoch als Aufforderung zum Löschen interpretieren.

Besitzt der Magento-Zugang technisch das Produktrecht, könnte er über die Standard-API sowohl die notwendigen Informationen lesen als auch Produkte bearbeiten oder löschen.

Ein Systemprompt kann das Risiko reduzieren. Er kann die Ausführung einer technisch erlaubten Aktion allerdings nicht zuverlässig verhindern. Eine belastbare Grenze muss im Berechtigungsmodell oder in der ausführenden Software liegen.

Welche neuen Risiken entstehen konkret?

Unbeabsichtigte Änderungen an Produktdaten

Ein Agent soll Produkte mit unvollständigen Beschreibungen finden. Er interpretiert die Aufgabe als Auftrag zur automatischen Verbesserung und überschreibt vorhandene Texte.

Dabei können Produktinformationen verloren gehen, HTML-Strukturen beschädigt oder Inhalte in der falschen Store View gespeichert werden.

Versehentliche Produktlöschungen

Der Agent identifiziert alte oder deaktivierte Produkte als vermeintliche Dubletten. Aufgrund einer ungenauen Anweisung löscht er Datensätze, obwohl lediglich eine Prüfung gewünscht war.

Bei konfigurierbaren Produkten, Varianten, Bundles und Produktverknüpfungen können die Auswirkungen über das einzelne Produkt hinausgehen.

Falsche Preisänderungen

Ein Mitarbeiter bittet den Agenten, ungewöhnlich niedrige Preise zu finden. Der Agent versucht, diese Werte selbstständig zu korrigieren.

Mögliche Folgen sind falsche Basispreise, fehlerhafte Sonderpreise oder Änderungen an kundengruppenspezifischen Preisen.

Änderungen am falschen Produkt

Sprachmodelle können ähnliche Artikelnummern, Produktnamen oder Varianten verwechseln. Ein Fehler bei der Auswahl der SKU kann dazu führen, dass ein korrektes Produkt verändert wird.

Umfangreiche Massenoperationen

Eine einzelne fehlerhafte Entscheidung kann auf viele Datensätze angewendet werden. Ein Agent könnte mehrere hundert oder mehrere tausend Produkte aktualisieren, deaktivieren oder löschen.

Durch die Geschwindigkeit automatisierter API-Aufrufe kann der Schaden innerhalb kurzer Zeit entstehen.

Prompt Injection über Shopdaten

Ein KI-Agent verarbeitet nicht nur die Aufgabe des Benutzers. Er liest möglicherweise auch Produktbeschreibungen, CMS-Inhalte, Kundenkommentare oder importierte Daten.

Solche Inhalte können manipulierte Anweisungen enthalten. Behandelt das Modell diese Texte irrtümlich als Handlungsanweisung, kann es weitere Werkzeuge aufrufen.

Die Sicherheitsdokumentation des Model Context Protocol nennt mehrere Risiken rund um Berechtigungen, Token, Sitzungen und MCP-Proxy-Server. Sie empfiehlt unter anderem eine Minimierung der Berechtigungen, eine saubere Validierung und nachvollziehbare Autorisierungsprozesse.

Quelle https://modelcontextprotocol.io/docs/tutorials/security/security_best_practices

Missbrauch eines gestohlenen Integrationstokens

Der MCP-Server benötigt Zugangsdaten für Magento. Werden diese Zugangsdaten gestohlen, kann ein Angreifer Magento auch ohne den KI-Agenten direkt ansprechen.

Der Angreifer erhält alle Rechte, die der Integration zugewiesen wurden. Bei einem zu umfangreichen Produktrecht kann dies Lese-, Schreib- und Löschoperationen umfassen.

Adobe empfiehlt, Integrationstoken an einem sicheren und verschlüsselten Ort zu speichern.

Quelle https://experienceleague.adobe.com/en/docs/commerce-admin/systems/integrations

Erschwerte Nachvollziehbarkeit

Mehrere Benutzer können denselben MCP-Server verwenden. Der Server greift möglicherweise mit einem gemeinsamen Magento-Integrationstoken auf den Shop zu.

In Magento ist dann zunächst nur erkennbar, dass die technische Integration eine Anfrage ausgeführt hat. Ohne zusätzliche Protokollierung bleibt unklar:

welcher Mitarbeiter die ursprüngliche Frage gestellt hat
welcher MCP-Client verwendet wurde
welches Werkzeug ausgewählt wurde
welche Daten die Entscheidung beeinflusst haben
ob eine Änderung bestätigt wurde
welcher Zustand vor der Änderung bestand

Die MCP-Sicherheitsdokumentation weist darauf hin, dass unsaubere Token-Weitergabe und gemeinsame technische Identitäten die Zuordnung von Aufrufen und die Untersuchung von Sicherheitsvorfällen erschweren können.

Quelle https://modelcontextprotocol.io/docs/tutorials/security/security_best_practices

Warum hat Magento möglicherweise keine durchgehend granularen REST-Rechte?

Dazu konnten wir keine gesicherte öffentliche Erklärung von Adobe bzw. Magento finden. Die folgenden Gründe sind technische Einordnungen, die sich aus der Architektur und der historischen Nutzung der Plattform ableiten lassen unserer Meinung nach.

Sie sollten jedoch ausdrücklich nicht als bestätigte damalige Entscheidung von Magento oder Adobe bzw. Magento verstanden werden.

Das ACL-System wurde für mehrere Bereiche verwendet

Das Magento-ACL-System schützt nicht ausschließlich REST-Endpunkte. Dieselben ACL-Ressourcen können für Admin-Menüs, Controller, Layout-Bereiche und Web APIs verwendet werden.

Adobe zeigt in der eigenen Dokumentation, wie ACL-Regeln für Admin-Funktionen und API-Endpunkte gemeinsam definiert werden.

Quelle https://developer.adobe.com/commerce/php/tutorials/backend/create-access-control-list-rule

Im Magento-Adminbereich war eine fachliche Einteilung naheliegend. Eine Rolle erhielt beispielsweise Zugriff auf Produkte, Kategorien oder Bestellungen.

Ein Benutzer mit Produktzugriff sollte Produkte im Adminbereich normalerweise umfassend verwalten können. Dieses fachliche Modell wurde auch für API-Integrationen verwendet.

Die Berechtigung beantwortet damit vor allem die Frage, auf welchen Geschäftsbereich eine Rolle zugreifen darf. Die genaue einzelne Operation steht weniger im Vordergrund.

Repositories bündeln mehrere Operationen

Die Magento-Architektur fasst CRUD-Funktionen häufig in Repository-Schnittstellen zusammen. Das Produkt-Repository enthält Funktionen zum Speichern, Lesen, Suchen und Löschen von Produkten.

Es ist daher plausibel, dass das Repository beziehungsweise die fachliche Entität als Berechtigungseinheit betrachtet wurde.

Die API-Rechte folgen dann der Struktur:

Zugriff auf Produkte
Zugriff auf Kunden
Zugriff auf Kategorien
Zugriff auf Bestellungen

Eine zusätzliche Aufteilung nach jeder einzelnen Repository-Methode hätte die Zahl der Rechte deutlich erhöht.

Klassische Integrationen galten als kontrollierte Systeme

Eine Magento-Integration wird bewusst eingerichtet und erhält ausgewählte API-Ressourcen. Adobe empfiehlt ausdrücklich, den Zugriff einer Integration auf die benötigten Ressourcen zu begrenzen.

Quelle https://developer.adobe.com/commerce/webapi/get-started/

Das historische Sicherheitsmodell ging wahrscheinlich davon aus, dass der Code der angebundenen Anwendung den tatsächlichen Ablauf begrenzt.

Ein PIM erhielt Produktrechte, weil es Produktdaten verwalten sollte. Welche Funktionen es innerhalb dieses Bereichs nutzte, wurde im PIM programmiert.

Ein ERP erhielt Bestellrechte, weil es Bestellungen verarbeiten sollte. Die einzelnen API-Aufrufe waren Teil eines bekannten Prozesses.

Diese Annahme funktioniert bei einer dynamischen Werkzeugauswahl durch ein Sprachmodell nur eingeschränkt.

Eine sehr feine Rechtematrix wäre komplex

Eine vollständige Berechtigungstrennung könnte allein für Produkte zahlreiche Rechte erfordern:

Produktdaten lesen
Produkte anlegen
Produkte bearbeiten
Produkte löschen
Preise lesen
Preise ändern
Lagerbestände lesen
Lagerbestände ändern
Produktbilder lesen
Produktbilder ändern
Kategoriezuordnungen lesen
Kategoriezuordnungen ändern
Store-View-Daten lesen
Store-View-Daten ändern

Weitere Grenzen könnten sich auf Websites, Store Views, Attribute, Produkttypen und Kundengruppen beziehen.

Eine solche Struktur wäre genauer. Sie würde aber auch die Konfiguration, Dokumentation, Entwicklung und Pflege von Integrationen aufwendiger machen.

Es ist plausibel, dass Magento historisch einen Kompromiss zwischen Granularität und praktischer Administrierbarkeit gewählt hat. Eine bestätigte Aussage von Adobe zu dieser Abwägung konnten wir aber nicht finden.

Rückwärtskompatibilität erschwert eine spätere Aufteilung

Eine nachträgliche Änderung der Core-Berechtigungen könnte bestehende Integrationen beeinträchtigen.

Würde ein vorhandenes Produktrecht plötzlich in Lesen, Anlegen, Bearbeiten und Löschen aufgeteilt, müssten bestehende Rollen und Integrationen angepasst werden. Andernfalls könnten PIM-, ERP- oder Warenwirtschaftsanbindungen nach einem Magento-Update nicht mehr vollständig funktionieren.

Auch Erweiterungsentwickler müssten ihre API-Definitionen und Installationsprozesse prüfen.

Adobe dokumentiert inkompatible Änderungen an öffentlichen Schnittstellen gesondert. Dies zeigt die Bedeutung der Rückwärtskompatibilität innerhalb des Magento-Ökosystems.

Quelle https://developer.adobe.com/commerce/php/development/backward-incompatible-changes/

Dass Rückwärtskompatibilität der konkrete Grund für die nicht erfolgte ACL-Aufteilung ist, lässt sich daraus nicht sicher ableiten. Technisch wäre eine solche Änderung jedoch mit erheblichen Auswirkungen verbunden.

Kann Magento grundsätzlich feinere Rechte abbilden?

Ja. Das Magento-Framework kann eigene, getrennte ACL-Ressourcen verwalten.

Adobe zeigt in der Entwicklerdokumentation ein Beispiel mit getrennten Rechten für „Create“, „Delete“ und „View“. Diese Rechte können verschiedenen API-Endpunkten zugeordnet werden.

Quelle https://developer.adobe.com/commerce/php/tutorials/backend/create-access-control-list-rule

Auch bei selbst entwickelten REST-Endpunkten kann für jede Route eine eigene ACL-Ressource festgelegt werden.

Quelle https://developer.adobe.com/commerce/php/tutorials/backend/create-custom-rest-api

Die fehlende Trennung innerhalb wichtiger Core-Endpunkte ist damit keine grundsätzliche technische Grenze des Magento-Frameworks.

Die genauere Aussage lautet:

Magento unterstützt eine granulare ACL-Struktur, die Standard-REST-API verwendet sie in wichtigen Bereichen jedoch nicht konsequent zur Trennung von Lesen, Anlegen, Bearbeiten und Löschen.

Die historische REST API trifft auf einen neuen Akteur

Die Magento REST API war und ist eine wichtige Grundlage für die Integration externer Systeme. Ihre Architektur lässt sich aus den damaligen Anwendungsfällen nachvollziehen.

ERP-Systeme, PIM-Systeme, Warenwirtschaften und mobile Anwendungen arbeiteten mit bekannten Prozessen. Der Quellcode der Integration legte fest, welche Daten gelesen und welche Änderungen ausgeführt wurden.

MCP-Server bringen einen neuen Akteur in diese Architektur. Ein Sprachmodell kann Aufgaben interpretieren, Werkzeuge auswählen und mehrere Schritte miteinander verbinden. Damit steigt die Bedeutung technisch erzwungener Grenzen.

Die Frage lautet nicht mehr nur, auf welchen fachlichen Bereich ein System zugreifen darf.

Es muss zusätzlich geklärt werden:

Darf der Agent Daten lesen?
Darf er Daten verändern?
Darf er neue Datensätze anlegen?
Darf er Daten löschen?
Welche Felder darf er sehen?
Wie viele Datensätze darf er abrufen?
Wer muss eine Aktion bestätigen?
Wie wird der Vorgang dokumentiert?

Welche Grenzen sollten umgesetzt werden?

Ein reiner Lesezugriff ist ein wichtiger erster Schritt. Für einen kontrollierten MCP-Betrieb sind weitere Begrenzungen sinnvoll.

Nur benötigte Daten zurückgeben

Ein Endpunkt sollte ausschließlich die Felder ausgeben, die für den jeweiligen Anwendungsfall benötigt werden.

Ein Werkzeug zur Prüfung der Produktdatenqualität benötigt möglicherweise SKU, Produktname, Status, Bilder, Beschreibungen und ausgewählte Attribute. Es benötigt nicht automatisch sämtliche internen Produktdaten.

Bei Kunden- und Bestelldaten ist diese Begrenzung besonders wichtig, weil dort personenbezogene Informationen verarbeitet werden.

Datenmengen begrenzen

Der MCP-Server sollte nicht unbegrenzt große Katalogabfragen durchführen können.

Sinnvolle Grenzen sind:

maximale Anzahl von Ergebnissen
feste Seitengrößen
erlaubte Filterfelder
Zeitlimits
Begrenzung paralleler Aufrufe
Rate Limits
Abbruch sehr aufwendiger Abfragen

Die MCP-Spezifikation nennt Eingabevalidierung, Zugriffskontrollen und Rate Limits ausdrücklich als Anforderungen für Server, die Werkzeuge bereitstellen.

Quelle https://modelcontextprotocol.io/specification/2025-11-25/server/tools

Fachliche Werkzeuge statt eines allgemeinen REST-Proxys

Ein allgemeines MCP-Werkzeug könnte HTTP-Methode, Endpunkt und Parameter frei entgegennehmen. Ein solches Werkzeug wäre sehr flexibel, würde dem Sprachmodell jedoch einen großen technischen Handlungsspielraum geben.

Sicherer sind klar begrenzte Funktionen:

get_product_by_sku
find_products_without_images
get_order_status
search_orders_by_email
get_inventory_by_sku

Diese Werkzeuge verwenden intern nur festgelegte Magento-Endpunkte. Der KI-Agent kann weder eine beliebige Route auswählen noch die HTTP-Methode frei bestimmen.

Aufrufe nachvollziehbar protokollieren

Für jeden Zugriff sollten mindestens folgende Angaben protokolliert werden:

Benutzer oder technischer Aufrufer
verwendeter MCP-Client
aufgerufenes Werkzeug
übermittelte Parameter
angesprochener Magento-Endpunkt
Zeitpunkt
Ergebnisstatus
Umfang der zurückgegebenen Daten

Dabei dürfen Zugangstoken und unnötige personenbezogene Daten nicht in normale Protokolldateien gelangen.

Wie könnten spätere Schreibzugriffe aussehen?

Schreibzugriffe durch KI-Agenten sind grundsätzlich möglich. Sie benötigen jedoch eine andere Sicherheitsarchitektur als reine Informationsabfragen.

Ein sinnvoller Prozess könnte mehrere Stufen enthalten:

Der KI-Agent analysiert die vorhandenen Daten.
Er erstellt einen konkreten Änderungsvorschlag.
Betroffene Produkte und neue Werte werden angezeigt.
Ein Mitarbeiter prüft den Vorschlag.
Der Mitarbeiter bestätigt die Änderung.
Eine getrennt berechtigte Funktion führt den Auftrag aus.
Alte und neue Werte werden protokolliert.

Löschfunktionen sollten nochmals strenger behandelt werden. In vielen Fällen ist eine Deaktivierung, Kennzeichnung oder Übergabe an eine Prüfliste sinnvoller als eine sofortige Löschung.

Auch die MCP-Spezifikation empfiehlt, bei sensiblen Operationen einen Menschen einzubeziehen und vor der Ausführung eine Bestätigung einzuholen.

Quelle https://modelcontextprotocol.io/specification/draft/server/tools

Die KonVis Lösung für Magento REST API und MCP-Server sicher verbinden

Unser MCP-Server Ansatz für einen kontrollierten KI-Zugriff auf Magento

Der MCP-Server in der ersten Versin erfolgrt einen klaren Read-Only Anasatz. Der MCP-Server soll die benötigten Magento-Daten abrufen und für den KI-Agenten verfügbar machen können. Schreib- und Löschoperationen erhalten über diesen Zugang keine Freigabe.

Eigene REST-Endpunkte und eigene ACL-Ressourcen schaffen eine technische Grenze direkt im Magento-System. Der Schutz hängt damit nicht allein davon ab, ob das Sprachmodell eine Anweisung korrekt interpretiert.

Zusätzlich werden die verfügbaren Daten, Abfragen und Ergebnismengen auf den jeweiligen Anwendungsfall begrenzt. Der MCP-Server erhält klar definierte fachliche Werkzeuge anstelle eines beliebigen Zugriffs auf die gesamte Magento REST API.

Warum die KonVis REST-API-Erweiterung sinnvoll ist?

Eine eigene Magento-Erweiterung kann gezielt dafür entwickelte REST-Endpunkte bereitstellen. Jeder Endpunkt erhält ein eigenes Leserecht. Schreib- und Löschfunktionen werden über diesen Zugang gar nicht angeboten.

Mögliche Berechtigungen wären:

Konvis_AiApi::products_read
Konvis_AiApi::orders_read
Konvis_AiApi::customers_read
Konvis_AiApi::inventory_read
Konvis_AiApi::cms_read

Der verwendete Magento-Integrationstoken erhält nur diese Rechte. Selbst wenn der KI-Agent einen verändernden Aufruf plant, fehlt ihm dafür ein erreichbarer Endpunkt und die notwendige Berechtigung.

Die KonVis Rest-API Erweiterung soll genau dieses Punkte besser lösen als die bestehende Core-REST API in Magento.

Dazu prüfen wir welche weiteren Kontroll-Möglichkeiten für z.B Logging, Rate-Limiting und anderen Vorkehrungen sinnvoll erscheinen können. Unser Ziel ist die historisch gewachsene REST-API deutlich sicherer und kontrollierbarer zu gestalten um die Möglichkeiten von MCP kontrollierbar nutzbar zu machen.

Wir sind daher dabei eine Erweiterung für die bestehende Core Rest-API-Erweiterung von AdobeCommerce umzusetzen. Ausführliche Informationen zur Entwicklung finden Sie auf konvis.de im Blog oder schreiben Sie uns gerne an (martin.steudter@konvis.de)

Fazit

Die Magento REST API wurde für klassische Systemintegrationen entwickelt. Sie verband den Shop mit ERP-Systemen, Warenwirtschaften, PIM-Systemen, mobilen Anwendungen und weiteren Drittsystemen.

Diese Integrationen arbeiteten mit vorher programmierten Abläufen. Ihre tatsächlichen Funktionen wurden durch den Quellcode der angeschlossenen Anwendung begrenzt.

Ein KI-Agent arbeitet anders. Er interpretiert natürlich formulierte Aufgaben, plant Abfragen und wählt Werkzeuge abhängig vom Kontext aus. Dadurch können grobe Magento-Berechtigungen eine größere Wirkung entfalten als bei einer fest programmierten Integration.

Besonders problematisch ist, dass wichtige Core-Endpunkte keine konsequente Trennung zwischen Lesen, Anlegen, Ändern und Löschen vornehmen. Beim zentralen Produktzugriff verwenden diese Operationen dasselbe Magento-Recht.

Eine eigene REST-API-Erweiterung kann diese historische Lücke für den neuen Anwendungsfall schließen. Eigene Leserechte, klar begrenzte Endpunkte, kontrollierte Datenfelder und fachlich definierte MCP-Werkzeuge reduzieren die Angriffsfläche.

Damit entsteht eine Grundlage, auf der KI-Assistenten Magento-Daten nutzen können, ohne unnötige Änderungs- und Löschrechte für den Shop zu erhalten.