Every time you ask Joule a question, your request passes through multiple layers of security, each one independently verifying, isolating, and constraining what happens. Here's what that journey looks like from the inside
Every Joule request flow through two core runtime layers: the Orchestration Runtime, where scenarios are resolved and reasoning happens, and the Execution Runtime, where Joule Functions run. The sections below trace your request through these layers, and the security controls that travel with it.
1. At the Front Door – Proving Who You Are
The moment you interact with Joule; your identity is verified through OAuth2 via SAP Identity Authentication Service. A signed token is issued, and this isn't a one-time check. Every single service in Joule's pipeline independently re-validates that token.
Layer: Runtime Entry
2. Everywhere – Controls That Follow Your Request Across All Layers
Some security controls aren't tied to a single layer; they're enforced uniformly at every boundary your request crosses.
Your identity is re-verified at every hop. All inter-service communication uses mutual TLS (mTLS), both sides of every connection prove their identity. There is no “trusted internal zone.” Whether your request is at the runtime entry, orchestration, or execution layer, the service handling it independently validates your authentication token and the calling service's certificate. This creates a zero-trust internal mesh.
Your data is isolated from every other customer's. Each tenant's data lives in its own isolated database schema, Joule cannot query across tenant boundaries. Conversation identifiers are cryptographically derived, making them impossible to guess or enumerate. Your conversations, context, and business data are unreachable by any other customer on the platform.
Applies to: All layers
3. Routing Your Request – Only What You're Allowed to Invoke
Once authenticated, your request reaches Joule's orchestration layer. Before any AI processing begins, your available scenarios are filtered.
Joule supports role-based access to AI scenarios, capability developers define visibility conditions that restrict which scenarios are available to which users. These conditions can be based on navigation authorizations or identity attributes from the user's authentication token. A finance analyst and a warehouse manager see different Joule scenarios, enforced server-side, not by hiding UI elements.
Layer: Orchestration Runtime
4. Safer Conversations – Filtering Harmful Content
Joule's reasoning runs through large language models accessed via SAP's centralised AI orchestration platform. That platform brings a content-safety layer with it, and Joule turns it on by default.
The filter screens AI inputs and outputs for harmful content and operates on both sides of the model:
– Before your message reaches the LLM, the input is checked.
– Before any model-generated text returns to you, the output is checked.
The platform attaches the filter automatically when an AI call is made. Capability developers don't have to remember to switch it on; safety is the default path.
By consolidating on a centrally managed safety service rather than per-team guardrails, Joule benefits from continuous improvements to the underlying classifiers without every capability needing to change its own code.
Layer: Orchestration Runtime
5. Taking Action – The AI Can't Run Wild
When Joule resolves your request into a backend action such as querying an SAP system, updating a record, running a calculation, etc. that action executes inside a hardened sandbox:
– Expression sandbox: only pre-approved operations can execute. Arbitrary code is structurally impossible; the sandbox uses a strict allowlist of permitted types and methods.
– Template engine: scripting is limited to template logic, not general-purpose computation. The engine evaluates structure, never executes code.
– Resource governors: execution timeouts, response size caps, and iteration limits prevent any single action from consuming unbounded resources.
Even in an adversarial scenario, the execution environment constrains what can physically happen, code execution and resource exhaustion are architecturally prevented.
Layer: Execution Runtime
6. Reaching Backend Systems – Only Where You've Approved, Only What You Can See
Joule doesn't have open network access. All outbound connectivity is routed through a fixed, admin-configured allowlist of approved hosts. Combined with IP-range blocking, this means:
– Joule can only communicate with systems your organisation has explicitly permitted
– No AI-generated URL or parameter can redirect connectivity to an unapproved host
When Joule does reach a backend system, it acts “as you”, not as a privileged service account.
Backend calls use principal propagation, meaning your existing authorization rules are enforced by the backend itself. If you can't access a purchase order in SAP directly, you can't access it through Joule either.
Your administrators control the network boundary. Your backend controls the data boundary. Joule inherits both.
Layer: Execution Runtime
7. The Response – Secure All the Way Back
The response travels back through the same authenticated, encrypted service mesh. Every hop is mTLS-protected, every service re-validates the request context, and tenant isolation ensures your response data never intermingles with another customer's pipeline.
Security by Architecture, Not by Afterthought
Joule wasn't secured after the fact – security is built into how requests flow through the system. Identity is verified at every boundary. Data is isolated at the infrastructure level. Code execution is sandboxed by design. Network access is bounded by admin policy.
The result: an enterprise AI assistant where security isn't a layer on top, it's the architecture itself.
