AI Agent Security in SAP, Explained Like Building Security

In 30 seconds

What it is An agent acts as the user, with narrow tools, a log, a stop button and a human on money.

You use it when You are approving, designing or auditing an AI agent that can read or change SAP data.

Next in this section Joule Trust Boundaries and Identity Propagation, Explained Plainly →

Treat every AI agent like a visitor in your building: checked at the door, badged per floor, logged, escorted on money, and stoppable within the hour.

40-second version of this explainer, no sound.

Part 8 of 26 in SAP Business AI, Explained.

People talk about AI agent security as if it were a new discipline. Mostly it’s building security, applied to a new kind of visitor. If you know how your office keeps strangers off the finance floor, you already understand the shape of it.

An AI agent should only ever do what the person it works for is allowed to do, with every step recorded and a human sign-off before money or pay changes.

The short answer

The agent acts as the user who asked, with that user’s permissions. It should never run as an all-powerful technical account.
Give each agent a small set of specific tools, check every call, and treat whatever it reads as information to weigh rather than orders to follow.
Keep an audit trail, require human approval on high-impact actions, and have a fast way to switch one agent off.

Your office building already does this

Think of your head office. The front desk checks who you are. Your badge opens only the floors your job needs, and the visitor log records who came in and where they went. Fire doors can seal a section in seconds, and a trip to the vault comes with an escort.

Elsewhere in this series I describe the agent gateway as the security desk. This post adds the fire doors and the escorts, plus one firm rule: the visitor’s badge is a copy of the host’s badge.

Walking an agent through the building

Front desk: identity. The user signs in once through the company’s sign-on service, and the agent carries that checked identity on every call it makes, with a gateway checking identity, access and policy on the way (the product names are in Go deeper).
Floor badges: roles and least privilege. The agent carries the user’s identity to the backend, and the backend applies that user’s roles. SAP Community authors show this for SAP Cloud ERP Private, where existing ABAP (Advanced Business Application Programming) authorizations still decide, and for SAP SuccessFactors, where Role-Based Permissions (RBP) filter every tool call.
Escorts: human approval. When an action moves money, changes pay or creates a legal outcome, a person confirms it. SAP’s guidance points to configuring confirmations and step-up approval for sensitive or irreversible actions.
Visitor log: audit. Every hop leaves evidence in identity logs, Joule conversation logs, platform audit logs and the backend security audit log. You correlate them so one request can be traced end to end.
Fire doors: stop one agent fast. You want to be able to disable a single agent, its tools or its connection within one hour, without switching Joule off for everyone.

The sentence I keep coming back to is from an SAP architect on SAP Community: “Joule inherits your security model; it does not replace it” (Jana Subramanian, SAP Community). Joule doesn’t grant extra backend permissions. As agents get more autonomous, those permissions stay the foundation, with agent identities, tool permissions and approval controls on top.

A few habits complete the picture. They’re general good practice, drawn largely from the OWASP (Open Worldwide Application Security Project) guidance on large language model (LLM) risks:

Act as the user. OWASP lists excessive permissions and a generic high-privilege identity as root causes of agents doing damage, so run actions in the user’s context with minimum scopes.
Keep tools narrow, down to the functions each tool needs. A read-only task gets read-only access.
Validate every call against policy, in code and in the downstream system. Don’t rely on the model to decide whether an action is allowed.
Treat tool output and other agents’ replies as data. A document, an email or a partner agent’s answer can hide instructions, and the agent should read them without acting on them (post 22 covers this).
Keep secrets out of prompts. Passwords, keys and tokens belong in the platform’s credential stores. The SuccessFactors pattern on SAP Community describes an agent that holds no long-lived backend credentials at all.

A pay-rise request at NextSAP

NextSAP Utilities, the fictional Dubai utility used across this site’s SAP content, runs a custom salary-change request agent, agent 3 in our register. It’s conversational, sits at L2 Propose on the autonomy ladder and is rated high risk. Mariam, the HR (human resources) Director, owns it, and Hana, the AI Governance Lead, signed off its controls. The controls themselves are the real ones.

A field supervisor at a Dubai depot asks the agent: “Propose a raise for my senior meter technician, and show me how her pay compares with the rest of my team.” Here’s what happens:

Front desk. The supervisor is already signed in through the company’s sign-on service. The agent receives her identity, not a shared account.
Floor badge. The agent queries SAP SuccessFactors with her propagated identity. RBP returns pay data for her 14 direct reports only, and nothing for the 9 people at the neighbouring depot, because she can’t see them in SuccessFactors either. That mirrors the SAP Community demo, where an HR manager saw contract and salary details and a standard employee asking the same question got no records.
Narrow tools. The agent has two tools: read team compensation, and draft a change request. There’s no tool to post a change, and it can’t touch payroll.
Escort. The agent proposes AED (UAE dirham) 1,500 per month, from AED 11,000 to AED 12,500, with a short reason based on band and tenure. Nothing changes until Mariam’s HR team approves the draft.
Visitor log. Later, Daniel from Internal Audit can see who asked, what the agent read, what it proposed and who approved it.
Fire door. If the agent ever proposed changes outside its policy, Priya, the IT (information technology) Platform Owner, could disable it within the hour while the leave Q&A agent kept running.

Now the bad version, which I still see suggested in design reviews. The agent connects with a technical super-user that can read all 4,200 employee records. The model is polite and well prompted, so it usually shows only the supervisor’s team. But “usually” isn’t something an auditor will accept as a control. One clever question or one poisoned document, and salary data for the whole company ends up in a chat window.

How much control each kind of agent needs

Situation	Minimum control set I recommend
Agent only answers questions from policies (L1)	User identity, read-only tools, conversation logging
Agent reads personal or financial data (L1 to L2)	User identity propagated to the backend, data filtered by backend roles, audit correlation
Agent proposes changes (L2)	All of the above, plus a draft-only tool and a named human approver
Agent acts with approval (L3)	All of the above, plus step-up approval on amounts or pay, and segregation-of-duties checks on the approver
Agent receives content from outside (PDFs, emails, partner agents)	Treat it as data, validate outputs, block instruction-like content from reaching tool calls

Where security controls stop helping

Done well, all this keeps the agent inside its user’s permissions, gives audit a trail from question to backend change, and lets you stop one agent alone. What it can’t do:

Make the model trustworthy. A model can still be wrong or manipulated. The controls limit the damage.
Replace your roles and segregation of duties. If roles are too broad today, an agent inherits that problem.
Configure itself. SAP operates the Joule runtime, but identity configuration, roles, destinations and approval design are yours.

Explain it to your CFO

The agent can only see and do what the person asking could already see and do.
Anything that moves money or changes pay waits for a human signature, and we can switch off any single agent within one hour.

Questions for your security team

Will any agent ever use a shared technical account to read business data? I’d say no, except for narrow, read-only, non-personal data, approved by security and logged. The agent acts as the user, never as a super-user.
Which actions always need a human? My default list is anything that moves money, changes pay, changes supplier or customer master data, or creates a legal commitment.
Who can pull the fire door, and how fast? The platform owner and the agent’s business owner, within one hour, with a tested runbook.

Go deeper

Technical detail for architects and developers

Identity products. The front desk is SAP Cloud Identity Services. SAP’s own architecture write-up describes Identity Authentication as the trust broker for Joule, with Identity Provisioning keeping users and groups in sync, and one shared identity tenant across Joule and the connected SAP products. In the NextSAP example, the company identity provider is federated to SAP Cloud Identity Services. SAP also describes an enterprise agent gateway that applies identity, access and policy at runtime and governs agent communications, tool use and human oversight.

Identity chain. SAP’s architecture write-up for SAP Cloud ERP Private (RISE with SAP) describes this chain. A corporate identity provider is federated to SAP Cloud Identity Services, and users sign in to the Joule runtime with OpenID Connect (OIDC). Calls to the backend go through a SAP Business Technology Platform (BTP) destination with principal propagation and the Cloud Connector, which turns the user token into a short-lived X.509 certificate. The ABAP system maps it to a user and runs standard role checks. Joule has no direct database connection (post 21 walks through it).

Agent-to-agent delegation. For agent-to-agent (A2A) calls, SAP describes Joule acting as an A2A client to external agents, with App2App trust in Identity Authentication, and, where available, an SAP Agent Gateway for external agents calling Joule Agents with named user context. An SAP post describes that inbound path as generally available; another SAP Community post says “where available”. Confirm in the capability watch linked below. Agent Gateway audit logging is provided through SAP Cloud ALM (Application Lifecycle Management). The same write-up makes a point I treat as a rule: delegating a task does not grant data access. The receiving agent needs its own governed path to the data.

Custom agents. In the SuccessFactors Bring Your Own Agent pattern, the agent validates the inbound user token against the identity tenant, then passes it to the BTP Destination service, which issues a user-bound token for the backend. The author warns that a missing setting can make the service silently fall back to a technical user, so test with a low-privilege user.

Tool exposure. For custom tools, SAP describes the MCP Gateway in SAP Integration Suite, which exposes APIs as governed Model Context Protocol (MCP) tools with OIDC authentication, rate limiting, payload protection and monitoring. It’s customer-managed, so tool selection and policies are yours. Availability depends on edition and plan, so check the current status in the Joule capability watch.

Inventory and governance. SAP AI Agent Hub provides discovery, inventory and governance of agents, and SAP News describes it inventorying agents, LLMs and MCP servers mapped to owners. If an agent isn’t in the inventory, you can’t close a fire door on it.

Frameworks. OWASP’s Excessive Agency entry gives the clearest control list: minimise tools and permissions, execute in the user’s context, require approval, and enforce authorization in the downstream system, which it calls complete mediation. For the governance side, the NIST (National Institute of Standards and Technology) AI Risk Management Framework, with its Govern, Map, Measure and Manage functions, is a useful umbrella. Post 24 maps it to SAP.

Words you’ll hear

Least privilege: give a person or agent only the access its task needs, and nothing more.
Identity propagation (principal propagation): passing the real user’s identity through every hop, so the backend checks that user’s permissions.
Technical user (super-user): a shared system account, often with broad access, that hides who really asked.
Role-Based Permissions (RBP): the SAP SuccessFactors model that decides who can see and change which data.
Agent gateway: a control point that applies identity, access and policy to agent traffic at runtime.
Human-in-the-loop: a person approves before the action happens, like the four-eyes principle.
Kill switch: a tested way to stop one agent, its tools or its connection quickly.

Keep going

Independent explainer, not affiliated with or endorsed by SAP SE. SAP, Joule and other SAP product names are trademarks of SAP SE.

Frequently asked questions

Does Joule get more access than the user who asks it?

No, not in the standard skill path SAP describes. Existing backend authorizations still govern data and actions, and an action denied to the user stays denied when requested through Joule.

What is the single most important control for an AI agent?

Make the agent act with the identity and permissions of the person it works for, not a shared technical super-user. The backend then filters data the same way it does for that person.

Can we just tell the model in its prompt not to do dangerous things?

Prompt instructions help but are not a control. OWASP says there may be no fool-proof prevention for prompt injection, so enforce limits in identity, roles, tools and approvals.

Who should own AI agent security?

It is shared. SAP operates the Joule runtime; your team owns identity configuration, roles, destinations, which agents are enabled, approval design and log review.