Governance, not gatekeeping: How SAP brings enterprise‑grade safety to AI connectivity

Source: VentureBeat

Presented by SAP

The enterprise software industry has undergone a fundamental shift, and vendors are adapting their approaches to better protect the customers who rely on them. For years, every global platform vendor running multi‑tenant cloud infrastructure has maintained documented rate limits, usage controls, and restrictions on the use of undocumented internal interfaces.

Typical Platform Controls

• CRM platforms – daily API‑call limits per organization, platform‑layer limits, and a strict separation between bulk‑data APIs and transactional REST surfaces.
• Productivity & collaboration suites – throttled graph APIs; bulk workloads are redirected to purpose‑built data‑access channels designed for that load.
• HR & workforce‑management platforms – concurrent‑request limits and per‑session data‑retrieval caps.
• IT service‑management platforms – per‑user rate limits and instance‑level throttling.
• Hyperscalers – published per‑service quotas enforced at the infrastructure layer; explicit prohibition of calls to non‑SDK or non‑published interfaces.

These are baseline hygiene for enterprise‑grade software platforms operating shared infrastructure at scale. For more than a decade these measures have been in place without serious objection.

Why SAP’s Unified API Policy Is Not a New Restriction

As SAP has taken responsibility for securing customers’ mission‑critical workloads in the cloud, a unified API policy with clarified usage controls is not a restriction but the expression of enterprise‑grade stewardship.

• The policy does not introduce new restrictions; it simply names and unifies controls that have existed across individual SAP products for years.
• SAP is not inventing API governance. Solutions such as SAP SuccessFactors, SAP Ariba, SAP LeanIX, and many others have already enforced documented rate limits and usage controls.
• SAP Notes and SAP documentation have historically defined API usage.

What the recent policy does is consolidate that existing practice into a single cross‑portfolio standard—a step made urgent by the arrival of autonomous, agentic harnesses that SAP is fully committed to enabling. These agents place a categorically different performance, stability, and security load on API surfaces that were never designed for autonomous orchestration and data extraction at scale.

Custom Interfaces: What SAP’s API Policy Does & Does Not Restrict

Customer‑Developed APIs

• Custom APIs built by customers in their own namespace (the Z namespace) for extensibility, integration, and migration are customer‑developed interfaces.
• The policy’s restriction on non‑published APIs does not constitute a demolition order for these custom services.

Scope of the Policy

• The focus is on SAP’s own internal interfaces that were never published, never documented for customer use, and never offered as a dependable foundation for integration.
• Most custom code never touches these internals and will continue untouched. Where it does, the risk has always existed; the policy merely names it rather than invents it.

Explicitly Prohibited Interfaces

• ODP‑RFC belongs to a smaller class of interfaces that are prohibited. It resides in SAP’s namespace as an internal, non‑released interface that SAP explicitly classifies as “unpermitted” for customer or third‑party use (see SAP Note 3255746).

These interfaces will be flagged as prohibited in notes and automated tooling so that such usage can be identified early, rather than discovered late in deployment or operation.

Note: Clean Core is distinct from the API Policy but points in the same direction. Customers have repeatedly asked for Clean Core recommendations after experiencing upgrade costs of alternative approaches. In the agentic era—where SAP runs mission‑critical ERP as a service—both Clean Core recommendations and the API Policy are conditions of the enterprise‑grade reliability that cloud operations make possible.

How AI Agents Change API Usage Patterns in SAP Systems

While some commentators argue that this policy is primarily a commercial move, the technical evidence tells a different story.

Traditional Transactional Interfaces

• Designed for request‑response interactions: fetch a sales order, post a goods receipt, trigger a payment run.
• Typically called by human‑authored integration flows at predictable frequencies for defined business purposes.

Autonomous AI Orchestration

• AI agents run thousands of sequential calls against these APIs to extract semantic context about the business model.
• This pattern is not a clean‑core integration approach.

Architectural Distinction

• Traditional integration tool: reads a sales order, converts it to a target schema, and moves it on. SAP’s data model is a transient interpretation step.
• AI agent: does something categorically different. It does not merely retrieve a value; it interprets, correlates, and acts on the data in ways that were never anticipated by the original API design.

Because AI agents impose high‑frequency, high‑volume, and context‑rich workloads on API surfaces, the unified API policy is essential to preserve performance, stability, and security in the emerging agentic era.

Understanding the SAP Data Model

The agent reads the line‑item data and learns how individual items relate to an order. It reads the net value and learns that this number is meaningful only when paired with the document currency. It traces the path that a sales order takes through delivery, billing, and finally into the accounting ledger, internalizing how SAP reconciles operations and finance within its business‑object model.

The agent is not only consuming a customer’s transactional data; it is also consuming the semantic ontology:

• Business‑object definitions
• Relationships between entities
• The conceptual architecture that SAP has built and refined over five decades of enterprise‑knowledge encoding

SAP has long distinguished between enabling transactional access to customer data and the broader extraction or replication of the underlying ontology. The policy does not create this boundary—it already existed. Autonomous agents must continue to respect that boundary rather than redefine it.

Security Risks in Third‑Party MCP Implementations

Then there is a security angle, and it is not abstract. The same week this policy was published, a supply‑chain attack named Mini Shai‑Hulud—a variant of the npm worm—quietly compromised hundreds of software packages. SAP‑ecosystem npm packages were compromised, and we addressed this with a security note for customers. This is not a theoretical threat model; it is the active threat environment in which community‑built MCP servers are being connected to productive SAP systems running mission‑critical business processes.

The OWASP MCP Top 10 documents the vulnerability classes systematically:

1. Tool poisoning
2. Prompt injection
3. Privilege escalation via scope creep
4. Token mismanagement
5. Supply‑chain compromise

Recent research across thousands of analyzed MCP implementations shows that a majority operate with static long‑lived credentials or carry identifiable security findings. A single compromised package in the MCP ecosystem can cascade into hundreds of thousands of exposed development environments.

VentureBeat just last week reported a serious com.mand execution flaw that made up to 200,000 MCP servers vulnerable.

Consider what that means in practice. An AI agent that has just internalized the semantic structure of your SAP data model and is operating through a community MCP server moves beyond a productivity tool and into an elevated risk category, one that combines broad system access with an attack surface that is still evolving.

Why MCP Alone Cannot Run SAP Business Processes

The MCP debate has also obscured a technical reality that enterprise architects need to confront directly.

• Model Context Protocol (MCP) is plumbing. It specifies how an AI model calls a tool.
• It says nothing about whether the model understands what the tool does in a business context, what sequence tools must be called, what side effects a given API invocation will trigger, or the consequences of an incorrect parameter.

A naive MCP implementation connecting to SAP OData services can call a tool, but it cannot run a business process.

Token‑Consumption Example

*Cost based on a typical LLM pricing model for a single operation.

The standard MCP implementation is not automation; it is an expensive approximation of automation that fails on complex queries while loading the API surface with traffic it was not designed to carry.

SAP’s Architecture for Open Third‑Party AI Integration via A2A

SAP’s response to these challenges is not to close the ecosystem but to build the right infrastructure for an open one. That distinction is worth dwelling on.

Key Elements

• API Policy – anchors compliance in documented, co‑engineered architectures.
• Agentic Interoperability Reference Architectures – jointly developed with major technology partners, published on the SAP Architecture Center, prioritized by customer demand, and updated as new patterns are validated.
• Bi‑directional Integration of SAP Joule and Microsoft 365 Copilot – the most visible example of co‑engineered agentic integration in production: two AI systems from different vendors work across each other’s application surfaces without bypassing the other’s security model.
• Agent Gateway via the A2A protocol – the endorsed path for external AI‑agent access to SAP.
• Reference AI Golden Path – available on the SAP Architecture Center.
• SAP Knowledge Graph, Open Resource Discovery (ORD) specification for metadata, and SAP BDC data products – provide the context layer that transforms a protocol connection into a business‑capable interaction.
• Governed MCP servers – for CAP, UI5, Fiori Elements, with intent to extend to additional development environments, including ABAP.

These are not closed doors; they are the right doors.

Standards Community Involvement

• SAP is an active contributor, not a gatekeeper.
• Launch partner of the Agent‑to‑Agent (A2A) protocol under the Linux Foundation.
• Holds Gold‑level membership in the Agentic AI Foundation, co‑chairing the Agent Identity and Trust workstream alongside organizations that define how AI agents authenticate, authorize, and interoperate across enterprise boundaries.

A2A and MCP are not external constraints that SAP is grudgingly accommodating. They are protocols SAP uses internally and is actively hardening through standards work. When community and open‑source frameworks meet these hardened standards, enterprises gain a secure, scalable path to leverage AI agents across SAP landscapes.

Enterprise Security and API Openness

The security floor that enterprise deployment requires, external integration pathways will follow. The API Policy issued by SAP does not mark the end of openness. The industry has spent two years deploying AI agents against enterprise systems using protocols that the enterprise security community had not finished hardening, against APIs that were never designed for autonomous orchestration, with community tooling that attackers had already learned to compromise. Governance was not optional; it was timely.

Anirban Majumdar is Head of the Office of the CTO at SAP.

Sponsored Content Disclosure

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 sales@venturebeat.com.