Joule Trust Boundaries and Identity Propagation Explained

In 30 seconds

What it is Five trust zones, one rule: the backend checks the real user's permissions.

You use it when You are designing, reviewing or auditing how Joule or a custom agent reaches SAP Cloud ERP or SAP SuccessFactors data.

Next in this section Prompt Injection in SAP AI Agents: Poisoned Data, Explained Plainly →

A Joule request crosses five zones with different owners. The user’s identity has to survive every hop so the backend can make the final call.

Part 21 of 26 in SAP Business AI, Explained.

When security teams review Joule, the model is rarely what worries them first. In design reviews they ask what the agent can reach, whose identity it uses and what evidence it leaves behind. The short answer is that every time Joule or an agent asks an SAP system for data, that system should know exactly which person is asking and apply that person’s permissions.

Who owns each hop?

A request moves from the user, through the SAP-managed Joule runtime and your SAP Business Technology Platform (BTP) configuration, to your SAP systems, with model calls on the side. Five zones, several owners.
The user’s identity is passed along each step (identity or principal propagation), so the backend applies that user’s roles. The tempting shortcut is a shared technical super-user, which lets the agent see everything and leaves the backend unable to protect you.

Badges, receptions and master keys

In this series the agent gateway is the building security desk. Now picture a campus with several buildings, each with its own reception. In the good pattern, each reception checks a copy of your badge. In the bad one, the first reception hands the visitor a master key and every later door just opens. The receptions are the trust boundaries, and identity propagation is the badge copy travelling with the request.

Following one request through the five zones

I’m following the architecture SAP’s Jana Subramanian sets out on SAP Community for SAP Cloud ERP Private (RISE with SAP), plus another SAP author’s SuccessFactors walkthrough. Both say Joule inherits your security model and does not grant extra backend permissions.

User and identity. Your corporate sign-in still owns login and multi-factor authentication. SAP’s identity service sits behind it, vouching for the user to Joule and keeping users and groups in sync. Joule and every SAP product connected to it must share one identity tenant.
Joule runtime (SAP-managed). SAP operates the runtime and orchestration that decides which skill, agent or tool handles the request. Tool permissions and user confirmations depend on how the scenario is configured.
Your BTP configuration. Destinations, the stored connection settings, say where to call and how to authenticate. Change a destination’s authentication type and you change whose identity reaches the backend, the write-up stresses, so destinations need change control.
Your SAP systems. For SAP Cloud ERP Private, a connector inside your network opens an outbound, encrypted tunnel and turns the user’s sign-in token into a short-lived certificate. The SAP backend maps that certificate to a named user and runs its normal role checks. Joule has no direct database connection.
Model access. SAP decides which model handles a Joule request, using models it makes available on its own AI platform. It isn’t a setting you configure for Joule. Custom agents choose their own models from SAP’s published list.

In plain terms, SAP runs the Joule engine, the gateway that agents come through, model choice for its own capabilities and the platform underneath. You run your sign-in setup, users and roles, the connection settings, which tools and agents are switched on, approval design and log review. A few network components and security patching in a RISE landscape are shared. The full split is in Go deeper, and your RISE with SAP roles and responsibilities document is the authority for your contract.

Two things are easy to miss. Masking and content filtering for model calls are modules you configure, not defaults. And while SAP states it does not share customer data with third-party model providers for training, authorised business context does enter prompts.

Agent-to-agent (A2A) calls add hops. SAP describes Joule calling external agents (Bring Your Own Agent), and external agents calling Joule Agents through an SAP Agent Gateway with named user context. For that inbound path, an SAP post describes it as generally available; another SAP Community post says “where available”. Confirm in the capability watch linked below. The write-up puts it well: “An A2A call delegates a task. It does not grant data access” (Jana Subramanian, SAP Community). The receiving agent still needs its own governed path to the data.

Whose permissions does NextSAP’s agent use?

Priya, the IT Platform Owner, is preparing the custom payment clarification agent (agent 4, which works in SAP contract accounting, Contract Accounts Receivable and Payable, FI-CA) and an HR query agent in SAP SuccessFactors. NextSAP Utilities is the fictional Dubai utility used across this site’s SAP content; the connection patterns come from the SAP Community write-ups cited here. Daniel from Internal Audit has one question: “Whose permissions does the agent use?”

The first prototype, later rejected, used a technical user with read access to every contract account for NextSAP’s roughly 5 million customers on SAP FI-CA. An analyst in Omar’s shared-services team in India asked about one commercial customer’s AED 23,480 payment, and the prototype could just as easily have listed the 3 restricted key accounts (large government and industrial customers) that she isn’t allowed to see. Only the model’s good manners stood in the way.

The approved version carries the analyst’s identity with every call, so the backend returns only the contract accounts her roles allow. The agent still finds the AED 23,480 payment and proposes a clarification, but the restricted key accounts never leave the system.

For the HR agent, Priya copies the SuccessFactors walkthrough’s test and runs the same conversation as two people. Mariam’s HR administrator sees contract renewal details, including pay. A field technician asking the same question gets “no records found”, because SuccessFactors Role-Based Permissions (RBP) filter the data at source. The agent has no permission logic of its own.

Before go-live, she deliberately removes a token setting on a test destination and checks that the call fails rather than quietly falling back to a technical user. This is the test I see skipped most often.

Choosing the connection for each scenario

Situation	Recommended connection	Why
Joule standard skills on SAP Cloud ERP Private	Destination with principal propagation through Cloud Connector, as SAP describes	Backend roles decide, unchanged
Custom agent reading SuccessFactors data	User token exchange to the backend, as in the SuccessFactors walkthrough	RBP filters every tool call
Background job with no human user, non-personal data	Narrow technical user, read-only, logged	Acceptable only with tight scope and owner sign-off
External agent calling a Joule Agent	Agent Gateway with named user context (sources differ on availability)	The receiving side still applies user permissions

Check the current status of gateway and managed-integration features in the Joule capability watch. For SAP Cloud ERP Private, the SAP Community write-up notes that SAP lists the managed integration with Joule as available through SAP Early Adopter Care.

Propagation’s gains and its limits

With identity propagation, the backend applies the real user’s roles, so denied stays denied. Backend credentials stay out of the agent (the SuccessFactors pattern describes a credential-less agent), and auditors get a named person behind every agent call.

It won’t fix roles that are already too broad, though, and it can’t stop an agent misusing data the user is allowed to see (that needs narrow tools and approvals). Nor does it configure itself. Destinations, trust settings and tests are your team’s work.

Explain it to your CFO

The agent sees only what the person asking is already allowed to see. SAP runs its engine, and we control who can use it and what it can reach.
Before launch we test it as a junior employee, to prove it can’t see too much.

Decisions for your security review

Do we allow any technical user for agent access to business data? My default is no for personal or financial data, and yes only for narrow, read-only, non-personal jobs with a named owner.
Who approves destination changes? Treat them like role changes, with a security review and a change ticket.
What’s our go-live identity test? Run each agent as a high-privilege and a low-privilege user and compare. If the low-privilege run shows too much, fix it in the backend roles and connection. Authorisation doesn’t belong in the prompt.

Go deeper

Technical detail for architects and developers

The components behind the five zones: your corporate identity provider federates to SAP Cloud Identity Services, where Identity Authentication acts as the trust broker for Joule and Identity Provisioning keeps users and groups in sync. On SAP Cloud ERP Private, the Cloud Connector is the tunnel and the ABAP (Advanced Business Application Programming) system runs the role checks. Joule’s model routing uses models available through the generative AI hub in SAP AI Core, where masking and content filtering are configured.

Who manages what, per the SAP Community write-up (your RISE with SAP roles and responsibilities document is the authority for your contract):

SAP-managed	Customer-managed	Shared
Joule runtime and orchestration	Corporate identity provider and Identity Authentication setup	Cloud Connector and Web Dispatcher operations in the RISE landscape
Agent Gateway endpoint	User provisioning, roles and segregation of duties	Security note implementation
Model routing for SAP-delivered capabilities	Destination configuration
BTP platform and Connectivity service	Integration Suite and MCP Gateway policies
RISE infrastructure and operations	Which tools and agents to enable, approval design, log review

Users sign in to the Joule runtime with OpenID Connect (OIDC). SAP S/4HANA Cloud Private Edition must already be integrated with Identity Authentication, and the setup also needs SAP Build Work Zone, standard edition and the Cloud Identity Services connectivity plan.

On Cloud ERP Private, the standard skill uses a destination of proxy type OnPremise with principal propagation, then the Connectivity service and Cloud Connector. Cloud Connector trusts the subaccount’s Identity Authentication tenant, creates a short-lived X.509 certificate and forwards it over mutual Transport Layer Security (TLS). Web Dispatcher and the Internet Communication Manager must trust only known intermediaries, and SAP’s documentation is explicit that a forwarded client certificate header must never be accepted from an untrusted source. A TLS-terminating proxy in between breaks the chain unless it’s a trusted intermediary. Rule-based certificate mapping then assigns the user, and normal role (PFCG) checks apply. The write-up mentions OIDC bearer mode as a documented alternative, depending on scenario.

On SuccessFactors, Joule’s A2A client in the walkthrough calls a pro-code agent on Cloud Foundry through a BTP destination using an App2App token exchange in Identity Authentication. The agent validates the token against the identity tenant, then calls the Destination service with the user token. A second destination performs an OAuth 2.0 SAML bearer assertion to SuccessFactors, and RBP is applied at the OData (Open Data Protocol) API layer. The author warns about two silent fallbacks to a technical user: leaving out the user-token header, and leaving out the token-validation key setting on the destination.

For tools, SAP Integration Suite’s MCP Gateway can expose APIs as governed Model Context Protocol (MCP) tools with OIDC authentication, rate limiting and monitoring. It’s customer-managed, and availability depends on edition and plan.

For evidence, correlate identity provider logs, Joule conversation logs, the BTP Audit Log service, Agent Gateway audit logs in SAP Cloud ALM (Application Lifecycle Management), Cloud Connector and Web Dispatcher logs, and the ABAP Security Audit Log, as the write-up recommends.

Nor is this only an SAP concern. OWASP’s Excessive Agency entry lists acting under a generic high-privilege identity as a root cause, and recommends executing actions in the user’s own context with minimum scopes.

Words you’ll hear

Trust boundary: a point where a request passes from one owner or system to another, and has to be checked again.
Identity propagation (principal propagation): passing the real user’s identity through every hop so the backend can apply that user’s permissions.
Identity Authentication: the SAP Cloud Identity Services component that signs users in and brokers trust between applications.
Destination: a stored BTP configuration that says where a system is and how to authenticate to it.
Cloud Connector: software inside your landscape that opens a secure outbound tunnel to BTP.
Role-Based Permissions (RBP): the SAP SuccessFactors model that decides who sees which fields and records.
Technical user: a shared system account. Useful for jobs, risky for agents acting for people.

Keep going

Independent explainer, not affiliated with or endorsed by SAP SE. SAP, Joule and other SAP product names are trademarks of SAP SE.

Frequently asked questions

Does Joule bypass SAP authorizations?

Not in the standard skill path SAP describes for SAP Cloud ERP Private. Existing ABAP authorizations and roles still govern data and actions, and Joule grants no extra backend permissions.

Which parts does SAP manage and which do we manage?

SAP's write-up lists the Joule runtime, the Agent Gateway endpoint and model routing for SAP-delivered capabilities as SAP-managed. Identity configuration, roles, destinations, tool and agent choices, approvals and log review are customer-managed. Your RISE roles and responsibilities document is the authority.

Why not let a custom agent use one technical user?

A technical user bypasses the individual user's permissions, so the agent can see far more than the person asking. SAP Community authors call identity propagation non-negotiable for production agents on SAP SuccessFactors.

Can a misconfiguration silently fall back to a technical user?

Yes. The SuccessFactors walkthrough warns that missing token settings on the destination can make the service fall back to a technical user. Test with a low-privilege user before go-live.