--- title: Every vendor needs an API policy. Not every architecture is fit for one. description: DELIVERY MODEL · INTEGRATION · ENTERPRISE ARCHITECTURE - Onshore, Offshore, Hybrid — Choosing Without Trading Away Security image: https://www.cloudorizon.com/hubfs/Blog%20Header%20Alternatives%20-%20API%20Policy-selection.png --- [Skip to content](http://www.cloudorizon.com/insights/every-vendor-needs-an-api-policy.-not-every-architecture-is-fit-for-one#main-content) [![logo-old](https://www.cloudorizon.com/hs-fs/hubfs/logo-old.png?width=583&height=110&name=logo-old.png "logo-old")](http://cloudorizon.com) - [Home](http://www.cloudorizon.com) - [Solutions](http://www.cloudorizon.com/solutions-at-cloudorizon) - [About](http://www.cloudorizon.com/about-cloudorizon) - [Case Studies](http://www.cloudorizon.com/case-studies-cloudorizon) - [Insights](http://www.cloudorizon.com/insights) - [Contact](http://www.cloudorizon.com/book-a-meeting-with-us) - [ROI](https://calc.cloudorizon.com/) - [Enterprise Architecture](http://www.cloudorizon.com/insights/tag/enterprise-architecture), - [Delivery](http://www.cloudorizon.com/insights/tag/delivery), - [Integration](http://www.cloudorizon.com/insights/tag/integration), - [Automation](http://www.cloudorizon.com/insights/tag/automation) # Every vendor needs an API policy. Not every architecture is fit for one. - October 6, 2026 ![Lee Cunningham](https://www.cloudorizon.com/hubfs/Lee-Cunningham-Cloudorizon.jpg) [Lee Cunningham](http://www.cloudorizon.com/insights/author/lee-cunningham) #### At the UKISUG AI Symposium last week, I argued that SAP were right to write their API Policy. Every software vendor needs one now that agents call APIs on our behalf, and so does every company that runs their software. My concern is the architecture SAP have published around it. A policy says what you may not do. The architecture says how to comply. And an architecture that goes with a policy should pass three tests: 1. **You can comply without buying more of the vendor's products.** 2. **Your pace of change is not tied to the vendor's roadmap.** 3. **The rules would still work if every vendor applied them.** This is the short version of that talk. The detail follows in a series, listed at the end. ![Blog Header Alternatives - API Policy-selection](https://www.cloudorizon.com/hs-fs/hubfs/Blog%20Header%20Alternatives%20-%20API%20Policy-selection.png?width=960&height=536&name=Blog%20Header%20Alternatives%20-%20API%20Policy-selection.png) ### **Why every vendor needs a policy now** [SAP's own FAQ](https://www.sap.com/documents/2026/04/e2a0665e-4c7f-0010-bca6-c68f7e60039b.html) gives two reasons, and both are sound. Volume: "a single user prompt to an AI orchestration harness can generate thousands of API calls against SAP endpoints." Security: independent research has found "a significant proportion of MCP servers using static long-lived credentials with high exploit probability." The examples are not hard to find. In July 2025, [researchers at General Analysis showed](https://generalanalysis.com/blog/supabase-mcp-blog) an AI assistant connected to a database through Supabase's MCP server, holding a key that could see everything. A hidden instruction in a support ticket got it to read out the credentials table. In August 2025, [stolen OAuth tokens from the Salesloft Drift integration](https://cloud.google.com/blog/topics/threat-intelligence/data-theft-salesforce-instances-via-salesloft-drift) were used to bulk-query Salesforce across many companies. And when [Astrix examined over 5,000 MCP servers](https://astrix.security/learn/blog/state-of-mcp-server-security-2025/), mostly open-source implementations rather than enterprise deployments, more than half relied on static keys or tokens, and fewer than one in ten used OAuth. There are hundreds more. Different systems, the same three gaps: - long-lived, over-privileged credentials; - no bounded set of tools; - nothing in the record to say an agent acted. SAP also cite the Mini Shai-Hulud attack on SAP-ecosystem npm packages ([SAP Note 3747787](https://me.sap.com/notes/3747787)). That was a supply chain compromise rather than an agent misusing a credential, but it makes the same point from another side: the tooling agents run on is software you have to govern too. So a gate in front of a vendor's APIs is right, for SAP and for everyone else. The question is the architecture around it.   ### **What SAP's policy says** Three clauses in [SAP's API Policy](https://help.sap.com/doc/sap-api-policy/latest/en-US/API_Policy_latest.pdf) matter. Clause 1.2: every endpoint you call must be a published API. Section 2.2.2: AI systems that "plan, select, or execute sequences of API calls" may do so only through SAP-endorsed architectures. Section 3: no circumventing the controls through intermediaries, proxies or gateways. The policy never says what an endorsed architecture is. It names no product and says nothing about identity. Apart from ODP-RFC, which SAP block technically, enforcement today is monitoring, dialogue and the right to throttle. The FAQ fills the gap. It names the endorsed routes, and all of them are SAP's: A2A through the Agent Gateway, where your agent hands the task to a Joule agent, and the MCP Gateway in Integration Suite. SAP's [Third-Party MCP Access to SAP Solutions](https://architecture.learning.sap.com/docs/ref-arch/137800) guidance then permits two more: a custom MCP server you build on BTP, and a third-party MCP server or integration platform outside it. Permitted is not the same as endorsed: those routes are allowed if they meet SAP's conditions, but they are unsupported, and you carry the risk. Three of those four routes end at exactly the same published APIs. The fourth hands the job to SAP. What differs is who sits in the middle, and whose rules they follow. ### **Same job, different bar** SAP's MCP Gateway and an MCP server you run do the same job. Each takes a tool call from an agent, turns it into calls on SAP's published APIs, and returns the result. SAP hold them to different identity bars. Their [reference architecture for Copilot Studio and the MCP Gateway](https://architecture.learning.sap.com/docs/ref-arch/d2e34e) shows the user's token and nothing more. Their third-party guidance requires a server you run, on BTP or off it, to exchange that token at SAP's identity service for one that also names the agent, and the agent must be registered in SAP Cloud Identity Services. ![](https://www.cloudorizon.com/hs-fs/hubfs/undefined.png?width=864&height=394&name=undefined.png) Same job, different bar · the endorsed and self-managed routes Both routes end at the same published APIs; only the self-managed one makes the extra hop to SAP's identity service. Same job, different badge, different bar. That's my reading of the documents side by side, and I'd put the point carefully: - **The exchange is fine.** It's an open standard, and I'd do it anyway. - **Agent identity is right.** Without it, nobody can tell an agent's mistake from a stolen credential. It should apply to every route, SAP's included. - **The question is where the agent's identity is defined.** I have no objection to SAP's identity service being in the token path. The friction is that the agent must be registered there, rather than defined once in your own identity provider and trusted by SAP's, as people already are. I'd expect SAP to answer that registration lets them guarantee the audit record and non-repudiation when an agent changes a ledger. That is a fair concern, and federation meets it: SAP's identity service still issues the token that names the agent, and SAP still own the record. The same concern would also apply to SAP's own MCP Gateway reference architecture, which documents no agent identity at all. The permitted route is not a free pass either. SAP's conditions also cover rate limits, audit and versioned tools, and their FAQ is plain that compliance depends on "the SAP API surface being used and the usage pattern, not the integration platform". Your integration platform doesn't make you compliant. What it calls, and how, does. The asymmetry isn't in the policy. It's in the reference architecture, the least binding layer of SAP's documents. That is also the easiest layer to fix. ### **The three tests** **Can you comply without buying more?** A partial pass. For integration, yes: your existing platform is fine on published APIs. For agents, only just. The permitted routes need no SAP product beyond its identity service, but they are unsupported and carry the heaviest identity condition. Every endorsed route is an SAP product. The protocols are open; the endpoints are SAP's. **Whose roadmap sets your pace?** Managed platforms absorbing protocol change is a genuine service, which is why a hand-built MCP server is the worst answer here. The narrower problem is that SAP decide when a new protocol is "sufficiently hardened" to become an endorsed route. Use SAP's gateway for SAP's tools and that is fine. Make it the control point for your whole estate, and SAP's timetable becomes yours. **Would it work if every vendor did it?** Not yet. Take one agent that turns an opportunity into an order and an onboarding case across Salesforce, SAP, ServiceNow and Workday. Apply SAP's identity rule at every vendor and you get four registrations, four audit trails that don't join up and four revocations, one of which someone will forget. We solved this once already, for people: identity held once, in the company's own identity provider, and trusted by each vendor through federation. SAP already do that for people, and their own [Agent Identity](https://architecture.learning.sap.com/docs/ref-arch/140bdb) architecture says their identity service supports federation. Letting "registered" mean federated would close most of the gap. ![](https://www.cloudorizon.com/hs-fs/hubfs/undefined-1.png?width=864&height=334&name=undefined-1.png) Test three · four registers against one federated identity   ### **One plane, many edges** **![](https://www.cloudorizon.com/hs-fs/hubfs/undefined-2.png?width=864&height=444&name=undefined-2.png)** The plane and the edge · one plane, four vendor edges. Every vendor needs an edge: its own controls in front of its own APIs. For SAP, that is its identity service and the published API surface. The MCP Gateway is one way through that edge, not the edge itself. You go through each edge, never round it. The estate needs one control plane: the thing that decides which tools exist, who the agent is, what it may attempt, and how the whole interaction is audited across every system the work touches. That is what SAP's own FAQ calls a governance layer. In most estates the job already has an owner, the integration platform that makes SAP and everything else coexist today. If that platform is Integration Suite, the plane is Integration Suite, and that is a perfectly good answer. What the architecture should not do is let one vendor's edge become everyone's plane by default. One plane doesn't mean every call runs through one box, either. The plane sets the policy: the catalogue, the agent's identity, the limits and the audit record. Execution stays at each vendor's edge, and teams can still prototype in a sandbox. What goes live goes through the plane. SAP are better placed than most to get this right. Until they do, the answer is a governance layer. Not SAP's. ### **What to do now** None of this waits for SAP. 1. **Inventory** every agent, MCP server and service account that can reach SAP. 2. **Check the surface:** published, tolerated at your own risk, or prohibited. 3. **Place each interaction** at a vendor's edge or through your plane, with a named owner. 4. **Meet the bar before you argue about it:** identity that names the agent, limits, audit, and a catalogue of tools fixed at design time, which is how SAP bound their own Joule agents. 5. **Ask every vendor in writing,** your integration platform included: can our agent's identity live in our own identity provider and be federated into yours, as our people's identities are? If you do one thing, make it step 5. It's the question this whole argument comes down to. **What comes next** Next in the series: how MCP works, and why a gateway isn't enough. The policy reaches well beyond AI, so the series covers integration too. **Agents and AI** 1. How MCP works, and why a gateway isn't enough 2. Same job, different bar: the endorsed and permitted routes side by side 3. The permitted route is not a free pass 4. One plane, many edges **Integration** 1. ODP-RFC: the one thing SAP actually block, and the alternatives 2. Your custom interfaces under the policy: published, tolerated, prohibited 3. The clause 1.2 inventory: a practical guide If you're working through this in your own estate, I'm happy to compare notes. *Disclosure: Cloudorizon is an enterprise architecture company specialising in SAP Integration Suite and third-party integration platforms. Everything above is drawn from SAP's published API Policy, its FAQ (v1.3, June 2026) and SAP's Architecture Center; where it is my reading rather than SAP's words, I have said so.*           Blog Post ## Related Articles ### Check out our Insights into all things Workato, SAP and AI These articles will give you a flavour for our approach to making you the best you can be in terms of Integration and Automation. Check all articles CONNECT WITH CLOUDORIZON ### We move money from maintenance to momentum and prove it with a real result in production A Workato and SAP integration partner focused on one thing: turning integration from your biggest bottleneck into a capability your team owns. [CONTACT](http://www.cloudorizon.com/book-a-meeting-with-us) ### Start a conversation with our team today   [![logo-old](https://www.cloudorizon.com/hs-fs/hubfs/logo-old.png?width=292&height=55&name=logo-old.png "logo-old")](http://cloudorizon.com) #### We move money from maintenance to momentum and prove it with a real result in production A Workato and SAP integration partner focused on one thing: turning integration from your biggest bottleneck into a capability your team owns. > ##### [Click here to start a conversation with our team.](http://www.cloudorizon.com/book-a-meeting-with-us)   ### Pages - [Home](http://www.cloudorizon.com) - [Solutions](http://www.cloudorizon.com/solutions-at-cloudorizon) - [Case Studies](http://www.cloudorizon.com/case-studies-cloudorizon) - [About](http://www.cloudorizon.com/about-cloudorizon) - [Resources](http://www.cloudorizon.com/resources) - [Insights](http://www.cloudorizon.com/insights) - [Contact](http://www.cloudorizon.com/book-a-meeting-with-us) #### Insights - [The Four Decisions That Decide Your ESB Migration](http://www.cloudorizon.com/insights/the-four-decisions-that-decide-your-esb-migration) - [Stop Paying to Keep the Lights On](http://www.cloudorizon.com/insights/stop-paying-to-keep-the-lights-on) - [You Bought the Platform. Why Isn't It Delivering?](http://www.cloudorizon.com/insights/you-bought-the-platform.-why-isnt-it-delivering) - [It's Not a Moving Job. It's a Design Job](http://www.cloudorizon.com/insights/its-not-a-moving-job.-its-a-design-job) - [Onshore, Offshore, Hybrid - Choosing Without Trading Away Security](http://www.cloudorizon.com/insights/onshore-offshore-hybrid-choosing-without-trading-away-security) - [Before You Scale AI Agents, Govern the Ones You Can't See](http://www.cloudorizon.com/insights/before-you-scale-ai-agents-govern-the-ones-you-cant-see) - [SAP Without the Spaghetti](http://www.cloudorizon.com/insights/sap-without-the-spaghetti) #### Links - [SAP](https://www.sap.com) - [Workato](https://www.workato.com) - [Workato Documentation](https://docs.workato.com) - [Workato Academy](https://academy.workato.com) - [Resources](http://www.cloudorizon.com/resources) --- - [Terms and Services](http://www.cloudorizon.com/terms-and-conditions) - [Privacy Policy](http://www.cloudorizon.com/privacy-policy) Connect Online [Follow us on LinkedIn](https://www.linkedin.com/company/cloudorizon) ```json { "@context" : "https://schema.org", "@type" : "BlogPosting", "author" : { "@type" : "Person", "name" : "Lee Cunningham", "url" : "http://www.cloudorizon.com/insights/author/lee-cunningham" }, "dateModified" : "2026-10-06T17:10:53.237Z", "datePublished" : "2026-10-06T17:10:53.000Z", "headline" : "Every vendor needs an API policy. Not every architecture is fit for one.", "image" : [ "https://www.cloudorizon.com/hubfs/Blog%20Header%20Alternatives%20-%20API%20Policy-selection.png" ], "mainEntityOfPage" : { "@id" : "http://www.cloudorizon.com/insights/every-vendor-needs-an-api-policy.-not-every-architecture-is-fit-for-one", "@type" : "WebPage" }, "publisher" : { "@type" : "Organization", "logo" : { "@type" : "ImageObject" }, "name" : "Cloudorizon" } } ```