Lesson 4 of 6
Security and traffic management
10 min
Listen to this lesson
An MCP server is an API that a model drives. The model can loop, retry, misread a description or be steered by text injected into the data it reads. The security design therefore has two jobs: decide who the call runs as and what that identity may do, and limit how much any agent can do, however it behaves. Nadia, Contoso's security and GRC lead, owns both questions for the agent pilot.
Authentication and authorization policies
Every MCP server in Integration Suite gets an Authentication policy and an Authorization policy by default. They are mandatory and cannot be deleted, and the Authentication policy must be the first policy in the request flow. Only OAuth-based authentication is supported, with tokens from the default XSUAA or from an external OIDC-compliant identity provider (External OAuth). When the server is built from an API artifact, the Authentication policy is inherited from that API artifact and is read-only; the Authorization policy stays editable. If the source API artifact has its own Authorization policy, SAP recommends enabling Trust Upstream MCP Authorization there to avoid checking twice.
Authorization can check OAuth scopes (for example the API.invoke role for user-token access, which needs a custom role collection because there is no default one) or a developer key. With shadow users, individual role assignments are not available, so SAP points to Developer Key or OAuth Scope OR Developer Key instead.
Who does the call run as?
| Model | How it works | Fits | Watch out for |
|---|---|---|---|
| Technical user token | The agent gets a token with a technical user's client credentials; every call runs with that user's permissions | Background agents and machine-to-machine jobs where no person is in the loop | One identity for all users: the audit trail shows the agent, not the person; keep its rights narrow |
| IdP user token | The agent obtains a token for the signed-in user via OAuth Authorization Code; calls run with that user's permissions | Interactive assistants and copilots, and any write tool | The user must exist in the IdP; some IdPs need extra setup (SAP notes a limitation for Microsoft Entra ID and Auth0) |
Two access models documented by SAP for MCP servers (October 2026).
User tokens can come from default authentication (XSUAA), where the user must exist in the identity provider trusted by the subaccount, or from an external identity provider: SAP lists SAP Cloud Identity Services (IAS), Okta, Auth0 and Microsoft Entra ID. You register the agent's redirect URI with the OAuth application, for example the callback that SAP's documentation shows for Claude Desktop. With PKCE enabled on a public client, the agent needs no client secret.
Principal propagation closes the loop: S/4HANA checks Maria's own authorizations, not a shared technical user's. SAP's What's New lists principal propagation for on-premise MCP server flows as generally available since July 26, 2026, and as an authentication type for on-premise API artifacts from October 18, 2026. The OAuth2SAMLBearerAssertion destination type is listed among supported authentications for HTTP-endpoint and remote MCP sources. Earlier slides showed both as roadmap, so check What's New for the exact scope in your tenant before you rely on them.
Traffic management
Three traffic policies are supported on MCP servers:
- Quota limits the total number of requests an application can make over a period, such as 2,000 per day. When it is reached, calls are rejected with HTTP 429 until the window resets.
- Surge Protection smooths spikes in real time, independent of the client: SAP's own example limits an agent to 4 calls every 10 seconds. The interval must be between 200 milliseconds and 10 seconds; excess calls get HTTP 429.
- IP Filter allows or denies calls from IP addresses or ranges, for example only Contoso's network and its agent platform.
Payload limits come from the source API artifact: JSON and XML threat protection policies on API artifacts cap payloads at 10,000 KB. Agents can also be fooled by content they read, so keep write tools out of servers that read free text from external parties, and keep human approval where the business already requires it.
- Does a person start the request and see the answer?Yes → IdP user token · No → technical user token with minimal rights
- Can the tool change data?Yes → user token and principal propagation are mandatory · No → next question
- Do backend authorizations differ by user (sales area, plant)?Yes → propagate the user · No → a narrowly scoped technical user may be acceptable
- Is the result logged against the right person for audit?Yes → ready for review · No → fix identity before go-live
What would you do?
For speed, a developer configures the interactive order assistant with a technical user that has broad S/4HANA sales authorizations, "so nobody gets authorization errors". Maria's team is in sales area 1710/10/00 only. What should Nadia require?
- Authentication (OAuth only, first in the flow) and Authorization policies are mandatory on every MCP server.
- Use IdP user tokens with principal propagation for interactive and write scenarios; technical users only for narrow machine-to-machine jobs.
- Quota, Surge Protection and IP Filter bound what any agent can do; both limit policies return HTTP 429.
- Principal propagation for on-premise MCP flows is GA since July 2026; check What's New for the exact scope.
Check your understanding · not graded
Lesson check
1. Which policy must always come first in an MCP server's request flow?
2. What is the main difference between Quota and Surge Protection?
3. An interactive assistant must show each user only orders they may see in S/4HANA. Which design meets that?
4. Where do JSON and XML payload size limits for agent traffic come from in this design?