SAP’s recent­ly updat­ed API pol­i­cy, intro­duc­ing new gov­er­nance for AI agents and data access, has sparked sig­nif­i­cant dis­cus­sion across the enter­prise land­scape, as cus­tomers seek to clar­i­fy any poten­tial impli­ca­tions for their use of APIs, exten­sions, and relat­ed data trans­mis­sion inter­faces. In a June 30 webi­nar — intend­ed to pro­vide an overview of the SAP API Pol­i­cy and its role in enabling secure, scal­able, and com­pli­ant inte­gra­tions with SAP solu­tions — SAP experts sought to assuage con­cerns that SAP might nar­row the inte­gra­tions and exten­sions they cur­rent­ly depend on. 

“It’s not about shut­ting doors,” explained Christof Momm, Lead Soft­ware Archi­tect at SAP. ​“We are build­ing new doors — bet­ter ones.”

Watch the full web­cast record­ing here and down­load the rel­e­vant PDF; for more, read SAP’s full API Pol­i­cy FAQ and ASUG­’s pre­vi­ous cov­er­age.

While adding rules for AI and agen­tic traf­fic, the pol­i­cy update leaves the prac­tices most cus­tomers depend on in place. Only one inter­face, ODP-RFC, sits on the unper­mit­ted list as of today. Clean core exten­si­bil­i­ty, cus­tom code in the Z and Y name­spaces, and pub­lished APIs used as doc­u­ment­ed all con­tin­ue unaf­fect­ed. SAP used the ses­sion to explain why this pol­i­cy update was nec­es­sary; its rea­son­ing start­ed with API traf­fic itself.

A quick look at a few of the webinar’s key takeaways: 

• SAP’s pre­sen­ters cast the update as out­lin­ing gov­er­nance and new AI-era path­ways, rather than as the crack­down some cus­tomers feared; the update, they stat­ed, is dri­ven by a surge in bot and AI-agent traf­fic that lega­cy APIs can’t absorb, as well as by ris­ing secu­ri­ty threats to AI tooling.
• What you can use comes down to doc­u­men­ta­tion: pub­lished APIs used as doc­u­ment­ed are sup­port­ed, undoc­u­ment­ed SAP inter­faces are at your own risk, and any exist­ing inte­gra­tions will receive mon­i­tor­ing and out­reach before any hard enforcement.
• Cus­tomers can check ODP-RFC expo­sure via a self-assess­ment tool at SAP Note 3439624; enforce­ment began June 9, 2026, with a secu­ri­ty patch that tech­ni­cal­ly blocks non­com­pli­ant ODP via RFC calls, while a Decem­ber 31, 2026 opt-out dead­line applies. (Use of ODP over ODa­ta is con­sid­ered a valid alter­na­tive, and there is no plan at this time to restrict this.)
• For AI and agents, SAP is steer­ing cus­tomers to stan­dards-based path­ways: A2A, into its own Joule agents; the MCP Gate­way in SAP Inte­gra­tion Suite; and SAP Busi­ness Data Cloud, for data extraction.

Why SAP Updat­ed Its API Policy

One of the main cat­a­lysts behind the pol­i­cy is vol­ume. SAP has watched auto­mat­ed traf­fic climb as cus­tomers point cod­ing agents and chat­bots at their sys­tems, and it behaves noth­ing like the human activ­i­ty its old­er APIs were built to absorb. Bots scrape data from pub­lic end­points and, increas­ing­ly, hit pro­tect­ed ones with valid cre­den­tials. When con­text is thin, an agent often resorts to tri­al and error, mul­ti­ply­ing calls. In some solu­tions, the load growth was sharp enough that SAP had to throt­tle some cus­tomers to keep one ten­ant from degrad­ing anoth­er, said Momm.

Then, there is the secu­ri­ty side. Momm point­ed to a run of sup­ply chain attacks that touched SAP direct­ly, includ­ing a LiteLLM inci­dent SAP mit­i­gat­ed with SAP LeanIX, and to a new attack sur­face that AI-native pro­to­cols open. MCP, he not­ed, now car­ries its own OWASP Top 10 of vul­ner­a­bil­i­ties spe­cif­ic to the pro­to­col. Left unpatched, he said, they can spread.

To explain the mechan­ics of this, Momm com­pared it to a high­way. The exist­ing APIs are a road built for human-dri­ven cars, he said, and AI has sent autonomous trucks onto it. Rather than widen the road or add tolls, SAP kept the orig­i­nal lanes for their traf­fic and added con­trols for the heav­ier load. It then built a sep­a­rate fast lane where autonomous traf­fic can coor­di­nate, with no human-dri­ven car in the way. 

What Changes, and What Stays the Same

The pol­i­cy itself can be read on a sin­gle page, with prac­ti­cal guid­ance deliv­ered via an FAQ Momm urged cus­tomers to read close­ly. Its log­ic rests on a sin­gle default tied to SAP’s doc­u­men­ta­tion. Where SAP doc­u­ments an API and the use a cus­tomer puts it to, that use is sup­port­ed. Where noth­ing is doc­u­ment­ed, SAP’s assump­tion is that the inter­face was not built for a clear pur­pose, and the risk falls to the cus­tomer. Pub­lished APIs are the offi­cial­ly sup­port­ed, low­est-risk path. Undoc­u­ment­ed ones may have run sta­bly for decades, but they sit out­side sup­port, and they were nev­er meant for mass data egress or AI consumption.

Cus­tom code stays square­ly inside these lines. Any­thing a cus­tomer builds in its own name­spaces, and every­thing the clean core frame­work clas­si­fies at lev­els A through D, remains per­mit­ted. SAP does not gov­ern cus­tom APIs direct­ly, said Momm, though they inher­it what­ev­er lim­its attach to the SAP APIs beneath them. 

Such inter­faces, he said, ​“must not be used to cir­cum­vent the mea­sures,” whether that means dodg­ing a rate lim­it or mak­ing an inter­face unsuit­ed to mass egress per­form it. The same scope reach­es third-par­ty ven­dor prod­ucts — SAP will not assess their com­pli­ance, leav­ing cus­tomers to ver­i­fy it with the vendor.

SAP is tread­ing care­ful­ly with inte­gra­tions already run­ning in pro­duc­tion. The com­pa­ny is wary of break­ing changes, said Momm, and would rather mon­i­tor usage and reach out to cus­tomers than impose hard lim­its; noth­ing already per­mit­ted is being inval­i­dat­ed after the fact. Cus­tomers who want to audit them­selves can use the ABAP Test Cock­pit and its Cloud Readi­ness Check to scan cus­tom code for non-pub­lished depen­den­cies; auto­mat­ic flag­ging of pro­hib­it­ed APIs is still in preparation.

Where SAP Draws the Line on ODP-RFC

One inter­face does cross into pro­hib­it­ed ter­ri­to­ry, and so far it is the only one. ODP-RFC was built as an inter­nal SAP inter­face, and SAP objects to its use for the exter­nal, large-scale data calls it was nev­er designed to car­ry. Even here, the restric­tion comes with room to maneuver. 

Cus­tomers can run a self-assess­ment with the tool­ing in SAP Note 3439624 to learn whether they are affect­ed. A secu­ri­ty patch shipped on June 9. Cus­tomers found to be impact­ed could sus­pend it tem­porar­i­ly while they migrate to a tar­get-state archi­tec­ture; an opt-out is avail­able only through Decem­ber 31, 2026, after which the restric­tion becomes permanent.

Cus­tomers rely­ing on the inter­face today have a sup­port­ed alter­na­tive. ODP over ODa­ta remains valid and unre­strict­ed, a doc­u­ment­ed route to the same data with­out the pro­hib­it­ed RFC path. More inter­faces are like­ly to be flagged over time, Momm said, as SAP labels con­fi­den­tial ABAP com­po­nents and extends ATC to detect them. ABAP is open and can be read, he acknowl­edged, but that does not mean that every­thing can be used.

A Primer on MCP and A2A

The policy’s oth­er half is the part SAP most wants noticed. Even as it sets defaults on the old­er inter­faces, it opens path­ways designed for AI, and those run on two open pro­to­cols instead of cus­tom, one-off inte­gra­tions. The Mod­el Con­text Pro­to­col (MCP) con­nects an agent to sys­tems, doc­u­ments, and data, expos­ing them as tools it can call. Momm likened it to JDBC, a stan­dard way to reach the data lay­er. The Agent2Agent pro­to­col (A2A) han­dles the oth­er direc­tion, let­ting inde­pen­dent agents and sys­tems talk to one anoth­er, work that old­er REST inter­faces once did.

SAP has tied itself to both. It is a found­ing mem­ber of the Lin­ux Foundation’s A2A project and a Gold mem­ber of the Agen­tic AI Foun­da­tion. SAP is also con­tribut­ing to MCP to make it enterprise-ready.

Those pro­to­cols anchor a set of endorsed path­ways. The one SAP prefers is A2A into its own agents, Joule among them, because those agents, as Momm put it, ​“have the con­text, and they know pre­cise­ly what to do with the tasks,” spar­ing the APIs the overuse of a less-informed caller. MCP through the Inte­gra­tion Suite turns exist­ing APIs into agent-ready tools, and SAP Busi­ness Data Cloud han­dles extrac­tion for data and ana­lyt­ics work, includ­ing a doc­u­ment­ed pat­tern that con­nects to Databricks. 

The ded­i­cat­ed gate­way for the pre­ferred A2A route, the Agent Gate­way, is still forth­com­ing; until it ships, SAP points cus­tomers to the endorsed pat­terns in its Archi­tec­ture Cen­ter and AI Gold­en Path guide.

SAP recent­ly added a more open option allow­ing third-par­ty MCP servers, though Momm was clear it puts the secu­ri­ty and inte­gra­tion bur­den — from authen­ti­ca­tion to sup­ply chain expo­sure — on the cus­tomer. Using it is ​“their own risk,” he said, and SAP steers cus­tomers toward man­aged offer­ings instead.

Gov­ern­ing Agent Access Through the MCP Gateway

To make MCP prac­ti­cal at enter­prise scale, Dhaw­al Joshi, Chief Prod­uct Own­er for SAP’s API Plat­form in the Inte­gra­tion Suite, intro­duced the new MCP Gate­way. The gate­way takes APIs, inte­gra­tions, and data sources a cus­tomer already runs and, in Joshi’s words, turns them into ​“dis­cov­er­able and reusable tools for agent use.” A cus­tomer can build a serv­er from an exist­ing API arti­fact, an Ope­nAPI or ODa­ta spec­i­fi­ca­tion, or an RFC, then secure it through SAP’s iden­ti­ty services.

Gov­er­nance, more than raw con­nec­tiv­i­ty, is the gateway’s point, said Joshi. Agents sub­scribe to a pub­lished serv­er through a devel­op­er hub and receive their own scoped cre­den­tials, grant­ed and traced agent by agent, with an ana­lyt­ics view show­ing which agents and tools are in use. The design also trims the token cost of agent access. A raw, ver­bose ODa­ta call hand­ed to an agent can bal­loon its con­text and raise the chance of agents hal­lu­ci­nat­ing; an MCP tool gives it a lean­er, pur­pose-shaped inter­face instead.

Joshi gave a live demon­stra­tion, build­ing a pro­cure­ment-com­pli­ance serv­er and run­ning an agent that reviewed a pur­chase order and flagged an inac­tive supplier.

The MCP Gate­way ships as part of the Inte­gra­tion Suite’s Enhanced and Pre­mi­um edi­tions. Joshi said the roll­out began the day of the webi­nar, reach­ing pro­duc­tion data cen­ters on AWS and Azure from July 5, with more on July 12 and Google Cloud Plat­form to fol­low. About 20 cus­tomers had run the gate­way in beta, and SAP uses it inter­nal­ly, though none had yet gone live on the gen­er­al­ly avail­able release.

The Q&A drew out a dis­tinc­tion worth keep­ing in mind. SAP does not man­date its own gate­way; cus­tomers can front their agents with oth­er MCP servers, pro­vid­ed they take on the secu­ri­ty and life­cy­cle work them­selves. One par­tic­i­pant flagged the gap between the policy’s strict legal tone and the FAQ’s more prac­ti­cal one, and SAP said the two do dif­fer­ent jobs. The pol­i­cy sets the legal frame­work, while the FAQ explains how to live with­in it day to day.

Momm offered his own sum­ma­tion after the demo. ​“We are not lock­ing down every­thing with the API pol­i­cy. We are also open­ing up a lot,” he said, ​“but doing things right is impor­tant.” For now, the pol­i­cy restricts a sin­gle inter­face, leaves clean core and cus­tom code alone, and routes the new agent traf­fic through path­ways SAP is still build­ing out. 

Watch the full web­cast record­ing here and down­load the rel­e­vant PDF.