MCP and vendor policies: what SAP, Microsoft, Google, Slack, Salesforce and Stripe allow for AI access

Why have vendor policies determined MCP projects since 2025?

Because the major software vendors have now explicitly aligned their API terms with AI agents, AI training and bulk retrieval: Slack as of 10 October 2025, SAP as of 27 April 2026, and eight of the eleven sets of terms reviewed here carry a date from October 2025 onwards. An MCP server that runs flawlessly from a technical point of view can still violate these terms and then be throttled or blocked.

The Model Context Protocol makes it easy to give a language model tools that call the interfaces of a business system. This is exactly the pattern the vendors have in view. Four themes keep coming up:

• Agent clauses: Who may call an interface when it is no longer a human or a fixed program deciding, but a model? SAP has regulated this explicitly since April 2026.
• AI training: Slack, Google, HubSpot and Shopify prohibit using data from their interfaces to train or improve models.
• Data export and bulk retrieval: Systematically extracting large volumes of data is expressly prohibited at SAP, Slack and Shopify, and at Microsoft permitted only as far as the application needs it.
• Access routes: Dedicated key types for agents (Stripe), dedicated OAuth scopes for MCP (Salesforce) or the obligation to be registered as a Marketplace or internal app (Slack).

For you this means: the question "Is it technically possible?" is usually answered quickly. The question "Is it permitted under the vendor's terms, and by which route?" belongs at the start of every project.

What do the vendors allow for AI access? Overview, as of October 2026

Ten of the eleven vendors reviewed offer an official MCP route, DATEV does not; at Shopify it is aimed at shopping agents in the store. The terms for AI access, however, differ considerably. The table summarises what we read in each primary source (retrieved 28 October 2026).

Terms change. The "As of" column gives the date the vendor itself states. Where none is given, it shows the date we retrieved the terms.

What applies at each vendor in detail?

The table necessarily condenses. Here are the points that tip the balance in projects, with the exact wording or reference in each case.

SAP: agents only via approved routes

SAP is the only vendor in this overview that ties the use of its APIs by AI agents to specific routes recognised by SAP. Clause 2.2.2 of the API Policy prohibits use by "(semi-) autonomous or generative AI systems that plan, select, or execute sequences of API calls" unless access runs via a route recognised by SAP. According to the SAP FAQ, this applies to cloud and on-premises, including RISE. Own MCP servers are permitted under question 56 of the FAQ if the entire use is compatible with the contract, documentation and policy; SAP gives no support commitment for this. Rule-based processes without planning by a language model are not covered by clause 2.2.2 according to question 40. The details, the quote and the DSAG's reaction are in the SAP guide, API Policy section.

Microsoft: data policies control the MCP tools

At Microsoft, governance in your own tenant is what mainly decides. Copilot Studio now supports only Streamable HTTP for MCP, SSE has no longer been supported since August 2025, and it connects servers with OAuth 2.0 or an API key (Microsoft Learn, as of 28 May 2026). Because MCP servers run there via Power Platform connectors, the Power Platform data policies apply. According to Microsoft, these have been enforced in all tenants since the start of 2025, and there are no longer exceptions for individual agents (Microsoft Learn, as of 1 October 2026).

For Microsoft 365 data, Microsoft recommends Work IQ MCP in new projects, which is generally available as part of the Work IQ API. According to Microsoft, the older, application-specific MCP servers for mail, calendar, SharePoint or Teams are intended only for backward compatibility and not for production use. Own MCP servers can be registered, reviewed and approved in the Microsoft 365 admin centre (Microsoft Learn, as of 8 October 2026). The Microsoft API Terms also require requesting only the minimum necessary data and permissions (clause 3.b.5). More in the guide MCP server for Microsoft 365.

Google Workspace: training ban and security assessment

In the Workspace User Data Policy, Google prohibits transferring or selling user data, or using it for a machine learning or artificial intelligence model "to create, train, or improve". For restricted scopes, such as full access to Drive or Gmail, a CASA security assessment is required, and Google can have it repeated regularly. Important for in-house developments: "If an app is only used by users within your own organization, then these additional requirements do not apply." The official Workspace MCP servers run as a developer preview, with OAuth 2.0; service accounts with domain-wide delegation cannot use the option for AI agents, and Google warns of indirect prompt injection (Google for Developers, as of 27 October 2026). Details in the guide MCP server for Google Workspace.

Slack: Marketplace or internal

The Slack API Terms of 10 October 2025 distinguish between apps for your own organisation and apps distributed to third parties. For distributed apps: no training of language models with API data, no bulk export of messages and files without an additional agreement. For the Data Access API and the Real-Time Search API there is a further rule: no permanent copies, archives or indexes of other organisations' data. According to the Slack docs, only apps published in the directory or internal apps may use the Slack MCP server, and workspace admins approve every MCP client. Since 29 May 2025, new, unlisted distributed apps have also been subject to a limit of one request per minute for conversations.history and conversations.replies; internal in-house developments are exempt (Slack changelog). More in the guide MCP server for Slack.

Salesforce: hosted servers with a dedicated OAuth scope

Salesforce made its hosted MCP servers generally available on 29 April 2026 for all orgs from Enterprise Edition. According to the announcement, every call runs with the identity of the signed-in user, without an anonymous service account, and changes appear in the audit trail under their name. A new OAuth scope gives access to MCP but not to the existing REST APIs, and every server must be explicitly activated in Setup (Salesforce Developers Blog). To get started, Salesforce recommends the read-only server platform/sobject-reads in a sandbox. More in the guide MCP server for Salesforce.

HubSpot: agents explicitly in the terms

HubSpot names agents directly in the API Terms (as of 4 May 2026): "any use or offering of agents or agentic features by your Solution must also adhere to these Terms." Clause 4.B.8 prohibits using customer data to train, fine-tune or improve AI or ML models. This is permitted only for exactly one customer, with their express consent and without benefit to others. Access is limited to documented developer tools; anyone using undocumented interfaces does so at their own risk (4.A.2). The remote MCP server has been generally available since 13 April 2026 and respects existing user permissions (HubSpot changelog). More in the guide MCP server for HubSpot.

Stripe: dedicated keys for agents

Stripe is switching MCP access to dedicated agent keys. According to the Stripe docs, from December 2026 the MCP server accepts neither secret keys with full access nor restricted keys without an agent tag; unsupported keys receive a 401 response. Anyone working with a restricted key today must switch to a new agent API key or OAuth by 30 November 2026. Administrators can switch MCP access on and off separately for live and test environments. More in the guide MCP server for Stripe.

Atlassian, Shopify, GitHub and DATEV

Atlassian: The Developer Terms (as of 1 December 2025) contain no separate AI clause. Clause 6(d) is relevant: no calls that are not triggered by a user request or the app itself. The Rovo MCP Server uses OAuth 2.1 and existing permissions (Atlassian Support), see also MCP server for Jira and Confluence.

Shopify: The API Terms (as of 7 October 2026) contain the most far-reaching training ban in the overview. It also covers anonymous, aggregated and derived data and expressly names language models. See MCP server for Shopify.

GitHub: Section H of the Terms of Service (as of 27 April 2026) reserves the right to block access in case of excessive API use. The official GitHub MCP Server can be started with --read-only and selected toolsets. See MCP server for GitHub.

DATEV: The terms of use for the Developer Portal and interfaces (as of 19 August 2024) do not regulate AI separately. However, putting an online API into operation requires DATEV's technical review and a conformity notice in text form. See MCP server for DATEV.

Which patterns recur in the terms?

Six rules appear at several vendors. Anyone who takes them into account when designing an MCP server answers a large part of the questions the vendor might ask later. It does not replace the review of the individual case.

What stands out is where the line runs: the training bans are directed against improving models with other people's data. That a model reads data to answer a specific question from an authorised user is not expressly prohibited by the clauses we read. SAP is the exception here, because clause 2.2.2 already covers the planning and selection of API calls by an AI system.

How do you check the vendor policies before building?

By treating the review as a project step of its own with a results document, before the first line of code is written. This is what has worked in our projects:

• 1. Determine the applicable versionWhich API terms, policy and terms of use apply to your contract? Record version and date, store a PDF or web archive copy.
• 2. Describe the use case preciselyWhich system, which data, read or write, who asks, how often. This is the yardstick for whether bulk retrieval or agent use is in play.
• 3. Check the official route firstIs there a vendor server or a recognised route such as the SAP MCP Gateway? If so, justify why an own server is still needed.
• 4. Internal or distributed appAt Slack and Google, obligations depend on whether the app runs only in your organisation. Decide this deliberately and document it.
• 5. Written vendor statementIf anything is unclear, put the question in writing to your contact at the vendor, specifically and with an architecture sketch. Add the answer to the project file.
• 6. Approval by procurement and legalHave the licensing question (do agent accesses count as users?), the terms and data processing approved together, with data protection and the works council where needed.
• 7. Record keys and deadlinesWhich key types are allowed, which expire? Example Stripe: switch by 30 November 2026.
• 8. Monitor changesCheck the vendors' changelogs and terms pages regularly, name a person responsible. A new version means: repeat the review.

The result is a short decision document per system: chosen route, applicable version, open questions, vendor statement, approvals. It also helps later, when internal audit or an auditor asks why the connection was built this way.

How can you design your own MCP server to comply with vendor policies?

An own MCP server can be built so that it technically observes the recurring vendor rules, instead of relying only on agreements. The governance checklist that SAP has published in the Architecture Center for own MCP servers serves as a template. It is written for SAP but fits most systems:

• Fixed tools instead of free-form queriesOne tool per use case, with fixed fields and upper limits. No generic "call any API".
• Documented APIs onlyEvery tool calls published, versioned interfaces, no internal components or databases.
• Rights of the individual userToken exchange with agent and user context (RFC 8693) instead of a shared account, no long-lived credentials in the server.
• Limits below the vendor quotasLimits per user, timeouts and circuit breakers, so that no agent runs into a loop and breaks the vendor limits.
• No storage, no trainingResponses are passed through, not collected. Exclude contractually with the AI provider that inputs are used for training.
• Audit log of every callCaller, parameters with redacted personal values, target API, status and duration. This lets you demonstrate to the vendor what the server does.
• Read firstTools that write only later and with approval by an authorised human, as Stripe itself provides for refunds.
• Treat third-party content as a riskError texts and content from the system are an entry point for prompt injection. Google and Stripe expressly warn of this in their MCP docs.

How these points look in practice in the SAP environment is shown in the section How we build an SAP MCP server. The privacy side, that is, data processing, hosting region and retention periods, is covered by the guide MCP server: security and GDPR. An overview of all systems is offered by the MCP cluster.

Frequently asked questions

May I connect an AI agent to SAP via MCP?

Yes, via the routes recognised by SAP, such as the MCP Gateway of the Integration Suite. According to the SAP FAQ on the API Policy, an own MCP server is permitted if the entire use is compatible with the contract, documentation and policy; responsibility then lies with the operator. We recommend obtaining a written assessment from your SAP contact beforehand.

Do the training clauses prohibit an AI model from reading my data at all?

No. The clauses of Slack, Google, HubSpot and Shopify prohibit using the data to train or improve models. That a model reads data to answer the question of an authorised user is not expressly prohibited by them. What matters then are storage, purpose limitation and a contract with the AI provider that excludes training on your inputs.

Do the rules also apply to internal in-house developments?

Partly. At Slack, the training and export bans are directed at apps distributed to other organisations, and internal apps are exempt from the tightened volume limits. At Google, the additional requirements for restricted scopes do not apply if the app is used only within your own organisation. The SAP API Policy does not distinguish between internal and distributed use.

What happens if an MCP server violates the terms?

The vendors reserve the right to throttle, block or terminate API access, SAP for example in clause 3 of its API Policy, Microsoft and GitHub in their API terms. For a company, this means in the worst case: the connection fails, and the matter is settled through the contract.

Is the vendor's official MCP server enough?

Often yes, and it is the route with the fewest open questions. An own server is worthwhile if you need tools across several systems, fixed processes or operation in your own environment. It should then technically observe the patterns from this page.

How often should we re-check the terms?

With every new version and before every extension of the use case. Eight of the eleven sets of terms reviewed here carry a date from October 2025 onwards, and Stripe has set a hard switchover deadline with 30 November 2026. Name a person responsible who watches the vendors' change pages.

Is this overview legal advice?

No. It is an assessment of the publicly available vendor terms as of October 2026. For your contract, the version agreed there applies, and for legal questions you should involve your legal department or a law firm. Our assessment, not legal advice.