Last updated: October 17, 2026
When a user performs an incorrect transaction in SAP, we can usually trace it. We know who the user is, which roles they have, and their actions are recorded in the logs. If they have excessive privileges, their role can be restricted; when they leave the company, their account can be disabled.
But what happens when the same action is performed by an AI agent?
And what if that agent does more than execute a single transaction—calling other tools, retrieving data from different systems, delegating tasks to another agent, and completing in seconds a chain of activities that would take a human user much longer?
We may be entering one of the most critical stages of the AI debate in the SAP world.
Until now, the discussion has largely focused on one question: “How much time can AI save us?” The next question is more difficult:
How much authority are we prepared to give these digital workers, and how will we control what they do?
This is no longer a theoretical security discussion. SAP is making the ability of AI agents to operate in real enterprise systems, invoke tools, execute business processes, and work across applications an increasingly important part of its product architecture.
The OpenShell initiative being developed by SAP and NVIDIA is one concrete example of this need. OpenShell, an open-source project developed by NVIDIA, is designed to provide AI agents with an isolated, authorized, and auditable runtime environment. SAP is also working to integrate OpenShell into the Joule Studio runtime to strengthen runtime security for AI agents. This integration is still under development.
Why Is an AI Agent Different from a Traditional SAP User?
From an SAP security perspective, the first instinct is understandable:
“We will create a user for the agent and assign the necessary roles.”
But the issue is more complex than that.
A traditional user typically performs actions through a specific screen or application. An AI agent, by contrast, operates toward a goal. It can interpret a request, decide which tools to use, call an API, retrieve information from another system, and determine the next step based on the result.
Open standards adopted by SAP, such as MCP (Model Context Protocol) and A2A (Agent2Agent), are intended to enable AI agents to work not only within SAP, but also across different agents, applications, and tools.
However, this architecture is not yet fully mature. According to SAP’s reference architecture dated October 9, 2026, bidirectional communication with third-party and self-hosted agents through Agent Gateway is not yet supported. This shows that SAP’s approach to agent interoperability is still evolving.
Table: A Five-Layer Trust Model for AI Agents
| Layer | Core Question |
|---|---|
| Identity | Who is the agent, and on whose behalf is it acting? |
| Access | What can it access, and which actions is it allowed to perform? |
| Boundary | Which data sources can it trust, and which tools, APIs, and agents can it invoke? |
| Traceability | Can its actions be explained and reconstructed after the fact? |
| Brake | How quickly can it be stopped when something goes wrong? |
Identity First: Who Is This Digital Actor Operating Inside the System?
It is relatively easy to think about enterprise identity management in terms of human employees.
An employee joins the company. A user account is created. Authorizations are assigned according to their role in the organization. If their responsibilities change, their permissions are adjusted. When they leave the company, their account is disabled.
It is becoming increasingly clear that AI agents need a similar identity lifecycle.
The Agent Identity approach being developed within SAP Cloud Identity Services is one concrete example. SAP’s current documentation describes agents as separately registered identities, with controls over which users may invoke them and how their access policies are managed.
There is, however, an important distinction.
Under the model documented by SAP Cloud Identity Services as part of the Early Adopter Care program as of October 2026, agents are invoked within a user context. The user must be authorized to access the relevant agent, and the agent cannot exceed the invoking user’s existing authorizations in backend systems.
But a user’s backend authorizations are only one layer of security. The tools an agent can access, its API scope, its relationships with other agents, and its runtime policies must also be governed separately.
At the same time, SAP’s AI-native target architecture points toward a more advanced model in which agent identities and lifecycles are managed as more independent enterprise entities. This makes it important to distinguish between how the technology works today and SAP’s longer-term architectural direction.
That distinction matters. It would be misleading to suggest that agents can simply be given unrestricted technical users and allowed to operate independently across SAP environments today.
But the direction is clear: AI agents are becoming more than software components. They are emerging as a new class of digital identity whose ownership, authorizations, access policies, and lifecycle all need to be governed.
“The Agent Can Do It” Does Not Mean “The Agent Should Do It”
This is where the real security challenge begins.
It may be perfectly reasonable for a procurement agent to compare supplier quotations. But should it also be allowed to create a purchase order? Can it create an order above a certain value without approval? Can it create a new supplier? Can it change a supplier’s bank account details?
The fact that an action is technically possible does not mean the agent should be authorized to perform it.
The principle of least privilege, which SAP security teams have applied to human users for years, may become even more important for AI agents. An autonomous system with excessive permissions can reproduce an error far faster and at a much greater scale than a human user.
For that reason, agent access management cannot simply be a new version of traditional role-based authorization. Access may need to be evaluated in the context of the agent’s purpose, transaction type, data sensitivity, organizational scope, financial limits, and the risk associated with the action itself.
Should Segregation of Duties Be Rethought for a World of AI Agents?
SAP Security and GRC (Governance, Risk and Compliance) teams have worked with one principle for many years:
Segregation of Duties (SoD).
For example, the same user should not be able to create a supplier and execute the payment, or both create and approve a purchase order.
But what happens if two different AI agents perform those tasks?
Agent A creates the supplier. Agent B prepares the payment.
The two agents may have different technical identities. But if both are operating toward the same business objective as part of the same orchestration, is traditional SoD control still sufficient?
It is still too early to speak of an established SAP standard for this scenario. But the question is already important.
In the future, Segregation of Duties controls may need to assess not only user-role combinations, but also the chains of actions performed collaboratively by multiple agents.
This may become one of the next frontiers for GRC.
Further Reading
ou can check out our guide, From Screens to Intent in SAP: How Joule Work Will Change the Way We Work with SAP, to explore how SAP user experience is evolving from screen-based tasks to intent-driven AI agents.
MCP and Third-Party Agents Are Expanding the Security Perimeter
The value of AI agents does not come only from what they can do inside SAP. Their real potential lies in their ability to work across different systems.
MCP (Model Context Protocol) is critical in this context.
An agent can use an MCP server to access an enterprise tool or data source. It can also delegate tasks to another agent through A2A. SAP Integration Suite is likewise developing capabilities to expose existing APIs as managed MCP services that agents can consume.
But as the number of connections grows, so does the security perimeter.
Organizations now need answers to a new set of questions:
Who trusts this MCP server?
Which tools is it allowed to use?
Which data can it access?
Which SAP actions can a third-party agent trigger?
How quickly can access be revoked if the trust level changes?
That is why SAP AI Agent Hub’s approach to blocking unverified MCP servers from production workflows — and revoking access when verification status changes — is particularly significant.
The security boundary of the enterprise no longer ends at the SAP system itself.
Can an Agent Be Manipulated Even When Its Authorizations Are Correct? The Prompt Injection Risk
Even when identity and authorization are properly designed, AI agents face a different class of security risk: prompt injection, particularly indirect prompt injection.
An agent may encounter a malicious instruction hidden inside an email, document, web page, or external data source and interpret it as a legitimate business input.
That means the question is no longer only, “What is the agent allowed to access?”
Organizations must also decide which sources the agent is allowed to trust, how external content should be constrained, and which policy controls critical actions must pass through before execution.
In agentic security, authorization and trust are not the same thing.
An agent may be fully authorized to perform an action, while the input that triggered that action may still be untrusted.
The Invisible Risk: Shadow Agents
Another governance risk is the emergence of shadow agents — agents that are not included in the central inventory maintained by IT and security teams.
Users may connect their own AI tools to SAP APIs, MCP servers, or third-party integrations, creating new access paths outside the organization’s established control framework.
For this reason, an agent inventory must answer more than the question, “Which agents have we officially approved?”
It must also answer:
Which agents are actually connecting to SAP?
Audit Trail Is No Longer Just About “Who Did What?”
One of the most basic questions in any audit is:
Who performed which action, and when?
With AI agents, several additional questions become relevant:
Why did it perform the action?
Which request triggered it?
Which tool did it use?
Which data did it rely on?
Did it delegate part of the task to another agent?
Was human approval involved?
In an agentic AI environment, seeing only the final transaction may no longer be enough.
Organizations may need to reconstruct the full path of the action: which user context initiated it, which agents and tools were involved, and which sequence of steps ultimately produced the transaction.
According to SAP’s AI Agent Hub reference architecture, telemetry collected from supported SAP-managed agent environments is used for different purposes. Operational monitoring data is sent to SAP Cloud ALM, while agent execution traces — which show the sequence of steps followed by an agent — are sent to SAP Signavio Process Intelligence for behavioral process analysis.
SAP AI Agent Hub’s centralized governance approach, built on SAP LeanIX, also supports making agents, their connections, and related components visible in a shared enterprise inventory.
This is where security and observability increasingly begin to converge.
Audit is no longer only about maintaining a transaction log. It is about being able to reconstruct how an agent acted, which tools it used, and which chain of actions ultimately led to the outcome.
Where Is the Brake?
In enterprise AI security, there is another issue that matters just as much as authorization:
How quickly can we stop an agent when it starts behaving incorrectly?
Human errors usually spread at human speed; agent-driven errors can propagate at automation speed. In agentic systems, the risk is therefore not only whether an error can occur, but also how many transactions, processes, or connected systems it can affect before anyone intervenes.
An agent may execute dozens of actions within seconds.
And once the problem is detected, simply saying “we will roll it back” is not always realistic. A business document created in SAP may already have triggered other documents, integrations, accounting entries, or outbound messages to external systems.
That means operational control needs to work on three levels:
- Stop the agent
- Contain the impact
- Safely compensate for the actions already performed
Compensation may mean cancelling a document, posting a reversal, or creating a corrective transaction.
Speed itself therefore becomes a new risk metric.
How much time passes between the moment abnormal behavior begins, the moment it is detected, and the moment the agent is actually stopped?
In agentic systems, security teams will increasingly need to think beyond access control and consider operational safeguards such as rate limits, emergency stop mechanisms (kill switches), thresholds, and abnormal transaction volumes.
Human-in-the-Loop Does Not Solve Every Problem
The first reaction may be:
“Then let a human approve every action.”
That may improve security, but it can also eliminate much of the efficiency that makes AI agents valuable in the first place.
In agentic AI governance, human oversight can be considered at three different levels:
Human-in-the-loop: A human must approve the action before a critical transaction is executed.
Human-on-the-loop: The agent operates within predefined boundaries while a human monitors the process and intervenes when necessary.
Human-in-command: A human retains ultimate authority to stop the agent or the system.
The right model will not be the same for every process.
An agent preparing a sales report should not be governed at the same risk level as an agent changing a supplier’s bank account details.
So the real question is not, “Will there be human approval?”
It is:
How much human control is required for each type of action?
New Responsibilities for Basis, Security, and GRC Teams
It is no longer sufficient to treat AI agents as an issue only for application or AI teams.
In the new environment, the responsibilities of Basis, IAM, Security, GRC, integration, and business process teams will increasingly overlap.
Maintaining an agent inventory, managing agent identities, defining access policies, controlling MCP connections, monitoring telemetry, detecting abnormal transaction volumes, and removing access from agents that are no longer in use will become natural parts of the operating model.
There is also another question for Basis teams:
The agent may be working correctly — but how much load is it putting on the system?
Hundreds of parallel API calls, frequent backend transactions, integration traffic, or an uncontrolled agent loop can create not only a security issue, but also a performance problem.
For that reason, agent observability goes beyond monitoring CPU and memory. Session volumes, tool-call success rates, transaction duration, error rates, and resource consumption will increasingly need to be monitored together. The direction of SAP’s Agent Hub and Cloud ALM architecture also reflects this shift.
The commercial model should not be ignored either. For SAP’s own autonomous agents, consumption-based pricing through AI Units applies in 2026. As a result, unnecessary agent actions may eventually become relevant not only from a technical and performance perspective, but also from a cost-observability perspective.
In other words, monitoring whether agents are generating unnecessary actions may gradually become part of operational management alongside security and performance.
Conclusion: Define the Rules Before You Hire the Agents
The biggest barrier to broader adoption of AI agents in SAP may not be what the agents are capable of doing.
The real differentiator will be how much organizations can trust these digital actors — and which controls they put in place to support that trust.
That is why every AI agent moving toward production should be evaluated across five layers: identity, access, boundary, traceability, and brake. If an organization cannot provide clear answers across those five dimensions, the agent may be technically functional but still not be ready for production from a governance perspective.
An agent without a clear identity cannot be properly governed. An agent without defined authorization boundaries may perform more actions than intended. If its trusted data sources and callable tools are not constrained, it can still be misdirected even when its permissions are technically correct. If its actions cannot be traced, accountability becomes difficult. And if it cannot be stopped quickly, a small issue can become an operational incident.
In our view, SAP’s simultaneous investments in areas such as Agent Identity, AI Agent Hub, Agent Gateway, MCP governance, and OpenShell are a strong signal that security and governance are no longer peripheral concerns around agentic AI architecture — they are moving directly to the center of it.
The SAP world has spent decades building mature practices around identity, authorization, Segregation of Duties, and auditability for human users.
Now a new kind of digital actor is entering the system: not a human user, not a traditional technical user, and not merely a chatbot that provides recommendations.
It is an actor that can make decisions, use tools, and execute transactions.
Bringing AI agents into production SAP environments therefore means more than deploying a new technology.
It means rethinking SAP’s established identity, authorization, Segregation of Duties, and audit model for a new kind of digital worker.
Five steps to get started today
Create an inventory of the AI agents currently in use or being planned across the organization.
Define the business owner, technical owner, user context, and access scope for each agent.
Where possible, begin pilots with read-only or low-risk scenarios.
Define the emergency stop mechanism (kill switch), transaction limits, and the team responsible for intervention before go-live.
Define logging, audit trail, and telemetry requirements before the agent enters production.
Frequently Asked Questions
The Agent Identity approach is designed to register agents within SAP Cloud Identity Services as separate, manageable entities, while also governing their access, user context, and identity lifecycle. This provides greater control over which users can invoke specific agents and the boundaries within which those agents are allowed to operate. It is also important to note that some of these capabilities are still available under the Early Adopter Care program.
Not exactly. Technical users, service accounts, or similar mechanisms may be part of an agent architecture, but AI agents require more than identity management alone. Their purpose, tool access, user context, lifecycle, and runtime policies also need to be governed.
It depends on the use case and the capabilities of the relevant SAP product. For critical actions, a human-in-the-loop model may require explicit human approval before execution. In lower-risk scenarios, an agent may operate independently within predefined boundaries. As of October 2026, user context and human authorization remain important in many SAP agent scenarios.
Traditional SoD controls focus primarily on combinations of users and roles. However, when multiple agents work together toward the same business objective, a Segregation of Duties conflict may still arise even if the agents have separate technical identities. In the future, SoD controls may therefore need to assess not only user-role combinations, but also chains of actions performed across multiple agents.
MCP makes it easier for agents to connect to different tools and data sources. But every new connection also expands the trust boundary. Organizations need to understand whether an MCP server can be trusted, which data it can access, which actions it can invoke, and how quickly that access can be revoked when trust conditions change.
An agent may interpret malicious instructions embedded in an email, document, web page, or other external data source as legitimate instructions. For this reason, security cannot rely on authorization alone. Source trust, content controls, and policy enforcement for critical actions are also necessary.
The first priority is to stop the agent and prevent the error from spreading further. This requires safeguards such as emergency stop mechanisms (kill switches), transaction limits, anomaly detection, and clearly defined incident-response responsibilities.
In SAP, business documents that have already been created cannot always be undone through a traditional database rollback. Depending on the process, recovery may require cancellation, reversal postings, or corrective transactions.