SAP Joule Security Guide: AI Copilot and Agents in SAP

Joule can read business data and run transactions across SAP S/4HANA, SAP SuccessFactors and other SAP cloud applications on a user's behalf, so its security rests on the identity, role and connectivity setup the customer builds around it. SAP's reference architecture states that Joule is aware of the user's roles and permissions, so a user cannot do through Joule what they could not do directly in the application. That guarantee holds only when users, role assignments, trusts and destinations are configured correctly in SAP Cloud Identity Services and SAP BTP. This guide covers the Joule identity flow, the administrative surfaces, custom skills and agents built in Joule Studio, external agent access through the Agent Gateway, and the logs to watch. It is for SAP Basis and BTP administrators, identity teams and the architects approving Joule rollouts. For the wider platform, see the SAP BTP Security Guide.

This is an independent guide from NHI Mgmt Group, based on SAP's public documentation as of November 2026. It is not sponsored or reviewed by SAP. Product features change, so confirm settings against SAP's current documentation.

Key takeaways

• SAP Cloud Identity Services is mandatory for Joule. SAP describes it as a prerequisite for all Joule integrations and recommends one common instance for production and one for non-production across your SAP applications.
• Joule acts as the user, through principal propagation. The BTP Destination Service exchanges the user's Joule token for an application token, so backend authorisations, not Joule, decide what each request can do.
• Role assignment is replicated, so replication is a control. Identity Provisioning jobs carry user and role assignments from each application into SAP Build Work Zone, which Joule uses to decide which functions a user may call in a session.
• Custom skills and agents widen what Joule can change. SAP's own guidance makes confirmation steps a requirement for create, update and delete operations in Joule Studio skills.
• External agents connect through named trusts. The Agent Gateway exposes Joule Agents over A2A and authenticates callers with SAP Cloud Identity Services App2App tokens carrying named user context.

How identity and access work in SAP Joule

SAP's Joule IAM reference architecture describes a cross-application setup that is built once, when the first application is connected, and reused by every application added later. Joule uses SAP Cloud Identity Services as its user store, primarily integrates through OpenID Connect, and uses SAP Build Work Zone for navigation across applications.

SAP notes that Identity Authentication terminates the authentication flow and issues a new token to the application, that service provider initiated SAML and OIDC flows are supported, and that IdP-initiated SAML is technically possible but not the default or recommendation. For the identity service itself, see SAP Cloud Identity Services.

Data grounding and the model layer

Joule answers informational questions through Retrieval Augmented Generation over a Knowledge Catalog that holds SAP content and, optionally, customer content connected through the Document Grounding service. SAP's reference architecture states that the LLMs Joule uses are provided under contractual agreements that prohibit SAP's partners from training their models on customer data. Document Grounding can ingest sources such as SharePoint or SAP Advanced Document Management, so the access model of those sources matters: a document grounded into Joule's knowledge should already be appropriate for every user who can ask about it. See the RAG Security Guide for the general controls.

Admin roles and privileged access

Joule administration is spread across several consoles, so privileged access has to be governed in each.

• SAP BTP global account and subaccount administrators: entitle Joule and SAP Build Work Zone, run the Joule booster that SAP provides to automate setup (service instances, Cloud Foundry enablement and destinations), and assign the role collections the booster creates. Limit subaccount administrators to the named Joule platform team.
• SAP Cloud Identity Services administrators: manage the Identity Directory, trusts with the corporate IdP and the Identity Provisioning jobs. A change here alters who can sign in to Joule across every connected application.
• Application administrators: in SAP S/4HANA Cloud Public Edition, an SAP Community setup guide written by an SAP Product and Topic Expert (listed in the references) has administrators mark business roles as exposed to BTP and set up communication arrangements for content exposure (SAP_COM_0647) and role replication (SAP_COM_0193). Only roles you intend Joule to surface should be exposed.
• Joule Studio developers: in SAP Build, they create skills and agents that call APIs through destinations. Separate the ability to build from the ability to deploy to production.

Our recommendation: review these four groups together each quarter, because a change in one (for example a new exposed business role) can widen what Joule offers users without any change in Joule itself.

Integrations, API tokens and service accounts

• Treat agent tools as non-human identities: every destination a skill or agent can call is a credential with an owner, a scope and a review date. See the Agent Identity and Access Guide.
• Prefer A2A trusts over shared keys for external agents: SAP's architecture prioritises A2A through the Agent Gateway or SAP Integration Suite for vendor-to-vendor agent interoperability. See the A2A Protocol Security Guide.
• Keep confirmation on writes: SAP's Joule Studio guidance requires confirmation dialogs that show what will change before any create, update or delete runs. This is the platform's human-in-the-loop control; see the Human-in-the-Loop for AI Agents Guide.

Logging and detection

• Identity Provisioning logs: The same SAP Community setup guide has administrators run the read job and check provisioning logs. Alert on failed or partial jobs, because stale role assignments mean Joule offers functions a user should no longer have, or withholds ones they need.
• Identity Authentication sign-in logs: Joule logins pass through Identity Authentication, so its logs (and the corporate IdP's) show who used Joule and from where.
• Backend application logs: because calls run under principal propagation, transactions created through Joule appear under the real user in the application's change documents and security logs. Use them to review Joule-initiated changes.
• Agent interactions: SAP's inbound A2A architecture states that Agent Gateway interactions use role-based access control and audit logging through SAP Cloud ALM. Forward those records to your SIEM.
• BTP subaccount changes: record changes to destinations, role collection assignments and trusts in the subaccount, which define what Joule can reach.

Metrics: percentage of Joule users authenticating through the corporate IdP with MFA; number of failed Identity Provisioning runs per month; number of destinations using technical users rather than user token exchange (target zero for runtime calls); number of deployed Joule Studio skills with write actions and confirmation steps (target 100 percent with confirmation); number of App2App trusts with a named owner.

Hardening baseline

1. Foundation: stand up one production and one non-production SAP Cloud Identity Services tenant shared by your SAP applications, as SAP recommends, and federate both to the corporate IdP with MFA.
2. Pilot in non-production: run the Joule booster in a non-production subaccount, connect one application, and test with users whose roles you know. Confirm that a user without a backend authorisation cannot complete the matching action through Joule.
3. Expose roles deliberately: mark only the business roles intended for Joule as exposed, and record the list.
4. Check every destination: runtime destinations use user token exchange; any technical credentials are limited to provisioning and stored only where SAP's setup requires them.
5. Govern grounding sources: connect document repositories only after checking that their permissions suit everyone who can query Joule.
6. Gate Joule Studio: require review of each skill and agent before production deployment, with confirmation steps on all write actions.
7. Roll back safely: SAP Build lifecycle tooling deploys skills and agents alongside the Joule instance, so keep the previous version available for redeployment, and remove an exposed role or disable a destination to cut off a capability quickly.

Decision guidance: rollout choices

• Public versus private edition: for SAP S/4HANA Cloud Public Edition, SAP manages tenant context and much of the setup through the booster. For private edition, SAP's architecture adds the Cloud Connector tunnel and requires the matching OData services to be active, so the customer owns more of the connectivity and its hardening.
• Low-code versus pro-code agents: agents built in Joule Studio register in Joule's catalogue automatically and run on SAP AI Core. Pro-code agents give full control but are connected through the A2A Bring Your Own Agent pattern, so the customer secures the endpoint, its identity and its input handling.
• Agent Gateway versus SAP Integration Suite: SAP recommends Integration Suite where you need API management, customer-controlled governance, guaranteed delivery and monitoring around agent traffic; the Agent Gateway is the SAP-managed public A2A endpoint.
• Small versus large organisations: a small team can run identity, BTP and Joule Studio administration from one group if every change is logged and reviewed; larger organisations should separate those duties so no single administrator can both widen access and deploy a new write-capable skill.

Common misconfigurations

• Global User ID mismatch: a user created separately in an application without the shared Global User ID breaks the link Joule depends on and leads to manual workarounds.
• Technical users in runtime destinations: a destination using a shared technical user lets every Joule user act with that user's rights, bypassing the per-user authorisation SAP's design relies on.
• Exposing all business roles: choosing "All" for content exposure when only a subset is intended for Joule widens the catalogue of available functions.
• Provisioning jobs nobody watches: role removals in the application do not reach Work Zone until the next successful run.
• Grounding broad repositories: connecting a whole document library makes restricted documents answerable to every Joule user.
• Write skills without confirmation: skills that create or update records without a confirmation step remove the human check SAP requires.

Framework mapping

Practitioner checklist

• Confirm one production and one non-production SAP Cloud Identity Services tenant, federated to the corporate IdP with MFA.
• Verify that every Joule user has a consistent Global User ID across connected applications.
• List business roles exposed to BTP for Joule and remove any not intended.
• Check that all runtime destinations use user token exchange rather than technical users.
• Monitor Identity Provisioning jobs and alert on failures.
• Review grounding sources and their permissions before connecting them.
• Require review and confirmation steps for every Joule Studio skill or agent that writes data.
• Give each Agent Gateway App2App trust and each pro-code agent endpoint a named owner and review date.
• Forward IAS, IPS, Cloud ALM and BTP subaccount change logs to the SIEM.

Standards and references

• SAP Architecture Center: Integrating and Extending Joule, SAP's AI Copilot
• SAP Architecture Center: Identity and Access Management for SAP Joule
• SAP Architecture Center: Extend Joule with Joule Studio
• SAP Architecture Center: Integrating Joule Agents into Your Ecosystem (Inbound A2A)
• SAP Architecture Center: Joule skills golden path
• SAP Learning: Setting up Joule for SAP S/4HANA Cloud Public Edition
• SAP Community (SAP): Joule in SAP S/4HANA Cloud Public Edition setup guide
• NIST: SP 800-53 Rev. 5

Related NHI Mgmt Group resources: SAP BTP Security Guide · SAP Identity and Access Security Guide · OWASP LLM Top 10 LLM06 Excessive Agency Guide · Prompt Injection Guide