Joule Agent Authorization Testing: A Practitioner Guide

To test a Joule agent's authorization, you prove two things: the agent can only be invoked by the users you approved, and once invoked it can do no more than the signed-in user could do in the SAP application. Both checks have to pass, and they need separate evidence. Most agent test plans cover only the second one, and they usually skip the first.

This guide is for the functional and test leads who will sign off an agent before it reaches a production user. It covers the 2026 Joule Studio model, how it differs between S/4HANA Private Edition and Public Cloud, and the test pack I would want to see before I signed.

Why agent authorization is a different test from role testing

In classic SAP testing, a user runs a transaction and the authorization check happens in PFCG roles and authorization objects. An agent adds a layer in front of that. A user types a request into Joule, the agent decides which tool or API to call, and the call runs against S/4HANA. If the agent has its own broad service user, the old role design can be bypassed without anyone noticing.

SAP's current design avoids that. The agent holds no long-lived backend credentials of its own, and every backend call is executed against the real, logged-in user's permissions. That is the design principle. Your job is to prove it holds in your system, with your roles, for your agents.

The three authorization checks you are testing

SAP Cloud Identity Services (CIS) describes a three-layer authorization model for agents running in Joule. For the test plan, I break it into three checks:

• Agent access check (who may invoke the agent). To control which users or user groups can invoke an agent, use the Agents tile in the administration console. The gateway enforces this on every request, so a denied user should never reach the agent at all.
• Agent policy (what the agent may call). When an agent is deployed, SAP Cloud Identity Services registers it using the agent's own metadata and generates baseline authorization policies at that point. The agent can access only the APIs defined by its authorization policies. The target application also applies the user's own authorization checks.
• Target application check (what the user may do). This is the familiar S/4HANA layer. A community post on Joule and S/4HANA Private Edition describes how ABAP maps the identity to an SAP user, and after mapping, SAP authorization is evaluated in the normal backend security model.

The rule that matters most to your SoD and audit colleagues is the intersection. One third-party analysis of the CIS model summarizes it as an agent can never do more than its human principal could do. Treat that as the pass criterion for every test in this guide.

How the request flows, and where each test sits

Map each test case to one point in the flow below. A failure at one point looks different from a failure at another, and the fix owner changes.

1. User signs inIdentity is established through IAS or CIS before Joule acts.
2. Agent access checkGateway tests whether this user or group may invoke this agent.
3. Agent policyAgent may call only the APIs in its CIS authorization policies.
4. User mappingIdentity maps to the SAP user (principal propagation or certificate mapping).
5. Backend authorizationPFCG roles and authorization objects decide the result; SU53 shows the denial.

Build the test matrix before you open Joule Studio

Start with an inventory, not a test script. For each agent, record the following in your test log:

• Agent name, version and owner, and the Joule Studio project it came from.
• The agent identity that CIS created, and the date its baseline policies were generated.
• Every user group allowed to invoke it, with the business reason for each group.
• Every tool, skill, OData or BAPI service and MCP server the agent can call.
• The PFCG roles behind each business user in the pilot, including any SAP_ALL-style or broad debug access that should not exist.

Then build a matrix with one row per agent tool and one column per persona: the authorized user, the user with a partial role, the user with no role for that process, and the user who is invoke-denied. This matrix is the spine of your evidence.

Step-by-step: run the paired-user test

The most useful test in this area is the paired-user run. You send the same prompt from two users who differ only in one authorization. Here is how I run it.

1. Pick a business prompt that touches a protected object. For a purchase order agent, that might be a request to release a blocked PO. Use a prompt your users will actually type, not a clever one.
2. Run it as the authorized approver. Record the agent's trace, the tools it called and the final result. Confirm that the result matches what the approver sees in the native transaction.
3. Run it as a user who can see the PO but cannot release it. The agent should not complete the release. If it does, you have a finding, regardless of what the agent says in its reply.
4. Check the denial in the backend. Ask the Basis or security team to read the failed check in SU53 for the mapped user, or in the usual authorization trace. The denial should come from the SAP authorization check. A polite refusal in chat is not proof on its own.
5. Run the invoke-denied user. This user should be stopped at the gateway. Record where the request stopped, not just the message the user saw.
6. Repeat for each tool. Agents with several skills need a separate row per skill, because one skill may have a wider service user than another.

On the desk, this takes less time than it sounds. The expensive part is the role analysis you need to know which two users differ by exactly one authorization.

Use the Joule Studio test tools for behavior, not authorization

Joule Studio's own testing tools are useful, but they answer a different question. The Playground is where you find behavior problems. Validate the agent using Joule Studio's built-in "Playground" to simulate conversations and edge cases. The Agent Builder documentation describes debugging before deployment to see each step of its reasoning, actions and data flow, using mock conversations, tool-call scenarios and edge cases.

Mock data does not test the authorization model. A mock tool returns what you tell it to return, so a green Playground run says nothing about whether the mapped user can call the real API. Run the Playground for behavior, then move the same prompts to a test system with real users and real roles for authorization.

Evaluations are the other half. SAP's Joule Studio material says automated evaluations assess whether the agent behaved as intended, not just whether it ran. In one SAP webinar recap, the test suite covered structural, server, and agent tests. Ask for both the behavior evaluations and the authorization matrix. They are separate artifacts, and an auditor will ask for the second one.

For the full treatment of evaluation sets and non-deterministic answers, the free SAP Academy course Testing Joule Agents and AI Features in SAP: Evaluation Sets, Non-Determinism and Sign-Off goes deeper. For the build side of the same agent, the Building Joule Agents in Joule Studio course covers skills, grounding and evaluations.

What changes between Private Edition, Public Cloud and ECC

The authorization design depends on your edition, so write the test plan per landscape.

Area	ECC (classic)	S/4HANA Private Edition (Joule)	S/4HANA Public Cloud (Joule)
Who the agent acts as	Not applicable; custom integrations often used a technical user	The business user, mapped in ABAP from the propagated identity	The business user, propagated through IAS and token exchange
Where the identity is resolved	Not applicable	Cloud Connector and trusted ingress, then ABAP mapping	IAS, then a SAML or token exchange into the backend
What you test for denial	PFCG roles on the RFC or transaction	PFCG roles and authorization objects in the mapped user	Backend authorizations of the business user, plus gateway policies

For Public Cloud, one SAP Community walkthrough shows a custom A2A agent that holds no long-lived backend credentials of its own. That is the right pattern. What you still need to test is whether your custom code or a third-party tool quietly adds a service path.

Third-party agents need their own rows. SAP's CIS guidance says that the agent must be permitted at the gateway, must have scoped access to the APIs it requires, and its actions remain subject to the target application's own authorization checks. The Agent Gateway status also needs checking on the day you sign. A recent SAP architecture news item says that a customer administrator onboards the external AI client through SAP for Me as an Agent Gateway Consumer, and the customer explicitly defines which SAP Agents the client is allowed to invoke. An older SAP architecture page said the Agent Gateway is not yet generally available (GA). Confirm the release status for your tenant before you write the test as if the feature is live.

Evidence and sign-off: what to hand over

Your sign-off pack should be short and specific. I would not accept a deck of screenshots. Ask for these items:

• The authorization matrix, with each row marked pass or fail and linked to the gateway decision and backend result.
• The CIS agent registration and policy export for each agent version under test.
• The list of invoke groups, approved by the business owner and the security team, with the date of each approval.
• Paired-user traces for every protected tool, saved with the prompt, the user, the agent version and the timestamp.
• Results of the behavior evaluations, kept separate from authorization results.
• A retest rule: any change to the agent, its tools, or the S/4HANA roles it depends on reopens the affected rows.

The retest rule is the one teams drop first. Agents change more often than classic custom programs, and a role change in S/4HANA can alter an agent's result without any change to the agent itself. Put the agent version and the role transport numbers in the same log, so you can see when they drift apart. The AI Agent Guardrails & Approval Gate Register template is a starting point for that log.

Where to start on Monday

If you have one agent in pilot, start with the inventory and the paired-user run for its most sensitive tool. That single test shows whether your role design holds. Then expand the matrix. For the wider AI governance picture, the SAP AI for Practitioners guide explains how agents, Joule and the AI platform fit into your program. If your team needs the basics of Joule prompts before it writes agent instructions, the SAP Joule prompts guide covers that. For the edition-specific Joule capabilities, see Joule in S/4HANA Private Edition: What It Does by LOB.

Frequently asked questions

Does a Joule agent use the user's permissions or its own?

Under SAP's current model, the agent works within the signed-in user's authorization context. SAP Community material describes it this way: when accessing data or calling APIs, Joule operates under the initiating user's authorization context. You still need to test each tool, because the agent's own policy also limits what it can call.

Is the Joule Studio Playground enough to test agent security?

No. The Playground is for behavior and edge cases, and it can run against mock tools. Authorization needs real mapped users in a test system, plus the backend check for each denial. Keep the two results separate in your sign-off pack.

Where do I see why an agent request was denied?

Start with the gateway decision for invoke access, then the mapped user's backend authorization. For backend denials on the S/4HANA side, the SU53 display for the mapped user shows the failed check. Confirm the exact logs your Basis team uses in your landscape, because the tooling varies with the edition and the connectivity setup.

Do I need to retest agents after each S/4HANA quarterly update?

Yes, if the update touches the authorization objects, the roles or the APIs an agent calls. The agent itself may not change, but the result can. Reopen the matrix rows for every tool that depends on a changed role or service, and record the release in your evidence log.

Sources

1. Agents, SAP Cloud Identity Services, SAP Help Portal
2. Managing Agents, SAP Cloud Identity Services, SAP Help Portal
3. Use Existing Agents, Build New Ones, Connect to Others, All Securely with SAP Joule Work, SAP Community
4. From Prompt to Permission: How Joule Securely Accesses SAP Cloud ERP Private, SAP Community
5. Joule A2A: Propagate the User Identity from Joule into S/4HANA, SAP Community
6. Third-party agents can now interoperate with SAP Agents via the Agent Gateway, SAP Architecture Center, October 2026
7. Build AI Agents on SAP Business AI Platform, SAP Architecture Center
8. Agent builder in Joule Studio is now generally available, SAP Community
9. From Prototype to Production with Joule Studio: Recap of Session 4, SAP Community
10. Content-based Agents with SAP Joule Studio Agent Builder, SAP BTP AI Best Practices
11. Creating an AI Agent with Joule Studio, SAP Learning
12. Use Joule Studio to Create an Agent, SAP Developers
13. SAP Joule Authorization Model 2026: CIS, SoD, Audit, nashcon, October 2026 (third-party analysis)