Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

What Sensitive Data Can SAP Joule Agents Access?

Whatever the signed-in user may see: SAP states that Joule honors existing permissions, so an agent run by a payroll administrator or a payables clerk can read payroll figures, employee records and supplier bank details as model context. Check which roles run each agent, what their authorizations reach, and whether the task needs the raw values.

A central agent connects to separate financial, employee, and operational record collections.

Whatever the signed-in user may see: SAP states that Joule honors existing permissions, so an agent run by a payroll administrator or a payables clerk can read payroll figures, employee records and supplier bank details as model context. Check which roles run each agent, what their authorizations reach, and whether the task needs the raw values. SAP systems hold the most consequential data in most enterprises: who is paid what, which supplier is paid at which bank, what a customer owes. SAP's answer to the data question for Joule is the one every application vendor gives, and it is accurate as far as it goes: the agents respect the authorizations already in place. The limit of that answer is that authorizations decide which people may view which data, on the assumption that a person who may view a value needs to read it. An agent preparing a payment run does not need the supplier's bank account number, yet it reads it, because the user running the agent is authorized to. This page sets out what decides a Joule agent's reach, which SAP data becomes model context under common roles, how reach extends beyond SAP, what SAP documents about agent-to-agent access, what the wider record says, and what a buyer should verify. The pattern is the general one of agent data access following identity rather than task.

Key findings

  • SAP's learning material states that Joule honors existing permissions so users only see and interact with data that they are authorized to access, which makes the user's SAP authorizations the boundary of what an agent reads (SAP Learning, 2026).
  • The same material states that Joule agents can reach external systems such as databases, applications or even the web, so an agent's reach is not confined to SAP data (SAP Learning, 2026).
  • SAP's Sapphire innovation guide states that Joule Agents can access enterprise data and act across both SAP and third-party systems (SAP, 2026).
  • SAP describes A2A as primarily used for outbound agent-to-agent communication, with inbound requests routed through the Agent Hub, which enforces authentication and authorization; token or credential handling is not documented (SAP Learning, 2026).
  • An index of 30 deployed agentic systems found that most developers share little information about safety, evaluations and societal impacts, which places the burden of discovery on the buyer (Staufer et al., 2026).
  • Authorizations decide who may open a record; a separate control is needed to decide whether the model reads the raw values inside it, which is the question an accounts payable workflow without vendor bank details poses directly.

What decides what a Joule agent can read?

SAP's learning material on Joule gives the rule in one sentence: Joule honors existing permissions so users only see and interact with data that they are authorized to access (SAP Learning, 2026). The rule is correct and it is the right starting point. SAP authorizations are among the most mature permission systems in enterprise software, and a Joule agent that stays inside them inherits that maturity. A user who cannot display supplier bank details in the application cannot get them through Joule either.

A Joule agent's reach is the reach of the roles assigned to whoever runs it. For a payables clerk, that is supplier master data including bank details, open invoices, payment proposals and vendor history. For an HR business partner using SuccessFactors, it is employee records including compensation, personal identifiers and performance notes for the populations in their scope. For a payroll administrator, it is pay results. None has excessive access by the organization's own standard; each has what the job requires, and each, running an agent, hands the model that same view.

What the rule does not say is as important. It does not say that an agent reads only the fields its task needs, or that any field is withheld from the model once the user is authorized for it. Whether Joule narrows the data presented to the model within the user's authorizations is not described in the pages reviewed. The authorization model answers "may this person see this?" The question for an agent is "should the model read this to do the task?", and the SAP material reviewed does not address it, because the authorization model was never asked to.

Which SAP data becomes model context under a common role?

Consider one record type: a supplier master record in S/4HANA, opened by an agent preparing a payment proposal for a payables clerk. The record carries the supplier's name and number, address, tax identifier, payment terms and bank account details, all of which the clerk's role may display. The agent's task is to match open invoices to purchase orders and goods receipts and propose them for payment. It needs the supplier number, invoice references and amounts, not the bank account number, which the model reads anyway because the record is presented as the clerk sees it.

Dimension SAP, per its documentation What a buyer should verify
Access boundary Joule honors existing permissions The authorization roles of every user who runs each agent
Data reach Enterprise data across SAP and third-party systems Which systems each agent connects to, under what identity
External systems Agents can reach databases, applications or even the web Which agents reach outside SAP, and what they read there
Inbound control Inbound A2A requests pass through the Agent Hub, which enforces authentication and authorization How outbound calls are controlled
Values the model reads Not described in the pages reviewed Which fields the model receives for one record and task

The same shape recurs in HR: an agent summarizing a team's open requests in SuccessFactors reads the employee records in the manager's scope, salary fields included, though the summary needs only names and request types. This is what happens when a permission model built for human viewing becomes the boundary for machine reading. The design that separates the two gives the model a consistent token in place of the bank account number or salary, so that an agent can prepare payables without seeing vendor bank details, resolving the real value only when the payment is released.

How far does a Joule agent's reach extend beyond SAP?

The authorization rule describes SAP data. Joule agents are documented as reaching further. SAP's learning material states that agents can reach external systems such as databases, applications or even the web (SAP Learning, 2026). The Sapphire innovation guide states that Joule Agents can access enterprise data and act across both SAP and third-party systems (SAP, 2026), and the Joule Studio page invites builders to seamlessly connect to SAP and third-party applications and AI agents that augment the Joule Agents framework (SAP, 2026).

The inventory of sensitive data an agent can access is therefore not the SAP authorization report alone. An agent that reads a supplier record in S/4HANA and then checks the supplier in a vendor portal or a bank validation service has a reach defined by several permission systems, and the SAP rule governs only the first. Whether the user's SAP authorizations carry any force in the third-party system depends on how the connection was built, which is not described in the pages reviewed. The risks on the far side of that connection are the subject of the companion page on connecting Joule agents to non-SAP systems; this page notes only that the reach exists and must be inventoried.

The web is the widest case. An agent that reads the web reads content nobody in the organization authored, and it becomes model context alongside the supplier record. SAP names the web as reachable without describing the controls that apply. Any agent with web reach has inputs that include untrusted text, and a buyer should ask how that text is kept apart from the enterprise data the agent is trusted with.

What does SAP document about agent-to-agent access?

Joule agents can call and be called by other agents. SAP's interoperability course states that A2A is primarily used for outbound agent-to-agent communication, and that inbound A2A requests route through Joule via the Agent Hub, which enforces authentication and authorization (SAP Learning, 2026). The inbound gate is documented. Specific token or credential handling, meaning how an outbound call carries identity and what the receiving agent can do with it, is not documented in the pages reviewed.

The asymmetry matters. When another agent asks a Joule agent for something, the Agent Hub decides whether the request is authenticated and authorized, protecting SAP data from unauthorized callers. When a Joule agent calls out, the supplier record it has read is already in its context, and what it passes along, and under what credential, is governed by the design of the outbound call. A Joule agent summarizing a supplier's status for a procurement agent elsewhere may include the bank details it read, not because anything failed, but because nothing told it to leave them out.

This is where the distinction between access and reading becomes operational. The Agent Hub governs access to SAP data: who may ask. Nothing in the pages reviewed governs what a Joule agent, having legitimately read a record, carries into a conversation with another agent. The OWASP Top 10 for LLM Applications names the resulting risk, sensitive information disclosure, as data reaching a model and surfacing in its outputs, and an agent's message to another agent is an output (OWASP, 2025). An organization that connects Joule agents to others should ask, per connection, what fields can leave and whether any of them are the ones its auditors would mind.

What does the wider record say about how much a buyer can learn?

Documentation answers part of the question and leaves the rest to the buyer, and that is not peculiar to SAP. An index of 30 deployed agentic systems, published in February 2026, found that most developers share little information about safety, evaluations and societal impacts (Staufer et al., 2026). For a Joule buyer, the authorization rule, the reach statements and the Agent Hub description are what the public record offers; questions about field-level presentation to the model, outbound credential handling and web content controls have to be put to the vendor in writing.

The risk frameworks give the buyer vocabulary. OWASP's excessive agency entry describes agents with more permission or autonomy than the task requires, and an agent inheriting a payables clerk's full authorizations for a three-field matching task fits the description even though every permission is legitimate (OWASP, 2025). The NIST AI Risk Management Framework's Map function asks organizations to identify what data an AI system is exposed to, in context, before measuring the risk (NIST, 2023). For Joule, mapping means listing, per agent, the roles that run it, what those roles reach, the external systems it connects to, and the fields each task uses, and treating the difference as exposure.

None of this requires distrust of SAP's statements. The authorization rule is accurate, and it answers the question SAP was asked: whether Joule weakens access control. The title question is different, and a buyer must assemble its answer from the authorization report, the agent inventory and the vendor's written responses, because auditing what an agent reads across applications is not something any one document provides.

What does a governed environment change?

A governed environment separates what a user is authorized to open from what the model reads inside it, which is the distinction SAP authorizations alone cannot make. SAP states that Joule honors existing permissions, so an agent run by a payroll administrator or payables clerk reads whatever that role reaches (SAP Learning, 2026). Run directly in the application, the agent's context is the role's full field set; in the environment, the sensitive fields are replaced.

This class of control works at the rendered screen. Supplier bank details, compensation figures and personal identifiers are replaced with consistent tokens before any model reads the page, and the task runs on tokens. Real values resolve only at an approved destination at the moment of an approved action, such as a payment release or a master data change. A named person confirms what is tokenized and approves consequential actions. Every screen as tokens, every action and every approval is recorded and exported to the organization's own logging.

This answers the test the previous section said authorizations cannot run. For one agent, one record and one task, the exported record shows the context the model received, each field as a token or a real value, so the organization can mark what the task needed against what the model saw without relying on vendor disclosure, which the wider record shows is thin (Staufer et al., 2026). The reach question remains: connections beyond SAP and credential handling on outbound agent-to-agent calls still need to be inventoried from the organization's own configuration.

The control does not alter SAP, the user's authorization roles or the model, and it covers the rendered page rather than data an agent exchanges with other agents or systems directly.

Where does RedactSure sit?

The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company. The design addresses the last row of the table: what the model receives for a record the user is authorized to open. Work runs in a governed environment in the customer's cloud. When an agent opens a supplier master record, an employee record or a payment proposal screen, substitution happens at the render layer before any model reads the screen, so identifiers appear to the model as consistent tokens such as ACCT_001 or PATIENT_001 for the whole run, and a bank account number or salary is a token the model can reason about without reading. Real values resolve only at approved destinations at the moment of an approved action, such as the payment release. A named person confirms the tokenization policy and approves every payment, submission and record change under Supervised Delegation. Every screen as tokens, every action and every approval lands in the AI Control Record and exports to the customer's SIEM. The design is model agnostic, requires no per-application integration, and leaves user permissions unchanged, so SAP authorizations remain the access boundary beneath it.

Deployments are in pilot. For this page's question, a pilot on the reader's own SAP workflow would show, for one agent and one record type, which fields the model received as tokens, which it never needed, and which were resolved for an approved action, producing the field-level record that the authorization report cannot. Everyone else controls where data can go. RedactSure controls what the AI can see.

Methodology and limitations

This page rests on SAP's own material: the SAP Learning course content on Joule and Joule Agents, the SAP Learning course on enabling interoperability for AI agents, the Sapphire innovation guide page on SAP Business AI, and the Joule Studio agent builder product page (vendor documentation and vendor pages). It also draws on the 2025 AI Agent Index preprint documenting technical and safety features of deployed agentic systems, the OWASP Top 10 for LLM Applications entries on sensitive information disclosure and excessive agency (industry standards), and the NIST AI Risk Management Framework (official guidance). All sources were read as of October 16, 2026.

No hands-on testing of Joule, Joule Agents, Joule Studio, the Agent Hub or any SAP S/4HANA or SuccessFactors system was performed for this page. "Not described in the pages reviewed" and "not documented" concern the material consulted, not claims that the product lacks a capability; SAP may document field-level controls, outbound credential handling or web content controls in material not reviewed. Vendor features change, and the page carries its date. Statements about RedactSure describe its current design, with deployments in pilot. The supplier master record, payment proposal and employee record examples describe record types and roles, not any organization; no customer or prospect is described.

Whether a given set of authorization roles, agent connections and model inputs satisfies an organization's financial, employment or privacy obligations is a determination for its counsel, its assessors and its own security and compliance officers, not for a research page.

What the record shows

SAP states that Joule honors existing permissions, that agents can reach enterprise data across SAP and third-party systems including databases, applications and the web, and that inbound agent-to-agent requests pass through an Agent Hub that enforces authentication and authorization. Together those statements mean that a Joule agent reads whatever the user running it is authorized to see, in SAP and in whatever else it is connected to, and that the public record does not describe any narrowing of that view to the fields a task needs, nor how outbound calls carry what the agent has read. The test is to name one agent and one task, pull the authorization roles of the user who will run it, obtain the context the model received for one record, and ask which of those values the task used.

Frequently asked questions

Can a Joule agent see data the user cannot?

Not according to SAP, whose learning material states that Joule honors existing permissions so users only see and interact with data they are authorized to access. The agent's reach inside SAP is the reach of the roles assigned to whoever runs it. The exposure question is about accumulation, not escalation: roles built for human work reach far more than any single agent task needs, and the model receives the whole authorized view.

Which categories of sensitive data are most exposed?

The ones that sit inside roles people need for daily work: supplier bank details in payables roles, employee compensation and personal identifiers in HR and manager roles, pay results in payroll roles, and customer credit and payment data in receivables roles. In each case the user is legitimately authorized, and an agent run under that user reads those fields as part of the record, whether or not the task at hand calls for them.

Does Joule limit what the model reads within a user's authorizations?

Whether Joule narrows the data presented to the model to the fields a task requires is not described in the pages reviewed. SAP's statements concern access control, which decides who may open a record, rather than model input, which decides what the model reads once the record is open. A buyer should ask SAP that question directly and in writing, and should plan on the full authorized view being model context until the answer says otherwise.

Do SAP authorizations apply when an agent reaches outside SAP?

SAP's material says agents can reach external systems such as databases, applications or even the web, and act across SAP and third-party systems. Whether a user's SAP authorizations have any effect in a third-party system depends on how the connection was built, and is not described in the pages reviewed. Each external connection should be treated as a separate permission system with its own identity and its own answer to what the agent can read there.

What does SAP document about agent-to-agent traffic?

Its interoperability course states that A2A is primarily used for outbound communication and that inbound requests route through Joule via the Agent Hub, which enforces authentication and authorization. That protects SAP data from unauthorized callers. How outbound calls carry credentials, and what limits the data a Joule agent passes to another agent after reading a record, is not documented in the pages reviewed, and is the question to put to the vendor.

What is the first thing to check in a Joule deployment?

The authorization roles of the users who will run each agent, translated into data categories. That exercise usually reveals that a matching or summarizing task will run under roles reaching bank details, compensation or identifiers it does not need. From there, inventory each agent's external connections and obtain the model's actual input for one record and one task, so the gap between authorized access and task need is measured rather than assumed.

Book an AI Agent Security Review →

Bring your hardest questions.

Bring one sensitive workflow and the decisions your team needs to keep in its hands.

Book a demo

About the author

Christopher Sowa
Chris SowaCo-Founder, President and Chief Commercial Officer, RedactSure

Chris Sowa is a founder of RedactSure and a former CEO of an AI company; he started it years before ChatGPT existed. He previously led AI at Accenture, served as Global VP of Strategy & Innovation at Schneider Electric, was CCO of Sovos, and spent more than a decade at Oracle, with earlier roles at SAP and IBM.

Book a demo

Book a demo

Having trouble? Open the booking page or email us.