What are non-human identities in SAP?

Non-human identities are autonomous agents, applications, bots, APIs, service accounts, and machine identities that authenticate and perform actions within SAP systems. As AI agents become embedded into enterprise processes, organizations must extend traditional SAP Security and GRC controls beyond human users to govern these new digital actors.

When Agents Become Users: Governing Non-Human Identities in SAP's Autonomous Enterprise

Emerging Governance Challenge

Your newest privileged user was never hired, never onboarded, and doesn’t appear in any access review.

It is an autonomous agent, and it can run an entire end-to-end process under its own identity.

As organizations embrace SAP's Autonomous Enterprise vision, a new governance challenge is emerging. Autonomous agents are becoming active participants inside business processes, often operating with authorizations, responsibilities, and risks that existing access governance models were never designed to manage.

Before exploring the governance challenges introduced by autonomous agents, it is helpful to understand how the execution model itself is changing.

The shift is subtle but important: users are increasingly moving from executing transactions themselves to invoking agents that execute business processes on their behalf.

Figure 1. Traditional SAP governance assumes users execute transactions directly. In the Autonomous Enterprise, users increasingly invoke agents that execute processes using their own identities and authorizations.

The assumption beneath every access control

Imagine arriving at work on Monday morning and discovering that a vendor was created, bank details were changed, an invoice was posted, and a payment was released before anyone reviewed the activity.

No account was compromised.
No approval was bypassed.
No control technically failed.
Every action was performed by an authorized identity.
The only problem is that the identity was not a person.

The actor that performed all of them was an agent provisioned to run procure-to-pay end to end, and the access review that should have caught the conflict never included it. The person who triggered the agent holds almost no access of their own.

Nothing in that sequence required a breach. It required an actor the access model was never built to see.

SAP access governance has always rested on one assumption: the actor performing a transaction is a named human user. Identity management, role design, Segregation of Duties analysis, emergency access, all of it is built on that single idea - A user requests access. An approver grants it.

The system records who did what. Accountability lands on a person.

That assumption is now beginning to change.

SAP's Autonomous Enterprise vision introduces a new category of actor into enterprise processes: autonomous agents that can authenticate, make decisions, and execute transactions with varying degrees of human involvement.

Before an agent can make a decision, it must authenticate, receive authorizations, access business data, and interact with business processes.

At SAP Sapphire 2026, SAP positioned the Autonomous Enterprise at the center of its future enterprise strategy. More than 200 agents and over 50 assistants are arriving across five domains:

Autonomous Finance
Autonomous Spend
Autonomous Supply Chain
Autonomous HCM, and
Autonomous CX.

These are not assistants that summarize a report or answer a question. They create master data, validate conditions, post documents, and release transactions, often with little human involvement.

What We Are Seeing in Customer Conversations

Over the last few months, conversations around SAP Business AI have shifted noticeably. Organizations are no longer asking whether they should adopt AI. They are asking how they can govern it.

The most common assumption we encounter is that agent governance is primarily an AI governance or AI ethics problem.

In reality, it is often an identity and access governance problem first.

In our discussions with SAP customers, one theme appears consistently. Organizations are investing significant effort into defining AI use cases, but considerably less effort into defining how those agents will be governed once they enter production. That gap is where many of the future control challenges will emerge.

Security teams should care because autonomous agents introduce governance questions that existing SAP security frameworks were never designed to answer consistently.

Before deploying autonomous agents into production, organizations should be able to answer five governance questions:

Who owns the agent?
Who approved its access?
How is its activity monitored?
How is its access reviewed?
Who remains accountable for its actions?

The actor model underneath SAP access governance now has a participant it was never designed to hold: the autonomous agent.

The reflex in most security teams is to treat this as a policy question. It is one, but the policy cannot be written until the mechanics are clear. Before you decide how to govern an agent, you have to be precise about what an agent is inside the landscape, how it authenticates, and where its authorizations come from.

How an agent actually holds access in SAP

From a governance perspective, one question matters more than any other:

Is the agent acting as itself, or is it acting as the user?

Everything else follows from that answer.

In the current architecture, agent identities sit in the SAP Cloud Identity Services Identity Directory, next to human identities, and are provisioned through Identity Provisioning using the same lifecycle the workforce runs on, including SCIM-based replication and a consistent global user identity across products. SAP frames this as a unified governance model for a new class of actor. The practical implication for security teams is straightforward: an agent is now a first-class identity living in the same directory as your people.

How that identity acts on a backend comes down to one design decision, and the entire control conversation turns on it.

The distinction may appear technical, but it fundamentally changes who carries the risk, who is reviewed, and where governance controls should be applied.

Figure 2. Autonomous agents typically authenticate using either delegated user credentials or dedicated service identities. Each approach introduces a different governance and control challenge.

The first pattern is application-to-application authentication, usually the OAuth 2.0 client credentials flow. The token identifies the agent, not the person who triggered it. The agent calls the backend under its own identity and its own authorizations: scopes and role collections on SAP BTP, or a communication user provisioned through a communication arrangement in S/4HANA. The invoking user's access never enters the request.

The second pattern is principal propagation. The agent carries the identity of the person through the call chain, and the backend evaluates the request against that user's authorizations. The agent acts with the user's access, not its own.

This is not a footnote. It decides which identity carries the risk, which identity an auditor analyzes, and where Segregation of Duties is actually evaluated.

One more enforcement point sits between agents. SAP routes agent-to-agent traffic through an Agent Gateway that verifies identity and checks authorization policy at each hop, rejecting out-of-scope requests before they propagate. That governs whether a call can proceed. It does not decide whether the underlying authorization should have existed in the first place. That stays a governance question.

Source: SAP Architecture Center, Identity and Access Management for SAP Joule

Whether an agent borrows a user's access or holds its own changes the whole control problem. Most organizations have not decided which pattern they are running, let alone governed it.

What SAP built, and where control responsibility sits

SAP structures the Business AI Platform in three layers. Security teams should know where to establish the right controls.

Figure 3. The three layers of the SAP Business AI platform, viewed through a Security and GRC lens.

The context layer decides what an agent can reach: the processes, services, and data exposed to it. The build layer, anchored by Joule Studio, is where organizations and partners build their own agents, connect them to SAP and non-SAP data, and deploy them with role-based access mapped to SAP authorization objects. The governance layer is anchored by SAP AI Agent Hub, which leverages SAP LeanIX capabilities to provide visibility, discovery, verification, and lifecycle governance for AI agents across the enterprise.

Each layer lands on a control discipline you already run. The context layer is an authorization design question. The build layer is a provisioning and Segregation of Duties question. The governance layer is an inventory, certification, and monitoring question. The platform supplies the capability at every layer. It does not supply the control decision. That part is still yours.

The governance layer is a system of record, not a control framework

The AI Agent Hub is an inventory and verification layer, not a monitoring dashboard. SAP positions AI Agent Hub as a central system of record for AI agents, large language models, and Model Context Protocol (MCP) servers across the landscape.

Two things make it matter from a control standpoint. First, it does not wait for manual registration. It auto-discovers agents across SAP, Microsoft, Google, AWS, and ServiceNow, and SAP has indicated the underlying capability already manages more than 100,000 agents across 150 organizations. Second, it enforces verification: an agent or server without a verified governance record can be kept out of production, and access is revoked when verification status changes. The Q3 2026 release adds agent identity management through SAP Cloud Identity Services, with session-level observability and performance monitoring.

Security teams should avoid a common misconception. Visibility does not automatically create governance.

An inventory helps answer what exists. Governance determines what should exist, who owns it, and whether its access remains appropriate.

A complete, verified list of agents that have not actually been governed is simply a well-documented record of exposure.

Segregation of Duties was built for one identity at a time

Once an agent has an identity and authorizations, the next question becomes unavoidable: how do existing SAP governance controls evaluate the risk it introduces?

SAP GRC Access Control evaluates risk one identity at a time. The Access Risk Analysis ruleset is built from Functions, each defined by Actions, the transactions or services involved, and Permissions, the underlying authorization objects and field values. Functions combine into Risks at a defined risk level, and a user either holds a conflicting combination or does not. User Access Reviews and SoD reviews recertify those results on a cycle. The model is mature, and for human users analyzed one at a time it works.

Autonomous agents stress it in three distinct ways, and the authentication pattern decides which one you are facing.

The first is the agent that runs under its own identity. A communication or technical user provisioned for an end-to-end process like procure-to-pay can quietly accumulate the authorization to create a vendor and to run the automatic payment run. Analyzed on its own, that is a textbook Segregation of Duties conflict. The trouble is that these identities usually fall outside the population anyone reviews. Technical and communication users are excluded from User Access Reviews by convention, which means the one identity now running the process end to end is the one identity nobody recertifies. The first fix is unglamorous and non-negotiable. Bring agent identities into the ARA ruleset and into review scope, and analyze them as the privileged identities they are.

The second is the agent that runs under principal propagation. Here ARA keeps analyzing the human user, which is correct, but the assumption under many mitigating controls quietly fails. A latent conflict that was accepted because it never fired in normal operation now has an actor that will fire it, again and again. Mitigations written around human behaviour, the comfortable assumption that one person would not realistically perform both halves of a conflict, stop holding the moment an agent performs both as routine. Every behaviour-based mitigation on a propagated user needs to be re-examined on exactly that basis.

The third is the combination, and this is the genuinely new exposure. Assume a user with deliberately narrow access who can invoke an agent that runs under client credentials with a broad scope. ARA sees a low-risk user. It separately sees an agent identity, if that identity is in scope at all. It never sees the path that connects them. In plain terms, the right to invoke the agent has become an authorization, and the user's real capability is the union of what they hold directly and what the agent will do on their behalf.

The effective authorization of an agent-enabled user no longer shows up in a single ARA report. It is spread across the user, the agent, and the right to connect them.

Traditional SoD analysis evaluates what a user can do. Agent-enabled environments must evaluate what a user can trigger.

An agent can execute both sides of a Segregation of Duties conflict repeatedly and at machine speed while the report still shows green.

Governing this means treating invocation rights as access: map which roles and users can trigger which agents, and analyze that path alongside the conventional ruleset, not in a separate exercise nobody links back.

Emergency access assumes a human who checks out

Emergency Access Management rests on a sequence of human actions.

A named Firefighter checks out a Firefighter ID, picks a reason code, does the work inside a bounded window, and a Firefighter Controller later reviews the consolidated log that pulls together transaction usage, change documents, the system log, the Security Audit Log, and any debug-and-replace or operating system activity. Every step assumes a person. Someone to attach intent to. Someone whose session can be reviewed. Someone who is accountable.

An autonomous agent satisfies none of it. It does not interactively check out an ID through the launchpad. There is no human to attach a reason code to. The consolidated log review, designed around a human session, has nothing to anchor to.

A common mistake is granting standing privileged access to agent identities so they can handle exceptions without interruption. This recreates the very risk Emergency Access Management was designed to control. The safer model is narrow standing access combined with time-bound elevation and complete auditability.

Process Control for an actor that never sleeps

Process Control assumes a rhythm of activity that agents do not keep. Automated controls and Continuous Control Monitoring evaluate business rules against data sources, and the cadence of review was tuned to human throughput. An agent runs continuously, which makes exception-based automated monitoring more important, not less.

The data sources are already familiar. CCM rules can watch change documents for vendor bank detail changes, filtered to the agent and communication users that should rarely if ever make them. They can watch finance postings created under an agent identity above a defined threshold. They can flag execution of the automatic payment run under an identity that is not an authorized controller. A confirmed exception routes to a control owner through the deficiency workflow.

The change that matters is conceptual, not technical. Periodic review and sampling were built on the quiet assumption that a person can only do so much in a day. An agent removes that ceiling. Monitoring has to start from the premise that anything an agent is permitted to do, it may do continuously, and the control frequency has to reflect that.

What an agent can read is a new disclosure surface

There is a quieter risk that never shows up in a Segregation of Duties report. Whatever an agent can read, it can surface. Ground an agent in business data and its read scope becomes a disclosure surface, and data can leave through a generated response instead of a download.

This is where access governance meets data protection. The authorizations that decide what an agent can read, table access through S_TABU, the function modules reachable through S_RFC, the OData services exposed to it, deserve the same minimization you apply to any privileged identity.

Read Access Logging (RAL) should be configured for the sensitive fields an agent can reach, so access to personal or otherwise protected data is recorded. Unified Connectivity (UCON) can constrain the RFC surface available to the agent's identity. Across data protection regimes worldwide, from the GDPR to the national frameworks modelled on it, the governing test is the same: purpose limitation.

The agent should read what its task requires and nothing more, and that read access should be logged.

Aligning to emerging AI governance frameworks

The regulatory context points the same way. The EU AI Act, Regulation (EU) 2024/1689, brings its high-risk obligations into full effect in August 2026, covering risk management, data governance, human oversight, and accuracy. ISO/IEC 42001 provides a certifiable AI management system that extends existing ISO/IEC 27001 practice into AI-specific areas like human oversight and lifecycle control. The NIST AI Risk Management Framework offers a structured way to identify and manage AI risk.

Source: EU AI Act, Regulation (EU) 2024/1689 · NIST AI Risk Management Framework

For control monitoring specifically, ISACA's COBIT framework keeps making the point that control effectiveness depends on usage-based and performance-based evaluation, not just confirmation that a control ran. The same holds for agents. A registered and verified agent can still operate well outside its intended purpose.

Source: ISACA COBIT

The most useful artifact a security function can build out of all this is a single control crosswalk. A well-designed agent recertification gate works at once as an access control, a human oversight measure under the EU AI Act, a lifecycle control under ISO/IEC 42001, and an IT general control under SOX. Showing that one control satisfies several obligations is how AI governance turns into evidence of control maturity instead of another standalone program.

A Practical Governance Framework for SAP Agents

While technologies, platforms, and agent architectures will evolve, these six governance questions remain relevant regardless of how autonomous agents are implemented.

Governance Area Key Questions

Governance Area	Key Question
Ownership	Who owns the agent?
Identity	How does it authenticate?
Access	What authorizations does it hold?
Monitoring	How is activity reviewed?
Accountability	Who is responsible for outcomes?
Lifecycle	When should it be recertified or retired?

Figure 4. A practical governance framework for governing AI agents and non-human identities in SAP.

Organizations that answer these six questions consistently will be significantly better positioned to govern autonomous agents than those relying solely on traditional user-centric controls.

Closing perspective

For decades, SAP Security programs were built around a simple assumption: every action could ultimately be traced back to a human user.

The Autonomous Enterprise changes that assumption.

Autonomous agents are becoming participants in business processes, holding identities, authorizations, and decision-making responsibilities of their own.

The challenge for security and GRC teams is not learning how to govern AI.

It is extending proven governance principles to a new category of actor.

Because in the Autonomous Enterprise, not every user is human anymore.