SAP Joule and SAP_ALL: Clean Up Before You Go Live

Joule never grants anyone new access. It also never limits the access they already have. If a user holds SAP_ALL, every Joule scenario works for them without limits. That is the whole argument for cleaning up first.

How Joule reaches SAP: two gates

Every Joule answer has to pass two gates, in order.

Gate 1: a scenario must exist

Joule can only do what a Joule scenario or Joule Agent has been built for, by SAP or by you in Joule Studio. Each scenario is wired to specific APIs, usually OData services, reached through SAP BTP destinations. Joule does not discover or call a user's other apps on its own.
Gate 2: the user's roles decide what comes back

In S/4HANA, Joule calls those APIs as the signed-in user through principal propagation. The backend applies that user's authorization objects, so the same question returns different records for different people.

There is one exception to Gate 1. Joule can navigate a user to any app on their launchpad. A user with 100 apps can be taken to all 100, but navigation only opens the app. Joule reads data or takes actions only where a scenario exists.

What this means for an FI user

Ask about a journal entry or overdue receivables, where SAP ships a scenario, and Joule answers within that user's company codes. Ask about a custom Z report, where no scenario exists, and Joule can at best open the app for them to work in by hand.

So what happens with SAP_ALL?

Gate 1 still applies, so an SAP_ALL user cannot run "anything" through Joule. Gate 2 disappears. Every scenario works across every company code, plant and dataset, and navigation can drop them straight into SU01, PFCG or SE16.

Conversational AI makes three things worse:

Reach. Nobody needs to know a transaction code or table name any more. One sentence is enough.
Aggregation. Data that was scattered across apps comes back as one answer, which can reveal more than any single screen did.
Growth. Every new scenario SAP ships widens what an SAP_ALL user can reach automatically, without anyone changing a role.

Check every scenario's identity

Principal propagation is the standard pattern, but not every integration uses it. Some agents or extensions call SAP with a technical or communication user. Then that user's authorizations apply, not the person's, and the audit trail shows the technical user. Check each scenario and agent you enable.

Does Joule go through MCP?

No. Standard Joule scenarios call S/4HANA APIs through SAP BTP destinations, and code-based agents connect to Joule over A2A, SAP's agent-to-agent route. MCP (Model Context Protocol) is optional. It comes in when Joule agents are given extra tools hosted on an MCP server, or when non-SAP AI assistants need a way to reach SAP.

That is why so many teams are building MCP servers for SAP even though Joule exists:

Many companies have standardized on a non-SAP AI assistant, and MCP is how it reaches SAP.
Joule's delivered scenarios focus on business processes. Custom Z objects, company-specific processes, and Basis and security analysis are largely not covered.
ECC and older on-premise systems cannot run Joule, but they can sit behind an MCP server.
Developers use coding agents with SAP's own ADT MCP server for ABAP work.
Agents that work across SAP and non-SAP systems need a common connector.

With MCP, is it everything they're authorized for, or only what's exposed?

Both limits apply. Effective access = the tools the MCP server exposes AND the authorizations of the identity behind the call. With principal propagation, an agent can only call the tools the server defines, and the backend still checks the real user's authorization objects.

That sounds safe. In practice, two things break it.

Pattern	What it means for an SAP_ALL user
Generic tools such as table preview, free SQL or code changes, common in open-source ADT MCP servers	"Only what's exposed" becomes every table in the system
Shared technical user, where the server logs in with basic auth or a service key	If that user holds SAP_ALL, everyone using the agent effectively has SAP_ALL, and the audit log shows only the technical user
Narrow business tools with principal propagation, such as a few specific OData services	Access stays limited to those services and to the real user's roles

There is also a contractual angle. SAP's API Policy (version 4/2026a, April 2026) has been reported to restrict third-party generative or autonomous AI systems that plan and execute sequences of SAP API calls outside SAP-endorsed routes such as Joule. Check your own contract before connecting third-party agents directly to SAP.

Five steps before any AI go-live

Remove SAP_ALL and SAP_NEW from production dialog users. Use firefighter IDs for break-glass access.
Review privileged access for your Joule pilot group first. Trim org levels and sensitive transactions.
Require principal propagation for Joule and every MCP server. Never put a shared SAP_ALL technical user behind an agent.
Expose narrow, business-specific tools, not generic table-read, free-SQL or code-write tools. Keep writes off by default.
Turn on the Security Audit Log for the AI channel, and actually review it.

AI doesn't break your authorization concept. It reveals it.

— SyntaAI Research

Syntasec by SyntaAI is an on-premises SAP security and compliance platform. It finds SAP_ALL holders, dormant privileged accounts and credentials stored in RFC destinations, and it complements SAP GRC rather than replacing it. The platform proposes findings, and a human on your team approves and executes any change. If you are preparing for a Joule rollout, we are glad to compare notes.

Preparing for Joule? Check your SAP_ALL exposure first

See how Syntasec finds every user with SAP_ALL, dormant privileged accounts and risky technical users, read-only and on your own infrastructure.

Request a demo

Sources

Some SAP pages could not be read in full by our tooling. Points marked "reported" come from secondary summaries, and the scope of Joule scenarios is our reading of SAP's capability documentation. Verify against your own release and contract.

Frequently asked questions

Do we need to remove SAP_ALL before deploying SAP Joule?

Joule does not technically require it and will work either way. But Joule adds no authorizations of its own: it runs as the signed-in user through principal propagation and inherits their roles. That makes the existing authorization concept the only real control, so SAP_ALL on production dialog users should be removed before go-live.

Can a user with SAP_ALL run anything through Joule?

No. Joule can only do what a Joule scenario or agent exists for. But every scenario that exists works for an SAP_ALL user with no organizational limits, across all company codes and data, and navigation can take them straight into transactions such as SU01, PFCG or SE16.

Does Joule call every app or API a user is authorized for?

No. Each Joule scenario is wired to specific APIs, and Joule calls only those. Joule can navigate a user to the apps on their launchpad, but it only reads data or takes actions where a scenario has been built by SAP or by you in Joule Studio.

Does Joule need MCP to reach SAP?

No. Standard Joule scenarios call SAP S/4HANA APIs through SAP BTP destinations, and code-based agents connect over A2A, SAP's agent-to-agent route. MCP is optional, for example to give Joule agents extra tools or to let non-SAP AI assistants reach SAP.

With MCP, can a user reach everything they are authorized for in SAP?

Effective access is the overlap of the tools the MCP server exposes and the authorizations of the identity behind the call. That limit is weak when a generic MCP server exposes table preview or free SQL, or when the server logs in with a shared technical user that holds SAP_ALL.