For years, "can we connect this to SAP?" was a technical question. In 2026 it also became a policy question. SAP's updated API policy adds explicit governance for AI and agent traffic, and it changes how any agent, whether built in n8n, Camunda, Spring AI or a vendor product, should reach SAP S/4HANA®.
This article explains what the policy says, where the line actually falls, and a design pattern that keeps both workflows and agents on the right side of it.
What the policy says, in plain terms
SAP's reasoning is straightforward. Agent and bot traffic against SAP systems has grown fast, legacy interfaces were never designed for it, and AI tooling brings new security risks. So the policy sorts access by documentation.
Published APIs used as documented are the officially supported, lowest-risk path. Undocumented interfaces are used at the customer's own risk and were never meant for mass data extraction or AI consumption. Agents must not be used to get around rate limits or other controls. Third-party MCP servers are allowed, but the customer carries the security and integration burden, and SAP steers customers towards its managed options.
Just as important is what does not change. According to ASUG's summary of SAP's guidance, clean core extensions, custom code in the Z and Y namespaces, and published APIs used as documented are unaffected, and existing production integrations get monitoring and outreach before any hard enforcement.
The line that matters: who chooses the call
The most useful way to read the policy is to ask one question about every SAP call: who decided to make it?
| Deterministic workflow step | Agent-driven call | |
|---|---|---|
| Who picks the call | The developer, at design time | The model, at runtime |
| Example | Read purchase order 4500018233, post the confirmation, write the log | "Find out why these ten invoices are unpaid" |
| Payload | Fixed and known | Varies per question |
| Policy view | A documented integration, like any other | Should go through SAP's endorsed pathways |
A fixed workflow step in n8n or a service task in Camunda that calls a released OData API is an integration. It behaves the same way on every run, it can be tested, and it is what SAP has always supported.
An AI agent that plans, selects or executes SAP calls on its own is a different category. That is the traffic the policy wants routed through managed gateways.
The endorsed pathways for agents
SAP names a small number of routes for agent access.
The MCP Gateway in SAP Integration Suite turns existing APIs, integrations and data sources into tools that agents can discover, with scoped credentials per agent. It ships with the Enhanced and Premium editions of Integration Suite, and its rollout to production data centres began in July 2026, starting with AWS and Azure.
Agent-to-agent (A2A) into Joule agents is SAP's preferred route when your agent needs something SAP's own agents already do. A dedicated Agent Gateway for this route has been announced without a date.
SAP Business Data Cloud is the path for data extraction for analytics and AI training, rather than pulling large volumes through transactional APIs.
Alongside this, SAP's May 2026 investment in n8n and the plan to build n8n into Joule Studio point to a future where n8n workflows run inside SAP's own agent environment, with these pathways close at hand.
What is not aligned
The pattern to avoid is an LLM that calls SAP production APIs directly and decides which calls to make. That includes an "agent tool" node in any workflow tool, n8n included, pointed straight at a production S/4HANA system with a technical user. However good the prompt, the agent is choosing its own calls against production, outside a governed route.
The same agent tooling is perfectly reasonable against a sandbox, a mock service or a test system while you build and evaluate. The production path is what has to change.
What this means for n8n workflows
For most n8n work around SAP, very little changes. A workflow that picks up a supplier PDF, extracts the items, reads the purchase order via OData, compares the values and writes back an approved confirmation is a sequence of documented API calls. Build it on released APIs from the SAP Business Accelerator Hub and you are on the supported path.
What needs care is the agent part. If an n8n AI Agent node needs SAP data in production, give it read-only tools that go through the MCP Gateway, scope them per agent, and leave the writing to the workflow.
What this means for Camunda and BPM engines
BPMN-orchestrated processes already separate decisions from actions. Service tasks call released APIs; DMN tables decide; user tasks capture approvals. Adding an AI agent inside a BPMN process fits the policy well, provided the agent's SAP access goes through an endorsed pathway and its output feeds a decision the process controls, rather than a write the agent performs itself.
A pattern that holds up: agent reads, workflow writes
Take cash application. A payment arrives that SAP's automatic matching could not clear: a bulk payment, a central settlement, a deduction by a large retail customer, or a transposed digit.
An agent is useful here because the question is open. It looks at open items, the business partner, the remittance advice and the payment history, using read-only tools through the MCP Gateway. It returns a proposed match with its reasoning.
From there, the workflow takes over. Rules check amounts, tolerances and discounts against SAP data. A person confirms the match in a review step. Only then does the workflow post the clearing through a released API, logging the approver, the agent's reasoning and the before and after values.
The agent decides what to look at next. It never decides what gets booked. That split is what keeps the design aligned with the policy, and it is also what makes it auditable.
A short checklist before your next agent touches SAP
Is every write a released API called by a fixed workflow step? If an agent writes directly, redesign.
Do agents reach production SAP through an endorsed pathway? MCP Gateway or A2A, not a direct technical user.
Are agent tools read-only by default and scoped per agent? Write tools, if any, sit behind human approval.
Do decisions run on SAP data rather than model opinion? The model proposes; rules and people decide.
Is there an evaluation set? Every AI step should be tested against cases with known answers before go-live.
Is everything logged? Approver, timestamp, agent reasoning, rule version, before and after values.
One deadline worth checking now
The policy also tightens one older interface. ODP-RFC is currently the only interface on SAP's unpermitted list, with an opt-out deadline of 31 December 2026, after which the restriction becomes permanent. ODP over OData remains a valid alternative. If any of your data extraction, including tools that feed AI or analytics, relies on ODP-RFC, SAP Note 3439624 provides a self-assessment, and the ABAP Test Cockpit and Cloud Readiness Check can scan custom code for dependencies on non-published interfaces.
The bottom line
SAP is not closing the door on agents. It is putting a front door in front of them. Workflows that call released APIs carry on as before. Agents need to come in through the gateway, read before they act, and leave the booking to a governed workflow with a person on the exceptions.
That is how we build n8n workflows and agents for SAP, and how we place AI agents inside BPMN processes. If you are deciding which tool should own which part, start with n8n vs Camunda vs SAP Integration Suite vs RPA.
Source for the policy details: ASUG, SAP API Policy Overview: API Availability, Agentic AI Architectures and Impacts on Existing Integrations. Always confirm specifics against SAP's current policy documents for your contract.
Planning AI agents on top of S/4HANA? Book a free Agentic Readiness Audit. We'll check your current and planned SAP access against the policy and show you an architecture that holds up.