SAP API Policy: Facts, risks and recommendations for your AI strategy

SAP draws the guard rails: What the new API policy means for AI strategies in the midmarket

In May 2026, SAP published a revised API policy that fundamentally reorganizes access to SAP interfaces by AI agents, automation tools and third-party platforms. This has far-reaching consequences for companies that are currently developing their AI strategy. We analyze the most important points and show which recommendations for action result from this.

What does the new SAP API Policy regulate?

The API Policy is part of the official SAP documentation and applies to all SAP cloud solutions as well as the on-premise portfolio – including S/4HANA Private Cloud (RISE) and all line-of-business solutions. It pursues four central objectives:

• APIs should be used as intended – i.e. only as specified in the documentation.
• Platform stability and security should be protected.
• Misuse should be prevented – in particular through uncontrolled automated access.
• Scalable innovation should be supported, precisely because AI and agentic access is increasing.

Important: SAP emphasizes that the policy does not change any existing license rights or functional authorizations. Nevertheless, it clearly defines which APIs may be used – and which may not.

The three categories: Permitted, tolerated, prohibited

In future, SAP will make a clear distinction between three types of interfaces:

1. Published APIs (Published APIs): All interfaces that are documented in the SAP Business Accelerator Hub, in the SAP Help Portal or in product-specific portals (e.g. Ariba, Concur). These may be used within the documented limits.
2. Non-published APIs: SAP-internal interfaces that have never been officially documented but are used by many customers and partners. These fall into the “use at your own risk” category – they can be changed or removed at any time.
3. Explicitly prohibited APIs: Interfaces that are marked as “Confidential and Proprietary” or have been classified as not permitted by SAP Notes. Prominent example: ODP-RFC for third-party tools.

Particularly relevant for SMEs: Community blog posts and forum contributions do not make an API a “Published API”. Only the official SAP documentation confers this status.

What does this mean for AI agents and automation?

This is where it gets exciting – and at the same time critical for many companies that are currently developing their AI strategy. The policy explicitly requires that AI-controlled, agentic or automated access patterns require SAP endorsement. The reasoning from the official FAQ document is revealing:

• Volume and unpredictability: A single prompt to an AI agent can trigger thousands of API calls – in patterns that transactional APIs cannot handle.
• Security risks: Independent research shows that a significant proportion of MCP servers use static, long-lived credentials. Supply chain attacks such as “Mini Shai-Hulud”(SAP Note 3747787 see also our blog post on vibe coding at BTP) have directly compromised SAP ecosystem packages.
• Data integrity: An agent without a complete business context can inadvertently write incorrect data back into the system.

SAP explicitly recognizes that agentic AI is an important trend. The restriction is directed against uncontrolled, undocumented access patterns – not against AI in general.

The two “endorsed” architectures: MCP Gateway and A2A

SAP defines two official paths for AI access to SAP systems:

1. MCP Gateway on SAP Integration Suite: A customer-managed entry point with authentication, authorization, rate limiting and audit logging. External AI platforms can access SAP via this route.
2. Agent2Agent (A2A) protocol: For multi-agent scenarios in which an external AI orchestrator needs to delegate tasks to SAP-managed agents. A2A is an open standard under the Linux Foundation.

SAP is positioning itself here as a standards developer, not a standards consumer: the company is a gold member of the Agentic AI Foundation (AAIF) and leads the workstream on agent identity and security.

What does that mean in concrete terms?

Companies that today let AI agents loose directly on SAP APIs – for example via self-built MCP servers or direct API calls from LLM orchestration tools – are operating in a gray area that SAP will increasingly restrict. The preferred routes are via SAP-controlled gateways.

Voices from the industry: “Not a restriction, but a step towards maturity”

Reactions in the SAP community are varied. Valentino Koester, Global SAP & AI Leader at KPMG, puts it in a nutshell in a much-noticed LinkedIn analysis:

“SAP didn’t close its APIs. It redefined how AI is allowed to interact with SAP systems.

”
Koester argues that the policy marks an architectural paradigm shift: away from the idea of a central AI layer that orchestrates all workflows across SAP and non-SAP platforms towards distributed intelligence with platform-specific execution boundaries:

• Distributed intelligence instead of centralized orchestration
• Federated agents – AI systems exchange intentions instead of taking over each other’s processes
• Platform-owned Execution Boundaries – each platform controls its own execution environment

Jennifer Maier (KPMG) adds a crucial question in the comments: Who bears responsibility when AI agents autonomously prioritize decisions, change process flows or trigger actions across multiple systems? Governance models and control mechanisms need to develop in parallel with the technology – not years later.

This perspective coincides with a key finding: the API policy is less a technical restriction than the formalization of what enterprise architects already know – uncontrolled AI autonomy in transactional systems is not a viable model.

Vendor lock-in or legitimate governance?

SAP addresses the vendor lock-in issue directly in the FAQ. The central statement: the policy does not restrict the use of third-party integration tools, AI platforms or data platforms – provided that access is via published SAP APIs and endorsed architectures.

Nevertheless, a differentiated picture emerges:

• Third-party integration platforms may continue to be used – but only via Published APIs and in compliance with the rate limits.
• Third-party AI platforms must access via endorsed architectures (A2A via Joule/Agent Gateway).
• Third-party data platforms receive SAP data via BDC Connect and Delta Sharing – legacy paths such as ODP-RFC are explicitly no longer supported.

For customers, this means that the freedom of choice on the non-SAP side remains intact. But access on the SAP side is increasingly being channeled. Anyone relying on uncontrolled API access today needs to rethink.

Impact on RISE customers and existing integrations

There is good news and not so good news for companies in the RISE transformation process:

Good: Customer APIs in the Z or Y namespace are not affected. Custom RFCs, BAPIs and function modules remain permitted – as long as they do not bypass any SAP-internal APIs or generate uncontrolled load.

Less good: Remediation of existing integrations that rely on non-published SAP APIs is not automatically included in the RISE scope. SAP recommends clarifying this explicitly during contract negotiations.

SAP provides tools such as the ABAP Test Cockpit (ATC) with Cloud Readiness Check to identify dependencies on non-published interfaces in your own code.

Five recommendations for action for SMEs

Based on the analysis of the SAP API policy and the implications for SMEs, we recommend the following steps:

1. Perform an API inventory: Check which SAP APIs your integrations are using today. Are they published APIs? Use the ATC Cloud Readiness Check to identify risks.
2. Align AI strategy with governance: If you use AI agents that access SAP data, evaluate the endorsed architectures (MCP Gateway, A2A). Do not plan any production scenarios based on uncontrolled API access.
3. Ensure platform independence: Rely on integration platforms that can connect both SAP-endorsed and non-SAP systems – without having to rely on a single vendor architecture.
4. Check RISE contracts: Before signing or renewing a contract, clarify whether the remediation of existing integrations is included in the scope.
5. Build an orchestration layer: Instead of letting AI agents loose directly on individual system APIs, you need a governance layer that centrally controls authentication, authorization, rate limiting and audit logging.

The Simplifier perspective: Sovereign AI orchestration as the answer

The SAP API Policy makes one thing clear: direct, uncontrolled access by AI agents to enterprise systems is not a viable architecture – regardless of the vendor. What companies need is a sovereign orchestration layer that mediates between AI agents and backend systems.

This is precisely the core of the Simplifier platform: As an agentic AI platform for SAP companies, Simplifier offers an architecture that embeds AI agents into existing process landscapes in a governance-compliant manner – with complete control over authentication, data flows and system access.

The decisive advantages:

• No vendor lock-in: Simplifier relies on open standards (API-first, MCP-compatible) and gives customers full code ownership.
• SAP-native integration: Deep SAP connection via published APIs – compliant with the new API policy.
• Governance by design: AI agents are orchestrated via a central runtime that enforces roles, authorizations and audit trails.
• Operation according to customer choice: On-premise, hybrid or sovereign cloud – no forced hyperscaler dependency.

The SAP API Policy confirms a development that we have been advocating for a long time: AI in enterprise systems needs a controlled execution layer. No longer “AI can do everything directly”, but “AI is used in an orchestrated, governed and controlled manner”.

Conclusion: The API policy as a catalyst for better AI architectures

SAP’s new API policy is not a step backwards, but a necessary step towards maturity. It enforces what was overdue in enterprise AI anyway: governance, controlled access paths and clear architectural decisions. For medium-sized companies, this means a need for action in the short term – but more stable and secure AI integrations in the long term.

The key question for decision-makers is no longer “Whether AI”, but “How do I orchestrate AI so that it works securely and in compliance with governance in my enterprise landscape?”

If you want to answer this question for your company, talk to us. We will show you how to use AI agents productively in your SAP landscape – without governance risks, without lock-in and without architectural compromises.

---

Sources: SAP API Policy FAQ (May 2026, Version 1.1) | Valentino Koester (KPMG) – LinkedIn analysis