Does XSUAA provide SAP AI Core security?

XSUAA provides the documented authentication mechanism for access to SAP AI Core. XSUAA credentials support obtaining the access token used by a technical client. A complete deployment also needs resource-group design and workload controls. Container controls and secret management also apply, along with network policy and request-level authorization. The exact mix depends on what the application sends and which model endpoint it calls.

Are SAP AI Core resource groups an authorization control?

Resource groups are an important scope and isolation mechanism. SAP maps them to namespaces and assigns executions and deployments to a specific group. Configurations and artifacts also belong to that group, along with generic secrets. The AI-Resource-Group request header selects that scope for lifecycle operations. Content-aware inference authorization requires additional context because a resource group alone lacks the originating principal and prompt classification.

Can an inline gateway fix a compromised container?

A compromised container requires supply-chain and runtime controls plus an incident-response plan. SAP explicitly places responsibility for Docker-image content with the user and recommends scans and reviews, plus malware checks and signature verification. An inline gateway can block or record HTTP AI requests crossing its boundary. It cannot repair malicious code or govern local execution inside the workload.

Which SAP AI Core requests fit the DeepInspect boundary?

HTTP requests sent by authenticated users or agents toward an LLM endpoint fit the boundary when they are routed through the proxy and carry application-supplied identity context. Container build activity and local process execution require separate controls. Stolen credentials and internal workload behavior do too. Keeping that line explicit prevents an API policy product from being credited for platform security work it never performed.

SAP AI Core Security: Tenant Boundaries Stop Short of Request Authorization

SAP AI Core puts authentication at the service boundary. Its documentation says the platform uses SAP Authorization and Trust Management service (XSUAA), with credentials used to access AI Core arriving in the service key. That mechanism establishes a tenant-level caller for an API request. It does not automatically establish the employee or agent behind an application call, or decide whether the prompt carried data that this caller may send to this model. I want to separate those two jobs, because a security review that treats a valid bearer token as the final authorization decision leaves the most important request unexamined.

TL;DR

SAP AI Core uses XSUAA credentials from a service key to authenticate access to the service.
Resource groups isolate runtime objects and secrets inside tenant namespaces. Those objects include executions and deployments as well as configurations and artifacts.
SAP assigns customers responsibility for their workflow and serving templates plus Docker images.
Content-aware authorization still needs an inline decision on the HTTP request before it reaches the model.

XSUAA authenticates the SAP AI Core tenant

SAP states that AI Core uses XSUAA authentication. The service key supplies the credentials used to obtain access, and the resulting bearer token identifies access within the SAP BTP tenancy model. This is a concrete, documented security boundary. A client without the required credential should fail before it can administer deployments or invoke the exposed API.

The identity represented by that credential deserves close inspection. A backend commonly obtains the token and then sends model requests on behalf of many people or automated callers, including scheduled jobs and agents. At that point, the service can identify the authorized SAP AI Core tenant or technical client presented on the call. The HTTP request may still lack the originating employee or delegated agent, along with the business role and purpose that caused the prompt to exist.

This is the post-authentication gap in a familiar enterprise shape. XSUAA answers who may access the SAP service. The application still has to carry enough context for a second decision about this particular inference request.

Resource groups provide a real isolation boundary

The SAP AI Core multitenancy model maps each main tenant and resource group to a namespace. Tenant-level resources include user authentication and authorization alongside Docker registries. They also include workflow and serving templates. Runtime entities such as executions and deployments, plus configurations and artifacts, belong to a specific resource group. Generic secrets also belong to that group, and none of these resources can be shared across groups.

That separation is useful because it constrains where an execution runs and which resource-group secrets a workload can consume. SAP also requires the tenant to set the appropriate resource group in the request header when managing the lifecycle through the AI API. A reviewer can therefore test the token and selected header against the runtime object rather than treating the tenant as one undifferentiated pool.

A laptop screen showing AI-Resource-Group: finance-prod next to a bearer token is a good start. It proves routing context. The header still says nothing about a prompt containing an unreleased earnings draft or about a contractor asking the finance deployment to summarize it.

Workload isolation and content ownership stay separate

SAP documents that AI Core workloads run in a sandbox and cannot access workflows belonging to other tenants or resource groups. The platform also limits workload traffic to TCP. Those controls narrow lateral movement inside the managed runtime and deserve credit in the threat model.

The customer owns a different layer. SAP's AI content security guidance defines AI content as Docker images and the workflow or serving templates that use them. It tells users to perform threat modeling and static code scans. The same guidance calls for open-source vulnerability scans and peer code review. It also calls for malware scanning and image digest checks, along with image signature verification. The page also states that AI Core users are responsible for their Docker-image content and assume the risk of running compromised containers.

That is the software supply-chain boundary. Container scanning addresses code and packages before deployment. Sandbox isolation addresses workload behavior after deployment. Prompt authorization addresses an HTTP message at inference time. Folding all three into a green box labeled "SAP AI Core security" hides which team owns each control and which evidence proves it worked.

The inference request needs its own decision

Consider a procurement assistant hosted through SAP AI Core. A service credential is valid, and the deployment belongs to the correct resource group. The container also passed image-signature verification. An employee then asks the assistant to compare bids while attaching a document that includes another supplier's confidential pricing. Every SAP platform control named above can work as designed while the request remains inappropriate for the selected model route.

The missing decision uses context that the service token and resource-group header do not carry by themselves:

the originating human or agent identity supplied by the application
the role and delegated authority in force for this business operation
the classification of prompt content and retrieved context
the approved model endpoint and route for that data class
the versioned policy that permits, redacts, or denies the request

This treatment is deliberately separate from SAP Joule DLP. DLP asks what sensitive material crosses the AI request boundary. SAP AI Core security also asks who authenticated to the platform and where the workload runs. It then asks who owns the container and which request-level authorization joins those facts.

Evidence should follow each control owner

A SAP AI Core review should produce several artifacts rather than one generic assurance statement. Platform engineering can show XSUAA configuration and service-key rotation. It can also show the selected resource group and namespace ownership. The model operations team can show deployment configuration and the approved image digest. Application owners can show how they propagate the initiating principal instead of collapsing every user into one technical client. Security can show the policy decision for a controlled request.

I would reject a diagram that stops at "authenticated via XSUAA." That phrase proves service access and leaves the business action unresolved. Run one synthetic request under a named test identity with a labeled value in the prompt. Retain the request ID and technical client. Record the resource group and deployment, then preserve the classification result and policy version alongside the outcome. Then remove the initiating identity and confirm that the request enters a defined exception path or fails closed.

The AI gateway architecture provides the natural place for that final check. Its value comes from sitting on the same HTTP path as the inference request, where it can evaluate context before forwarding traffic.

DeepInspect

This is the gap DeepInspect closes. DeepInspect sits inline as a stateless proxy on HTTP AI traffic between authenticated users or agents and LLM endpoints. For a SAP AI Core route, it can evaluate the identity context supplied by the application and the role in force. It can then assess prompt classification and destination against the policy version before forwarding the request.

XSUAA continues to authenticate access to SAP AI Core. Resource groups continue to isolate runtime entities, and the SAP AI Core team continues to own container and workload security. DeepInspect adds a per-request allow or deny decision, with redaction when policy requires it, at the AI request boundary and produces a signed, tamper-evident record of that decision. Book a technical deep dive at deepinspect.ai.