Data security and governance
SAP data is business-critical, so access to it must be controlled. In the AI Context Hub, what an agent may see and do is configured per data source, not decided by the AI model.
The data boundary
The AI model is used to interpret a request and to plan against the catalog, which is metadata: the names of services, operations, and fields, and their descriptions. The values returned by the SAP system are handled separately. By default, they do not enter the AI model. They are returned to the user as the answer.
This separation lets the AI model determine how to obtain an answer without receiving the business data itself.
Data-access modes
You decide how strict the boundary is with the LLM Data Access setting on the data source:
- Always
-
The AI model may read actual result values to interpret them. Use this only where a request requires the model to reason over the data, and where sending those values to the selected model is acceptable.
- Ask User (default)
-
The AI model works from metadata only. When a request cannot be answered without reading values, the orchestration engine asks the user for one-off consent before it does. Values are not read unless a user grants consent, and the consent applies to that one request.
- Never
-
The AI model works from metadata only and never asks to read values. If answering requires the model to read values, it is answered from metadata alone or not at all.
For where this setting sits and how to set it, see Configure the orchestration engine.
| The AI model is one you choose, and it can be a hosted, third-party model. When LLM Data Access is Always, or when a user consents under Ask User, the values in question are sent to that model. Confirm that this is acceptable with regard to where the selected model runs, data residency and processing terms for BYO models for the data involved before you use those modes. |
Result retention
LLM Data Access governs what a model may read while answering. Result Retention is a separate control: it governs how much of a result a run keeps once stored, either the shape of the data only or the full result with its SAP values. Set it to keep only what later review genuinely needs.
Two-tiered access
The data source has its own LLM Data Access setting, and the agent that consumes it has another. A value withheld at the data source can still be exposed to the agent’s model, and the reverse. Set the access deliberately at both layers.
Granted access
A data source does not expose a whole SAP system. You grant it access to specific services and, within them, specific operations. An agent using the data source can reach only what you granted. For example, you can scope one agent to read purchasing data and nothing else. You can also give several agents different reach against the same system. You set this on the SAP Services tab.
Runtime user
When the orchestration engine executes a plan, it runs the operations against SAP as a user, not as an anonymous service. You configure this on the data source with an execution authentication: a system role and a pre-configured API authentication. The SAP system therefore applies its own authorizations to every call, on top of what the data source grants. See Add execution authentication.
|
A data source can create, update, and delete data in SAP, not only read it. Because a granted operation runs against the live system as this user, non-read operations change business data. Grant them only where a use case needs them, scope the runtime user’s SAP authorizations accordingly, and prefer read-only access otherwise. |
Ingestion and runtime identities
Two separate identities reach SAP, and each is assigned in its own place. Ingestion, which builds the catalog, authenticates with the proxy authentication on the remote system, and typically needs developer or repository authorization. Runtime, which executes a request, authenticates with the proxy authentication on the SAP data source, and typically needs business authorization on the operations it runs. Runtime does not fall back to the remote-system credentials, so set both. For the endpoints and SAP-side authorizations each identity requires, see SAP connectivity and authorizations.
Run tracing
Every request the orchestration engine answers can be traced, so an administrator can review what an agent did. Two controls in the data source’s Engine Configuration set how much is recorded. See Configure the orchestration engine.
Agent Trace Detail controls what the run records in the Agent Trace tool:
- Steps
-
The plan, the plan-cache decisions, each step’s outcome, and the OData and BAPI calls with their request options.
- LLM
-
Adds the orchestration engine’s prompts, responses, and token counts.
- Full
-
Adds truncated samples of the raw OData and BAPI response data.
Run Log File, when turned on, writes the full event stream of every run, all plan,
LLM, and SAP transport events, to a per-run JSONL file on the server under log-files/sap
for deeper debugging. Its Default setting turns it on outside production and
off in production. Run logs older than 14 days are cleaned up automatically.
Governance checklist
Before you attach a data source to an agent, confirm the following:
-
LLM Data Access is set to the strictest mode the use case allows, at both the data source and the consuming agent, and Always is used only where sending values to the AI model is acceptable.
-
Result Retention keeps only what later review needs.
-
The data source grants only the services and operations the agent needs.
-
An execution authentication is set, so calls run as an appropriate user.
-
Tracing is set to a level that lets you review runs later.