Presented by SAP
The enterprise software landscape is undergoing a significant transformation, prompting vendors to reassess their strategies for safeguarding the customers who depend on their platforms. For years, global platform providers operating multi-tenant cloud infrastructure have consistently implemented documented rate limits, usage controls, and restrictions on the exploitation of undocumented internal interfaces. This practice is standard across various enterprise solutions.
For instance, Customer Relationship Management (CRM) platforms enforce daily API call limits per organization, impose platform-level restrictions, and maintain a clear distinction between APIs designated for bulk data operations and transactional REST endpoints. Similarly, productivity and collaboration suites throttle their Graph APIs and channel bulk workloads to specialized data access mechanisms optimized for such demands. Human Resources (HR) and workforce management platforms regulate concurrent requests and establish per-session data retrieval caps. IT Service Management (ITSM) platforms enforce per-user rate limits and instance-wide throttling. Hyperscalers define and enforce per-service quotas at the infrastructure level, explicitly prohibiting applications from accessing non-SDK or unpublished interfaces.
These measures are not considered controversial; rather, they represent fundamental operational hygiene for enterprise-grade software platforms managing shared infrastructure at scale. For over a decade, these controls have been in place without significant opposition.
As SAP assumes responsibility for securing its customers’ mission-critical workloads in the cloud, a unified API policy with clearly defined usage controls is an expression of enterprise-grade stewardship, not a restriction. Some interpretations of this policy have viewed it as introducing new limitations. However, the policy does not impose novel restrictions; it codifies and unifies controls that have long existed across individual SAP products.
SAP is not introducing API governance as a new concept. Solutions such as SAP SuccessFactors, SAP Ariba, and SAP LeanIX, among others, have already enforced documented rate limits and usage controls. SAP Notes and existing documentation have also previously defined API usage parameters.
The recent policy standardizes these existing practices into a single, cross-portfolio framework. This unification has become increasingly critical with the advent of autonomous agentic systems, which SAP is committed to supporting but which impose a fundamentally different level of performance, stability, and security load on API surfaces that were not originally designed for autonomous orchestration and large-scale data extraction.
Custom Interfaces: What SAP’s API Policy Entails and Excludes
Customer-built APIs within their own namespaces, developed for extensibility, integration, and migration, are distinct from vendor-published interfaces. For businesses that have invested years in developing custom data services, Remote Function Calls (RFCs), and ABAP interfaces to connect their SAP systems to external environments, the policy’s restriction on non-published APIs might initially appear prohibitive. However, this is not the case. The policy’s restrictions are targeted at SAP’s own internal, unreleased objects and do not impact custom code developed in the ‘Z’ namespace, preserving decades of ABAP engineering work.
SAP’s Private Cloud customers benefit from a unique advantage compared to many in the enterprise sector, as they have long possessed the ability to build within their own namespaces and shape their environments through modification and extension – a freedom that remains unaltered by this policy.
The policy’s focus is more specific: it addresses SAP’s internal interfaces that were never officially published, documented for customer use, or offered as a stable integration foundation. The vast majority of custom code operates independently of these internal interfaces and will remain unaffected. Where custom code does interact with these internals, the inherent risk has always existed and is now explicitly acknowledged by the policy rather than being introduced by it.
Within this context, a small subset of interfaces warrants strict prohibition rather than debate. ODP-RFC falls into this category; it resides within SAP’s namespace as an internal, unreleased interface that SAP explicitly classifies as “unpermitted” for customer or third-party application use, as detailed in SAP Note 3255746.
These are precisely the types of interfaces SAP will flag as prohibited through official notes and automated tooling. This proactive identification facilitates early detection and guidance, preventing issues that might otherwise be discovered late in deployment or operational phases. The concept of a “Clean Core” operates distinctly but aligns with the API Policy’s objectives. Customers have not only accepted these principles but have actively requested them, having experienced the significant upgrade costs associated with alternatives. In the era of AI agents, where SAP functions as a managed service for mission-critical ERP systems, both the Clean Core Recommendations and the API Policy are essential prerequisites for the enterprise-grade reliability afforded by cloud operations.
AI Agents Redefine API Usage Patterns in SAP Environments
While some commentary suggests this policy is primarily a commercial strategy, the technical evidence points to a different narrative.
Artificial Intelligence (AI) has fundamentally altered the traditional perspective on transactional interfaces. APIs used by enterprises for decades to integrate SAP systems with third-party applications are typically request-response interfaces designed for transactional workloads. They were built to execute specific actions, such as retrieving a sales order, posting a goods receipt, or initiating a payment run. Their design anticipated calls from human-authored integration flows, executed at predictable frequencies for defined business purposes. They were not engineered to handle autonomous AI orchestration harnesses making thousands of sequential calls to glean semantic context about the business model encoded within the system. This deviates significantly from clean core integration patterns.
Much of the discourse overlooks a crucial architectural distinction. Traditional integration tools typically extract a sales order from SAP, convert it to the required format for a target schema, and then transfer it. In this process, SAP’s data model serves merely as a transient interpretive step.
An AI agent operates on a fundamentally different principle. It does not merely retrieve a value; it analyzes the sales order header data to understand its significance as a customer commitment to purchase. It examines the line item data to grasp the relationships between individual products within the order. It assesses the net value, recognizing its meaning only in conjunction with the document’s currency. By tracing the sales order’s lifecycle through delivery, billing, and finally into the accounting ledger, it internalizes how SAP reconciles operations and finance within its business object model.
In essence, the AI agent consumes not only the customer’s transactional data but also the underlying semantic ontology: the definitions of business objects, the interrelationships between entities, and the conceptual architecture that SAP has meticulously developed and refined over five decades of enterprise knowledge encoding.
SAP has historically differentiated between enabling transactional access to customer data and the broader extraction or replication of the underlying ontology. This policy does not create this distinction, as it has always existed. Autonomous agents must continue to respect this boundary rather than redefine it.
Security Risks in Third-Party Model Context Protocol Implementations
Adding to these considerations is a security dimension that is far from abstract. Coinciding with the publication of this policy, a supply chain attack known as Mini Shai-Hulud—a variation of the npm worm—quietly compromised hundreds of software packages. SAP ecosystem npm packages were affected, prompting SAP to issue a security note to customers. This highlights not a theoretical threat model, but the active threat environment in which community-built Model Context Protocol (MCP) servers are being connected to productive SAP systems governing mission-critical business processes.
The OWASP MCP Top 10 comprehensively documents these vulnerability classes, including tool poisoning, prompt injection, privilege escalation through scope creep, token mismanagement, and supply chain compromise. Recent analyses of thousands of MCP implementations reveal that a majority operate with static, long-lived credentials or exhibit identifiable security flaws. A single compromised package within the MCP ecosystem can lead to the exposure of hundreds of thousands of development environments. VentureBeat recently reported a critical command execution flaw that rendered up to 200,000 MCP servers vulnerable.
Consider the practical implications: an AI agent that has just internalized the semantic structure of your SAP data model and is operating through a community MCP server transitions from being a mere productivity tool to an elevated risk category. This category combines broad system access with an attack surface that is still in its nascent stages of evolution.
Why MCP Alone Cannot Execute SAP Business Processes
The discussion surrounding MCP has also obscured a technical reality that enterprise architects must confront directly. The Model Context Protocol serves as a communication layer, defining how an AI model invokes a tool. It does not intrinsically convey whether the model comprehends the tool’s business context, the correct sequence for invoking multiple tools, the potential side effects of a given API invocation, or the consequences of incorrect parameters. A basic MCP implementation connecting to SAP OData services can invoke a tool, but it cannot execute a business process.
Data on token consumption from production agentic deployments offers valuable insights. For example, a query to retrieve an employee’s manager while traversing a list of peers within an SAP SuccessFactors system consumed 565,000 tokens under a standard MCP implementation. The same query, executed via a context-aware implementation, required only 80,000 tokens. This translates to a significant cost difference per operation, particularly when such queries are repeated thousands of times daily. A standard MCP implementation, therefore, represents not true automation, but an expensive approximation that falters on complex queries while subjecting API surfaces to traffic they were not designed to handle.
SAP’s Architecture for Open Third-Party AI Integration via Agent-to-Agent (A2A)
SAP’s response to these challenges is not to restrict the ecosystem but to develop the appropriate infrastructure for an open one. This distinction warrants careful consideration.
The API Policy grounds compliance in documented, co-engineered architectures. Reference architectures for agentic interoperability, developed in collaboration with major technology partners, are publicly available on the SAP Architecture Center. These are prioritized based on customer demand and updated as new patterns are validated.
The bi-directional integration of SAP Joule and Microsoft 365 Copilot serves as a prime example of co-engineered agentic integration in production. This demonstrates how AI systems from different vendors can operate across each other’s application surfaces without bypassing the security models of either party. The recommended approach for external AI agents accessing SAP is through the Agent Gateway utilizing the Agent-to-Agent (A2A) protocol, with reference AI Golden Paths available on the SAP Architecture Center. The SAP Knowledge Graph, the Open Resource Discovery (ORD) specification for metadata, and SAP Business Data Cloud (BDC) data products provide the contextual layer necessary to transform a protocol connection into a business-capable interaction. SAP also offers governed MCP servers for CAP, UI5, and Fiori Elements, with plans to extend this model to additional development environments, including ABAP development. These offerings represent guided pathways rather than closed doors.
SAP’s stance within the standards community is that of an active contributor, not a gatekeeper. SAP is a launch partner for the Agent2Agent (A2A) protocol under the Linux Foundation and holds a Gold level membership in the Agentic AI Foundation. The company co-chairs the Agent Identity and Trust workstream, collaborating with organizations that define how AI agents authenticate, authorize, and interoperate across enterprise boundaries.
A2A and MCP are not external constraints that SAP is reluctantly accommodating; they are protocols that SAP utilizes internally and is actively strengthening through standards work. As community and open-source frameworks meet the enterprise-level security requirements, external integration pathways will naturally follow.
The API Policy issued by SAP does not signify an end to openness. The industry has spent the past two years deploying AI agents against enterprise systems using protocols that the enterprise security community had not yet fully hardened, interacting with APIs not designed for autonomous orchestration, and relying on community tooling that attackers had already learned to compromise. Governance was not an optional consideration; it was a timely necessity.
Anirban Majumdar is Head of the Office of the CTO at SAP.
Sponsored articles are content produced by a company that is either paying for the post or has a business relationship with VentureBeat, and they’re always clearly marked. For more information, contact [email protected].
Business Style Takeaway: SAP’s new API policy is a necessary response to the evolving AI landscape, aiming to enhance security and stability by unifying existing controls rather than imposing new restrictions. Businesses relying on SAP should view this as an assurance of enterprise-grade reliability and a foundational step towards secure, scalable AI integration, rather than a limitation on their existing custom development.
Learn more at : venturebeat.com