Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

What Are the Risks of Connecting SAP Joule Agents to Non-SAP Systems?

SAP's authorization model stops at the boundary: SAP documents the Agent Hub gating inbound requests, but not how identity, data and untrusted content are controlled once a Joule agent calls out over A2A or MCP, which is where prompt injection and data spillover enter. Map each outbound connection, its identity, and what the agent carries across it.

A business record passes through a gateway and branches toward cloud, database, and other external system shapes.

SAP's authorization model stops at the boundary: SAP documents the Agent Hub gating inbound requests, but not how identity, data and untrusted content are controlled once a Joule agent calls out over A2A or MCP, which is where prompt injection and data spillover enter. Map each outbound connection, its identity, and what the agent carries across it. Inside SAP, a Joule agent lives under a mature authorization system, and SAP states that Joule honors it. The appeal of Joule agents, by SAP's own description, is that they do not stay inside: they connect to third-party applications and other agents, reach databases and the web, and act across SAP and non-SAP systems. Each connection is a place where the SAP authorization model has no jurisdiction, and SAP's public material describes the inbound side of that boundary in more detail than the outbound side. This page sets out where the SAP model stops, what SAP recommends about A2A versus MCP and why, and then takes the three risks in turn: whose identity acts in the third-party system, what data the agent carries across, and what untrusted content flows back. It closes with what a buyer should verify. The general question of which systems an agent should be allowed to use is the frame; this page applies it to one vendor's documented design.

Key findings

  • SAP states that A2A is primarily used for outbound agent-to-agent communication and that inbound requests route through Joule via the Agent Hub, which enforces authentication and authorization; token or credential handling is not documented (SAP Learning, 2026).
  • SAP's Architecture Center states a preference for A2A over direct MCP server exposure, citing enterprise-grade security, governance and controlled access to SAP systems (SAP Architecture Center, 2026).
  • SAP states that Joule Agents can access enterprise data and act across both SAP and third-party systems, and that agents can reach external systems such as databases, applications or even the web (SAP, 2026).
  • Indirect prompt injection, in which instructions embedded in retrieved content redirect an LLM-integrated application, was demonstrated against real systems in 2023 (Greshake et al., 2023).
  • Joint CISA guidance on the adoption of agentic AI services counsels organizations to understand what agents can access and do, under which identities, before connecting them (CISA, 2026).
  • An agent that has read a record in one system carries that content into every system it calls next, so a connected agent's data boundary is the union of its connections (How to protect sensitive data across Microsoft and non-Microsoft applications?).

Where does SAP's authorization model stop?

SAP's learning material states that Joule honors existing permissions so users only see and interact with data that they are authorized to access, and in the same material that agents can reach external systems such as databases, applications or even the web (SAP Learning, 2026). Together the two sentences locate the boundary: the authorization model governs the part of an agent's work that touches SAP data, and the part that touches everything else is governed by something the SAP material does not describe.

The interoperability course gives the clearest picture of the boundary itself. It 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 system does with it, is not documented in the pages reviewed.

Consider a single record type: a supplier master record in S/4HANA, read by a Joule agent on behalf of a procurement specialist. The agent then calls a third-party procurement platform to check the supplier's certifications and a logistics provider's system to confirm delivery status. Inside S/4HANA, the specialist's roles decided what the agent read. At the moment the agent calls the procurement platform, three questions arise that the SAP authorization model cannot answer: under whose identity does the call go, what from the supplier record does the agent include, and what does the agent do with whatever the platform returns. Those are the three risks this page takes in order.

What does SAP recommend about A2A versus MCP, and why does it matter?

SAP's Architecture Center states a preference for A2A over direct MCP server exposure, citing enterprise-grade security, governance and controlled access to SAP systems (SAP Architecture Center, 2026). The recommendation protects SAP: an A2A path routes requests through an agent that applies SAP's controls, whereas exposing SAP functions as MCP tools lets any MCP client call them. It is sound guidance for the inbound direction and says nothing about the outbound one, where a Joule agent is the client.

Dimension SAP, per its documentation What a buyer should verify
Inbound requests Route through the Agent Hub, which enforces authentication and authorization What roles the Hub applies to an outside agent's request
Outbound A2A Primarily used for outbound agent-to-agent communication The identity each outbound call carries and who provisioned it
MCP exposure A2A preferred over direct MCP server exposure Whether any SAP function is exposed directly as an MCP tool
Third-party connections Seamlessly connect to SAP and third-party applications and agents Each connection's identity, scope and permitted data
Content returned Not described in the pages reviewed How third-party content is separated from instructions

The Joule Studio page invites builders to seamlessly connect to SAP and third-party applications and AI agents (SAP, 2026). Seamless is a product virtue and a governance warning: a seam is where a control can be placed, and the fewer seams a builder notices, the more likely the connection was configured for function rather than for the three questions above. SAP's preference for A2A shows careful thought about who may call in. The material reviewed shows no equivalent guidance for what a Joule agent may carry out.

Risk one: whose identity acts in the third-party system?

When the agent calls the procurement platform, something authenticates it. The pages reviewed do not say what. The possibilities are the ones every integration faces: a service account with whatever permissions its creator granted, an OAuth token carrying the user's permissions in the third-party system, or an API key in the agent's configuration. Each answers differently what the agent can do on the far side, and none is governed by the specialist's SAP roles.

The risk is scope drift. A service account created for checking certifications tends to get read access to the whole supplier directory, because the platform's permissions are coarser than SAP's and nobody revisits them. An agent authorized in SAP to see one supplier can now read every supplier the platform knows. The SAP model has not failed; it does not reach there. Joint guidance from CISA and partner agencies on the careful adoption of agentic AI services makes the identity question central: organizations are counseled to understand which identities agents use, what those identities can access, and what actions they permit, before deployment (CISA, 2026).

Every outbound connection from a Joule agent therefore needs its own permission review, in the third-party system's terms; the SAP authorization report is irrelevant to it. The same discipline applies to any agent given access to external systems, as the analysis of giving an agent access to company systems sets out: the agent's reach is the union of what each of its credentials permits, and the weakest-scoped credential defines the exposure.

Risk two: what data does the agent carry across the boundary?

By the time the agent calls the procurement platform, it has read the supplier master record, and the record is in its context: name, number, address, tax identifier, payment terms, bank account details. What it includes in the outbound call is decided by the agent's design and the model's judgment, not by SAP authorizations, which governed only whether the agent could read the record. A request to check certifications may carry the supplier number alone or the whole record, because nothing told the agent to leave the bank details out.

This is spillover: data legitimately read in one system appearing in another through an agent authorized in both. SAP's Sapphire guide describes the capability that makes it possible, Joule Agents that can access enterprise data and act across both SAP and third-party systems (SAP, 2026). Harvard's information security guidance on managing generative AI systems makes the general point that institutions should know what data such systems can reach and limit it to what is needed for the purpose (Harvard University Information Security and Data Privacy, accessed 2026). For a connected agent, "what it can reach" includes every system downstream of the first.

Spillover also runs in reverse: data read in the procurement platform, including other suppliers' records if the account is over-scoped, enters the agent's context and may be written into SAP or carried into the next call. The agent is a conduit between permission systems never designed to share a reader. A design that gives the model tokens in place of identifiers and bank details from the moment the record is rendered limits what can cross; what the companion page on Joule's data access describes as a reading problem inside SAP becomes a carrying problem once the agent connects outward.

Risk three: what untrusted content flows back?

The third risk is the one the literature has studied most. Whatever the procurement platform returns becomes part of the agent's context, and content that reads like an instruction can redirect what the agent does next. Greshake and colleagues demonstrated in 2023 that LLM-integrated applications could be compromised by instructions planted in content the application retrieved, without the user doing anything wrong (Greshake et al., 2023). The OWASP Top 10 for LLM Applications names this as prompt injection and treats the indirect form, instructions arriving inside data, as the one that applies to agents reading external sources (OWASP, 2025).

For a Joule agent, exposure grows with every connection. A supplier can edit its own profile on a procurement platform; a logistics system shows free-text status notes; the web, which SAP names as reachable, is written by everyone. Each is a place where someone outside the organization can put text a Joule agent will read, and an agent holding SAP authorizations and third-party credentials is a valuable thing to redirect. A planted note that persuades the agent to update the supplier's bank details in S/4HANA is the textbook case, and SAP would permit the update because the specialist is authorized to make it.

Content screening has value. What the pages reviewed do not describe is how content returned from third-party systems is separated from instructions before the model reads it, or whether such content is treated differently from SAP data. A buyer should assume it is not, until the documentation says otherwise, and should treat every outbound connection as a channel through which untrusted text reaches an agent that can act in SAP.

What does a governed environment change?

In a governed environment, a Joule agent that calls out to a non-SAP system carries tokens across the boundary rather than the supplier's bank details, so the data boundary stops being the union of every connection the agent holds.

The mechanism is a class of control that sits between the rendered screen and the model on either side of the SAP boundary. Sensitive values on the page, such as the bank details and tax identifiers on a supplier record, are replaced with consistent tokens before any model reads them, so the task runs on tokens in SAP and the third-party system alike. Real values resolve only at an approved destination at the moment of an approved action. A named person confirms what is tokenized and approves consequential actions, including payments, submissions and record changes. Every screen as the model received it, in token form, every action and every approval is recorded and exported to the organization's own logging.

This addresses two risks SAP's documentation leaves open. SAP documents the Agent Hub as the authentication and authorization gate for inbound requests, with outbound credential handling not described (SAP Learning, 2026); the environment's record supplies what the authorization report will not, an account of what the agent carried out and did there. On the return path, an instruction-like string planted in a third-party field can still redirect the agent (Greshake et al., 2023), but the values it could be told to exfiltrate are tokens, and the action it could be told to take waits for a person.

The control does not change SAP's authorization model, the identity each connection uses or the model; it changes what crosses the boundary and what is recorded when it does.

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 two rows the SAP material leaves open, what the agent carries across the boundary and what it can do when untrusted content comes back. Work runs in a governed environment in the customer's cloud. When an agent opens a supplier master record, a procurement platform page or a logistics console, 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 is a token wherever the agent carries it. Real values resolve only at approved destinations at the moment of an approved action. A named person confirms the tokenization policy and approves every payment, submission and record change under Supervised Delegation, so an instruction planted in a third-party field cannot change a supplier's bank details without a person saying yes. 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 in SAP and in every connected system.

Deployments are in pilot. For this page's question, a pilot on the reader's own cross-system workflow would show, for one agent and one connection, which values crossed the boundary as tokens, which actions reached a named approver, and the record each produced. 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 on enabling interoperability for AI agents, the SAP Architecture Center guidance on building AI agents on SAP BTP, the Joule Studio agent builder product page, the Sapphire innovation guide page on SAP Business AI, and the SAP Learning content on Joule and Joule Agents (vendor documentation and vendor pages). It also draws on the Greshake et al. preprint on indirect prompt injection (also presented at AISec 2023), the OWASP Top 10 for LLM Applications entry on prompt injection (industry standard), the joint CISA guidance on careful adoption of agentic AI services (official guidance), and Harvard University's information security best practices for managing generative AI systems (institutional guidance). All sources were read as of October 16, 2026.

No hands-on testing of Joule, Joule Studio, the Agent Hub or any SAP or third-party system was performed. "Not documented" and "not described in the pages reviewed" concern the material consulted, not claims that the product lacks a capability. Vendor features change, and the page carries its date for that reason. Statements about RedactSure describe its current design, with deployments in pilot. The supplier master record, procurement platform and logistics system examples describe record types and connection patterns, not any organization; no customer or prospect is described.

Whether a given set of connections, credentials and controls satisfies an organization's 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 documents a well-governed inbound boundary, an Agent Hub that authenticates and authorizes requests from other agents, and a stated preference for A2A over direct MCP exposure to protect SAP systems. It also documents, as a feature, that Joule agents connect to third-party applications, other agents, databases and the web. What the pages reviewed do not document is the outbound side: the identity an agent uses in a third-party system, what it carries from an SAP record into the call, and how content returned from outside is kept from steering the agent. Those three gaps are the three risks, and SAP's authorization model does not reach any of them. The test is to name one agent and one outbound connection and ask who provisioned its credential, what it carried across on the last run, and what would happen if a field on the far side contained an instruction.

Frequently asked questions

Do SAP authorizations protect data once a Joule agent calls a third-party system?

No. SAP states that Joule honors existing permissions, and that governs what the agent reads in SAP. Once the agent calls out, what it can do in the third-party system is decided by the credential the connection uses, and what it carries across is decided by the agent's design. The SAP roles that limited the agent inside S/4HANA have no effect in a procurement platform or a logistics provider's system, and each of those systems needs its own review.

What does the Agent Hub secure?

SAP's interoperability course describes inbound A2A requests routing through Joule via the Agent Hub, which enforces authentication and authorization. It is the gate for requests arriving from other agents. The same material describes A2A as primarily used for outbound communication and states that specific token or credential handling is not documented, so the Hub should not be read as a control on what a Joule agent does when it is the caller.

Why does SAP prefer A2A over direct MCP exposure?

The Architecture Center cites enterprise-grade security, governance and controlled access to SAP systems. Routing requests through an agent lets SAP's controls apply, whereas exposing SAP functions directly as MCP tools lets any MCP client call them. The preference protects the SAP side. It does not address what a Joule agent does as an MCP or A2A client of someone else's system, which is where the risks on this page sit.

How does prompt injection reach a Joule agent through a connection?

Through content the agent reads on the far side. A supplier editing its own profile, a note in a logistics system, or a web page can contain text that reads like an instruction. Research since 2023 has shown that such text can redirect an LLM-integrated application. An agent holding SAP authorizations and third-party credentials is a valuable target, and an injected instruction to change a supplier's bank details would be permitted by SAP if the user is authorized to make the change.

What is data spillover in this context?

Data read legitimately in one system appearing in another through an agent authorized in both. A Joule agent that reads a supplier record and then calls a procurement platform may include bank details in the call because nothing told it to omit them. Spillover also runs backward: over-scoped third-party data comes into the agent's context and may be written into SAP or the next call. Each connection widens the set of systems that share one reader.

What is the first control to put in place?

A connection inventory with a permission review per connection, done in each third-party system's terms, since the SAP authorization report does not cover them. Record the identity each connection uses, who provisioned it and what it can reach. Then obtain the outbound requests for one task and check which SAP fields they carried. Those two exercises reveal most of the exposure before any technical control is chosen, and they produce the inventory every later control will depend on.

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.