SAP experts are questioning whether a recent Salesforce public demo of its AI technology would breach the German vendor’s controversial API policy - launched in April - in production environments. Salesforce has denied it would break any of SAP’s access rules. During the keynote presentation at the CRM vendor’s flagship Dreamforce conference in San Francisco last week, Katie O'Neil, Salesforce product marketing director, showed how a Salesforce AI agent was able to perform supplier onboarding with SAP, showcasing global engineering manufacturer Siemens as a customer. The demo appears to show AI agent Marshall working in an SAP sandbox, learning “where to click, which fields are required,” O'Neil said. The AI agent would use “LLM reasoning to really understand the business rules behind that process,” she said. The outcome is that users working in Salesforce’s collaboration platform, Slack, can onboard customers in SAP, or so the demo purports to show. “Marshall will package them up, create a library of trusted actions, and that is where AI reasoning becomes deterministic execution. What does that mean? It means when it comes time for something like supplier onboarding, Marshall's not just improvising. Marshall is executing against the same set of trusted actions every single time, so you know you can rely on him,” O’Neil said. How ERP giant SAP — a company also betting its future on AI — feels about all this is another matter. Being demoted to providing backend systems while Salesforce takes control of the user experience is not part of the German vendor's plans, we assume. In a social media post, an independent SAP consultant argued that the demo, if replicated in the real world, would not be allowed by SAP under its API Policy. Mario de Felipe, VP SAP data and AI at IT and managed services company Apiphani, said the API policy forbids "impersonation techniques." At the same time, any autonomous AI must go through SAP "endorsed architectures" to get inside SAP applications. “Not only did they connect to the SAP API to update a supplier, which would have been simple, but not the wow-effect required for a keynote, they connected to an SAP system, captured SAP application logic… how the BP [business process] role model works... the complete SAP's product behavior,” he said. The demo was not the result of a new partnership between the vendors, he pointed out on LinkedIn. A Salesforce spokesperson told The Register: “There’s an important distinction here: the Dreamforce demonstration interacted with SAP through its user interface using service accounts, without using SAP APIs. The API-use restrictions cited in the LinkedIn post therefore do not apply to the activity demonstrated.” SAP has declined the opportunity to comment. Speaking to The Register, De Felipe pointed out SAP's API Policy prohibits API use for “interaction or integration with (semi-) autonomous or generative AI systems that plan, select, or execute sequences of API calls” unless “through and within the limits of SAP-endorsed architectures.” Scraping, harvesting, or systematic and/or large-scale data extraction or replication is also banned with the same caveat. “More than breaking the rules, Salesforce knew what they showed during that keynote is not what the customers should be doing," he claimed. "There is a way to do these things following SAP architecture: that's SAP's point of view. There is a way of doing these things following Salesforce architectures. But what Salesforce did is clearly [not] the best practice architecture on how to deploy AI agents.". Others see some rule-breaking in Salesforce’s demo. Marian Zeis, an independent SAP consultant in Germany, said he agreed with most of De Felipe’s interpretation. “Robotic Process Automation itself is generally fine. It gets more difficult once an LLM or autonomous agent starts planning and executing calls against SAP, because then SAP expects documented or endorsed access paths. I would not automatically call an agent acting with a user’s authorization an ‘impersonation technique.’ In the policy, that wording is used in the context of bypassing API controls, so it really depends on how the Salesforce demo is implemented,” he said. SAP's API Policy was launched in April, with some critics arguing it would prohibit the use of APIs to integrate with AI systems outside its endorsed architectures, locking out other systems users want to employ. “My bigger issue is the practical one: the API Policy is reasonable as a governance document, but it still does not fit very well with how customers actually work today,” Zeis said. In the LinkedIn comments to De Felipe's post, John Appleby, a long-time SAP expert and former CEO of SAP partner Avantra, cautioned that demos were often designed to “be edgy but not break any license agreements.” Whether the Salesforce demo broke any of the API policy rules was a grey area, he said, while there were also ways to integrate these kinds of technology through “a permissible layer like SAP Integration Suite.” “Given they are namedropping Siemens, you can be sure that this has been checked as compliant. But yeah, there have been dragons in this sort of use case ever since SAP's Indirect Access rules, which go back nearly two decades, and of course since the new API Policy was put in place,” he said. One senior analyst who spoke to The Register off the record said that SAP’s API policy was pure protectionism given how far the vendor is in any AI Race. Linking AI to RISE with SAP — the vendor’s partnership agreement to get customers to the cloud and upgrade their ERP software — was “a big mistake,” he said. SAP’s first effort at AI, called Joule, is only a digital assistant, he said. “The consequences of exclusivity is 93 percent — almost all large customers — are denied access, which explains why they have no significant case studies. SAP were forced to make some U-turns as their large customers are not going to RISE anytime soon,” he said. Later, SAP launched Joule Agent Builder, part of Joule Studio within SAP Build, which is accessible to all RISE and non-RISE customers. “This was released in December ’25 but they have not yet talked to anyone that has used it,” he said. Then in May, SAP began to offer AI to on-prem customers on legacy systems. “SAP API policy in April was to cover their announcement in the following month at Sapphire when announcing AI services for both ECC and S/4HANA on-prem,” he said. However, customers were not keen on “wasting money talking to their ERP” in the SAP-approved architectures, he said. Most SAP customers that have already deployed GenAI that used APIs will now be non-compliant according to the SAP API policy, he claimed. SAP would rather its customers built agents in its environment, and from there reached out to work with other systems. When it launched its Joule Studio 2.0 at its Sapphire conference in May, SAP said it would allow developers to create and manage AI agents which connect and collaborate with third-party tools and third-party agents. "We've made extensibility a core design principle… This allows you to connect them to your non-SAP applications, because we know you're going to have to do that," Muhammad Alam, SAP executive board member for product and engineering, said at the time. Whether this will be enough to prevent others — Salesforce, ServiceNow, Microsoft or whoever has the most natural fit with end users — from stealing a march on SAP is unanswered. Publishing an API policy document seems unlikely to stop them. ®
/s3/static.nrc.nl/wp-content/uploads/2026/09/23144441/240926CUL_2036847791_1.jpg)
