SAP Joule Security: Four Boundaries to Test Before Production

A SAP Joule request passes through several security boundaries before an answer appears in the chat window. SAP's central AppRouter handles the user-interface request, XSUAA issues the OAuth authorization code, SAP Identity Authentication supplies the configured trust relationship, and connected applications apply their own permissions. Outbound connections rely on destinations configured in the SAP BTP subaccount. I want to separate these controls because a green check beside "SSO enabled" proves one part of the path. It says very little about the business data inside a prompt or the model route selected for that request.

TL;DR

• SAP Joule uses a central AppRouter and an OAuth Authorization Code flow to establish the business user's session. XSUAA issues the code, while SAP Identity Authentication supplies the configured trust relationship.
• Connected applications still apply their own user permissions, including when Joule is reached through Microsoft 365 Copilot or Teams.
• TLS and trusted certificate authorities protect network connections. SAP BTP destinations define outbound connections.
• A production test should join identity, application permission, prompt classification, model route, and policy outcome for one controlled request.

The OAuth session establishes the business user

SAP's authentication-of-requests documentation says all Joule user-interface requests pass through a central AppRouter in the SAP BTP Cloud Foundry environment. The AppRouter requires an OAuth Authorization Code grant flow. XSUAA issues the authorization code and requires the user to authenticate according to the trust configuration for the relevant SAP BTP subaccount.

A reviewer can inspect the subaccount trust configuration and confirm the expected identity provider. The reviewer can then test which user reaches Joule. It also gives the team a clear failure case: an account outside the configured trust relationship should fail before a Joule session begins.

The same SAP page adds an operational warning that belongs in every test plan. Joule should avoid shared desktop environments where several people use one browser in kiosk mode. SAP recommends a separate operating-system session for each user rather than reliance on browser logout alone. A browser tab left open on a reception desk is a concrete identity problem, even when the OAuth configuration itself is correct.

Single logout has a wider blast radius

SAP documents Single Logout through SAP Identity Authentication. Signing out of Joule Admin Center or a parent application can terminate the authenticated Joule session. If development and test Joule tenants share one SAP Identity Authentication tenant with production, signing out of one can end active sessions across all of them.

That behavior deserves an explicit production test. Put two test tenants in separate browser windows, authenticate through the shared identity tenant, then sign out through the parent application. Record which Joule sessions terminate and which application remains reachable. The expected result should match the documented trust design rather than the assumptions in an architecture slide.

Session termination protects access after logout. Authorization during an active session is a different control decision. The account can be genuine, the session can be current, and the user can still ask Joule to act on a record outside the intended business purpose. The post-authentication gap begins at that point. Authentication establishes who is present. Request policy must determine which prompt, data, action, and model route that identity may use now.

Connected applications retain their permission checks

The application boundary becomes visible in SAP's roles and authorizations guidance for Microsoft 365 Copilot and Teams. SAP says the trust setup links identities between Microsoft Entra and SAP Identity Authentication, then through Joule to connected SAP backends. A question raised through Copilot or Teams is processed in the scope of that user's identity and permissions. Joule answers only when the user is known and authorized, with the same permission checks applied to direct Joule access.

The originating employee survives the handoff instead of disappearing behind one shared integration account. The backend remains the authority for access to its business objects.

A security review should still test the whole chain with named accounts. Give one user permission to a synthetic purchase order and deny a second user. Ask the same question through direct Joule access and through Teams. Capture the Entra identity and SAP identity mapping. Preserve the backend result and request correlation value. Four screenshots showing the expected allow and deny outcomes tell the reviewer more than a role spreadsheet exported six months earlier.

TLS and destinations define the communication path

SAP's network and communication security page places Joule on the SAP BTP Cloud Foundry network topology. It points administrators to TLS connectivity and trusted certificate-authority configuration. For outbound connectivity, SAP says destinations are configured in the BTP subaccount during provisioning to connect Joule with different SAP systems.

These controls answer where traffic can go and which remote certificate the connection trusts. Reviewers should inventory each destination by hostname and authentication type. The inventory should also name the owning team, connected SAP system, and last test date. They should also test a certificate failure and an unapproved destination in a non-production subaccount. The result establishes that transport and route configuration behave as designed.

TLS protects data while it crosses the network. A configured destination directs traffic to an approved system. The content inside an authorized request still needs its own treatment. A procurement user may have legitimate access to two supplier records and a valid destination to the ERP system, yet company policy may prohibit sending one supplier's confidential bid into the model context used to summarize the other. Zero trust for AI requires that decision at the request rather than at the network connection alone.

Four tests produce a defensible security review

I would reject a SAP Joule security review that ends with an SSO screenshot and a list of BTP destinations. Both artifacts support the review. They still leave the business request unresolved. A review runs four tests under a named identity and retains the outcome of each one.

• Session test: authenticate through the configured SAP Identity Authentication trust and verify the expected user. Exercise Single Logout and confirm the documented behavior across every linked tenant.
• Permission test: ask for one allowed and one denied synthetic business object through direct Joule access and any enabled Microsoft 365 channel. Preserve the identity mapping and backend permission result.
• Route test: confirm TLS validation and the configured BTP destination for each connected SAP system. Exercise a failed certificate or disabled destination in a test subaccount.
• Request-policy test: send a labeled fictional value under two roles. Record the originating identity and prompt classification. Add the destination model and policy version, then preserve whether the policy allowed or denied the request or redacted content before inference.

A sheet with four rows and four owners keeps these boundaries separate. Links to the resulting evidence belong in each row. Identity engineering owns the trust and session. The SAP application owner controls business permissions. Platform engineering owns destinations and transport. Security owns the prompt and route policy. The AI gateway architecture gives that final owner a decision point on HTTP AI traffic before the model receives the request.

Request authorization joins the boundaries

The four tests become more useful when one correlation identifier connects them. Start with the employee identity established through XSUAA and SAP Identity Authentication. Add the business authorization result returned by the connected application. Then attach the destination and prompt classification. Add the model route and policy version, followed by the outcome produced at the AI request boundary.

This article deliberately stays apart from SAP Joule DLP, which focuses on sensitive content moving through prompts and responses. It also avoids treating conversation and configuration records as preventive controls. SAP Joule security is the larger architecture. Session identity and backend permission checks have their own enforcement points. Transport and configured destinations have separate enforcement points, as does a request-level decision.

Keep the product boundary precise. An inline HTTP policy point can evaluate Joule-related model traffic routed through it. Shared desktop security and Entra-to-SAP identity mapping remain with endpoint and IAM owners. Backend business roles and compromised endpoint response remain with SAP application and endpoint owners. The gateway's job begins when an authenticated user or agent sends an HTTP request toward an LLM endpoint.

DeepInspect

This is the gap DeepInspect closes. DeepInspect is a stateless proxy on HTTP AI traffic between authenticated users or agents and LLM endpoints. For SAP Joule-related model traffic routed through that boundary, it evaluates application-supplied identity and role. It also evaluates prompt classification and destination against versioned policy before forwarding the request.

SAP Identity Authentication and XSUAA continue to establish the user session. Connected SAP applications continue to enforce their business permissions, while BTP destinations and TLS continue to govern communication paths. DeepInspect adds the independent decision to allow or deny the AI request, or redact its content, and produces a signed, tamper-evident record of that decision. Book a technical deep dive at deepinspect.ai.