Everyone is demoing agents that post journal entries, approve POs, and reconcile accounts in seconds. Almost none of them can tell an auditor, six months later, exactly why the agent did what it did — and that gap, not the model’s intelligence, is what decides which agents survive contact with production.
The wrong question
The question every SAP steering committee asks is “what can Joule automate first?” That’s backwards. The right question is “what can Joule prove it did, and undo, if it’s wrong?” SAP’s own autonomous-enterprise architecture is built around that reframing: govern every agent as an identity with scoped permissions, continuous observability, and a documented lifecycle — not a script that fires and forgets. The SAP AI Agent Hub exists as a control plane precisely because policy documents don’t survive contact with 300 agents; only a registry with enforced identity, evaluation gates, and revocation does. That’s the tell. SAP isn’t building agent governance because it’s good practice. It’s building it because auditors will not sign off on anything else.
What SAP actually shipped
Strip away the keynote language and three concrete mechanisms remain. First, agent identity: every Joule agent gets a verifiable principal via SAP Cloud Identity Services rather than borrowing a human’s session, with session-level observability logging every prompt, tool call, and handoff. Second, a lifecycle model — proposed, evaluated, approved, active, retired — that functions as a procurement gate rather than a one-time sign-off, with evaluation required before an agent moves stages. Third, full action-logging: the audit trail captures every call, parameter, and decision, down to which data snapshot informed a given output, so a later finance audit can reconstruct the reasoning, not just the result. SAP’s own materials are blunt about why: governance has to run at the speed of autonomous execution, not just development. That names the real failure mode — governance calibrated for human-speed mistakes, applied to machine-speed action.
The SoD problem nobody wants to say out loud
Here is the uncomfortable mechanic. Joule, by default, inherits the invoking user’s authorizations — it does not get its own restricted role unless someone deliberately builds one. So a controller who holds both vendor-master-create and payment-approval access — a classic segregation-of-duties conflict that has survived for decades only because no human creates a vendor and approves its first payment in the same six seconds — now has an agent that can execute both sides at machine speed. The “practical difficulty” compensating control that much of internal audit has quietly relied on evaporates the moment that person can just ask an agent. The fix isn’t a policy memo; it’s structural: every agent gets its own identity, never a reused human credential; AI-only minimum-privilege roles that are blocked from human assignment; every execution gated behind a human approval token in workflow; and every agent identity run through GRC access-risk analysis exactly like a human user, with a correlation ID tying each action back to the approving human.
GRC catches up — barely
SAP GRC for HANA 2026, the unified successor to Access Control 12.0, reached early-adopter shipment on 6 March 2026, with general availability ramping through the second half of the year (Access Control 12.0 mainstream maintenance ends 31 December 2027). It adds AI/ML-driven access reviews that analyse usage patterns, SoD baselines, and peer-group norms to flag anomalous or unused permissions, plus conversational access requests through Joule. That’s progress — but note the sequencing problem: this generation governs human access reviews augmented by AI. It does not yet treat an agent’s own authorization footprint as a first-class risk object the way a named employee’s is. Its rule-set simulation sandbox is a real improvement for modelling SoD changes before production, but it was designed for human role design, not for scoring what happens when an autonomous agent inherits a role. Consultancies deploying agents today are, in effect, building the missing layer themselves — agent identity in Cloud Identity Services, minimum-privilege roles scoped to the agent, GRC risk analysis run against that identity — ahead of the tooling.
The regulation makes this non-optional
The EU AI Act’s high-risk obligations under Annex III — which explicitly cover AI in employment, access to essential services, and critical decisions — reach full enforcement on 2 August 2026. Article 12 requires record-keeping precise enough to attribute a specific action to a specific system instance, not merely to a shared service account — a direct problem for any finance function running several agent instances off one credential. Article 14 requires human oversight that is effective, not decorative: overseers must understand the system’s limits, correctly interpret its output, and be able to intervene or halt it. Penalties for breaching high-risk requirements reach up to €15 million or 3% of worldwide annual turnover, whichever is higher (rising to €35 million or 7% for prohibited practices). For a GCC-headquartered enterprise with EU staff, vendors, or subsidiaries — or a North American firm with EU operations — this is not a European footnote. It’s a binding constraint on how any SAP agent touching finance, HR, or procurement can be built from here on.
The position: earn write access, don’t demo it
Put the threads together and the design principle is obvious, even though almost nobody follows it. Auditors do not approve what performs well in a steering-committee demo. They approve what they can reconstruct after the fact and revoke within a defined window — the exact criteria embedded in SAP’s action-logging model and the Act’s instance-level attribution requirement. A read-only agent that recommends a journal entry, cites its sources, and waits for a human click clears both bars trivially: nothing was changed, so there’s nothing to reconstruct, and no write occurred, so there’s nothing to revoke. A bounded-autonomy agent posting below a threshold clears neither — unless you’ve already built agent identity, SoD screening, and immutable logging underneath it. Most enterprises are trying to build the write-capable agent first and back-fill the governance. That ordering guarantees an audit finding. The faster route to production is the opposite: build the governance ladder first, and let write privileges climb it as evidence accumulates.
A staged rollout an auditor will actually sign
Four rungs, and no agent skips one:
- Read — the agent queries S/4HANA, BTP data products, or GRC risk data and returns findings only; zero write scope, identity provisioned but permission-scoped to display/query transactions.
- Recommend — the agent drafts the journal entry, PO change, or access decision and routes it to a named human via workflow, with the full reasoning chain and tool-call log attached to the request, not buried elsewhere.
- Post-with-approval — the agent executes only after an explicit approval token from a human whose own access has been screened by GRC against the agent’s proposed action, closing the SoD gap rather than assuming it away.
- Bounded autonomy — the agent posts unsupervised only within pre-agreed dollar thresholds, transaction types, and time windows, with mandatory post-hoc sampling review and an automated, tested revocation path that can suspend the agent’s credential in minutes, not days.
Each rung requires the same four artifacts before promotion: a unique agent identity in Cloud Identity Services, an SoD risk analysis run through GRC against that identity, a complete action log tied to a correlation ID, and a documented, exercised revocation procedure. An agent that cannot produce all four does not advance — regardless of how well it performed in the pilot. That’s the discipline that gets agents into production and keeps them there through the next audit cycle, instead of becoming the finding that ends the program.
### Sources – SAP Learning — Planning and executing complex business scenarios with AI agents (Joule Studio): https://learning.sap.com/courses/introducing-joule-studio-in-sap-build/planning-and-executing-complex-business-scenarios-with-ai-agents – IgniteSAP — SAP AI Agent Hub and Agent Governance: https://ignitesap.com/sap-ai-agent-hub-and-agent-governance/ – SAP Community — Securing SAP Agentic AI for the Autonomous Enterprise: https://community.sap.com/t5/technology-blog-posts-by-sap/securing-sap-agentic-ai-for-the-autonomous-enterprise/ba-p/14349147 – SafePaas — SAP Authorisation Best Practices: Avoiding Segregation of Duties Conflicts: https://www.safepaas.com/blog/sap-authorisation-best-practices-avoiding-segregation-of-duties-conflicts/ – SAP Community — SAP GRC for HANA 2026: Unified Successor for SAP Access Control 12.0: https://community.sap.com/t5/enterprise-resource-planning-blog-posts-by-sap/sap-grc-for-hana-2026-unified-successor-for-sap-access-control-12-0-sap/ba-p/14200964 – EU AI Act — Article 14: Human Oversight: https://artificialintelligenceact.eu/article/14/ – EU AI Act — Article 99: Penalties: https://artificialintelligenceact.eu/article/99/