SAP's New API Policy Isn't Lock-In. It's the First Honest Architecture Spec for Agents on ERP.

SAP's API Policy v.4.2026a is being called lock-in. The framing is wrong. SAP is the first major ERP vendor to write down the architecture spec for agents on a system of record, and the customers fighting the policy will spend eighteen months building the wrong thing.

What Section 2.2.2 Actually Says

The clause that started the controversy is short. From the published policy document:

Except through and within the limits of SAP-endorsed architectures, data services, or service-specific pathways expressly identified and intended for such purposes, SAP prohibits API use for: (a) interaction or integration with (semi-)autonomous or generative AI systems that plan, select, or execute sequences of API calls, and (b) scraping, harvesting, or systematic and/or large-scale data extraction or replication.

Two clauses. The first restricts AI agents from planning, selecting, or executing sequences of SAP API calls outside endorsed pathways. The second restricts large-scale, systematic, or replicated data extraction outside endorsed pathways. The endorsed pathways operationally are Joule, Business Data Cloud, the Agent Gateway, and APIs catalogued in the SAP Business Accelerator Hub.

Two clauses, one architectural argument. An agent that orchestrates SAP API calls is not the same operational primitive as a human user filling out a Fiori form, and SAP is not going to pretend it is.

That argument is correct.

The Lock-In Critique Misreads the Threat Model

The dominant industry response, captured by The Register, CIO's coverage of the DSAG response, and most of the LinkedIn commentary, is that SAP is locking customers out of choice. That argument treats agentic AI as a normal API consumer with novel authorship. It is not. Agentic AI is a different threat model.

The threat model has four properties that a human-driven OData consumer never had.

First, autonomous tool use. An agent decides which API to call next based on a model output. The OAuth scope you granted at design time is the upper bound, not the actual call volume or call shape. A misaligned plan loop or a prompt injection routes against your full scope at machine speed.

Second, replay risk. An agent that misclassifies an exception can post the same correction across hundreds of records before a human sees a single ticket. The transactional system has no idea this is a model output. To the system of record, the writes look like every other write.

Third, lineage gaps. The journal entry shows up. The model output that produced it lives somewhere else, possibly in a vendor cloud, possibly in a Slack thread, possibly nowhere durable. The audit trail has a hole that no SOX-controlled environment can absorb.

Fourth, mass egress. A general-purpose agent given a "summarize last quarter" prompt can pull thousands of customer records into a foundation-model context window in seconds. The data leaves your tenant boundary as a side effect of a question. There is no scraping intent. There is also no audit log that tells you it happened.

These are not theoretical. They are the same threat patterns that have shown up in public agent incidents over the last twelve months, from prompt-injection vectors in production AI assistants to over-permissioned automation pipelines that exfiltrated data the user never intended to share. SAP runs the system of record for global GL, accounts payable, payroll, and inventory at over 400,000 customers. A policy that treats AI agents the same as a user typing into Fiori is a policy that is wrong.

The lock-in critique pretends the threat does not exist. It does. The right question is not whether SAP should restrict agent traffic. It is what the restriction architecture should look like.

Data Ownership Is Not the Right Fight

The other complaint making the rounds is that the policy violates customer data ownership. Kai Waehner's piece frames it cleanly: extract data into a layer you control, keep it current, let agents consume from there. The technical recommendation, which is CDC into a streaming layer like Kafka with agents reading from a downstream data product, is sound. The ownership framing is a category error.

Customers own their data. SAP has stated this in writing across the AI Terms, the customer contract, and the data processing addendum. Nothing in v.4.2026a changes that. What customers do not own is SAP's API surface. The API is SAP's product. Every API vendor in enterprise software has acceptable use restrictions on it. Salesforce restricts mass-sync clients. Microsoft Graph throttles bulk crawlers. Stripe blocks specific automation patterns. AWS publishes service-specific restrictions on every major service. Writing usage rules for an API is not a property claim on the data flowing through it. It is a contract about how the API can be used.

The interesting boundary is not data ownership. It is the line between data egress, which is allowed through CDC, replication, and supported export, and agent execution, which is restricted until the agent runs through an endorsed control plane. Customers are free to take their data anywhere they like. They are not free to point an autonomous tool-use loop at a production financial system through whatever credentials happen to be on hand.

That is not a property dispute. That is a runtime control boundary. SAP wrote down where the boundary sits. Most of the industry has not caught up to the fact that the boundary needs to exist at all.

The Architecture SAP Just Sketched

Read v.4.2026a as a control plane spec rather than a policy document and the shape of what every enterprise needs to build comes into focus. There are four pieces.

Non-human identity for agents. Every agent that touches the system of record runs under a service principal with a model version, not a human user account. The principal has its own scoped permissions. Every action the agent takes is attributable to that principal, not to the human who provisioned it. NIST's CAISI work on agent identity is converging on the same primitive.

Allow-listed tool surfaces. Agents do not get to plan over the full API catalog. They get a curated list of tool functions that wrap specific business operations, each one parameterized and validated, each one logged. The agent calls suggest_journal_entry, not POST /odata/v4/journals. The wrapping function enforces preconditions, captures the model output as part of the call, and produces a single audit event the controllership can reason about.

Lineage and audit at the call site. Every agent action carries the model identifier, the input snapshot, the output, the confidence score, the prompt or feature vector, and the human reviewer who acted on it. That bundle persists for the same retention window as the underlying business record. PCAOB AS 1105 evidence requirements get satisfied at the transaction layer rather than reconstructed from a vendor log shipped weeks later.

Segregation of duties on writes. Agents create. Humans post. The service principal under which the agent runs has create-only rights on the financial object. The posting credential lives with a named human in a different role. The auditor sees the same SoD walkthrough they have always seen, and the agent does not break ICFR by inheriting a user's full permissions.

These four pieces are what a competent enterprise was going to need anyway. Joule plus Business Data Cloud plus Agent Gateway delivers about eighty percent of the scaffolding for the SAP estate. The remaining twenty percent is internal: identity provisioning, the function library, the audit pipeline, the workflow approvals. The policy makes the scaffolding non-optional.

If the policy did not exist, the typical agent integration would route agent traffic through a human user's OAuth token because that is what the developer documentation example uses on day one. That deployment passes a demo. It fails the second SOC 1 walkthrough. Multiply across two hundred deployments and you have the controls failure that SAP, as the runtime for global GL, cannot afford to host.

Where SAP Got This Wrong

Defending the architectural direction is not the same as defending the rollout. SAP's execution on v.4.2026a is poor, and the DSAG criticisms are valid.

The phrase "SAP-endorsed architectures" is not defined as a contract artifact in the policy itself. Customers are being told what they cannot do without a referenceable list of what they can do. DSAG board chair Jens Hungershausen put it plainly: "The unclear formulation of the policy creates uncertainty on the customer side. If you're uncertain, you probably won't do anything about it." That is exactly the wrong outcome for the customer base SAP is trying to move into agentic workloads.

There is no published grace period. Existing integrations that operate today through patterns the policy now restricts have no written grandfathering. The operational guidance is "remediate at your next maintenance cycle," which is not a transition plan. It is a deferral.

Pricing for endorsed pathways has not been published transparently. Customers asked to migrate from a custom integration to Joule, Business Data Cloud, or Agent Gateway have no firm view of what the migration costs over a five-year horizon. The migration ask without the cost number is a difficult board conversation.

Stefan Nogly of the DSAG technology board asked for one specific fix that should be uncontroversial: "Protection for already existing and SAP-tolerated integrations is important and should be recorded in the API Policy." That is a clean ask, and SAP should adopt it within the next minor version of the document.

The architecture spec is right. The rollout is rushed, under-defined, and pricing-opaque. The criticism that lands is the criticism of the document and the migration path, not the criticism of the policy direction. SAP can fix the rollout. The customers building agent control planes around a misread of the policy direction cannot fix the eighteen months of misallocated work as easily.

What Happens at the Other ERP Vendors

The forecast in this post is a single claim. Every major ERP vendor will publish a near-identical clause within the next eighteen months.

Right now, the picture looks the other way. Oracle's 26A release opened REST API access to AI Agent Studio for external callers. Workday's first-half 2026 roadmap is to host third-party agents inside the platform rather than block them. Microsoft Dynamics 365 Finance and Operations publishes service-protection rate limits but no AI-specific prohibition. SAP is alone on the v.4.2026a clause as of May 2026.

That changes. The threat model is universal. Every transactional system of record sits inside the same SOX, GDPR, and audit perimeter. Every one of those vendors carries the same liability when an agent integration causes a controls failure at a flagship customer. Right now the other three are betting on a permissive posture as a competitive differentiator against SAP. The first agent-driven controls incident at an Oracle Fusion or Workday flagship customer ends that bet. The clauses will arrive, written by the same lawyers who wrote SAP's, with the same scope, on a faster timeline because the precedent will be established.

The buyer's job today is to architect for what is true across vendors in eighteen months, not what is competitive talking-point true today. Building an agent strategy on the assumption that any single ERP vendor will permanently allow free third-party agent access is a roadmap with a sunset clause that the vendor has not told you about yet.

What to Build Now

The buyer action list is short and runs in parallel with the policy debate.

Build the agent control plane as a first-class internal platform. Service principals for non-human identity, an internal tool function library that wraps approved operations, lineage capture at the call site, and SoD enforcement on writes. The control plane is vendor-portable. The same identity, function, and lineage layer works against SAP's endorsed pathways, Oracle's REST APIs, and whatever clauses Workday and Microsoft publish next. Vendor-specific connectors plug into the bottom of the control plane. The plane itself is yours.

Inventory your existing agent integrations against the v.4.2026a clause text. Anything that has an autonomous loop, multi-step planning, or large-scale extraction outside an endorsed pathway is in scope. Some of those integrations route through the endorsed pathway with a configuration change. Some need to be rebuilt. The inventory is six to ten engineering days. Skipping it is the expensive choice.

Push your account team for clarity on the endorsed pathway list and pricing in writing. The DSAG criticism opens the door for procurement leverage. The pathway list and the pricing are reasonable contractual asks. SAP needs the migrations to happen smoothly more than it needs the policy to remain ambiguous.

Stream a governed copy of the data you need for agent-facing analytics into a layer you control, through CDC or batch ETL on the supported data export pathways. This is the Kai Waehner recommendation, and it is right for the read-side use cases. Agents that read summarized governance-cleared data from your downstream copy do not run through the policy at all. Reserve agent calls into the SAP system of record for the writes that actually need to land there.

Brief your audit committee on the policy and the architecture response in plain language. The committee does not need a v.4.2026a deep read. It needs to know that the agent traffic on the financial system runs through a control plane with the same shape as the human-traffic SoD model, and that the lineage is captured for the SOX retention window. That conversation is forty minutes. Skipping it is the conversation that becomes a 10-Q footnote.

The Gate, Not the Brake

The framing that lands on every conversation about enterprise AI right now is the same framing that landed on AI in finance: vendor risk, controls gap, lineage missing, audit trail incomplete. The vendors that write down the architecture first do not turn out to be the brakes on adoption. They turn out to be the gates. The gate opens when the controls show up.

SAP wrote down the controls. The lock-in story is going to age badly. The architecture spec is the durable artifact. Build to it. The customers who do are going to ship the next eighteen months of agent capabilities cleanly. The customers who treat the policy as a fight rather than a spec are going to ship slower, against an architecture they will rebuild anyway, with a worse audit story when they do.

Be bold on the agent capability. Be disciplined on the control plane. The two are not in tension. They have never been in tension. SAP just made the spec for the discipline non-optional, ahead of an industry that was about to need one.

If you are building an agent control plane against your ERP and want a second pair of eyes on the architecture before it goes to your CIO or audit committee, reach out. The next eighteen months are the design window.

Shubhendu Tripathi is an AI and ERP strategy consultant based in Toronto, advising organizations on digital transformation, enterprise AI adoption, and technology leadership. Connect on LinkedIn or reach out at tripathis@qubittron.com.