Securing the Autonomous Enterprise: SAP Cloud Identity Services, Joule & Agentic AI

This article is based on my review of SAP’s July 16, 2026, security webcast, SAP’s published materials, and my experience working with SAP Security, GRC, IAM, and access governance across enterprise SAP environments. I’m particularly interested in how the introduction of AI agents changes the identity and authorization model that SAP security teams have traditionally managed.

I’ve attended this interesting security webcast on SAP Cloud Identity Services supporting Agentic AI and SAP Managed scenarios on July 16, 2026, by Marko Sommer, Product Manager SAP Cloud Identity Services, SAP , and Sonia Petrescu, Product Manager SAP Cloud Identity Services, SAP . It was an interesting webcast that details how SAP Cloud Identity Services play a critical role in enabling the Autonomous Enterprise and securing identity and access management for business users and agent identities. The webcast also details how these agents can be used to act on behalf of a user or work as standalone agents. It explained how SAP managed IAM scenarios simplified the administration tasks required. I have outlined this article based on my learnings from the webcast and research, coupled with my project experience.  

Let’s dive into the topic.

For the last several years, SAP Security teams have been dealing with a familiar question: who has access to what?

We built roles, authorization objects, access request workflows, privileged access controls, and periodic access reviews around that question.

Agentic AI changes the question.

If a user asks an AI agent to perform a business activity, the human may no longer be the identity directly executing every step. The agent may interpret the request, retrieve information, invoke services, and ultimately trigger an action.

So the question becomes:

Who is actually allowed to do what when an AI agent is involved?

With the introduction of agents, users might not be performing the work directly. Instead, they may use an AI agent to execute an activity, understand the business context, access information, invoke services, and take action. These activities may be performed on behalf of a user or a business process.

This creates a fundamentally different identity and access challenge for SAP security teams and triggers the following questions:

• Does the AI agent have its identity? 
• Is it acting with the user's authority? 
• What specific access does it have? 
• Who approved that access? 
• Who is ultimately accountable for the action performed by the agent?

As SAP brings together Joule, SAP Business AI Platform (BAIP), Knowledge Graph, AI agents, and SAP Cloud Identity Services, these questions are becoming increasingly important.

This article explores what should change in your thinking when the ‘user’ is no longer a human, why agent identity is emerging as a critical security concern, how identity and authorization fit into SAP's Agentic AI architecture, and what security teams need to consider when outsourcing work to AI agents.

For the readers who are new to this topic, I would like to introduce the core terminology before I deep dive into the topic.

SAP Joule?

SAP’s generative agentic AI co-pilot solution is named "Joule." It spanned from a simple AI assistant to a complete interface for performing business processes and orchestrating AI agents. Joule agents are easy to set up, integrate, and use in SAP environments. 

What is SAP Business AI Platform?

SAP Business AI Platform (BAIP) is the new entry into SAP’s portfolio that offers a platform to build, deploy, and orchestrate AI capabilities across SAP’s business applications, data and processes. This connects AI models, agents, business context, and enterprise data. 

What is the SAP Knowledge Graph?

The SAP Knowledge Graph is the business context layer, which enables AI to comprehend the true operations of an enterprise.

While AI can extract and analyze data from enterprise databases, business data is rarely analyzed such as vendors, customers, sales orders, products, organizational structure, and so on. 

SAP Knowledge Graph models these relationships to ensure that Joule and AI agents are aware of the interrelations between the various components of the business, in addition to the messages from the users. SAP calls it a “semantic layer” connecting data, processes, and relationships so that artificial intelligence can reason with business context. 

Since the intent of this article is broad, I suggest SAP Security Expert readers learn more about Knowledge graph using the SAP’s official link .

Here is the high-level architecture:

SAP Joule → SAP Business AI Platform → Knowledge Graph → AI Agents → SAP Applications

Why Agentic AI Changes the Identity Model

Traditional IAM was largely designed around a human or a defined technical identity performing an activity. Agentic AI introduces additional identity and authorization scenarios that those models were not originally designed to address.

An AI agent may act on behalf of a human user or operate autonomously. It may interpret instructions, maintain context, invoke tools or APIs, and trigger actions across business applications. That introduces additional questions around identity ownership, delegated authority, capability scope, credential protection, and accountability.

For SAP Security teams, the important point is not that traditional IAM disappears. Rather, additional authorization and governance decisions are introduced around the agent before the request reaches the application's existing authorization model.

What is “Agent Identity”?

Before we go deeper into governance, let’s first understand what SAP means by an "Agent identity". SAP breaks agents down into three defining characteristics:

• They are applications.
• They utilize large language models (LLMs).
• They have memory and feedback loop.

SAP describes two basic operating scenarios for any agent: 

1. it can act for a human identity (i.e. as a delegate), or 
2. it can act completely autonomously, with its own standing permissions. (Referred to as autonomous agents.)

It is necessary to regulate both scenarios; however, the regulation of a delegated agent should be limited by the actions of the user it represents, but an autonomous agent requires a more carefully defined set of permissions.

Three concrete artifacts are introduced by SAP Cloud Identity Services (CIS) to implement either scenario:

1. An application trusted by the SAP Agent Gateway - the technical trust relationship that makes the agent requests trusted.
2. An agent user with a global user ID - this gives the agent its own addressable identity in the system, independent of any human user it may be acting for.
3. Policy and role assignments - the real permissions layer defining what the agent identity can do.

This is a major design decision. Instead of creating a new governance system from scratch for agents, SAP simplified it by extending existing identity infrastructure that is used for the management of human users by adding agent-specific artifacts.

The Three-Layer Authorization Model

The most important part of the technical aspect, and for anyone architecting or auditing an agentic AI deployment, is how authorization checks actually happen when an agent tries to carry activities. In SAP terminology, this is referred to as a three-part check, ranging from broad access to fine-grained, attribute-level permissions. Each layer has a different job and is in a different place in the architecture and is enforced via a different mechanism.

The logic is essentially a funnel. The below diagram outlines how it validates:

• The first check is a gate: can this identity use the agent at all? 
• The second check is a scope negotiation: given that the agent is in use, what is it functionally allowed to invoke, and importantly, does that get intersected with the permissions of the human on whose behalf it might be acting, so an agent can never exceed what its human principal could do? 
• The third check is the familiar, granular authorization logic that SAP applications have always performed.

Important: Current capability vs. roadmap

Not every element of the authorization model described above should be interpreted as generally available functionality today. SAP's webcast identified parts of the scoped authorization model, particularly the intersection between agent and human permissions, as roadmap items.

Therefore, security architects should distinguish between the authorization model SAP is defining and the capabilities currently available in their specific SAP environment.

Where Governance Actually Lives

SAP identified four components that together make up SAP's agent governance stack, as outlined in the below image:

• SAP Agent Hub provides visibility into the overall agent landscape, essentially the inventory and oversight layer.
• SAP Joule Studio allows agents to be created directly out of a conversation, lowering the barrier to building new automations.
• SAP Agent Gateway encapsulates agent-to-agent and agent-to-system communication, acting as the traffic cop described in the authorization table above.
• SAP Cloud Identity Services is where the actual agent identity lives, where policies are managed, and where tokens are issued to agents for use across SAP systems. This is being positioned as the single source of truth for both human and agent identity across the SAP landscape.

The Bigger Shift: SAP-Managed IAM

The major part from agent-specific concerns a broader change in how SAP wants to handle identity configuration generally, which is framed as a change in the shared responsibility model.

Historically, setting up identity and access management for SAP cloud solutions has been a customer-driven, often labour-intensive project. This with a "before and after" comparison for Joule specifically:

This SAP-managed approach has the below few pillars:

• The customer still decides what to integrate - that business decision doesn't go away.
• Tenant and solution activation, along with integration selection, happens through the SAP4ME management interface.
• The technical SAP-to-SAP integration work is handled automatically.
• Monitoring and operations become a shared responsibility between SAP and the customer, rather than resting entirely on the customer's team.

What is Managed by SAP?

Going one level deeper, the SAP detailed four specific aspects of what happens when SAP manages the Suite applications’ IAM setup:

Initial provisioning: When an administrator starts provisioning using SAP4ME, SAP automatically creates the initial application roles and sets up an SAP-managed IAM integration, including configuring Identity Authentication Service (IAS) as the authenticating identity provider and scheduling SAP-managed Identity Provisioning Service (IPS) jobs for user and role assignments. The applications publish roles that can be used by administrators to continue adding any additional users needed for initial setup and to maintain user-role assignments.

Identity provider configuration: Administrators can configure a third-party idP as the authentication source with IAS (acting as a proxy that delegates authentication back to the corporate IdP) or use IAS directly. Administrators can choose any path to maintain customer-specific information at the Suite level, including branding, password and privacy policies, and risk-based authentication rules. Technical details that are not relevant for the customer are intentionally hidden.

Authorization management: Depending on the application type, administrators define authorizations either directly in SCI (SAP Cloud Identity Services) (for XSUAA/AMS-based BAIP applications) or within the respective SAP Cloud application itself (for non-BAIP applications). Composite roles, bundled collections of groups - are built from published application roles, either in a third-party identity management tool or directly in Identity. Notably, composite roles in SCI (SAP Cloud Identity Services) were flagged as a planned rather than fully available capability. The upside for administrators is a single, central view of authorizations across the SAP application portfolio.

Identity lifecycle management: The two distinct paths here. With a third-party IDM tool in place, an HR administrator creates an employee in SAP SuccessFactors, a corresponding user gets created in the third-party IDM, roles are assigned, and the information is replicated to SCI (SAP Cloud Identity Services) which is customer managed and will be replicated to all connected SAP applications that are SAP managed. Without a third-party IDM tool, SuccessFactors integrates directly with SCI (SAP Cloud Identity Services) for user creation and role assignments automatically.

What Security teams should start thinking about 

If I were reviewing an AI agent as part of an SAP Security assessment today, I would add a different set of questions to the traditional access review.

This is where I believe SAP Security teams need to rethink existing access governance practices. Agent governance cannot simply become another checkbox in an existing role-review process. The identity, capability, delegation, and execution chain all need to be understood.

My SAP Security checklist for AI agents

Final Thoughts

SAP clearly does not see agent security as a separate problem requiring a separate set of tools. Instead, it is extending its existing identity backbone, SCI (SAP Cloud Identity Services), to take care of a new category of identity while at the same time shifting more of the IAM operational burden onto itself via SAP-managed scenarios. 

For customers, the model can mean less manual configuration effort, while also creating greater dependence on SAP's managed architecture and roadmap for capabilities such as scoped authorizations and composite roles that are still under development.

Sources and further reading

• SAP Cloud Identity Services supporting Agentic AI and SAP Managed scenarios—SAP webcast, July 2026
• SAP presentation accompanying the webcast 
• SAP Knowledge Graph documentation 
• SAP Business AI / Joule documentation
• SAP Cloud Identity Services documentation