14. September 2026 · Cybersecurity
Your Agent Acts With Your Permissions
What SAP’s agent documentation answers about process authorisation, what it leaves to your role design, and the three decisions that follow
Executive Summary
Strategic context
Situation. SAP is repositioning its applications around agents. Its learning material describes a layered model in which Joule Assistants interpret a user’s intent and coordinate Joule Agents that “plan, act, and execute complex multi-step tasks” across five autonomous domains: Finance, Spend, Supply Chain, HCM and Customer Experience. Governance is positioned as built in, with SAP AI Agent Hub as the “command center” for discovering, verifying and observing agents across vendors.
Complication. An earlier article on this site argued that agent risk is decided by four questions: which process steps an agent may alter, which thresholds apply, where a human countersigns, and how a wrong decision is detected and rolled back. SAP’s documentation now gives a concrete answer to the first of these, and it is a significant one. In SAP’s own words, “every agent action carries your identity and access permissions, so agents can only act on what you are entitled to act on.” That sentence moves the decisive control out of the agent and into the authorisation concept most SAP customers built years ago for humans working at human speed.
Question. When an agent inherits a user’s permissions, what does SAP’s documented architecture control, what does it leave to the customer, and which decisions have to be made before agents run in value-creating processes?
Key findings
1. Inherited permissions make role design the primary agent control. SAP states that agents in all three operating modes, conversational, embedded and system-triggered, “always operate within your organization’s authorization boundaries” and act with the triggering user’s identity. So what? Whatever breadth a user’s roles have, the agent has too. A role concept that was tolerable because a human needed hours to exploit its breadth is now exercised by software that plans and executes multi-step work.
2. The documentation does not say whose identity a system-triggered agent carries. SAP describes agents “initiated by a business event, a schedule, or a system signal rather than a user request,” and in the same lesson says every agent action carries “your” identity. Neither the lesson nor the product pages read for this article resolve which identity applies when no user triggered the run. So what? This is the question to put to SAP and to your own architecture board before the first background agent goes live, because in SAP landscapes the answer tends to default to a technical user with broad rights.
3. SAP AI Agent Hub governs agents and their connections, not individual process decisions. Its documented controls are an inventory across vendors, a verification workflow, runtime permissions for agents and MCP servers (“only verified MCP servers can be called in production workflows”), architecture decision workflows “for approval gating,” observability and agent mining. So what? These are genuine controls for which agent may run and which tools it may call. None of the pages read describes a value threshold per process step or a countersignature per action.
4. Conformance monitoring catches deviation, not a correct path with a wrong outcome. Agent mining measures “whether a deployed agent is following the execution pathway it was built for.” So what? The failure mode that produces no alert, a formally valid decision with a wrong business outcome, stays conformant by definition. Detection for that case remains customer design work.
5. “Reversible” is asserted, not defined. SAP’s lesson states that agent actions are “governed, auditable, and reversible.” What reversal means for a posted payment, a purchase order already transmitted to a supplier, or a changed master record is not described on the pages read. So what? Treat rollback as a requirement to specify per process, not as a platform property you have already bought.
Critical recommendations
| Priority | Recommendation | Effort | Timeline |
|---|---|---|---|
| High | Review the roles of every user population that will trigger agents, before activation, with segregation of duties as the test | Medium | Before go-live |
| High | Decide and document the identity under which system-triggered agents run, and cap its rights | Low | Before the first background agent |
| High | Enforce value and volume thresholds in the process configuration, outside the agent | Medium | Per process, before scaling |
| Medium | Specify what reversal means for each agent-executed step, and test it once | Medium | One quarter |
| Medium | Use Agent Hub inventory and MCP verification from the first agent onwards | Low | Immediate |
| Low | Add outcome-based detection for conformant but wrong decisions | High | Two quarters |
Bottom line
SAP has built serious governance for which agents exist and what they may connect to. The decision about what an agent may do inside a process is delegated to the authorisation concept, and that concept was designed for people. Review it as if it were the agent’s rulebook, because now it is.
Where this picks up
The article Which Process Steps May Your Agent Trigger? made a vendor-neutral argument: agent security is less a model problem than a process authorisation problem, and four questions decide it. That article deliberately stopped short of any specific platform.
This one applies the four questions to a specific, documented architecture. SAP is a sensible test case for two reasons. It is the system of record for many of the processes in which agents will move money and goods, and it has published unusually concrete material on how its agents operate, including partner-facing learning content that goes further than the product pages.
The method is simple. Read what SAP documents, quote it, and map it against the four questions. Where the documentation is silent, say so rather than infer.
Finding 1: The agent inherits the user
The central sentence sits in SAP’s learning lesson on Joule Agents:
“Across all three modes, agents always operate within your organization’s authorization boundaries. Every agent action carries your identity and access permissions, so agents can only act on what you are entitled to act on.”
Read as a security statement, this is reassuring. An agent cannot exceed the permissions of the user it acts for. There is no separate, invisible superuser.
Read as a process authorisation statement, it has a second implication. The permissions that bound the agent are the permissions that were designed for the user. In SAP landscapes those are typically expressed as roles bundling transactions and authorisation objects, not as process steps with thresholds. The question “which steps may this agent alter” is therefore answered by a role design that never anticipated the question.
Experience, not sourced. Role concepts in long-running SAP landscapes tend to accumulate breadth: temporary extensions that stayed, composite roles assigned for convenience, firefighter access that was never fully withdrawn. This is widely observed in practice and is the reason segregation of duties reviews exist. No figure is offered here because none was read for this article.
The practical consequence does not depend on a figure. Breadth that was tolerable because a person needed time and intent to use it becomes a different exposure when software plans and executes multi-step work with the same rights. The agent does nothing forbidden. It does what the role allows, faster and more consistently than the person ever would.
The decision this creates. Before a user population is given agents, its roles have to be reviewed with the agent in mind. The test is not “does this person need this” but “is it acceptable that an agent acting for this person executes this without asking.”
Finding 2: The identity gap in system-triggered mode
SAP describes three operating modes for Joule Agents:
- Conversational. A user issues a request in Joule, for example approving an expense report or creating a purchase order.
- Embedded. The agent works inside an application the user is already in.
- System-triggered. The agent is “initiated by a business event, a schedule, or a system signal rather than a user request.” SAP’s example is an agent that monitors trade policy changes and “autonomously propose[s] reclassifications when regulations shift.”
The first two modes have an obvious identity: the user in front of the screen. The third, by SAP’s own description, has no requesting user. Yet the same lesson states that every agent action carries “your” identity and permissions.
The pages read for this article do not resolve that tension. Neither the lesson nor the product pages specify which identity a system-triggered agent carries, how that identity is provisioned, or who owns its authorisations.
This matters more than it looks. The system-triggered mode is the one closest to the autonomous enterprise SAP describes, in which “demand changes no longer wait for planning cycles” and “automatically drive production adjustments, inventory reallocation, and procurement actions.” It is also the mode with the least human proximity.
Experience, not sourced. Background processing in SAP has historically run under technical or batch users, and those users are frequent audit findings precisely because they are given broad rights to avoid job failures. If background agents inherit that pattern, the most autonomous mode runs under the least scrutinised identity.
The decision this creates. The identity for system-triggered agents is an architecture decision with a named owner, taken before the first background agent runs. Ask SAP how it is resolved for the agents you intend to use, and cap the rights of whatever identity results.
Finding 3: What SAP AI Agent Hub actually governs
SAP positions AI Agent Hub as “a vendor-agnostic command center that provides a single entry point for the discovery and governance of AI agents, large language models (LLMs), and Model Context Protocol (MCP) servers.” Stripped of positioning, the product page and the learning lesson document the following controls:
| Documented capability | What SAP says | Which of the four questions it serves |
|---|---|---|
| AI registry | Inventory of agents, LLMs and MCP servers, with automatic discovery from SAP, Microsoft, Google, AWS, Databricks and ServiceNow | Precondition for all four: you cannot authorise what you have not inventoried |
| Evaluation and verification | “AI risk rating, build type, attached architecture decisions, and compliance mappings,” with “a formal verification workflow” | Which agents may run at all |
| Identity and access control | “Determine the access, runtime permissions, and policies for agents and MCP servers. Only verified MCP servers can be called in production workflows, and when verification status changes, access is revoked.” | Which tools an agent may call. Partially question 1 |
| Approval gating | “architecture decision workflows for approval gating” | A human decision at design and deployment time. Not a countersignature per action |
| AI observability | “session health, goal completion rate, tool call correctness,” with tracing of each tool call | Question 4, for technical failure |
| Agent mining | Measures “variants, path completion and conformance, and activity coverage” | Question 4, for deviation from the designed path |
| Org chart and skills mapping | Maps agents “to the business units and roles it affects” via SAP SuccessFactors | Workforce visibility. Not authorisation |
Two observations follow.
First, this is more than inventory. The rule that only verified MCP servers can be called in production, with access revoked when verification changes, is a real runtime control over what an agent can reach. Many organisations have nothing comparable for their non-SAP agents.
Second, it governs the agent as an asset, not the decision the agent takes. None of the documented capabilities describes a threshold such as “above a certain value, route to a human,” or a countersignature on an individual agent action. SAP’s Spend Management page mentions “built-in policy checks, audit rules, approvals and proactive guidance that happen automatically in real time,” but it does not describe how those are configured, and a marketing line is not a control specification.
A correction to our own earlier assessment. The earlier article noted that SAP LeanIX product documentation did not describe dependency mapping as a named capability. SAP’s Agent Hub page now positions LeanIX as supplying “the business capabilities [agents] support and the technology they depend and operate on,” and the learning lesson says LeanIX architecture context “is surfaced directly during agent creation.” That is a product page and a learning lesson, not product documentation, and it concerns agents rather than systems in general. It does narrow the gap the earlier article described, and it is recorded here for that reason.
The decision this creates. Use the Hub for what it documents: inventory from the first agent, verification of every MCP server, approval gating at deployment. Do not treat it as the place where process thresholds live, because nothing read indicates that it is.
Finding 4: Conformance is not correctness
Agent mining is the most interesting capability on the list, because it applies process mining to agents. SAP describes it as making “it possible to determine whether a deployed agent is following the execution pathway it was built for.”
That answers an important question: did the agent do what it was designed to do? It does not answer the question the earlier article identified as the harder one: was what it was designed to do the right thing in this case?
Consider a sourcing agent that follows its designed path precisely: collects bids, applies the scoring, recommends the award. If the scoring rule is wrong for an unusual category, every run is conformant and every outcome is wrong. Observability reports healthy sessions, high goal completion and correct tool calls. Agent mining reports full conformance. Nothing alerts.
This is not a weakness specific to SAP. It is the nature of conformance monitoring, and it is why the failure mode is dangerous everywhere. The point is narrower: an organisation that has deployed Agent Hub observability and agent mining can reasonably believe it has detection covered, and for this failure mode it does not.
The decision this creates. For agents in value-creating processes, add at least one outcome-based check that is independent of the agent’s design: a sampled human review of decisions, a comparison against a business benchmark, or a downstream reconciliation. Choose it per process, because what “wrong outcome” means is a business definition.
Finding 5: “Reversible” needs a definition per step
SAP’s introductory lesson makes a strong governance claim:
“Actions taken by agents are governed, auditable, and reversible. The system operates within compliance frameworks, provides a complete audit trail, and maintains clearly defined escalation paths.”
Auditable is well supported by the rest of the material: SAP states that “every decision an agent makes is logged and traceable.” Escalation paths are asserted without detail on the pages read.
Reversible is the claim that needs the most scrutiny, because reversibility is a property of the business step, not of the platform. A draft can be deleted. A reclassification proposal can be rejected. A posted payment has left the company. A purchase order transmitted to a supplier has created an expectation on the other side, and possibly a legal one. A changed master record may already have propagated.
The documentation does not describe how reversal works for steps like these, and it cannot, because the answer depends on the customer’s process, contracts and interfaces.
The decision this creates. For each step an agent may execute, write down what reversal means, who performs it, and within what time. Where reversal is not possible, that step belongs behind a threshold or a countersignature, which returns you to Finding 3.
Implications for Executives
The authorisation concept is now an AI governance artefact. It will be read by agents whether or not anyone reviews it for that purpose. Ownership of role design usually sits with SAP basis or a GRC function that has no mandate for AI. That mandate has to be assigned explicitly.
Platform governance and process governance are different jobs with different owners. SAP AI Agent Hub gives IT and architecture a strong handle on the first. The second belongs to process owners, who decide thresholds and countersignatures, and who are rarely in the room when agents are activated.
The cheapest controls are decisions, not tools. The identity for background agents, the threshold per step, the meaning of reversal: each is a short, documented decision. None requires procurement. Each becomes expensive once agents are running and the decision is made implicitly by default.
Recommendations
| Recommendation | Rationale | Owner | Effort |
|---|---|---|---|
| Review roles of agent-triggering user populations with SoD as the test | Agents inherit breadth that was tolerable for humans | GRC with process owner | Medium |
| Decide the identity for system-triggered agents and cap its rights | Not resolved in the documentation read; tends to default to broad technical users | Enterprise architecture | Low |
| Configure thresholds in the process, outside the agent | No per-action threshold is documented in Agent Hub | Process owner | Medium |
| Define reversal per agent-executed step, and test it | “Reversible” is asserted, not specified | Process owner with IT | Medium |
| Run inventory and MCP verification from the first agent | Documented, effective, cheapest early | IT and architecture | Low |
| Add one outcome-based check per value-critical agent | Conformance monitoring cannot see a correct path with a wrong outcome | Process owner with internal control | High |
Executive Dashboard
| Question | What SAP’s documentation provides | What remains your decision | Confidence |
|---|---|---|---|
| Which process steps may the agent alter? | Inherited user permissions; permissions defined at build time | Role design reviewed for agent use | High |
| Under which identity do background agents run? | Not specified on the pages read | Named identity with capped rights | High that it is unspecified |
| Which thresholds apply? | Not documented beyond marketing language | Thresholds configured in the process | Medium |
| Where does a human countersign? | Approval gating at deployment; “humans in the lead” as a principle | Countersignature per step and role | Medium |
| How is a wrong decision detected? | Observability and agent mining for technical failure and deviation | Outcome-based checks for conformant errors | High |
| How is it rolled back? | “Reversible” asserted | Reversal defined and tested per step | High that it is undefined |
Appendix: Methodology
Research type. Documentation-based gap analysis. The four-question frame comes from an earlier article on this site; the evidence is SAP’s own published material, mapped against that frame.
Sources and how they were read. Four SAP web pages and three lessons of the SAP Learning course “Introducing Joule” were opened and read in full on 14 September 2026. Several sap.com pages refuse automated retrieval, so the sap.com pages were read in a browser. Quotations are verbatim. The learning course is part of SAP’s “Positioning the Autonomous Enterprise” learning journeys, including variants for partner presales and sales, and should be read as positioning material with more technical detail than the product pages, not as product documentation.
Frameworks applied. SCQA for framing. A capability-to-question mapping for the analysis, using the four questions from the earlier article.
Frameworks considered and not applied. Porter’s Five Forces and BCG Matrix: this is not a question of industry structure or portfolio. Value Chain: the analysis concerns control points, not cost structure. PESTEL: regulatory context matters, but the question is operational. Technology Adoption Curve: no defensible data on agent authorisation practices was available, and constructing one would present estimation as evidence.
Evidence status, stated plainly.
- Sourced from SAP material read directly. The operating modes, the inherited-permission statement, the Agent Hub capabilities, the conformance description and the “reversible” claim.
- Absence findings. Statements that something is not described refer to the pages read for this article. SAP product documentation beyond them may address these points, and a reader with access to it should check.
- Experience claims, not sourced. Role breadth in long-running SAP landscapes and the audit history of technical users. Labelled where they appear and offered as argument, not evidence.
Confidence. High for Findings 1, 3 and 4, which rest on verbatim SAP statements. Medium to high for Findings 2 and 5, which are absence findings and therefore bounded by the material read.
Limitations.
- Product pages and learning lessons describe intent and positioning. Configuration guides, which were not read, may define thresholds, identities and reversal in more detail.
- SAP states that availability “spans general release, early access, and planned releases across 2026.” Some described capabilities may not yet be usable.
- No customer implementation was examined. The analysis concerns what is documented, not what is deployed.
What could not be answered. The identity model for system-triggered agents, and whether per-action thresholds are configurable in the agent layer or only in the underlying application workflow.
Update trigger. Revisit when SAP publishes configuration documentation for agent authorisation or identity, or when the first independent implementation reports appear.
Frequently Asked Questions
Does inheriting user permissions make SAP’s agents unsafe?
No. It is a sound design principle, because it prevents agents from exceeding what a user may do. The argument is that it moves the control into the role concept, which then has to be fit for that purpose.
Is SAP AI Agent Hub enough for agent governance?
It covers inventory, verification, tool access and observability, and those are necessary. It does not, on the documentation read, cover thresholds or countersignatures on individual agent decisions. Those belong in the process.
What should we ask SAP before activating background agents?
Under which identity a system-triggered agent runs, how that identity is provisioned and reviewed, and whether thresholds can be enforced per action. Ask for the answer in documentation, not in a presentation.
Does agent mining detect wrong decisions?
It detects deviation from the designed path. A decision that follows the path and still produces a wrong business outcome is conformant and will not be flagged.
Why was the Technology Adoption Curve not used?
Because no defensible data on how organisations authorise agents was available. Placing the market on a curve would have meant presenting an estimate as evidence.
Which parts of this are evidence, and which are experience?
SAP’s statements are quoted verbatim from material read directly. Observations about role breadth and technical users come from practice and are labelled as such.
We have a mature GRC process for SAP roles. Are we covered?
Possibly, if the review criteria change. A role review that asks whether a person needs an authorisation is a different test from one that asks whether an agent acting for that person may use it without asking.
Sources
- SAP, “Joule Agents and Joule Assistants,” https://www.sap.com/products/artificial-intelligence/ai-agents.html, retrieved 14 September 2026.
- SAP, “SAP AI Agent Hub,” https://www.sap.com/products/artificial-intelligence/ai-agent-hub.html, retrieved 14 September 2026.
- SAP Learning, “Introducing Joule,” lesson “Discovering Joule,” https://learning.sap.com/courses/introducing-joule/discovering-joule_e055e58d-18c3-48fd-9137-80a96e4431e7, retrieved 14 September 2026.
- SAP Learning, “Introducing Joule,” lesson “Getting to Know Joule Agents,” https://learning.sap.com/courses/introducing-joule/getting-to-know-joule-agents_f9d18ca0-1021-4c1a-a044-4c00ec8c2898, retrieved 14 September 2026.
- SAP Learning, “Introducing Joule,” lesson “Getting to Know AI Assistants in Joule,” https://learning.sap.com/courses/introducing-joule/getting-to-know-ai-assistants-in-joule_f6252c97-c6fd-46e9-b0c5-2467efd1f1c9, retrieved 14 September 2026.
- SAP, “The Autonomous Enterprise,” https://www.sap.com/products/business-suite.html, retrieved 14 September 2026.
- SAP, “Spend Management Software Solutions,” https://www.sap.com/india/products/spend-management.html, retrieved 14 September 2026.
- Sascha Theismann, “Which Process Steps May Your Agent Trigger?,” https://saschatheismann.de/en/which-process-steps-may-your-agent-trigger/, September 2026.
