Security and governance
AI in SAP, inside the rules you already have
An AI agent in SAP is only acceptable if IT can say exactly who may do what, and prove what was done. Every control on this page is built in and on by default.
All three calls are logged in SAP with the named user, the object and the result.
The controls
Eight controls, all built in
Single sign-on
Users sign in through your identity provider, such as Microsoft Entra ID, using SAML 2.0 or OAuth 2.0 / OpenID Connect. No separate passwords.
Named SAP users
Each signed-in person maps to exactly one SAP user, so every call runs under that person’s own SAP authorizations. Never a shared account.
Two gates on every call
A whitelist per role in the connector, inside the user’s normal SAP authorizations. A call must pass both.
Human-approved objects
An administrator decides, per role, which tables, reports, BAPIs and function modules the agent may use. The agent cannot browse or list the SAP repository.
Read and write kept apart
Each object is classified read-only or write-capable. A role can be read-only, and writes need an explicit commit.
Check, post, verify
Test runs where SAP offers them, and a read-back after every posting. If an outcome is unclear, the agent checks SAP before retrying.
Limits
Row limits per call and rate limits per user stop any single request from pulling bulk data out of SAP.
Full audit
Every call is logged in SAP, in the connector’s monitor (/CGR/MONI), with user, object, time, result and the full request and response.
Boundaries
The boundaries are fixed by IT, not by the agent
The agent starts from the list of objects approved for the user’s role. It cannot discover or call anything outside it.
- Reach an object that is not on the role’s whitelist
- Do anything the user’s own SAP authorizations don’t allow
- Write to SAP from a read-only role
- Post without an explicit commit
- Pull unlimited data in one call
- Act without a logged, named record in SAP
Architecture and data path
One path in, every hop encrypted
- UserCompany account · SSO
- AI assistantAny MCP client · MCP over HTTPS
- CGR MCP ServerYour cloud or CGR’s Azure · HTTPS, inbound only
- CGR SAP ConnectorInside SAP · in-system ABAP calls
- SAP dataUser’s own authorizations
SAP is never opened to the AI assistant directly. The MCP server calls the connector’s secured endpoints, and only for whitelisted objects.
The connector does not initiate outbound HTTP or HTTPS requests, including licence checks, update checks or telemetry.
All traffic between assistant, MCP server and SAP runs over HTTPS.
From SAP to the MCP server, then to your AI assistant. Your AI provider handles questions and answers under your own agreement with it.
Installation and removal
One add-on, installed and removed by your Basis team
01 · Install
Via SAINT in the SAP-reserved /CGR/ namespace. No modification to SAP standard objects.
02 · Ships closed
The service ships inactive. Nothing is reachable until your Basis team activates it.
03 · Kill switch
Deactivating the connector’s SICF service node shuts off all external access immediately, with no downtime.
04 · Remove
The add-on is removable through SAINT.
SAP API Policy
How the architecture sits against SAP’s API Policy
SAP’s API Policy restricts third-party access to non-published APIs, with an exception for custom-developed ABAP interfaces in private cloud and on-premise deployments. The connector is in-system ABAP, installed in your own system and running under your own authorization objects, the category that exception describes.
The policy also addresses AI systems that select and execute API calls. CGR’s design keeps the agent inside a fixed set of objects a human has approved for each role, under a named user, with every call logged.
SAP continues to update its policies on AI access. Customers should confirm their own use cases against their agreements with SAP.
For your security review
Everything Basis and security will ask for
Our CTO will join a call with your Basis or security team.