SAP's API Policy v4/2026 is the document every SAP+AI architecture now has to answer to. It is short, but its implications are not obvious. Here is what it actually says, in plain English.
The core rule
Agents must not orchestrate raw SAP API calls directly. Instead, agent traffic should route through SAP-endorsed pathways: Joule, Business Data Cloud, the Agent Gateway, or an MCP server that wraps a Published API.
In practice, an agent should not be handed a generic OData client and told to go. It should be handed a constrained tool that only does what the business approved.
What counts as on-policy
- Consuming a Published API from the SAP Business Accelerator Hub.
- Routing agent calls through an MCP server that wraps those Published APIs.
- Using Joule or the Agent Gateway as the sanctioned orchestration layer.
What is off-policy
- Scraping or reverse-engineering undocumented SAP endpoints.
- Letting an agent call raw OData with no guardrail, no audit, no scope.
- Building a bespoke integration that bypasses the approved pathway.
What this means for sapctl
sapctl is deterministic automation that consumes only Published APIs. It does not orchestrate generative AI calls. Instead, it emits MCP servers and A2A Agent Cards so agent traffic routes through the sanctioned surface. Every call still writes to the signed audit chain.
The result: an agent gets a constrained, auditable tool surface, exactly what the policy asks for and exactly what a regulated buyer needs to demonstrate.
What this buys you
The policy is not anti-agent. It is pro-guardrail. The teams that win are the ones that give agents a narrow, auditable, on-policy tool surface, not a raw API client.