MCP und Herstellerrichtlinien: Was SAP, Microsoft, Google, Slack, Salesforce und Stripe bei KI-Zugriff erlauben

Warum entscheiden Herstellerrichtlinien seit 2025 über MCP-Projekte?

Weil die großen Softwarehersteller ihre API-Bedingungen inzwischen ausdrücklich auf KI-Agenten, KI-Training und Massenabruf ausrichten: Slack zum 10.10.2025, SAP zum 27.04.2026, und acht der elf hier geprüften Bedingungswerke tragen ein Datum ab Oktober 2025. Ein MCP-Server, der technisch einwandfrei läuft, kann trotzdem gegen diese Bedingungen verstoßen und dann gedrosselt oder gesperrt werden.

Das Model Context Protocol macht es leicht, einem Sprachmodell Werkzeuge in die Hand zu geben, die Schnittstellen eines Geschäftssystems aufrufen. Genau dieses Muster haben die Hersteller im Blick. Vier Themen tauchen dabei immer wieder auf:

• Agenten-Klauseln: Wer darf eine Schnittstelle aufrufen, wenn nicht mehr ein Mensch oder ein festes Programm entscheidet, sondern ein Modell? SAP regelt das seit April 2026 ausdrücklich.
• KI-Training: Slack, Google, HubSpot und Shopify verbieten, mit Daten aus ihren Schnittstellen Modelle zu trainieren oder zu verbessern.
• Datenexport und Massenabruf: Systematisches Abziehen großer Datenmengen ist bei SAP, Slack und Shopify ausdrücklich untersagt, bei Microsoft nur so weit erlaubt, wie die Anwendung es braucht.
• Zugangswege: Eigene Schlüsseltypen für Agenten (Stripe), eigene OAuth-Bereiche für MCP (Salesforce) oder die Pflicht, als Marketplace- oder interne App registriert zu sein (Slack).

Für Sie heißt das: Die Frage „Geht das technisch?“ ist meist schnell beantwortet. Die Frage „Ist es nach den Bedingungen des Herstellers zulässig, und auf welchem Weg?“ gehört an den Anfang jedes Projekts.

Was erlauben die Hersteller bei KI-Zugriff? Übersicht, Stand Oktober 2026

Zehn der elf geprüften Hersteller bieten einen eigenen MCP-Weg an, DATEV nicht; bei Shopify richtet er sich an Einkaufsagenten im Shop. Die Bedingungen für KI-Zugriffe unterscheiden sich aber deutlich. Die Tabelle fasst zusammen, was wir an der jeweiligen Primärquelle gelesen haben (Abruf 28.10.2026).

Bedingungen ändern sich. Die Spalte „Stand“ nennt das Datum, das der Hersteller selbst angibt. Wo keines angegeben ist, steht das Datum unseres Abrufs.

Was gilt bei den einzelnen Herstellern im Detail?

Die Tabelle verkürzt zwangsläufig. Hier die Punkte, die in Projekten den Ausschlag geben, mit dem jeweiligen Wortlaut oder der genauen Fundstelle.

SAP: Agenten nur über anerkannte Wege

SAP bindet als einziger Hersteller dieser Übersicht die Nutzung seiner APIs durch KI-Agenten an bestimmte, von SAP anerkannte Wege. Ziffer 2.2.2 der API Policy untersagt die Nutzung durch „(semi-) autonomous or generative AI systems that plan, select, or execute sequences of API calls“, sofern der Zugriff nicht über einen von SAP anerkannten Weg läuft. Laut SAP-FAQ gilt das für Cloud und On-Premise einschließlich RISE. Eigene MCP-Server sind nach Frage 56 der FAQ zulässig, wenn die gesamte Nutzung mit Vertrag, Dokumentation und Policy vereinbar ist; SAP gibt dafür keine Support-Zusage. Regelbasierte Abläufe ohne Planung durch ein Sprachmodell erfasst Ziffer 2.2.2 nach Frage 40 nicht. Die Einzelheiten, das Zitat und die Reaktion der DSAG stehen im SAP-Ratgeber im Abschnitt API Policy.

Microsoft: Datenrichtlinien steuern die MCP-Werkzeuge

Bei Microsoft entscheidet vor allem die Governance im eigenen Tenant. Copilot Studio unterstützt für MCP nur noch Streamable HTTP, SSE seit August 2025 nicht mehr, und bindet Server mit OAuth 2.0 oder API-Schlüssel an (Microsoft Learn, Stand 28.05.2026). Weil MCP-Server dort über Power-Platform-Connectoren laufen, gelten die Datenrichtlinien der Power Platform. Diese werden laut Microsoft seit Anfang 2025 in allen Tenants durchgesetzt, Ausnahmen für einzelne Agenten gibt es nicht mehr (Microsoft Learn, Stand 01.10.2026).

Für Microsoft-365-Daten empfiehlt Microsoft in neuen Projekten Work IQ MCP, das als Teil der Work IQ API allgemein verfügbar ist. Die älteren, anwendungsbezogenen MCP-Server für Mail, Kalender, SharePoint oder Teams sind laut Microsoft nur noch für Rückwärtskompatibilität gedacht und nicht für den Produktivbetrieb. Eigene MCP-Server lassen sich im Microsoft 365 Admin Center registrieren, prüfen und freigeben (Microsoft Learn, Stand 08.10.2026). Die Microsoft API Terms verlangen außerdem, nur die minimal nötigen Daten und Rechte anzufordern (Ziffer 3.b.5). Mehr dazu im Ratgeber MCP-Server für Microsoft 365.

Google Workspace: Trainingsverbot und Sicherheitsprüfung

Google verbietet in der Workspace User Data Policy, Nutzerdaten zu übertragen, zu verkaufen oder zu nutzen, um ein Modell für maschinelles Lernen oder künstliche Intelligenz „to create, train, or improve“. Für Restricted Scopes, etwa Vollzugriff auf Drive oder Gmail, ist eine Sicherheitsprüfung nach CASA vorgesehen, Google kann sie regelmäßig wiederholen lassen. Wichtig für Eigenentwicklungen: „If an app is only used by users within your own organization, then these additional requirements do not apply.“ Die offiziellen Workspace-MCP-Server laufen als Developer Preview, mit OAuth 2.0; Dienstkonten mit domänenweiter Delegation können die Option für KI-Agenten nicht nutzen, und Google warnt vor indirekter Prompt-Injection (Google for Developers, Stand 27.10.2026). Details im Ratgeber MCP-Server für Google Workspace.

Slack: Marketplace oder intern

Die Slack API Terms vom 10.10.2025 unterscheiden zwischen Apps für die eigene Organisation und Apps, die an Dritte verteilt werden. Für verteilte Apps gilt: kein Training von Sprachmodellen mit API-Daten, kein Massenexport von Nachrichten und Dateien ohne Zusatzvereinbarung. Für die Data Access API und die Real-Time Search API kommt hinzu: keine dauerhaften Kopien, Archive oder Indizes der Daten anderer Organisationen. Den Slack-MCP-Server dürfen laut Slack-Doku nur im Verzeichnis veröffentlichte oder interne Apps nutzen, Workspace-Admins genehmigen jeden MCP-Client. Seit dem 29.05.2025 gilt zudem für neue, nicht gelistete verteilte Apps bei conversations.history und conversations.replies eine Grenze von einer Anfrage pro Minute; interne Eigenentwicklungen sind ausgenommen (Slack-Changelog). Mehr im Ratgeber MCP-Server für Slack.

Salesforce: gehostete Server mit eigenem OAuth-Bereich

Salesforce hat seine gehosteten MCP-Server am 29.04.2026 für alle Orgs ab Enterprise Edition allgemein verfügbar gemacht. Laut Ankündigung läuft jeder Aufruf mit der Identität des angemeldeten Nutzers, ohne anonymes Dienstkonto, und Änderungen erscheinen im Audit-Trail unter seinem Namen. Ein neuer OAuth-Bereich gibt Zugriff auf MCP, aber nicht auf die bestehenden REST-APIs, und jeder Server muss im Setup ausdrücklich aktiviert werden (Salesforce Developers Blog). Für den Einstieg empfiehlt Salesforce den Nur-Lese-Server platform/sobject-reads in einer Sandbox. Mehr im Ratgeber MCP-Server für Salesforce.

HubSpot: Agenten ausdrücklich in den Bedingungen

HubSpot nennt Agenten direkt in den API Terms (Stand 04.05.2026): „any use or offering of agents or agentic features by your Solution must also adhere to these Terms.“ Ziffer 4.B.8 verbietet, Kundendaten zum Training, Feintuning oder zur Verbesserung von KI- oder ML-Modellen zu nutzen. Erlaubt ist das nur für genau einen Kunden, mit dessen ausdrücklicher Zustimmung und ohne Nutzen für andere. Zugriff besteht nur auf dokumentierte Developer Tools, wer nicht dokumentierte Schnittstellen nutzt, tut das auf eigenes Risiko (4.A.2). Der Remote-MCP-Server ist seit 13.04.2026 allgemein verfügbar und respektiert die bestehenden Nutzerrechte (HubSpot-Changelog). Mehr im Ratgeber MCP-Server für HubSpot.

Stripe: eigene Schlüssel für Agenten

Stripe stellt den MCP-Zugang auf eigene Agenten-Schlüssel um. Laut Stripe-Doku akzeptiert der MCP-Server ab Dezember 2026 weder geheime Schlüssel mit Vollzugriff noch eingeschränkte Schlüssel ohne Agenten-Tag; nicht unterstützte Schlüssel erhalten eine 401-Antwort. Wer heute mit einem Restricted Key arbeitet, muss bis 30.11.2026 auf einen neuen Agenten-API-Schlüssel oder OAuth umstellen. Administratoren können den MCP-Zugang für Live- und Testumgebung getrennt ein- und ausschalten. Mehr im Ratgeber MCP-Server für Stripe.

Atlassian, Shopify, GitHub und DATEV

Atlassian: Die Developer Terms (Stand 01.12.2025) enthalten keine eigene KI-Klausel. Relevant ist Ziffer 6(d): keine Aufrufe, die nicht durch eine Anfrage des Nutzers oder die App selbst ausgelöst sind. Der Rovo MCP Server nutzt OAuth 2.1 und die bestehenden Rechte (Atlassian Support), siehe auch MCP-Server für Jira und Confluence.

Shopify: Die API Terms (Stand 07.10.2026) enthalten das weitreichendste Trainingsverbot der Übersicht. Es erfasst auch anonyme, aggregierte und abgeleitete Daten und nennt Sprachmodelle ausdrücklich. Siehe MCP-Server für Shopify.

GitHub: Abschnitt H der Terms of Service (Stand 27.04.2026) behält sich vor, bei übermäßiger API-Nutzung den Zugang zu sperren. Der offizielle GitHub MCP Server lässt sich mit --read-only und ausgewählten Toolsets starten. Siehe MCP-Server für GitHub.

DATEV: Die Nutzungsbedingungen für Developer Portal und Schnittstellen (Stand 19.08.2024) regeln KI nicht gesondert. Die Inbetriebnahme einer Online-API setzt aber die Technische Prüfung durch DATEV und eine Konformitätsmitteilung in Textform voraus. Siehe MCP-Server für DATEV.

Welche Muster wiederholen sich in den Bedingungen?

Sechs Regeln tauchen bei mehreren Herstellern auf. Wer sie schon beim Entwurf eines MCP-Servers berücksichtigt, beantwortet einen großen Teil der Fragen, die der Hersteller später stellen könnte. Die Prüfung des Einzelfalls ersetzt das nicht.

Auffällig ist, wo die Grenze verläuft: Die Trainingsverbote richten sich gegen das Verbessern von Modellen mit fremden Daten. Dass ein Modell Daten liest, um eine konkrete Frage eines berechtigten Nutzers zu beantworten, verbieten die gelesenen Klauseln nicht ausdrücklich. SAP ist hier die Ausnahme, weil Ziffer 2.2.2 schon das Planen und Auswählen von API-Aufrufen durch ein KI-System erfasst.

Wie prüfen Sie die Herstellerbedingungen vor dem Bau?

Indem Sie die Prüfung als eigenen Projektschritt mit Ergebnisdokument behandeln, bevor die erste Zeile Code entsteht. So hat es sich in unseren Projekten bewährt:

• 1. Gültige Fassung bestimmenWelche API-Bedingungen, Policy und Nutzungsbedingungen gelten für Ihren Vertrag? Fassung und Datum festhalten, PDF oder Webarchiv-Kopie ablegen.
• 2. Anwendungsfall genau beschreibenWelches System, welche Daten, lesend oder schreibend, wer fragt, wie oft. Daran misst sich, ob von Massenabruf oder Agentennutzung die Rede ist.
• 3. Offiziellen Weg zuerst prüfenGibt es einen Hersteller-Server oder einen anerkannten Weg wie das SAP MCP Gateway? Wenn ja, begründen, warum ein eigener Server trotzdem nötig ist.
• 4. Interne oder verteilte AppBei Slack und Google hängen Pflichten daran, ob die App nur in Ihrer Organisation läuft. Das bewusst entscheiden und dokumentieren.
• 5. Schriftliche HerstelleraussageBei Unklarheit die Frage schriftlich an Ihren Ansprechpartner beim Hersteller stellen, konkret und mit Architekturskizze. Die Antwort zur Projektakte nehmen.
• 6. Freigabe durch Einkauf und RechtLizenzfrage (zählen Agenten-Zugriffe als Nutzer?), Bedingungen und Auftragsverarbeitung gemeinsam freigeben lassen, bei Bedarf mit Datenschutz und Betriebsrat.
• 7. Schlüssel und Fristen erfassenWelche Schlüsseltypen sind erlaubt, welche laufen aus? Beispiel Stripe: Umstellung bis 30.11.2026.
• 8. Änderungen überwachenÄnderungsprotokolle und Bedingungsseiten der Hersteller regelmäßig prüfen, Verantwortlichen benennen. Neue Fassung heißt: Prüfung wiederholen.

Das Ergebnis ist ein kurzes Entscheidungsdokument je System: gewählter Weg, geltende Fassung, offene Fragen, Herstelleraussage, Freigaben. Es hilft auch später, wenn die Revision oder ein Auditor fragt, warum die Anbindung so gebaut ist.

Wie lässt sich ein eigener MCP-Server richtlinienkonform gestalten?

Ein eigener MCP-Server lässt sich so bauen, dass er die wiederkehrenden Herstellerregeln technisch einhält, statt sich nur auf Absprachen zu verlassen. Als Vorlage taugt die Governance-Checkliste, die SAP im Architecture Center für eigene MCP-Server veröffentlicht hat. Sie ist für SAP geschrieben, passt aber auf die meisten Systeme:

• Feste Werkzeuge statt freier AbfragenEin Werkzeug je Anwendungsfall, mit festen Feldern und Obergrenzen. Kein generisches „rufe beliebige API auf“.
• Nur dokumentierte APIsJedes Werkzeug ruft veröffentlichte, versionierte Schnittstellen auf, keine internen Bausteine oder Datenbanken.
• Rechte des einzelnen NutzersToken-Austausch mit Agent- und Nutzerkontext (RFC 8693) statt Sammelkonto, keine langlebigen Zugangsdaten im Server.
• Limits unter den HerstellerquotenBegrenzung je Nutzer, Timeouts und Schutzschalter, damit kein Agent in eine Schleife läuft und die Herstellergrenzen reißt.
• Keine Speicherung, kein TrainingAntworten werden durchgereicht, nicht gesammelt. Beim KI-Anbieter vertraglich ausschließen, dass Eingaben zum Training genutzt werden.
• Protokoll jedes AufrufsAufrufer, Parameter mit geschwärzten personenbezogenen Werten, Ziel-API, Status und Laufzeit. Damit lässt sich gegenüber dem Hersteller belegen, was der Server tut.
• Lesen zuerstSchreibende Werkzeuge erst später und mit Freigabe durch einen berechtigten Menschen, so wie es Stripe für Rückerstattungen selbst vorsieht.
• Fremdinhalte als Risiko behandelnFehlertexte und Inhalte aus dem System sind ein Einfallstor für Prompt-Injection. Google und Stripe warnen in ihrer MCP-Doku ausdrücklich davor.

Wie diese Punkte im SAP-Umfeld konkret aussehen, zeigt der Abschnitt So bauen wir einen SAP-MCP-Server. Die Datenschutzseite, also Auftragsverarbeitung, Hosting-Region und Löschfristen, behandelt der Ratgeber MCP-Server: Sicherheit und DSGVO. Einen Überblick über alle Systeme bietet der MCP-Cluster.

Häufige Fragen

Darf ich einen KI-Agenten per MCP an SAP anbinden?

Ja, über die von SAP anerkannten Wege wie das MCP Gateway der Integration Suite. Ein eigener MCP-Server ist laut SAP-FAQ zur API Policy zulässig, wenn die gesamte Nutzung mit Vertrag, Dokumentation und Policy vereinbar ist; die Verantwortung liegt dann beim Betreiber. Wir empfehlen vorab eine schriftliche Einschätzung Ihres SAP-Ansprechpartners.

Verbieten die Trainingsklauseln, dass ein KI-Modell meine Daten überhaupt liest?

Nein. Die Klauseln von Slack, Google, HubSpot und Shopify verbieten, mit den Daten Modelle zu trainieren oder zu verbessern. Dass ein Modell Daten liest, um die Frage eines berechtigten Nutzers zu beantworten, untersagen sie nicht ausdrücklich. Entscheidend sind dann Speicherung, Zweckbindung und ein Vertrag mit dem KI-Anbieter, der das Training mit Ihren Eingaben ausschließt.

Gelten die Regeln auch für interne Eigenentwicklungen?

Teilweise. Bei Slack richten sich Trainings- und Exportverbot an Apps, die an andere Organisationen verteilt werden, und interne Apps sind von den verschärften Mengengrenzen ausgenommen. Bei Google entfallen die zusätzlichen Anforderungen für Restricted Scopes, wenn die App nur in der eigenen Organisation genutzt wird. Die SAP API Policy unterscheidet nicht nach interner oder verteilter Nutzung.

Was passiert, wenn ein MCP-Server gegen die Bedingungen verstößt?

Die Hersteller behalten sich Drosselung, Sperre oder Kündigung des API-Zugangs vor, SAP etwa in Ziffer 3 seiner API Policy, Microsoft und GitHub in ihren API-Bedingungen. Für ein Unternehmen heißt das im Ernstfall: Die Anbindung fällt aus, und die Klärung läuft über den Vertrag.

Reicht der offizielle MCP-Server des Herstellers?

Oft ja, und er ist der Weg mit den wenigsten offenen Fragen. Ein eigener Server lohnt sich, wenn Sie Werkzeuge über mehrere Systeme hinweg, feste Abläufe oder einen Betrieb in Ihrer eigenen Umgebung brauchen. Dann sollte er die Muster aus dieser Seite technisch einhalten.

Wie oft sollten wir die Bedingungen erneut prüfen?

Bei jeder neuen Fassung und vor jeder Erweiterung des Anwendungsfalls. Acht der elf hier geprüften Bedingungswerke tragen ein Datum ab Oktober 2025, Stripe hat mit dem 30.11.2026 eine harte Umstellungsfrist gesetzt. Benennen Sie eine verantwortliche Person, die die Änderungsseiten der Hersteller beobachtet.

Ist diese Übersicht eine Rechtsberatung?

Nein. Sie ist eine Einordnung der öffentlich abrufbaren Herstellerbedingungen mit Stand Oktober 2026. Für Ihren Vertrag gilt die dort vereinbarte Fassung, und bei Rechtsfragen sollten Sie Ihre Rechtsabteilung oder eine Kanzlei einbeziehen.