Your vendor’s API policy may forbid your AI agent

Here is a failure mode with nothing to do with whether the technology works. You scope an agent, you build it, you test it, it does the job — and the vendor whose system it talks to has a clause saying you may not do that. No error, no rate limit, no technical signal of any kind. Just a term in a policy document nobody on the project read, because API policies are not where anyone looks for architecture constraints.

SAP has published one of the clearest examples we have seen. It is worth reading in full, because the wording is unusually specific about agents.

The clause

From the SAP API Policy, section 2.2.2, quoted in full:

“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.”

Read clause (a) slowly, because it describes an agent with precision rather than by accident. “(semi-) autonomous or generative AI systems that plan, select, or execute sequences of API calls” is not a vague gesture at AI. Planning and executing a sequence of API calls is the definition of the thing everyone is currently building. An agent that reads an order, checks stock and updates a record is three calls in a planned sequence, and that is what this clause is about.

This is an AI-specific term, not a general one. The clause immediately above it, 2.2.1, is the ordinary catch-all — no competitive analysis, no undocumented use, nothing that risks performance or security. Section 2.2.2 was written separately, for this. That distinction matters if someone tells you it is boilerplate.

It is a permission structure, not a ban

The clause does not say agents may never touch SAP. It says they may, “through and within the limits of SAP-endorsed architectures, data services, or service-specific pathways expressly identified and intended for such purposes.”

So the question for your project is not “is this allowed?” but “which pathway is endorsed, and is our design using it?” That has a specific answer your SAP account team can give you, and it is far cheaper to ask before the build than after. Note the clause itself names no products — it stays generic about what counts as endorsed, which means the answer is something you obtain rather than something you can look up.

The policy also closes off the obvious workarounds, in section 3:

“Customers, partners, and third parties must not bypass, disable, or otherwise circumvent API Controls, including through intermediary services, custom code or developments, proxies, gateways, impersonation techniques, or similar mechanisms.”

That sentence anticipates the engineering answer. Putting a service in front of the API so the calls do not look agentic is named. So is a proxy, so is a gateway, so is custom code written for the purpose. If your mitigation is “we will make it look like a normal integration,” that plan is already described in the document you would be breaching.

Why this is a governance problem, not an engineering one

Because nothing fails. An agent operating outside an endorsed pathway does not get blocked; it works, it passes testing, it goes live, and the exposure accrues quietly. The discovery event is commercial — a renewal, an audit, a licensing conversation — and by then the thing is load-bearing in your operations and expensive to unwind.

That is the same shape as everything else we write about here: the risk is not that the technology breaks, it is that a decision got made by default because nobody owned it — the pattern behind the AI decisions your company is making by default. The control that would catch this one is the same control we argued for in your AI agents need a manager, not just an API key: something that evaluates what the agent is about to do, before it does it. And it lands in a specific gap. Deloitte’s August 2026 readiness survey found that only 5% of organisations say their business processes are highly prepared for AI agents — the lowest-scoring of the six readiness dimensions it measured, below data, below security and governance, below workforce.

Put that beside RSM’s middle-market survey from July 2026, which found 86% of organisations have partially or fully integrated AI into their operations while only 36% have it fully embedded across core processes. Most of the mid-market has started. Far fewer have reached the process layer — which is exactly where contractual questions like this one live.

What to actually do

1. Read the API policy of every system your agent will touch, before you design the integration. Not the developer documentation — the policy or terms document. It is shorter, and it is the one that constrains you.
2. Ask the vendor, in writing, which pathway is endorsed for agentic access. Where a clause turns on what the vendor has endorsed, the only reliable source is the vendor. Get the answer in an email you can find again.
3. Treat “can we route around it?” as a red flag, not a solution. If the design only works by making agentic access look like something else, you have found a commercial problem wearing an engineering costume.
4. Assume other vendors follow. SAP is early and unusually explicit. The same question applies to any system an agent reaches over the network — which is the other half of the exposure we wrote about when agents get put on the public internet. It would be strange if it stayed alone, and the same question is worth asking of every major system you depend on.

Two honest caveats

We are not your lawyers and this is not legal advice. It is a pointer to a clause in a document you are probably already party to, so that somebody at your company reads it before the architecture is finished.

And on dates: the version we read carries the footer SAP API Policy v.4.2026a. The document states no effective date in its body, so we are not asserting one — if the date matters to a contractual position, get it from SAP’s own release notes rather than from us. What we can say is that the clause is in the current published policy, and that we read it there ourselves rather than in anyone’s summary of it.