When SAP introduced a new API Policy in April, it put firmer boundaries around how customers, partners, and automated systems could access SAP applications. Published APIs were tied to documented uses, non-published interfaces faced tighter restrictions, and SAP added specific controls for generative or semi-autonomous systems that can orchestrate sequences of API calls.
The change quickly raised questions about existing integrations, custom code, partner products, and whether SAP’s published APIs exposed enough functionality to replace undocumented interfaces. The Americas’ SAP Users’ Group (ASUG) also tracked concerns around API availability, existing integrations, and agentic AI architectures. By August, Hector Enriquez, founder and CEO of Surpoint.ai, said a broader interpretation was still circulating: that SAP’s new policy “forbids AI.”
SAP has since clarified many of those points. Existing documented integrations are not expected to be affected, customer-developed APIs remain permitted within defined limits, and third-party integration platforms can still connect to SAP. The bigger change is around agentic AI, where systems that decide for themselves which SAP APIs to call now face stricter governance requirements. Questions remain around mixed AI workflows, future commercial models, and how the policy will be applied in more complex architectures.
Does SAP’s API Policy Affect Existing Integrations?
For most existing integrations, the immediate answer is no. SAP says integrations and extensions that use APIs for their documented purposes are not expected to be affected by the policy. It recommends customers validate those connections against the relevant product documentation, including any applicable rate limits or security controls.
The position is more complicated for integrations built on undocumented interfaces. SAP says it will not retroactively invalidate those integrations simply as a policy enforcement action. In many cases, those interfaces can continue to operate, but without the same stability or support guarantees as published APIs. Interfaces SAP has explicitly prohibited are a separate case.
Can Customers Still Use Custom ABAP and Custom APIs?
Yes. SAP says customer-developed interfaces remain permitted, including custom ABAP interfaces, OData services, CDS views, and RFC modules built in the customer namespace. The policy does not treat that code the same way as SAP’s own internal or private interfaces.
The restriction comes into play when custom code is used to bypass SAP’s API controls. SAP says customer-developed interfaces cannot create unreasonable load or security risks, access protected internal components, or become an alternate route for unendorsed agentic AI or mass data extraction.
That leaves customers free to maintain legitimate custom integration and extension logic, while putting more responsibility on them to understand what those interfaces connect to and how they are being used.
Are Third-Party Integration Platforms Still Allowed?
Yes. SAP says the policy applies regardless of whether an API is called through SAP Integration Suite, API Management, third-party middleware, or custom integration tooling. The compliance question is the SAP interface being used and the access pattern, not the integration platform itself.
SAP Integration Suite is an endorsed pathway, but it is not mandatory. Third-party iPaaS and middleware platforms can remain compliant when they connect through published APIs and stay within SAP’s documented controls. Architectural changes are more likely where an integration depends on non-published APIs or falls under restrictions covering autonomous AI access or large-scale data extraction.
What Changes When an AI Agent Calls SAP APIs?
SAP says deterministic automation, including rule-based RPA that follows predefined API call sequences, does not fall under the specific restriction on agentic AI.
The restriction applies when an AI system can decide for itself which SAP APIs to call and in what sequence. SAP says those agentic access patterns must align with endorsed architectures and governance requirements around authentication, authorization, rate limits, and auditability.
SAP says the concern is that a single prompt can trigger large numbers of API calls, while an agent without enough business context could access data outside its intended scope or write incorrect information back into the system.
How Can Third-Party AI Agents Connect to SAP?
SAP says third-party AI agents can still connect to SAP, but autonomous access must use governed pathways. Its current endorsed options include MCP Gateway on SAP Integration Suite, SAP-provided MCP servers through Joule Studio, and the Agent2Agent protocol for communication between external and SAP-managed agents.
Those pathways are intended to put controls such as authentication, authorization, rate limiting, and audit logging between the agent and SAP APIs. SAP also says customers can use third-party or custom MCP servers, provided they comply with the API Policy and its underlying controls, although SAP does not provide the same support or stability guarantees for those implementations.
The result is that customers can still choose the AI platform they want to use, but the way that platform reaches SAP now matters much more.
What Is Still Unclear About SAP’s API Policy?
SAP has clarified the policy’s broad boundaries, but does not provide a binding decision matrix for every integration or automation pattern. The FAQ describes the AI Golden Path as directional guidance and directs customers to SAP when uncertainty remains. Some SAP support materials raise questions about mixed cases, including platforms with optional AI features and downstream consumers that add AI after an API is published.
Pricing also remains unsettled. SAP says the policy does not change current license grants or entitlements, while noting that technical options and commercial models will evolve as agentic and large-scale data access develop. The German-speaking SAP User Group (DSAG) has called for clearer pricing, contractual treatment, and planning certainty.
Enforcement and responsibility are less defined in mixed architectures. SAP’s support material raises questions about where conventional integration ends and agentic AI begins, and what responsibility falls on an API publisher when AI is introduced downstream. Customers may still need case-specific guidance where existing integrations, third-party platforms, and AI overlap.
What Should SAP Customers Review Now?
The immediate task is to map the current integration estate against the policy. SAP recommends maintaining an inventory of custom APIs that records the namespace, interface type, purpose, owning team, and underlying SAP dependencies. Customers should confirm whether each connection uses a published interface for its documented purpose and identify any reliance on non-published or explicitly prohibited APIs.
AI and automation deserve a separate review. Teams need to identify where workflows remain deterministic and where an AI system is deciding which SAP APIs to call and in what sequence. Those agentic patterns may require different governance around identity, authorization, rate limits, and auditability.
Responsibility also needs to be clear before remediation work begins. SAP says customer-built integrations that rely on non-published APIs are not automatically covered by the standard RISE scope, so customers may need to address ownership, timing, and commercial terms separately with SAP or their implementation partners.
What This Means for ERP Insiders
Architecture choices now carry compliance consequences. Customers cannot judge policy exposure by vendor or platform alone; the same tool may be acceptable in one configuration and problematic in another. Architecture review therefore becomes part of compliance planning.
API inventories become prerequisites for agent deployment. Customers that already understand their published, custom, and unsupported interfaces can assess agent access earlier. That reduces the risk of discovering integration constraints only after AI pilots are underway.
Agent governance moves into existing controls. AI projects will increasingly require involvement from identity, security, integration, and authorization teams before production deployment. Customers can treat agent access as an extension of established governance instead of a separate AI exercise.
This article was originally published by SAPinsider on September 8, 2026.
