What SAP’s API Policy and Architecture Center actually say about third-party MCP servers, and what that means for your AI roadmap.
If you have read SAP’s recent AI and API guidance and come away thinking that AI access to SAP now has to run on SAP’s own stack, you are not alone. Between the SAP AI Golden Path, SAP-managed AI services, and a steady drumbeat of commentary about API restrictions, the prevailing impression across the ecosystem is that the door to third-party AI has quietly closed.
It hasn’t. SAP’s own published architecture guidance documents and permits third-party MCP servers: explicitly, by name, as a named pattern.
That distinction matters, because enterprises are making multi-year architectural commitments right now based on an interpretation the source documents do not support.
What SAP’s Architecture Center says about third-party MCP servers
A third-party SAP MCP server is a Model Context Protocol (MCP) server operated by a vendor, an open-source project, or a SaaS provider that connects AI agents to SAP APIs from outside SAP’s own platform.
Start with SAP’s Architecture Center, not with the commentary about it. In its guidance on third-party MCP access to SAP solutions, SAP states plainly:
“Customers and partners may use third-party MCP servers to access SAP APIs, provided the following conditions are met.”
Those conditions are concrete: follow the SAP API Policy in full, especially its General API Controls; authenticate and authorize every connection; respect SAP API rate limits; and harden the infrastructure for stability and security.
SAP then goes further and defines Pattern 1: External MCP Server on a Third-Party Platform, a pattern that expressly includes MCP servers that are “vendor-supplied, open source, or SaaS-hosted.”
This is not a loophole or a grudging exception. It is a documented architecture pattern with a name, a description, and a decision guide sitting next to SAP’s own managed MCP infrastructure. SAP provides and endorses its own AI and MCP technologies and publishes an architecture for externally operated, vendor-provided MCP servers. Both are in the same document.
SAP API Policy FAQ: Integration Suite is optional, third-party MCP is permitted
The SAP API Policy FAQ (v1.3) says the same thing twice, reinforcing the point from two directions.
SAP Integration Suite is not the only compliant path. Q32 states:
“The API Policy does not mandate adoption of SAP Integration Suite. SAP Integration Suite is one endorsed integration pattern but it is not the exclusive compliant option.”
SAP then names the actual test: “The compliance criterion is the SAP API surface being used and the usage pattern, not the integration platform using the API itself.” Compliance is about which interfaces you call and how you call them. It is not about whose logo is on the middleware.
Third-party MCP servers are permitted. Q56 states:
“Customers and partners may use third-party or custom MCP servers to connect to SAP APIs, provided all use complies with the agreement, the Documentation and in particular the SAP API Policy.”
SAP does place responsibility for the design, operation, and maintenance of self-managed MCP servers on the customer or partner. Read that for what it is: a governance responsibility, not a prohibition. SAP is telling you to run it properly, not telling you that you can’t run it.
Endorsed vs. permitted: how SAP treats its own MCP and third-party MCP
Endorsed and permitted are two different words. This is where most of the confusion lives, so it is worth stating precisely.
SAP identifies its own MCP technologies as endorsed approaches and expresses a preference for them in certain enterprise scenarios. That is entirely reasonable, and enosix does not claim that SAP endorses arnold®.
But endorsement of SAP’s own technology is not prohibition of everyone else’s. SAP’s FAQ and Architecture Center explicitly recognize third-party and custom MCP servers and explicitly describe vendor-supplied external MCP architectures as a supported pattern. “SAP prefers its own” and “nothing else is allowed” are very different claims, and only one of them appears in the documents.
| SAP-native AI path | Governed third-party MCP (e.g. arnold®) | |
|---|---|---|
| SAP status | Endorsed by SAP | Documented and permitted by SAP (Pattern 1) |
| AI tool choice | SAP’s AI stack | Any MCP-capable agent: Copilot, Claude, Gemini, custom agents |
| SAP footprint | Requires SAP’s managed services | Runs against your existing ECC or S/4HANA |
| Compliance test | The API surface and usage pattern you use | The API surface and usage pattern you use |
| Operational responsibility | SAP | Customer or partner (governance, not prohibition) |
How arnold® fits SAP’s third-party MCP pattern
arnold® is a vendor-provided MCP server. That places it squarely inside the external third-party MCP category SAP documents in Pattern 1.
On the SAP side, enosix uses customer-installed custom ABAP interfaces to expose defined business capabilities. SAP FAQ Q27 specifically recognizes customer-namespace ABAP interfaces and custom RFC modules as customer-developed interfaces, and the SAP API Policy itself (Section 1.2) addresses custom-developed ABAP interfaces in private-cloud and on-premise deployments. Q31 further confirms that customers may continue creating custom APIs, provided they are not used to circumvent the SAP API Policy or applicable agreements.
The resulting path is deliberately narrow and governed:
AI / Agent → arnold® → governed business capability → customer SAP interface → SAP ECC or S/4HANA
No open table reads. No undocumented endpoints. No agent improvising its way across your ERP. Each capability is a defined, permissioned business operation with SAP’s own business logic and authorizations intact behind it.
The better question to ask your architecture team
“Does this use SAP’s Golden Path?” is the wrong first question. It sorts vendors into a binary that SAP’s own documentation does not use.
The question that actually maps to SAP’s published requirements is:
How does this deployment satisfy SAP’s requirements for third-party MCP access? Which interfaces does it use, what usage pattern does it follow, and what governance controls are in place?
That is an answerable, auditable question. It is also the question SAP’s FAQ effectively poses when it names the API surface and the usage pattern as the compliance criteria.
What to review in your own SAP AI architecture
Whatever path you choose, these are worth inventorying now:
- Which SAP interfaces do your AI tools and pipelines actually touch today? Published, documented, customer-namespace, or undocumented?
- Is there a governed intermediary between your agents and SAP, or are agents calling SAP directly with unbounded call patterns?
- What is the usage profile? Agentic traffic has a different load signature than human users, and that is a legitimate engineering concern regardless of policy.
- Are your business rules enforced in SAP, or reimplemented outside it? Logic that drifts outside SAP is both a compliance and a correctness problem.
- How locked-in is the path you are choosing? If your AI tooling choice changes in 18 months, does the integration survive it?
Frequently asked questions
What is a third-party SAP MCP server?
A third-party SAP MCP server is a Model Context Protocol (MCP) server operated by a vendor, an open-source project, or a SaaS provider that connects AI agents to SAP APIs from outside SAP’s own platform.
Does SAP allow third-party MCP servers?
Yes. SAP’s Architecture Center states that customers and partners may use third-party MCP servers to access SAP APIs, and defines an external third-party MCP server as a documented pattern that includes vendor-supplied options. FAQ Q56 says the same for third-party and custom MCP servers, subject to the agreement, the Documentation, and the SAP API Policy.
Do we have to use SAP Integration Suite to be compliant?
No. FAQ Q32 states the API Policy does not mandate adoption of SAP Integration Suite, and that it is one endorsed pattern rather than the exclusive compliant option.
Is arnold® endorsed by SAP?
No, and enosix does not claim that it is. arnold® falls within the third-party MCP architecture SAP documents and permits. Endorsed and permitted are different categories, and conflating them is the core misreading in the market right now.
Does arnold® work with SAP ECC as well as S/4HANA?
Yes. arnold® exposes governed business capabilities against existing SAP ECC and SAP S/4HANA systems, which means AI projects can build on the SAP investment, business logic, and processes already in place.
Who is responsible for operating a third-party MCP server?
Per SAP’s FAQ, the customer or partner holds responsibility for design, operation, and maintenance of self-managed MCP servers. That is a governance obligation to plan for, not a barrier to entry.
The bottom line
SAP’s published guidance establishes two things clearly: third-party and vendor-provided MCP servers are a recognized architecture pattern, and SAP’s own integration technologies are not the exclusive compliant option.
For enosix arnold®, then, the productive conversation is not whether a third-party MCP server is allowed. It is how a given deployment satisfies SAP’s published requirements.
With that foundation settled, the real work can start. arnold® gives organizations a streamlined path to bring AI into existing SAP ECC and S/4HANA processes: governed business capabilities exposed through MCP, so AI projects move faster while building on the SAP investments, business logic, and processes already running the business. That is a clearer line from AI concept to SAP-connected production use.
Want to see what governed AI access to your SAP system looks like?
Talk to enosix about arnold® and how a third-party MCP architecture maps to your SAP landscape, your interfaces, and your governance requirements.
SAP references
SAP updates these documents often. This article reflects the SAP API Policy v.4.2026a, the SAP API Policy FAQ v1.3 (June 2026), and the Architecture Center guidance as last updated October 26, 2026.
- SAP Architecture Center, “Third-Party MCP Access to SAP Solutions”, Customer Responsibility; last updated October 26, 2026.
- SAP Architecture Center, “Third-Party MCP Access to SAP Solutions”, Pattern 1: External MCP Server on a Third-Party Platform.
- SAP Architecture Center, “Third-Party MCP Access to SAP Solutions”, SAP-Provided MCP Infrastructure; Decision Guide.
- SAP API Policy FAQ, v1.3, June 2026, Q32, p. 11.
- SAP API Policy FAQ, v1.3, June 2026, Q56, p. 20.
- SAP API Policy FAQ, v1.3, June 2026, Q27, pp. 9–10.
- SAP API Policy FAQ, v1.3, June 2026, Q31, p. 11.
- SAP API Policy FAQ, v1.3, June 2026, Q37, pp. 13–14; Q39, p. 15.
- SAP API Policy, v.4.2026a, Section 1.2, p. 1: custom-developed ABAP interfaces in private-cloud and on-premise deployments.