SAP Agentic AI Integration: A Policy-Compliant Architecture for External Agents and SAP APIs

SAP’s API policy draws one hard line: ungoverned, direct agentic access to SAP APIs is prohibited. A single AI prompt can trigger thousands of API calls in patterns that transactional systems were never designed to absorb. The policy’s answer is a mandatory governance layer — verified identity, OAuth-enforced authorization, rate limiting, and full audit logging on every call — interposed between any external agent and SAP’s API surface.

Three endorsed pathways exist, and they are complementary rather than mutually exclusive: the MCP Gateway on SAP Integration Suite for external AI agents needing SAP business process access; SAP-provided MCP Servers via Joule Studio for BTP-native agent development; and the Agent2Agent (A2A) protocol via SAP Agent Gateway for multi-agent orchestration across vendors. For large-scale analytical or bulk data access, a structurally separate pathway applies — SAP Business Data Cloud with Delta Sharing — and transactional APIs are explicitly prohibited for that use case.

For technology leaders at organizations running SAP in production, the immediate action is twofold: route all new agentic integrations through one of the three endorsed pathways, and audit existing integrations — particularly any dependency on ODP-RFC or other non-published SAP-internal interfaces — using ABAP ATC with Cloud Readiness Check before enforcement posture hardens.

Traditional integration patterns — scheduled batch jobs, event-driven OData subscriptions, iPaaS-mediated API calls — are deterministic and bounded. The call volume, timing, and payload structure are known at design time. Agentic AI systems operate differently: an orchestrating model issues chains of API calls in response to natural-language goals, with neither a human nor a hard-coded script controlling the cadence. A single user prompt to a well-resourced agent can fan out into thousands of downstream calls, targeting APIs whose rate limits and concurrency assumptions were set for conventional integration workloads.

SAP’s production landscapes — particularly S/4HANA Private Cloud and RISE deployments — carry transactional integrity requirements that make this risk acute. A rogue agent hammering a goods-movement BAPI or a payment-processing OData service does not merely degrade performance; it can corrupt financial postings, trigger duplicate document creation, or exhaust connection pool resources shared across mission-critical processes. SAP’s policy formalizes what enterprise architects have understood operationally: the agentic access pattern requires a categorically different governance approach, not just a stricter rate limit.

The June 2026 FAQ makes three scope clarifications that matter architecturally:

• Rule-based RPA is out of scope. Deterministic, script-driven robotic process automation is not classified as agentic AI under Section 2.2.2. It remains subject to general API controls but is not subject to the agentic-specific requirements. Architects should classify integrations correctly — misclassification in either direction creates compliance exposure.
• The policy covers the API consumption pattern, not the tool. A third-party iPaaS (Boomi, MuleSoft, and similar) consuming only published SAP APIs within documented rate limits is compliant. The tool is not the variable; the API surface and usage pattern are.
• RISE migration scope does not include integration remediation by default. SAP RISE covers infrastructure migration. Organizations with non-compliant integrations — particularly ODP-RFC dependencies — should not assume remediation is included in their RISE contract. This needs to be negotiated explicitly.

The Model Context Protocol Gateway, deployed on SAP Integration Suite, is the primary endorsed pathway for external AI agents that need access to SAP business APIs. It sits between the external agent and SAP’s published OData V4 and Business Accelerator Hub API surfaces, enforcing OAuth 2.0 / JWT authentication, rate limiting, and audit logging at the perimeter.

The governance properties that make this pathway viable for production are entirely managed by SAP: authentication flows, quota enforcement, and audit trail generation are platform-delivered rather than customer-implemented. This is the decisive difference from community or custom MCP server implementations, where those controls are the customer’s responsibility and where the MCP specification itself has documented gaps around authentication and session management.

SAP Note 3747787 specifically calls out supply chain risk in the MCP ecosystem — the Mini Shai-Hulud npm package incident is cited as a concrete example of how community MCP servers using static, long-lived credentials become attack vectors. The MCP Gateway mitigates this class of risk by design.

When to use it: Any external AI orchestrator (LangChain, AutoGen, AWS Bedrock Agents, or similar) that needs to invoke SAP business process APIs should route through MCP Gateway. This applies regardless of whether the orchestrator is customer-built or vendor-provided.

The Agent2Agent protocol, developed under Linux Foundation governance with SAP as a launch partner, addresses a different architectural problem: multi-agent orchestration where an external agent needs to delegate tasks to SAP-managed agents, or where SAP agents need to call out to agents in other vendor ecosystems. A2A defines a standard task-delegation and capability-discovery mechanism that allows agents to interoperate without tight coupling to each other’s internal implementation.

SAP Agent Gateway implements this protocol natively. The governance layer — identity verification, authorization, audit — is enforced at the gateway before any delegated task reaches SAP’s agent or API layer.

The Linux Foundation lineage matters for enterprise architecture decisions. A2A is not a proprietary SAP protocol; it is an open standard with multi-vendor participation. Basing multi-agent orchestration on A2A rather than a vendor-specific mechanism reduces lock-in risk and provides a more durable foundation as the agentic ecosystem matures.

When to use it: Cross-vendor multi-agent scenarios — where an external orchestrator (e.g., a Microsoft Copilot Studio agent or an AWS Bedrock multi-agent workflow) needs to delegate tasks to SAP-managed agents — are the primary use case. It is also the right pathway when SAP agents need to call out to agents in adjacent systems as part of a broader orchestrated workflow.

For organizations building AI agents natively on SAP BTP, Joule Studio provides a development environment with SAP-managed MCP servers already configured for policy-compliant API access. The MCP servers here are SAP-provided and production-ready; they are not community implementations. Identity management, credential rotation, and API surface scoping are handled by the platform.

This pathway is the lowest-friction option for BTP-native development, but it is not appropriate as the sole pathway for external agent connectivity. Joule Studio is an authoring environment for SAP-managed agents; external agents still need to reach those agents through the MCP Gateway or A2A Gateway, not directly.

When to use it: SAP-native agent development on BTP, where the development team wants production-grade MCP server implementations without building and maintaining that infrastructure themselves.

The policy enforces a hard architectural boundary between two data access patterns that are frequently conflated:

SAP Business Data Cloud with Delta Sharing is the only endorsed pathway for feeding large-scale SAP data to external analytical platforms — Databricks, Snowflake, Microsoft Fabric, Google BigQuery, and similar. Delta Sharing is an open protocol; it supports the full breadth of target platforms without requiring a proprietary connector per destination.

SLT Replication Server feeds BDC for change-data-capture scenarios. The key architectural constraint is that replication and bulk extraction must stay on the BDC/Delta Sharing path — attempts to extract at volume through transactional OData APIs are prohibited under Section 2.2.2 of the policy, and ODP-RFC interfaces are explicitly prohibited regardless of volume.

The prohibition on “custom API as bypass” — building a Z-namespace OData or REST service that internally calls a prohibited BAPI or RFC and then exposing that to an agent — is an important detail. The policy targets the consumption pattern and the underlying interface, not just the surface protocol. Pattern-based monitoring in SAP’s cloud operations will flag this approach.

Every endorsed pathway converges on a shared set of identity and security requirements:

• Verifiable digital identity per agent. Each agent — not each application, each agent instance — must carry a distinct, verifiable identity. Shared credentials across agent instances are not acceptable under the policy.
• OAuth 2.0 / JWT. The authentication mechanism is specified. Static API keys and basic authentication are not compliant for agentic scenarios.
• Rate limiting enforced at the governance layer. Rate limits are not advisory; they are enforced controls at the gateway, not something agents are expected to self-regulate.
• Full audit logging. Every API call made by an agent must be traceable to a specific agent identity, timestamp, and invoked resource. This is non-negotiable for regulated industries and is a baseline policy requirement.

These controls are delivered out of the box by MCP Gateway and A2A Gateway. Custom MCP server implementations must deliver them through customer-built infrastructure — which is both an engineering cost and an ongoing compliance liability.

flowchart TD
    classDef external fill:#fff3e0,stroke:#e65100
    classDef governance fill:#e8f5e9,stroke:#2e7d32
    classDef sap fill:#e3f2fd,stroke:#1565c0
    classDef data fill:#f3e5f5,stroke:#6a1b9a

    subgraph EXTERNAL["External AI Ecosystem (Customer Choice)"]
        A1["Third-Party AI Orchestrator<br>(LangChain, AutoGen, AWS Bedrock, etc.)"]
        A2["External MCP Client / Agent"]
        A3["Third-Party iPaaS<br>(Boomi, MuleSoft, etc.)"]
    end

    subgraph GOVERNANCE["Governance Layer (SAP-Endorsed — MANDATORY)"]
        G1["MCP Gateway<br>on SAP Integration Suite"]
        G2["SAP Agent Gateway<br>(A2A Protocol)"]
        G3["Joule Studio<br>SAP-Managed MCP Servers"]
    end

    subgraph IDENTITY["Identity & Security Controls"]
        I1["Verifiable Digital Identity<br>per Agent"]
        I2["OAuth 2.0 / JWT Auth"]
        I3["Rate Limiting &<br>Audit Logging"]
    end

    subgraph SAP_APIS["SAP Published API Surface"]
        S1["OData V4 Services"]
        S2["SAP Business Accelerator Hub APIs"]
        S3["Analytical CDS Views"]
    end

    subgraph SAP_SYSTEMS["SAP Backend Systems"]
        B1["S/4HANA<br>(Private Cloud / RISE)"]
        B2["SAP LoB Solutions<br>(Ariba, SuccessFactors, etc.)"]
    end

    subgraph DATA["Large-Scale Data Access<br>(Separate Endorsed Path)"]
        D1["SAP Business Data Cloud<br>(BDC)"]
        D2["Delta Sharing Protocol<br>(Open Standard)"]
        D3["SLT Replication Server"]
        D4["Target Platforms<br>(Databricks, Snowflake, Fabric, BigQuery)"]
    end

    A1 -->|"A2A Protocol"| G2
    A2 -->|"MCP Protocol"| G1
    A3 -->|"Published APIs only"| G1

    G1 --- I1
    G1 --- I2
    G1 --- I3
    G2 --- I1
    G2 --- I2
    G2 --- I3
    G3 --- I1

    G1 --> S1
    G1 --> S2
    G2 --> G3
    G3 --> S2
    G3 --> S3

    S1 --> B1
    S2 --> B1
    S2 --> B2
    S3 --> B1

    B1 --> D1
    D1 --> D2
    D3 --> D1
    D2 --> D4

    class A1,A2,A3 external
    class G1,G2,G3 governance
    class S1,S2,S3,B1,B2 sap
    class D1,D2,D3,D4 data

flowchart TD
    classDef decision fill:#fff9c4,stroke:#f9a825
    classDef endpoint fill:#e8f5e9,stroke:#2e7d32
    classDef prohibited fill:#ffebee,stroke:#c62828

    START(["New Integration or Agent Use Case"])

    Q1{"Is it rule-based<br>deterministic RPA?"}
    Q2{"Is the goal bulk /<br>analytical data access?"}
    Q3{"Building natively<br>on SAP BTP?"}
    Q4{"Multi-agent orchestration<br>or cross-vendor delegation?"}
    Q5{"Consuming only<br>published APIs within<br>rate limits?"}

    E1["General API controls apply<br>Section 2.2.2 does not apply<br>RPA tooling unchanged"]
    E2["SAP Business Data Cloud<br>+ Delta Sharing<br>SLT for CDC"]
    E3["Joule Studio<br>SAP-provided MCP Servers<br>BTP-native agents"]
    E4["SAP Agent Gateway<br>A2A Protocol<br>Multi-vendor orchestration"]
    E5["MCP Gateway<br>on SAP Integration Suite<br>OAuth / rate limit / audit enforced"]
    E6["Third-party iPaaS allowed<br>MCP Gateway still required<br>for SAP API surface"]
    STOP["Non-compliant path<br>Remediation required<br>before production"]

    START --> Q1
    Q1 -->|"Yes"| E1
    Q1 -->|"No — agentic AI"| Q2
    Q2 -->|"Yes"| E2
    Q2 -->|"No — transactional"| Q3
    Q3 -->|"Yes"| E3
    Q3 -->|"No — external agent"| Q4
    Q4 -->|"Yes"| E4
    Q4 -->|"No — single agent"| Q5
    Q5 -->|"Yes — iPaaS"| E6
    Q5 -->|"No — ODP-RFC / direct"| STOP

    class Q1,Q2,Q3,Q4,Q5 decision
    class E1,E2,E3,E4,E5,E6 endpoint
    class STOP prohibited

1. Audit existing integrations before enforcement posture hardens. Run ABAP ATC with Cloud Readiness Check across all custom integrations. Any dependency on ODP-RFC, non-published RFCs, or BAPIs called directly from external systems is a compliance liability today, not a future risk. Prioritize interfaces touching financial postings, procurement, and HR — these carry both data integrity risk and regulatory exposure.

2. Establish MCP Gateway as the organizational default for all new agentic integrations. Do not allow teams to stand up community MCP servers pointing at SAP APIs. The engineering cost of building equivalent governance controls from scratch — OAuth flows, per-agent identity, audit logging, rate limiting — exceeds the cost of MCP Gateway adoption, and the compliance risk of getting it wrong is material. Set this as an architectural standard before the first production agentic workload goes live.

3. Negotiate RISE remediation scope explicitly. If the organization is mid-migration on RISE, integration remediation is not included by default. Surface this with SAP and negotiate scope now. The alternative is arriving at a RISE-migrated landscape with a non-compliant integration footprint and no contractual path to remediate it under the existing agreement.

The A2A protocol deserves investment attention beyond its immediate use cases. As an open Linux Foundation standard with SAP as a launch partner, it is likely to become the durable interoperability mechanism for enterprise multi-agent systems — analogous to what OAuth 2.0 became for human-facing authorization. Architectures that are designed around A2A from the outset will adapt more cleanly to the agent ecosystem’s evolution than those built on proprietary delegation mechanisms.

Similarly, the transactional/analytical split the policy enforces is not purely a compliance constraint — it reflects a sound architectural principle. Transactional APIs are not data warehousing APIs. Organizations that have historically blurred this boundary (using OData extracts for reporting, for example) have accumulated technical debt that the policy now forces them to resolve. The BDC / Delta Sharing pathway is the correct long-term architecture for SAP data in analytical platforms, regardless of the policy mandate.

The policy’s treatment of RISE deserves a dedicated note. RISE is an infrastructure and managed services contract. It does not transform SAP into the responsible party for a customer’s integration landscape. The integration governance burden — pathway selection, identity management, rate limit configuration, audit log retention — remains with the customer. RISE may simplify infrastructure operations, but it does not simplify integration compliance. Organizations that have assumed otherwise should recalibrate that assumption before their next audit cycle.

SAP’s June 2026 API policy is not primarily a restriction — it is an architecture specification. It describes, with unusual precision, the infrastructure required to make agentic AI integration with SAP production-safe: a mandatory governance layer, three clearly scoped endorsed pathways, a hard split between transactional and analytical access, and explicit prohibition of the bypass patterns that have historically accumulated as technical debt.

The organizations that will navigate this well are those that treat the policy as an architecture blueprint rather than a compliance checklist. MCP Gateway as the default entry point for external agents, A2A as the foundation for multi-agent orchestration, BDC and Delta Sharing as the canonical path for analytical data, and a clean audit of the existing integration estate — these are the structural moves. Done in that order, they produce a landscape that is both policy-compliant and architecturally sound for the agentic AI workloads that are already moving from proof-of-concept to production.