Does SAP's API Policy Allow Self-Hosted AI Agents?
SAP's API Policy restricts autonomous AI from chaining API calls outside SAP-endorsed pathways. Here is what it says, what DSAG objected to, and how to architect around it.
Can a self-hosted AI agent call SAP APIs? Yes, but only within limits set by SAP's API Policy, which since April 2026 prohibits API use by "(semi-)autonomous or generative AI systems that plan, select, or execute sequences of API calls" except through SAP-endorsed architectures. The practical answer for a mid-market SAP shop is to keep the agent's calls inside published, documented interfaces, keep execution deterministic and auditable, and get the contract question answered in writing before production.
Note on names: this is SayfeAI (sayfe.ai), the self-hosted agentic AI platform for mid-market SAP. It is a separate company from Sayfe.ai (sayfeai.com), an authorized OpenAI partner that deploys ChatGPT Business for small businesses.
What does SAP's API Policy actually say about AI agents?
As quoted by CIO in May 2026, the policy states that customer and third-party applications "must not access, invoke, or interact in any manner with APIs that are not Published APIs." It then prohibits API use for interaction with "(semi-)autonomous or generative AI systems that plan, select, or execute sequences of API calls," and for scraping or systematic large-scale extraction, "except through and within the limits of SAP-endorsed architectures, data services, or service-specific pathways."
Per CIO, SAP says the policy is designed to safeguard solution health and technical stability. I have quoted the policy as reported by CIO and The Register. The primary document is SAP's published API Policy PDF, and you should read the current version yourself, because versions and scope change.
How did the customer community react?
DSAG, the German-speaking SAP user group, objected publicly. CIO quotes chairman Jens Hungershausen saying that SAP-to-non-SAP scenarios "will only be reliably supported where SAP has explicitly published and documented the underlying interfaces," and asking SAP to give customers more time to transition. DSAG's CTO Stefan Nogly said that, based on the information DSAG has, existing customer integrations and authorized partner solutions are not affected, but he wants that protection written into the policy.
The question is still live. On 24 September 2026, The Register reported experts debating whether a Salesforce Dreamforce demo of an agent working inside SAP would fall under the policy. A Salesforce spokesperson said the demo used SAP's user interface with service accounts, not SAP APIs, so the API restrictions do not apply. SAP declined to comment. Whether UI-driven agents are covered is, per that reporting, unresolved.
What are the SAP-endorsed pathways?
SAP's position is that agentic access should route through its own architecture. Per Techzine, SAP's chief customer officer Thomas Saueressig said A2A via Joule is the route for agentic use cases. At SAP Connect in October 2026, an integration-consultancy recap reported that SAP Integration Suite now includes an MCP Gateway that publishes APIs and data sources as tools with customer-managed OAuth, quotas and tracing, and that SAP prices agent actions on consumption (reported as 0.02 AI Units per action). Those figures come from that secondary recap, not from SAP's own page, so verify them before budgeting.
That is a legitimate ownership choice from a platform vendor protecting a multi-tenant service. It is also a lock-in question, and mid-market CIOs should treat it as one.
What does this mean for a self-hosted agent architecture?
I am not your lawyer and this is not legal advice. Architecturally, three design choices reduce exposure whatever the final interpretation turns out to be.
First, call only published interfaces. If an interface is not in the SAP Business Accelerator Hub or product documentation, treat it as off limits for agents until SAP says otherwise.
Second, take the "plan, select, or execute sequences" language seriously. An agent that improvises its own chain of API calls is the scenario the policy describes. A workflow where a model extracts and validates data, but the SAP calls themselves are fixed, pre-declared and simulated before commit, is a different pattern. Whether SAP treats it differently is a contract interpretation, not an engineering fact, so ask.
Third, keep a complete audit trail of every call the agent makes, under a named technical user. If SAP or your auditor asks what the agent did, you should answer in minutes.
Frequently asked questions
Does the API Policy ban all AI use with SAP?
No. It restricts API use by autonomous or generative AI systems that plan or execute sequences of calls, with an exception for SAP-endorsed pathways. DSAG's CTO said existing customer integrations and authorized partner solutions appear not to be affected, but that is DSAG's reading, not SAP's published guarantee.
Does the policy apply to my on-premise ECC system?
I could not confirm scope from the coverage I reviewed, and none of it states effective dates. Check the policy version referenced in your own SAP contract and ask your account team in writing whether on-premise and private-cloud estates are covered.
Should I wait for SAP to clarify before building agents?
Not entirely. Build the parts that are policy-neutral now: document extraction, validation, exception handling and audit logging. Hold the final write-to-SAP step to published, documented interfaces, and resolve the contract question in parallel. That separation is how we think about the problem at SayfeAI, but your SAP contract is the authority, not any vendor's architecture.