Reviewing SAP Joule agents — BTP integration and the A2A protocol surface

SAP's own reference architecture describes governed Joule agent execution running through controlled tools, BTP integration services, and SAP business systems — with BTP providing the integration, security, API exposure, custom logic, and operational controls that connect an agent to enterprise systems. Interactions are secured through SAP Cloud Identity Services, role-based access control, and audit logging via SAP Cloud ALM.

Concretely: if a pro-code agent connected to Joule is built on CrewAI, the review questions in reviewing CrewAI deployments apply to that agent directly — SAP BTP's controls don't retroactively add auth, audit logging, or sandbox isolation to a framework that doesn't ship them by default. The A2A connection point is where governance responsibility hands off, and a review needs to know exactly where that line sits for a given integration.

No CVE has been disclosed against Joule itself. A real, sourced precedent exists one layer down, and it's worth citing precisely: Wiz Research's 2024 “SAPwned” disclosure found cross-tenant isolation failures in SAP AI Core — the shared training/inference infrastructure underneath SAP's broader AI stack — that allowed arbitrary code execution, access to other customers' AI training data and cloud credentials, and even cluster-admin access to SAP AI Core's own Kubernetes cluster. The root cause was familiar: malicious models or training procedures could run without adequate sandboxing. SAP patched it in May 2024 and stated no customer data was confirmed compromised.

This isn't a Joule vulnerability, and shouldn't be cited as one — it's dated, and it hit a different (if related) part of SAP's AI infrastructure. What it establishes is that the class of failure a review should be alert to — shared multi-tenant AI infrastructure with an isolation gap between customers — has real precedent at SAP specifically, not just as an abstract risk category.

Across its published agent-building scenarios, SAP converges on a consistent set of principles worth using as review criteria directly: narrow intent boundaries (an agent should be scoped to a specific business task, not a general-purpose assistant), controlled system access, explicit confirmation for consequential actions, and testing against real user variation rather than a narrow happy-path script.

SAP's documented confirmation mechanism is more specific than a generic approval button: it uses confidence-based routing and “smart escalation by exception type,” with timeout handling for a human who doesn't respond, and — a detail worth checking in any real deployment — the agent's full execution state is preserved during the pause, so approval resumes the exact in-progress task rather than restarting it. Separately, SAP Cloud ALM's standard tier ships with only a 24 GB / 30-day fair-use retention baseline for observability data — a real, concrete gap for any AI Committee or audit function that expects multi-year retention of agent decision logs by default.

For any SAP-connected agent deployment, a design-time review should be able to answer:

• Is this a governed Joule agent, a pro-code agent connected via A2A, or both — and is that distinction documented per deployment?
• For pro-code agents, which underlying framework is it built on, and has that framework's own review checklist been applied?
• What does SAP Cloud ALM's audit log actually capture for this agent's actions, and who reviews it?
• Which of the agent's actions require explicit confirmation, per SAP's own “consequential actions” principle — and is that list current?
• Does the AI Committee's expected audit-log retention window actually match SAP Cloud ALM's default 24 GB / 30-day fair-use baseline, or does it need an upgraded retention tier?